> you immediately need to build a reliable system to map between
> the two - where reliable means: fast, up-to-date, highly
> available, provides repeatable results across the entire
> network.
Many people keep claiming this, but I've yet to see the case clearly
laid out as to why. Let me explain.
If you start with a design which basically replicates the capabilities
of the system we have today, you arrange it so that whatever
transaction (in the loose sense) that provided you with the IPvn
address instead provides you with the locator/identifier pair.
this really only works if the transaction is repeatable (with all of the
usual caveats about precision, reliability, efficiency, and consistency)
by any of the peers that might get the locator/identifier pair, and
might need a different locator (or a change to a locator) at some point.
and this tends to mean that you want to sepearate the step that gets
you the precise endpoint identifier from the step that gets you
locators. of course, if you get an initial set of locators along with
the identifier, this is a useful optimization, but it doesn't mean you
can dispense with the capability to do an identifier->locator mapping in
the future.
Well, that's not a very interesting system, because it just replicates
the capabilities of the system we already have. To make it
useful/interesting, you want to be able to change the binding between
the two.
Well, for many cases of current interest, you can in fact do that
without having a mapping system available. E.g. for multi-homing (done
with multiple addresses), at ICP time the multi-homed entity provides
all of its addresses. Etc, etc - I won't go into all the details now.
this works just fine if all of the addresses always work. it's when one
of the addresses fails to work that it causes problems, especially when
you can't tell whether the addresses returned in response to a
subsequent query really refers to the same host you were talking to, or
just a different host that provided the same service.
Keith