Re: Maybe I'm misreading this but...
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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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
On Fri, 16 Oct 1998, I Am Not An Isp wrote:
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.
Well, with this definition, I could just decide to start using someone else's address space and if you filter it your policies have broken things, not me. Private address space is intended to be used for networks not directly connected to the Internet. We filter every external link to prevent private addresses flowing in either direction, outside packets claiming to be from our address space, inside packets not coming from our address space (and transit customers), and inside packets going to our address space. Until router CPU or number of filter entries are a problem, it makes sense to make sure everything is what is expected, and to drop anything that isn't. If they really don't want to use up valid addresses for the point-to-point links, why not just run the interfaces unnumbered instead? John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 256/705-7007 - FAX 256/705-7100 Huntsville, AL 35801
If they really don't want to use up valid addresses for the point-to-point links, why not just run the interfaces unnumbered instead?
Well, of course it is useful in a traceroute to see clearly which interface same in through, which you can't tell with unnumbered. I expect that most of the people who do use RFC1918 addresses on their point to point links also resolve those addresses to names on their internal DNS servers to provide an even nicer and easier to debug traceroute. -Phil
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.
That isn't the way it works. In PMTU, each hop *may* send something back to you. In the best case, in fact, where your initial MTU guess is correct, nobody will send you anything. In the worst case, where every link sequentially requires a smaller and smaller MTU, every hop will send something back to you. But you never send out anything except to your ultimate destination.
But perhaps it would work if everyone accepted rfc1918 sourced packets.
Yes. As far as I know, filtering by source address (or policy routing, or source routing, but I mention source address filtering because that is a widespread practice) is the only thing that would prevent PMTU from working properly with private addresses "in the middle". -Phil
On Fri, 16 Oct 1998, 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.
Path MTU discovery works by trying to send packets all the way through to the destination, with the MTU of the first hop. If it receives an ICMP fragmentation needed and DF bit set host unreachable message, it then tries successively smaller packet sizes until it stops getting the destination unreachable messages.
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.
If a router with an IP addrses in RFC1918 space is sending back destination unreachable messages, and somebody along the path is filtering out RFC1918 sourced packets, then it will break PMTU discovery. For that reason, using RFC1918 addresses on large MTU interfaces of routers that also have small MTUs would probably be a bad idea. However, unless there's something I'm not thinking of here, using RFC1918 addresses on a router where all interfaces have the same MTU should not break PMTU discovery. -Steve -- Steve Gibbard WWNet System Administration +1 734 513-7707 x 2009 http://www.wwnet.net
participants (5)
-
Dean Anderson -
I Am Not An Isp -
John A. Tamplin -
Phillip Vandry -
Steve Gibbard