Re: about Wedgelayer 3.5 / Fat IP approaches

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

> Among the multiple approaches that have been included within the 
> Wedgelayer 3.5 / Fat IP class, we can find very different mechanisms 
> imho. I I think that additional discussion is needed to understand 
> which one of the different approaches (not particular solution, but 
> general approach) would better fulfill our needs. the goal of this 
> message is then, to provide my opinion of some of the benefits and 
> limitations of each approach in order to foster discussion of this 
> topic.
> 
> So, as is see it the approaches included within the Wedgelayer 3.5 / 
> Fat IP class use the following types of ULP identifiers:
> - 128 bit long CBIDs (HIP, SIM)
> - CGAs (cb64)
> - Locators (i.e. the use a locators as the ULP id) (NOID, ODT)
> - ephemeral ids (WIMP, MAST?)

What I'm about to write might make things more confusing, but hopefully
also more clear.

I think conceptually we are using identifiers for two different purposes,
but in many (not all) cases the same bit strings serve both purposes.
1. A handle passed to the applications that can be used for things like
    - comparisons
    - callbacks and referrals
2. A thing used inside the multi6 (sub)layer as part of preventing redirection
   attacks.

A current case where they are not the same is in the (now expired) cb64 draft,
where the application sees a 128-bit handle with IP address semantics,
but the multi6 layer uses the 64 last bits as a hash of a public key.
In Santa Monica after the meeting Jukka Ylitalo brought up another interesting 
thing to try; using NOID-style AIDs with WIMP ephemeral IDs underneath.
(Sounds a bit complex to me, but well worth exploring to further our 
understanding in this space.)

Furthermore, we definitely need to be concerned about #1 for existing 
applications. But it migth also make sense to think about applications
that have been modified to be multi6-aware.

For instance, calling the getpeername() API might return what is essentially
a designated locator for the peer, which provides support for unmodified
applications. But we could decide to crate getpeerid() and getpeerlocators()
which would return more information to modified applications.
This might mean that unmodified applications would receive limited 
support for callbacks and referrals when a locator becomes unreachable,
but the modified applications would be robust against such failures.

   Erik