[48566] in North American Network Operators' Group
Re: Bogon list
daemon@ATHENA.MIT.EDU (Greg A. Woods)
Fri Jun 7 12:55:51 2002
From: woods@weird.com (Greg A. Woods)
To: "Stephen J. Wilcox" <steve@opaltelecom.co.uk>
Cc: Stephen Griffin <stephen.griffin@rcn.com>,
"Sean M. Doran" <smd@clock.org>, nanog@merit.edu
In-Reply-To: <Pine.LNX.4.21.0206071021520.28920-100000@staff.opaltelecom.net>
Reply-To: nanog@merit.edu (North America Network Operators Group Mailing List)
Date: Fri, 7 Jun 2002 12:55:08 -0400 (EDT)
Errors-To: owner-nanog-outgoing@merit.edu
[ On Friday, June 7, 2002 at 10:26:53 (+0100), Stephen J. Wilcox wrote: ]
> Subject: Re: Bogon list
>
> RFC1918 does not break path-mtu, filtering it does tho..
So, in other words inappropriate use of RFC 1918 does not break Path MTU
Discovery! You can't still have your cake and have eaten it too. One
way or another RFC 1918 addresses must not be let past the enterprise
boundaries. Lazy and/or ignorant people don't always meet all the
requirements of RFC 1918, but it's only their lack of compliance that
_may_ allow Path-MTU-discovery to continue working for their networks
for _some_ people _some_ of the time.
However any enterprise also using RFC 1918, but using it correctly (or
customers of such an enterprise), and thus who are also carefully
protecting their use from interference by outside parties, will be
filtering inbound packets with source addresses in the RFC 1918 assigned
networks, and so as a result they _will_ experience Path-MTU-discovery
failure (i.e. at any time it's necessary it literally cannot work) when
attempting to contact (and sometimes be contacted by, depending on the
application protocol in use) any host on or behind the lazy and/or
ignorant operator's network(s).
(and no, I'm not sorry if I've yet again offended anyone who might be
mis-using RFC 1918 addresses for public nodes -- you should all know
better by now! How many _years_ has it been?)
> > 2) Not believe in filtering RFC1918 sourced traffic at enterprise boundaries
> > (of which an exchange would be a boundary)
>
> What for? You'll find many more much more mailicious packets coming from
> legit routable address space.
If you have any IP address level trust relationsips on your internal
LANs then you _MUST_ (if you want those trust relationships to be valid)
filter all foreign packets with source addresses appearing to be part of
your internal LANs.
> For p2p you can use unnumbered.. it wont work on exchanges but i agree
> they shouldnt be rfc1918.
On this we can agree! :-)
--
Greg A. Woods
+1 416 218-0098; <gwoods@acm.org>; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>
