North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Maybe I'm misreading this but...
Sorry. I stand corrected. --Dean At 02:00 PM 10/16/98 -0700, I Am Not An Isp wrote: >At 04:37 PM 10/16/98 -0400, Dean Anderson wrote: > >>But Path MTU discovery is a bit more complicated. I'm not looking at any >>docs at the moment, so I hope I'm not completely wrong about this, but as I >>recall the discovery process tries to send packets to each hop. First >>discovering the route path, and then trying to determine the mtu of each >>hop. While the intermediate RFC1918 addresses can reply to things they >>happen to get, you can't directly send a packet to them to see if they will >>want to fragment it. > >This is incorrect. From RFC1191, which can be found at >http://www.pmg.lcs.mit.edu/cgi-bin/rfc/view-plain?number=1191, page 2, >section "2. Protocol overview": > ><quote> > The basic idea is that a source host initially assumes that the PMTU > of a path is the (known) MTU of its first hop, and sends all > datagrams on that path with the DF bit set. If any of the datagrams > are too large to be forwarded without fragmentation by some router > along the path, that router will discard them and return ICMP > Destination Unreachable messages with a code meaning "fragmentation > needed and DF set" [7]. Upon receipt of such a message (henceforth > called a "Datagram Too Big" message), the source host reduces its > assumed PMTU for the path. ></quote> > >So, as I stated in my last post, it will work unless you filter RFC1918 >space. I've received lots & lots of replies saying "I filter it", or "I >RFC1918 in my own LAN, so the firewall drops the packets assuming they are >spoofed" or stuff like that. This is fine, and possibly even desirable. >However, there is nothing to distinguish a packet with RFC1918 space as the >source address from any other "legal" packet on the 'Net other than your >own administrative policies - which can break *anything* on the 'Net, not >just PMTU with RFC1918 space. Sorry, but I have no control over your >policy. So, if someone asks "does this break...", the answer is no. > >> --Dean > >TTFN, >patrick > >I Am Not An Isp >www.ianai.net >"Think of it as evolution in action." - Niven & Pournelle > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc [email protected] LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|