It looks like that we are speaking about different issues.
I was trying to analyse the long term consequences of various practises. I fully agree that we most probably need to have identifiers that are also locators for quite some time. (That's why I think Hinden/Haberman addresses are probably good, even though they act as locators only locally.)
Furthermore, I am not so much concerned about multi-homing. Multi-homing is only one aspect. Remember that I was not posting the message to multi6. There are also other needs for stable end-point identifiers.
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,
I was not really discussing backwards API issues either. If we go for a real separation of locators and identifiers, we will also have to define new APIs in the longer run. And slightly revised transport protocols, too. (I know, the need to revise is actually *a* reason for doing the separation at the transport, e.g. using SCTP. But there are other issues that make a separate layer more attractive, IMHO.)
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.
Sorry, but now I don't understand your thinking at all. Firstly, I still think that if we mix the two, it would be hard to know which one an item is. Secondly, I honestly don't understand why one should see any difference between singly homed or multi-homed communication. It really looks like that we are speaking about really different things.
Would you please clarify?
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.
To me it looks like that you are going back to the current situation, where the locators and identifiers are overloaded.
The reason why some people seem to dislike non-locator identifiers is that they may be hard to be used for referral.
No, it's a backward compatibility issue, as I described above.
I still don't understand. I am sorry, but seemingly I just cannot grasp your reference of thinking.
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.
Indeed...
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.
Firstly, we still don't have secure DNS. Secondly, having to rely on an authority seems like a bad approach to me. At least when compared to one where you don't need to rely on authority. (Just can't resist: Could we compare this to the difference between Aristolean scholastics and Baconian science? :-)
--Pekka Nikander
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
