North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Maybe I'm misreading this but...

  • From: tvo
  • Date: Fri Oct 16 18:08:51 1998

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:[email protected]        |  / /__/ / _ \/ // /\ \/ / |  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
>