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