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

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


Pekka Nikander wrote:
>> I do understand your point about the benefits of an
>> identifier also being a locator, but I also believe
>> that the benefits of clean separation will more than
>> pay the drawbacks in the long run. (I don't have any
>> analysis or data to support this belief, though.)

Michel Py replied:
> I'd be interested in some vague rationale about this.

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.

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?  If you encode it somehow to the bits, then you
are actually going into the clean separation anyway, and
could can proceed and create distinct APIs, if that is
useful.  If you do not encode the difference into the bits,
then you have to "try" in some way or another.  That is,
you may try to use the identifier as a locator and see
what happens, or use some infrastructure to find out.
These all seem to be complicated.

The reason why some people seem to dislike non-locator
identifiers is that they may be hard to be used for referral.
That is, if you send just an non-locator identifier to
another host in an p2p kind of application, that other
host may not be able to use the identifier to contact
the host.  I think this concern is a consequence of less
than perfect understanding of the situation.

I just want to remind that identification and rendezvous
are different functions.  In my opinion, identifiers
should be used for identification, i.e., to make sure
that the peer is really the end-point that it is thought
to be.  (Hence I also believe that identifiers should be
self-authenticating, i.e., public keys.)   For rendezvous,
we obviously need either a locator or a name that can
be convered into an address.

Given this background, I don't see any immediate drawbacks
from the following approach to referral.  When a host want
to send an end-point identifier to another host, it always
includes either a currently known working address for the
identifier, a name (e.g. DNS name) that can be easily
converted to an address, or both.  Of course, if identifiers
were DNS names, this would always be the case.  On the other
hand, the DNS names do not fulfil the identifiability and
security goals that I have in mind.  Hence, it looks like
that sending an <identifier, address> or <identifier, name>
pair would be a fairly decent practise.

[Sidenote:  Taking another angle, we could even define that
  an identifier is always a <public key, DNS name, signature>
  triplet.  In that way we would have identifiers that are
  both secure (without a PKI) and resolvable.]

--Pekka Nikander

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