| Messy traceroutes make the helpdesk phone ring. Messy architecture is worse! There's two ways to deal with the "messy traceroute problem": 1. looking glasses - use them to compare traceroutes, point people at them, couple them with ample notes on how to interpret the results of multiple traceroutes launched from a variety of sources utility & education leads to wisdom, and away from "nuisance" phonecalls. everyone wins. 2. if you'd rather stem the tide of calls without helping your users much, break traceroute. a/ make it not work in practically all cases on the grounds that the catharsis of its spurious reputation as a powerful diagnostic tool is LONG overdue b/ intercept low-ttl packets and return them with "better" information some MPLS people have documented ways to do this, even it works, although if you do it some ways, you generate media attention. check your nanog records 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.
On Tuesday, June 4, 2002, at 07:49 , Sean M. Doran wrote:
| Messy traceroutes make the helpdesk phone ring.
Messy architecture is worse!
Agreed. An inconsistent architecture is a messy one. Why treat exchange subnets differently to any other bit of backbone infrastructure? Why number point-to-point links with even locally-unique addresses? Slashdot readers wielding traceroute can make an annoying pain in the side of your head, but traceroute and ping are not without their uses. Ask people who are cursed with running poorly-documented X.25 networks (surely there must be some left) how nice it would be to be able to map the network in-band. Ask them why they don't have any hair left, while you're at it.
There's two ways to deal with the "messy traceroute problem":
[messier 1]
[messier 2]
You don't need to deal with the messy traceroute problem if your consistent and clean architecture doesn't happen to make traceroute mess :) Joe
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.
On Thu, Jun 06, 2002 at 06:34:48PM -0400, Stephen Griffin wrote:
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. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
On Thu, 6 Jun 2002, Stephen Griffin wrote:
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
In any event, exchanges are inter-enterprise, and shouldn't be RFC1918.
[ 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! :-) -- Greg A. Woods +1 416 218-0098; <gwoods@acm.org>; <g.a.woods@ieee.org>; <woods@robohack.ca> Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>
Well, the biggest offender in this respect by far was @home, and you know what happened to THEM... -C On Fri, Jun 07, 2002 at 12:55:08PM -0400, Greg A. Woods wrote:
[ 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! :-)
-- Greg A. Woods
+1 416 218-0098; <gwoods@acm.org>; <g.a.woods@ieee.org>; <woods@robohack.ca> Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>
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 On Fri, 7 Jun 2002, Greg A. Woods wrote:
[ 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! :-)
In the referenced message, Stephen J. Wilcox said:
On Thu, 6 Jun 2002, Stephen Griffin wrote:
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..
sending RFC1918 addressed packets across enterprise boundaries is against RFC1918. RFC1918 states to filter ingress/egress at enterprise boundaries. Hence, filtering RFC1918 addresses is part of RFC1918. Therefore, the use of addresses where they are likely to generate traffic which violates RFC1918, is, well, a violation of RFC1918. This applies regardless of the ICMP error message generated.
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.
Who said anything about malicious? In any event, ICMP error messages are generally useful with a few minor exceptions. Things like Source Quench, unreachables, TTL expired, and Can't Frag (as examples of useful icmp.) <snip>
For p2p you can use unnumbered.. it wont work on exchanges but i agree they shouldnt be rfc1918.
I agree, however, most folks want to see the topology, some just choose to violate RFC1918 in order to do it.
Steve
[ On Friday, June 7, 2002 at 15:28:56 (-0400), Stephen Griffin wrote: ]
Subject: Re: Bogon list
I agree, however, most folks want to see the topology, some just choose to violate RFC1918 in order to do it.
Sometimes even I stoop so low! :-) # bloody rogers routers use these nets for interfaces, # thus we need to allow them for our own traceroutes to work.... # pass in quick proto icmp from 10.0.0.0/8 to 65.48.34.145 group 250 pass in quick proto icmp from 10.0.0.0/8 to 204.92.254.0/24 group 250 pass in quick proto icmp from 192.168.0.0/16 to 65.48.34.145 group 250 pass in quick proto icmp from 192.168.0.0/16 to 204.92.254.0/24 group 250 grrr.... -- Greg A. Woods +1 416 218-0098; <gwoods@acm.org>; <g.a.woods@ieee.org>; <woods@robohack.ca> Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>
participants (8)
-
Chris Woodfield -
Joe Abley -
John Payne -
Richard A Steenbergen -
smd＠clock.org -
Stephen Griffin -
Stephen J. Wilcox -
woods＠weird.com