You are correct in that there is nothing a-priori magical about RFC1918 addresses. "If you route them, they will pass". This is why one shouldn't make security assumptions about using "unrouteable" address space. It is no more or less secure than the routers leading to the network. 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. But perhaps it would work if everyone accepted rfc1918 sourced packets. However this isn't the case either. So I think it is safe to assume that PMTU is broken whenever RFC1918 networks are touched. --Dean At 12:08 PM 10/16/98 -0700, I Am Not An Isp wrote:
At 01:12 PM 10/16/98 -0400, tvo wrote:
Doesn't this break MTU path discovery though?
No, it wouldn't. Those addresses are not routable on the global 'Net, however, there is nothing stopping a device with an RFC1918 address from sending a packet onto the 'Net.
Assume you have a T1 between two routers, but you are out of 'normal' addresses. So you make the two serial ports 10.1.1.1 and 10.1.1.2. Simple, huh? Well, anyone outside your network attempting to reach those addresses will fail - there is no route to 10.x.x.x on the Internet. (At least not in *my* network. :) Let's further assume there's a LAN on the other side of this T1 with a MTU below 1500 bytes. Now, when you attempt PMTU discovery to a device on that small MTU LAN (going through the T1 of course), what happens? When the router on the opposite end of the T1 gets the packet, it sees that the packet is "too big" and DF bit is set (as per PMTU rules) and cannot send the packet. So what should it do? Why send an ICMP "Datagram Too Big" error message, of course. (Type 3, "Destination Unreachable", Code 4, "fragmentation needed and DF set". See RFC 1191, http://www.pmg.lcs.mit.edu/cgi-bin/rfc/view-plain?number=1191, and RFC 792, http://www.pmg.lcs.mit.edu/cgi-bin/rfc/view?792, for more info.) Just like any other (properly functioning) router on the Internet. But what's the source address? Why 10.1.1.1 of course. So you get a packet from RFC1918 space. Perfectly normal, perfectly acceptable, perfectly legitimate.
See, when a router gets a packet, it does not look at the source IP for routing info. (Unless you're doing something weird like policy routing.) So the source IP is irrelevant to a router. Hell, even the destination IP is irrelevant as long as it's 32 bits and matches something in the router's table (including a possible default route). I have never seen a router vendor treat a packet with RFC1918 space in source or destination any differently than any other packet. Unless, of course, the user manually modifies the default behavior with filters or something - which can be done to any address just as easily.
The point is, there is magical router fairy looking for RFC1918 space and removing all those packets from your network. Those addresses are treated by your router just like *any other address*. Forwarded, filtered, whatever depending upon the rules you set up and the information it receives dynamically.
I hope that explains everything.
TTFN, patrick
I Am Not An Isp www.ianai.net "Think of it as evolution in action." - Niven & Pournelle
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++