I Am Not An Isp <patrick(a)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
