On Wed, 22 Jan 2003 03:34:19 +0100 (CET) Erik Nordmark <[EMAIL PROTECTED]> wrote:
] Granted that this is a hard problem, but we seem to be spending emails ] on multiple subsets of this problem (in different WGs) thus I think it ] would be worth-while to concentrate thinking on the identifier/locator ] separation problem. Mumble. If you really want to split identifiers and locators then you need a fast, accurate, scalable, highly available, and robust mapping function between the two. That turns out to be very difficult, especially when you want things to continue working on isolated or ad hoc networks or on networks with intermittent connectivity to the outside world. Even then, there will still be cases where the right thing to do is to talk directly to a locator. And there will also be lots of apps for which a locator is "good enough" that probably shoudn't be made dependent on the mapping service. So I lean towards a view where you can use identifiers or locators interchangably - you can specify an identifier as a connection endpoint if that's what you want, or you can specify a locator, and the higher layer protocols mostly shouldn't care about the difference (though things like TCP might want to know if the locator changes so they can discard RTT estimates and initiate slow-start, and some apps protocols may have a preference as to which to use and may not perform as well if the preferred kind of name is not available). Which further implies that identifiers and locators look a lot like IP addresses. As for identifier-to-locator mapping, I think we'll have to be able to tolerate multiple coexisting mapping systems, one that works with global connectivity, another that works bottom-up. So if your destination happens to be near you, so you can still use the identifier to talk to that host even if the global mapping service is down. Of course, you'll want to verify the authenticity of the host you're talking to in either case - you shouldn't trust the mapping service. And you can use the locator as a last resort. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
