Well, that is all fine and well if the device with the RFC1918 address is the one screaming "Too Boocoo!" but if it's some other box trying to tell it that the packets are too bug, no dice. Non-routable address. ------- John Fraizer (tvo) | __ _ The System Administrator | / / (_)__ __ ____ __ | The choice mailto:tvo@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste... On Fri, 16 Oct 1998, 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