Pekka,
> Pekka Nikander wrote:
> 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.
Indeed, this the existing situation; the issue being size and even more
important stability of the GRT.
> 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.
Crystal.
> 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?
[note that I am being the devil's advocate here. I will cc: you on a
related thread on the MHAP list soon, as I will likely adopt the same
line as you but for different reasons].
Please explain me why does knowing matter if the locator and the
identifier have the same semantics? I mean, host A wants to talk to host
B; host A gets host B's {address|identifier} from DNS. Host A sends the
packet to the router with B's {address|identifier} as the destination.
Why should host A care at all if the {address|identifier} is a PA
locator (because B is singlehomed) or a PI identifier?
I can understand the reasoning when the id/loc mapping mechanism resides
in the source host, but not when it resides within the routing system.
There is a huge advantage in terms of bootstrapping the protocol:
imagine you can make a non-HIP host talk to a HIP host and still benefit
from the HIP functionality or some of it.
> If you encode it somehow to the bits, then you are actually
> going into the clean separation anyway.
Indeed; note that I insisted that we keep the "u" bit for the time being
precisely for this reason even though we don't know what to do with it
as of now.
Michel.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
