Maybe I'm misreading this but...

Mailman List Mirror (Read Only)
1

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

2

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

3

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

4

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

5

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.

This is getting way out of hand. The original question was "Does this
break PMTU" (paraphrased), to which the answer is "NO". There may or may
not be external factors which, in combination with RFC1918 space, breaks
PMTU. But the answer to the original question is still "no".

Thank you all for pointing out the possible (and even probable) external
factors which may combine to interfere with PMTU in this case.

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?

IMHO, numbered interfaces are easier to deal with and troubleshoot. Not to
mention it keeps people from directly addressing your router ports outside
your own network.

Besides, I just made that example up. Maybe some people do it
intentionally for reasons I haven't though of.

John Tamplin Traveller Information Services

TTFN,
patrick

I Am Not An Isp
www.ianai.net
"Think of it as evolution in action." - Niven & Pournelle

6

I Am Not An Isp <patrick@ianai.net> writes:

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.

except that it is still a violation of RFC1918 to be using them
in that manner, as they clearly excluded from category 1 (by
virtue of being used in transit), and are clearly in Category 3.

      Category 1: hosts that do not require access to hosts in
      other enterprises or the Internet at large; hosts within
      this category may use IP addresses that are unambiguous
      within an enterprise, but may be ambiguous between
      enterprises.

      Category 2: hosts that need access to a limited set of
      outside services (e.g., E-mail, FTP, netnews, remote login)
      which can be handled by mediating gateways (e.g.,
      application layer gateways). For many hosts in this
      category an unrestricted external access (provided via IP
      connectivity) may be unnecessary and even undesirable for
      privacy/security reasons. Just like hosts within the first
      category, such hosts may use IP addresses that are
      unambiguous within an enterprise, but may be ambiguous
      between enterprises.
                
      Category 3: hosts that need network layer access outside
      the enterprise (provided via IP connectivity); hosts in the
      last category require IP addresses that are globally
      unambiguous.

       We will refer to the hosts in the first and second
       categories as "private". We will refer to the hosts in
       the third category as "public".
                     
It's also a violation of RFC1918 to be using them in any way
which will generate packets with those source addresses, which
would mean traceroutes and using PMTU discovery.

  Because private addresses have no global meaning, routing
  information about private networks shall not be propagated on
  inter-enterprise links, and packets with private source or
  destination addresses should not be forwarded across such
  links. Routers in networks not using private address space,
  especially those of Internet service providers, are expected to
  be configured to reject (filter out) routing information about
  private networks. If such a router receives such information
  the rejection shall not be treated as a routing protocol error.

So, if the question is "does using RFC1918 address break PMTU
discovery?" the answer should be "maybe it won't, break it, but
it's supposed to"

Darrell

7

In article <199810162153.RAA25346@merit.edu>,