Re: cb64

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

> > But the protocol can still defer the public key operations until the 
> > first
> > locator change as far as I can tell.
> 
> But then this locator change wouldn't be protected by the key, so 
> what's the point of having it? To provide proof that the third locator 
> belongs to the same entity as the second locator?

In cb64 as it was written it accepts the first peer locator
(the one used to setup the state) on the faith of the return routability
check implicit in establishing the state. When there is a locator change
the peer have to prove itself using the CGA property i.e. public key crypto.

My point is that having different IIDs for the different prefixes
does not require a change to this way of doing things.

> I think it's essential to exchange _something_ that allows the other 
> side to recognize its correspondent after a rehoming event before such 
> a rehoming event happens (for the first time). 

Yes, which is why my email said that the context would need to be identified
at the receiver using only the flow label (compared to cb64 as written which
uses flow label + IID).

This *might* increase the desire to have something more than the 20 flow label
bits identify the context, which would push us into having an extension header
with a larger context tag. But I'm far from convinced this is required.

    Erik