Pekka Nikander wrote:
I do understand your point about the benefits of an identifier also being a locator, but I also believe that the benefits of clean separation will more than pay the drawbacks in the long run. (I don't have any analysis or data to support this belief, though.)
Michel Py replied:
I'd be interested in some vague rationale about this.
So, the question is about either using identifiers that sometimes are also locators vs. using identifiers that never are locators. If we could use identifiers that are always also locators, we would not need this discussion at all; the current IP addresses should do well.
Now, if we use identifiers that are never locators, the situation seems to be semantically simple to me. An identifier identifies a (potential) end-point of communication. However, it alone is not enough for communication. You also need to get the locator (the address), in some way or another.
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? If you encode it somehow to the bits, then you are actually going into the clean separation anyway, and could can proceed and create distinct APIs, if that is useful. If you do not encode the difference into the bits, then you have to "try" in some way or another. That is, you may try to use the identifier as a locator and see what happens, or use some infrastructure to find out. These all seem to be complicated.
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.
I just want to remind that identification and rendezvous are different functions. In my opinion, identifiers should be used for identification, i.e., to make sure that the peer is really the end-point that it is thought to be. (Hence I also believe that identifiers should be self-authenticating, i.e., public keys.) For rendezvous, we obviously need either a locator or a name that can be convered into an address.
Given this background, I don't see any immediate drawbacks from the following approach to referral. When a host want to send an end-point identifier to another host, it always includes either a currently known working address for the identifier, a name (e.g. DNS name) that can be easily converted to an address, or both. Of course, if identifiers were DNS names, this would always be the case. On the other hand, the DNS names do not fulfil the identifiability and security goals that I have in mind. Hence, it looks like that sending an <identifier, address> or <identifier, name> pair would be a fairly decent practise.
[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.]
--Pekka Nikander
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
