So, the question is about either using identifiers that sometimes are also locators vs. using identifiers that never are locators.
Now, if we use identifiers that are never locators, the situation seems to be semantically simple to me.
Maybe in theory. In practice, when you see a 128 bit value in a place where you would expect an IPv6 address, you not only want to know whether it's an identifier or a locator (this part would be easy) but also if it's used in the context of multihomed communication or in the context of single homed communication. That's the hard part. It should be possible to make the three (legacy, id and loc) not overlap, but that doesn't solve all potential problems. For instance, when a group of hosts participate in a group session, the multihoming aware hosts would probably exchange the identifiers to new group members, but if a host that doesn't support multihoming receives a reference to an identifier, it can't do anything useful with it.
On the other hand, if we use identifiers that are sometimes also locators, I'm afraid of semantic confusion. How do you know if a given identifier can be used as a locator or not?
You can either assume the identifier is a reachable locator (having the identifier be an _unreachable_ locator isn't very smart) and use it. This is what non multihoming aware systems will be doing anyway. Or you can look up the identifier in the mapping database to get the full set of locators.
What I'd like to see is doing #1 first, and only do #2 when #1 doesn't work. But if you don't like the ambiguity of having an identifier that may or may not be a locator, stamp on the letters "ID" in large type in a bright color and only use values that you encounter in an identifier context only as id. Then do the locator lookup when you need locators. The fact that a locator happens to be the same 128 bit value as your identifier shouldn't matter.
The reason why some people seem to dislike non-locator identifiers is that they may be hard to be used for referral. That is, if you send just an non-locator identifier to another host in an p2p kind of application, that other host may not be able to use the identifier to contact the host. I think this concern is a consequence of less than perfect understanding of the situation.
No, it's a backward compatibility issue, as I described above.
[Sidenote: Taking another angle, we could even define that an identifier is always a <public key, DNS name, signature> triplet. In that way we would have identifiers that are both secure (without a PKI) and resolvable.]
The usefulness of public key mechanisms for authentication is that it moves the authentication checks largely offline: you can see if someone is who they claim to be without having to contact some kind of authority. Using these mechanisms in cases where the availability of an authority can be assumed (i.e., when you can look the whole thing up in the DNS) doesn't make much sense to me.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
