moore(_at_)cs(_dot_)utk(_dot_)edu (Keith Moore) wrote on 19.12.00 in
<200012191915(_dot_)OAA09308(_at_)astro(_dot_)cs(_dot_)utk(_dot_)edu>:
agreed, *provided* there is a fast and reliable service for mapping
between one kind of identity and another. arguments of the form
"separate identities are better" tend to gloss over the difficulty
of providing an adequate mapping service.
(Hint: DNS is neither sufficiently fast nor sufficiently reliable)
Hmm, can't resist putting on my brain-storming hat here ...
Let's see: assume we have a map from "who" (endpoint identifier) to
"where" (topology descriptor).
There will probably be a seconf map mapping "where" to "how" (routing
info); this second will certainly be locally different - essentially
traditional routing.
Hmm. If this is to include multi-homing support, the who-where map needs
to be 1:N.
There's a problem with secure updating. I can connect via several
different ISPs, just like a multi-homed host, so preferrably my endpoint
identifier would not "belong" to those ISPs but to me. But then I don't
know the topology information for that map any better than "I just
connected to ISP X". And if that ISP isn't known to all routers globally
(and at least one of them certainly isn't, doesn't even have an AS), then
that information is not sufficient.
So: I need to update the map to say "I just connected to system X", and
there needs to be a secondary map (unless of course the first one can be
reused) that says "system X is in turn connected to system Y, which is
connected to globally known system Z". (Except all of those really are
1:N, not 1:1.)
Now when I want to send a packet, I need to do the equivalent to ARP -
query the map for topology information for the endpoint identifier of the
other side, resolve the next hop via local routing information, and send
it on it's way to the next hop.
And here it gets interesting again. ARP just sends out a broadcast packet.
We certainly don't want anything like that on the global Internet. So the
packet needs to go to a specific destination, and for that to not create a
bootstrapping problem, we'd need to have well-known ways to reach a local
proxy.
Proxy. Hmm. Caching would certainly be necessary. How long? Until someone
on the route says "I can't deliver this"? What about routers in the
middle, how do they find out?
Where does the map live? We'd need to distribute the storage according to
end-point ranges, I think, which means we get endpoint registries. Which
probably need to be globally known (i.e. use special routing table
entries) at least for the highest level, assuming there are several
levels. (Why am I thinking EUI-64?)
This looks possible, but I can see a great many new headaches in actually
getting it operable.
the other problem with separating the layers is that the ability to
drill down through layers is essential for diagnostic purposes,
for tracking down miscreants, and to allow prototyping new kinds
of services that need to operate with knowledge of layer 3. So
we will always have a need for some kinds of "applications" to
operate with knowledge of network addresses.
That seems entirely possible with something like the above.
MfG Kai