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

[Dean Anderson <dean () av8 com>]

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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++