Re: The state of IPv6 multihoming development

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

> 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.

Implementation details (like trust issues between the shared kernel and a
library) aside, I don't see how one can ensure that you can have
high connection rate servers without opening up a DoS hole.
For a low connection rate server the queue of one (or some rate limiting 
at a value larger than one) might make sense, but that doesn't
allow folks to build high-connection rate servers that do not want to
hard code a limit.

Carrying 2 locators and 2 identifiers in the connection establishment
seems like a way to avoid this performance vs. DoS morass.
Haven't though about UDP though.

  Erik