even if you do this the end system identifier needs to be globally
scoped, and you need to be able to use the end system identifier
from anywhere in the net, as a means to reach that end system.
DNS is a bright and successfull example of such deal.
actually, DNS is slow, unreliable, and often out of sync with reality.
DNS reverse lookup tables (PTR) are not as well maintained as forward
lookup tables (A) so they're even less reliable.
hosts often don't know their own DNS names, so they wouldn't know
their connection endpoint names either.
DNS names are often ambiguous - because a single DNS name corresponds
to multiple hosts (all implementing the same service) or because a
single host supports multiple DNS domains (a different name for each
service) or both.
the binding between a DNS name and an address is not the same thing
as the binding between an address and a connection endpoint. the
two have different purposes and different lifetimes.
when people say "DNS can do the job" they may be saying different
things, e.g.
(a) they are thinking in terms of using existing DNS servers,
(b) they are thinking in terms of using the DNS protocol, having
translation occur at the boundaries between routing goop realms
(similar to NAT's DNS ALG), or
(c) they are thinking in terms of a DNS-like system, but not DNS
with separate servers (whether they are existing DNS servers or not)
there is the problem of keeping the servers updated as to the
current condition of the network.
with DNS at translation boundaraies there is the problem of
"call setup overhead" (having queries propagate through
multiple layers of translation until they reach their destination
network) also in this case DNS becomes a routing protocol of
sorts, since the thing you advertise from one realm to another
becomes a DNS suffix rather than than an address prefix.
it's not at all clear that this scales.
in either case having to do a DNS-like query before you can transmit
is slow compared to just sending a packet to an IP address.
Keith
p.s. if there's ever going to be a split between endpoint names and
routing goop, I'm convinced that endpoint names have to be usable
by themselves (perhaps with some speed penalty), that the
mapping between endpoint names and routing goop needs to be maintained
by the routing infrastructure rather than in some separate database,
and that the lookup needs to be able to be done implicitly (as a side
effect of sending packets without routing goop to their destination)
rather than explicitly. I think such a separation might be a good idea,
because our current means of propagating reachability information
and computing routes does have limitations. but I don't see any need
to change the packet format seen by hosts (from IPv6), or any need to
change end hosts at all, in order to do this.