Re: identity persistence and comparison issues

[Erik Nordmark <Erik.Nordmark@sun.com>]

> Terminology questions: the application would only use the stable (long 
> lived) id, right?

Yes and no.

I see two reasons to be able to isolate the application from the ID
used by the multihoming mechanism:
1. Allow ephemeral IDs by the multihoming mechanism.
2. Allow, perhaps stable, IDs in the multihoming mechanism that can't be
   used for referrals, or that are not 128-bits long (such as the FQDN as
   part of NOID)

For both these reasons you don't want unmodified (non-multi6-aware)
applications to see the internal ID.
But in the case of #2 (and I haven't thought about #1) it might make
sense to allow modified (multi6-aware) applications from
finding the internal IDs as well as the current set of locators which
are used with that ID.

> The ephemeral id is internal to the multi6 layer, and it is not handled 
> by the ULP, right?
> would then this ephemeral id would be an id, or is this simply a key or 
> a token, just as in IPSec or pbk?

In some cases it might be just a context id/context tag (I try to avoid
to use the term "session" since it implies L5 to me),
but in other cases like NOID and HIP it might imply something longer
like a FQDN or a public key.

   Erik