On maandag, sep 15, 2003, at 13:26 Europe/Amsterdam, Pekka Nikander wrote:
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.)
We may indeed be talking about different aspects of this huge multi-faceted problem/opportunity.
I think unique local addresses can make for good identifiers that are also locators, but only if you make the assumption they're only used as reachable legacy addresses or locators if there is nothing else available. If you're not going to be able to reach the identifier as a locator, your _really_ want to know that immediately so you can proceed to do a locator lookup rather than first timeout on a single homed compatible connect. This implies that when two different organizations merge their networks clients will continue to use the PA addresses if these are available. It also means those addresses are of little use for legacy operation.
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.
Like what? :-)
Multihoming is the most pressing problem because there is no good alternative.
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.
Are you sure we won't be seeing IP version number depletion before that?
What exactly do you want to change about the APIs and transport protocols?
(I know, the need to revise is actually *a* reason for doing the separation at the transport, e.g. using SCTP.
Note that SCTP is cool in some regards but it in no way does a locator/identifier separation. Actually SCTP only makes things worse as you now have even more addresses to worry about at the application level.
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.
The question here is whether we're going to see those locators and/or identifiers outside of a locator of identifier context, and, if we do, whether it's important that we can regain such a context.
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.
Not so much multihomed or single homed, but mulithoming (loc/id) aware or non multihoming aware.
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.
Not really. An identifier is fixed, a locator is subject to change. That doesn't mean they can't be the same at one time or another, as long as the value can be changed in the places where it's a locator while it stays the same in the places where it acts as an identifier.
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.
The DNS is secure enough more than 99% of the time.
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.
I agree that the current way of doing it where I go ask some root nameservers to give me a pointer to my neighbor can be pretty pathetic at times. On the other hand it's the only way to find unknown correspondents that makes sense.
(Just can't resist: Could we compare this to the difference between Aristolean scholastics and Baconian science? :-)
Feel free... Me, I'm more of the Cartesian persuasion when it comes to this.
From another message:
I think that most of the threats and much of the solution model would most probably apply also to SCTP ADD-IP and, of course, also other multi-address multi-homing solutions.
You're assuming a view of the world that is very much MIP-inspired. There are other ways to do it. One would be a distributed database where the id->loc mappings are kept for everyone to find, another is setting up shared state at the start of an association and use that to authenticate address jumps. Then, unless you're dealing with a man in the middle, you can be sure you're still talking to the same person as before.
Iljitsch
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
