[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?)


> 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.


> 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.


IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6