Re: The state of IPv6 multihoming development

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

On Sun, 27 Oct 2002, Pekka Nikander wrote:

> If the new name space was cryptographic, the primary end-point
> identifiers would be public keys (or equivalents).  However,
> since public keys are so large, it would be more convenient to
> use digests of the keys in most data structures.

> Thus, instead of trying to make a TCP connection to e.g.
> your-ip:25 I would create a TCP connection to hash(your-key):25.

> Security would be trivial, since you would know the public
> key of your peer.  The details are in the HIP drafts.

Hm, what problem exactly does this solve that isn't solved by (for
instance) SSL?

Also, how does the hash to IP address mapping work in the absence of a
hierarchy?

> > Remember that we have to maintain backward compatibility
> > with a lot of stuff.

> There are lots of details to be worked out, but the basic
> idea in HIP is to represent the end-point ID as a 127 bit
> hash of the public key.  This hash would then be encoded
> so that it looks like an IPv6 address with the first two
> bits being either 01 or 10.  Both of these code points
> are currently unassigned.

I'm not sure if I've said so clearly on this list, but over the last
month or so I've come to realize that it's probably too soon to create a
definitive multihoming solution. So it would be good to come up with
meta-solutions that enable different solutions to work together, or
provide a growth path from one solution to the other. I share Peter's
scepticism towards crypto-based solutions, so I don't think we should
crate a solution that only works with crypto. But a first step solution
could very well have the right hooks to enable the use of cryptography
where desired. More specifically: if we can make some sort of
identifier/locator seperation solution where the identifiers are simply
routable addresses, most of the ground work to move to crypto hash
identifiers is in place, and the only thing necessary is a good locator
discovery mechanism.

> > That sounds good. Another pointer, please?

> The basic design is perhaps best explained in our forthcoming
> NDSS paper.  I'm happy to send preprints upon request;

Condiser it requested.

> According to my understanding, mobility requires reachability
> for the following two reasons:
>   a) Initial reachability.  You need some initial IP address
>      to reach the host in the first place.  If multi-homing
>      is supported in addition to mobility, the set of initial
>      addresses can contain more than one address.

I'm afraid we have to push this into the application (trying multiple
addresses) as long as we don't have a good locator discovery service.

>   b) Resolving simultaneous movements (double jump).  If both
>      ends of a connection are mobile and move at the same time,
>      they must somehow be able to reach each other after the
>      movements.

But what if the home agent becomes unreachable?

Requiring the home agent to be reachable just moves the problem to the
place where the home agent is located. This may have some benefits as
the number of home agent locations can be smaller than the number of
multihomed hosts, but it still requires some other means of multihoming
to protect the home agent.

I read about a homeless mobility proposal somewhere a while ago, but I
haven't been able to find it again afterwards...

Iljitsch