In the referenced message, Sean M. Doran said:
Basically, arguing that the routing system should carry around
even more information is backwards. It should carry less.
If IXes need numbers at all (why???) then use RFC 1918 addresses
and choose one of the approaches above to deal with questions
about why 1918 addresses result in "messy traceroutes."
Fewer routes, less address consumption, tastes great, less filling.
Sean.
Do you:
1) Not believe in PMTU-D
2) Not believe in filtering RFC1918 sourced traffic at enterprise boundaries
(of which an exchange would be a boundary)
3) Not believe packet-passing devices have legitimate needs in contacting
hosts, even if hosts don't have legitimate needs for contacting them? (a
superset of 1, above)
4) All or some of the above?
I would love if RFC1918 were adhered to such that L3 packet-passing devices
either weren't numbered out of those blocks, or allowed what juniper allows
with the ability to select the ip address with which packets sourced by
the L3 packet-passing device sent traffic (other than primary ip on
destination interface). The latter would permit intra-enterprise use
of RFC1918 addresses, while still conforming with RFC1918. Failing that,
use of RFC1918 addresses in places where inter-provider packets get
RFC1918 sources, is a violation of RFC1918.
In any event, exchanges are inter-enterprise, and shouldn't be RFC1918.
Do you:
1) Not believe in PMTU-D
Yes.
2) Not believe in filtering RFC1918 sourced traffic at enterprise
boundaries
Yes.
I would love if RFC1918 were adhered to such that L3 packet-passing
devices either weren't numbered out of those blocks, or allowed what
juniper allows with the ability to select the ip address with which
packets sourced by the L3 packet-passing device sent traffic (other than
primary ip on destination interface). The latter would permit
intra-enterprise use of RFC1918 addresses, while still conforming with
RFC1918. Failing that, use of RFC1918 addresses in places where
inter-provider packets get RFC1918 sources, is a violation of RFC1918.
Why? Why do you care about your inter-device link IPs other than for
traceroute results? Please, someone tell me another reason why they're
important. 
There are very legitimate reasons for wanting that communication to be
one-way, for example DoS attacks directed at the IPs which show up in
traceroutes. But using RFC1918 IPs is not practical for large networks,
since you can't communicate any DNS information about those IPs.
Even if there was an option to source ICMP from loopbacks (which I
support, the OPTION is nice), I wouldn't use it. The devices along the
path is far less important than the actual path, and you would immediately
lose the ability to see which of multiple circuits is being taken between
two endpoints. Loopbacks are better used for administrative access.
backhoe, nail... ip unnumbered loopback0
In the referenced message, Sean M. Doran said:
> Basically, arguing that the routing system should carry around
> even more information is backwards. It should carry less.
> If IXes need numbers at all (why???) then use RFC 1918 addresses
> and choose one of the approaches above to deal with questions
> about why 1918 addresses result in "messy traceroutes."
>
> Fewer routes, less address consumption, tastes great, less filling.
>
> Sean.
Do you:
1) Not believe in PMTU-D
RFC1918 does not break path-mtu, filtering it does tho..
2) Not believe in filtering RFC1918 sourced traffic at enterprise boundaries
(of which an exchange would be a boundary)
What for? You'll find many more much more mailicious packets coming from
legit routable address space.
3) Not believe packet-passing devices have legitimate needs in contacting
hosts, even if hosts don't have legitimate needs for contacting them? (a
superset of 1, above)
4) All or some of the above?
I would love if RFC1918 were adhered to such that L3 packet-passing devices
either weren't numbered out of those blocks, or allowed what juniper allows
with the ability to select the ip address with which packets sourced by
the L3 packet-passing device sent traffic (other than primary ip on
destination interface). The latter would permit intra-enterprise use
of RFC1918 addresses, while still conforming with RFC1918. Failing that,
use of RFC1918 addresses in places where inter-provider packets get
RFC1918 sources, is a violation of RFC1918.
For p2p you can use unnumbered.. it wont work on exchanges but i agree
they shouldnt be rfc1918.
Steve
Though many people either miss the point or don't care, RFC 1918 is also BCP 5. Last I checked, BCP stood for "Best Current Practice." So you've got a BCP document saying the addresses listed in RFC 1918 should not be present on the public network. So yes, filtering is required by RFC 1918, and so use of the private IP address blocks does break Path MTU discovery. Some folks find the private address space specified in RFC 1918 convenient, but ignore the stipulations on use contained in the same document.
Indeed, and that is one of the reasons why I agree IXPs and P2P should not
use RFC1918
My point was merely that using RFC1918 on links does not break P-MTU,
whether it should be used or not was another question...
Steve
[ On Friday, June 7, 2002 at 10:26:53 (+0100), Stephen J. Wilcox wrote: ]
Subject: Re: Bogon list
RFC1918 does not break path-mtu, filtering it does tho..
So, in other words inappropriate use of RFC 1918 does not break Path MTU
Discovery! You can't still have your cake and have eaten it too. One
way or another RFC 1918 addresses must not be let past the enterprise
boundaries. Lazy and/or ignorant people don't always meet all the
requirements of RFC 1918, but it's only their lack of compliance that
_may_ allow Path-MTU-discovery to continue working for their networks
for _some_ people _some_ of the time.
However any enterprise also using RFC 1918, but using it correctly (or
customers of such an enterprise), and thus who are also carefully
protecting their use from interference by outside parties, will be
filtering inbound packets with source addresses in the RFC 1918 assigned
networks, and so as a result they _will_ experience Path-MTU-discovery
failure (i.e. at any time it's necessary it literally cannot work) when
attempting to contact (and sometimes be contacted by, depending on the
application protocol in use) any host on or behind the lazy and/or
ignorant operator's network(s).
(and no, I'm not sorry if I've yet again offended anyone who might be
mis-using RFC 1918 addresses for public nodes -- you should all know
better by now! How many _years_ has it been?)
> 2) Not believe in filtering RFC1918 sourced traffic at enterprise boundaries
> (of which an exchange would be a boundary)
What for? You'll find many more much more mailicious packets coming from
legit routable address space.
If you have any IP address level trust relationsips on your internal
LANs then you _MUST_ (if you want those trust relationships to be valid)
filter all foreign packets with source addresses appearing to be part of
your internal LANs.
For p2p you can use unnumbered.. it wont work on exchanges but i agree
they shouldnt be rfc1918.
On this we can agree!
Well, the biggest offender in this respect by far was @home, and you know what
happened to THEM...
-C
Indeed, you should filter ingress packets with your own addresses for
security and as you say using non globally unique addresses will therefore
cause it to break pMTU.
I concede!!
Steve