| Why treat exchange subnets differently to any other bit of backbone | infrastructure? Oh, I wholeheartedly agree. I would love them all to use RFC 1918 addresses, because it is VERY VERY VERY rare that anything outside the scope in which the 1918 local use addresses are unique actually has to communicate with backbone infrastructure of any type. What communication can your workstation have with an XYZNET router? Can you log into it? Can you talk SMTP to it? How about SNMP? Oh, I know - you can start up a BGP session with it from your desk, right? In short, ping & traceroute are about the only interaction anyone will ever have with a router that is not under their control, excepting error messages (which is the usual way at least traceroute works), and it is NOT WORTH THE ADDRESS CONSUMPTION just to facilitate this. Regrettably, IP sux in the confusing of "where" and "what", so the only way to know who sent you the error ICMP datagram except by the source address. ICMP types that let one encode a handy URL or maybe some text explaining the error and its source would be cool, and if this is regularized, then there's no point in having global address space consumed by things which are only ever going to have interactive sessions with local hosts, and you get to keep your end-to-end diagnostic regime of incredibly useful, reliable and intuitive tools like traceroute and ping. In the absence of new ICMP messages (which really have to be rolled out "everywhere"), redirecting the attention spent on inducing and interpreting them to an in-the-network tool for diagnosing the condition of a LOCAL set of infrastructure is something I think is quite practical. Perhaps a tiny chunk of address space with useful IN-ADDR.ARPA messages would be a good start. : unix ; traceroute abc.defxyz.net symbolic-name (217.31.0.1) 1 ms 1 ms 1 ms symbolic-name.your.provider.net (217.31.10.2) 5 ms 5 ms 5 ms please-see.http.www.smartprovider.net (223.255.255.1) 50 ms 50 ms 50 ms please-see.http.www.smartprovider.net (223.255.255.1) 60 ms 60 ms 60 ms please-see.http.www.smartprovider.net (223.255.255.1) 65 ms 65 ms 65 ms please-see.http.www.smartprovider.net (223.255.255.1) 70 ms 70 ms 70 ms please-see.http.www.smartprovider.net (223.255.255.1) 75 ms 75 ms 75 ms please-see.http.www.otherprovider.net (223.255.255.2) 79 ms 80 ms 79 ms please-see.http.www.otherprovider.net (223.255.255.2) 85 ms 82 ms 98 ms ... (I was kinda thinking it might be fun for someone with some spare address space to offer up a mapping of A.B.HI.LO with HI.LO being the higher and lower order bytes of an AS number, although obviously that's not necessary, and is going to be wasteful, since people like Joe will think this is so abominable, that they won't have their ASes do it :-) ) | Why number point-to-point links with even locally-unique addresses? iBGP hack requires intra-domain connectivity to work, and may sometimes require distinguished interface addresses; eBGP insists on connectivity between peers in same logical subnet except when you break that with intentional use of knobs. SNMP hack requires interactive intra-domain connectivity to work. SSH (and telnet disaster) requires interactive intra-domain connectivity to work. Ping/traceroute/etc originating from route-server host(s) require interactive intra-domain connectivity to work. All these and more may benefit from discretely numbered interfaces. These numbers may be 1918 addresses, or they be kept discreet. You might think this is rather backwards and Victorian, like hiding the legs of tables from prying eyes through the use of extremely long tablecloths. However, there are people who have had funny carpentry done, who might see this as a feature. | Slashdot readers wielding traceroute can make an annoying pain in the | side of your head, but traceroute and ping are not without their uses. No functionality is broken - it's just you get ICMP messages from things you probably cannot connect to in any meaningful way. Big deal, that's what you have now, pace ping. | 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. MPLS cannot cause baldness. That lot all have thick and fuzzy hair, I think. I'll stick with conventional theory and suggest it might be genes or razors. (Are you gonna call NATs&6to4/faith X.75 gateways? Cool!) | You don't need to deal with the messy traceroute problem if your | consistent and clean architecture doesn't happen to make traceroute | mess :) Right, stop replying to things which are obviously or even probably traceroutes. No more traceroute mess. No more idiotic firewall operators complaining about these damn unreachable and exceeded messages. I think I'm in favour, although I have to admit traceroute can be fun. Did you ever see Louis Mamakos's toy? Sean.