|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Bogon list
[ 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; <[email protected]>; <[email protected]>; <[email protected]> Planix, Inc. <[email protected]>; VE3TCP; Secrets of the Weird <[email protected]>
|