Re: The state of IPv6 multihoming development

[Iljitsch van Beijnum <iljitsch@muada.com>]

>> The basic idea is simple: the IP addresses the transport layer uses
>> become the identifiers of a session. In transit, these identifiers
>> may/must be replaced by locators, but they identifiers are restored
>> before the packet reaches the transport layer at the other end.

>Why does this so much sound like Mobile IPv6 to me?

There are many similarities. That's why it would be good to talk with the mobility people.

>I am probably biased here, but IMHO once you start to really
>ponder the security consequences, you pretty much come to the
>idea that maybe, after all, it might be better to introduce
>a new cryptographic name space instead of once more overloading
>the IP name space with some IP addresses that are end-point
>identifiers (and locators) and some that are (just) locators.
>The resulting aliasing problems are nasty, security wise.

What would this cryptographic name space look like? Remember that we have to maintain backward compatibility with a lot of stuff.

>The NSRG report still makes a good reading.

Do you have a pointer?

>If you are going to require changes to the end-host and the
>introduction of a mudem box anyway, the HIP design might
>be a good place to start with.  The more recent variants of
>HIP already support end-host multi-homing, and they contain
>a "mudem" which is able to perform prefix translation, function
>as a mobility home agent, and as a mobility anchor point.

That sounds good. Another pointer, please?

However, mobility as I understand it assumes things, especially the home agent, are reachable. In multihoming, this definately isn't an assumption we can make.