Re: The state of IPv6 multihoming development

[Pekka Nikander <Pekka.Nikander@nomadiclab.com>]

Erik,

Pekka Nikander wrote:
> > The host stack would then, underneath TCP or UDP, look
> > at these two bits.  If the bits indicate a normal IPv6
> > address, nothing would happen and the host would work
> > just like today.  On the other hand, if the bits indicate
> > HIP, the host would select an IP address from the addresses
> > currently available for the given host, and replace the
> > key hash with the address.  The recipient would then make
> > the reverse, thereby preserving transport layer checksums.
Erik Nordmark wrote:
> In a scheme like this it sounds like something under the API needs to
> do some form of lookup in order to establish the mapping from the host
> identity to a set of IP destination addresses.
> Any thinking on how this lookup/mapping would occur?
In our current prototype the kernel maintains an ID -> address
mapping table.  If it encounters an ID that it has no mapping for,
it queues the packet in a queue of length 1, and sends the ID to
a user level daemon for resolution.  The current prototype daemon
reads the mapping from a configuration file.  This is clearly
unacceptable for real life.

My *current* idea of the right way of doing that is to
hack the resolver library.  That is, whenever the application
asks for AAAA records (e.g. through getaddrinfo), the resolver
asks for both AAAA records and KEY records.  If it gets any
HIP key(s), it returns the corresponding HIT(s) as the first
entri(es) in the address list, and the real addresses after them.
Additionally, it pushes the HIT->AAAA mapping(s) to the kernel.
The kernel maintains a status of the addresses and marks
one usable only after an ID verifying RR has been performed
on it.  Exact details to be worked out, but you get the idea.

> BTW: I'm interested in looking at your HIP paper.
Sent off-line.

--Pekka