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.
]]