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

From: "Michel Py" <[email-masked]>
Date: Mon, 15 Sep 2003 18:25:59 -0700

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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------