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