Re: The state of IPv6 multihoming development

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

Erik Nordmark wrote:
> > 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.
Why whould a server ever need to do such a lookup?  If a client doesn't
provide a working locator, it's the client's problem, not the servers.
Those servers that currently do a reverse DNS lookup on the first packet
also face the same DoS danger.  Today, it is actually better to reply
to a TCP SYN with a SYN ACK, deferring state creation to the forthcoming
ACK, and to do the reverse lookup at the ACK if really needed.

In other words, what I explained above concerns the client.

> Carrying 2 locators and 2 identifiers in the connection establishment
> seems like a way to avoid this performance vs. DoS morass.
Right.  Exactly what HIP does.

> Haven't though about UDP though.
If you have a request-reply term UDP transaction, you don't need real
mobility or multi-homing support.   You just retry if the reply doesn't
come through, perhaps trying a different set of locators.  No performance
penalty, but no security or multiple address support.

If you have a longer term UDP service, such as NFS, you can create the
ID -> locator mapping state, and use it just like with TCP.  The benefit
of having it below the transport is that you can share the same state
with all TCP and UDP (and SCTP) sockets.  Plus in the case of HIP you
get the (relative) security there, too.

--Pekka Nikander