Multiaddress multihoming

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

As I mentioned, I've been working on a draft for multiaddress
multihoming in IPv6. The problem I'm having is that most of what I'm
writing down is either too much detail or too obvious. The whole thing
is just too big. So I want to focus on the more practical aspects, but
I'm afraid the tradeoffs there will seem arbitrary without explaining
the big picture first. So that's what I want to do in this message.
Feedback is appreciated.

The basic idea is to apply logic similar to the end-to-end principle to
multihoming: if we can do it in the end hosts, don't impose any changes
on the network layer as this only makes the whole thing harder to
deploy.

The next step is to separate the locator and identifier functions. In
order to keep our options open, we shouldn't pick a single identifier
namespace, but rather accept any arbitrary variable-length binary value
as an identifier. The identifier/namespace type must be explicitly
identified inside protocols to be able to represent it using the right
conventions, to be able to perform identifier to locator mapping in the
right way, to avoid collisions and to make special handling of certain
identifier types possible.

The TCP or UDP checksum is calculated over the identifiers, the
transport protocol header and user data. A new API is provided that
makes it possible for applications to provide the transport protocol
with just an identifier, and the transport protocol looks up an initial
set of locators.

The preferred identifier type at this time would be the fully qualified
domain name. FQDNs are already in wide use and there is a
well-understood mapping mechanism for this type of identifier to
locators already in place: the DNS.

The new identifiers and the full set of locators for each end would not
be be carried in each packet, but rather be negotiated prior to the
exchange of data. Since this negotiation mechanism is common to
different transport protocols, it should be a separate protocol. Also,
it makes sense to make this a general negotiation mechanism that can
negotiate additional information, such as the use of additional
authentication that can replace the basic level of security prevously
provided by return routability.

So far so good, with plenty of work to do, for instance in the area of
security, but this should all be relatively straightforward.

Backward compatibility.

In order for unmodified applications that use the IPv4 or IPv6 socket
API to work with this scheme, calls to these APIs are intercepted. The
IPv4 or IPv6 address is turned into a hostname, that is subsequently
used as an identifier. (Presumably, using the .in-addr.arpa domain.)
Additional compatibility to existing implementations can be gained by
using the 4 or 16 byte IP address values as identifiers. Then regular
TCP or UDP over IPv4 or IPv6 can be used without any real changes, by
adding layers on top and underneath these protocols: the layer on top
does the negotiation and the layer underneath replaces the IP addresses
used as locators by the ones used as identifies, possibly switching IP
versions at the same time.

Hosts with unmodified IPv4 or IPv6 stacks can use this multihoming
mechanism by offloading the necessary processing to a proxy. The proxy
presents itself as a router to the host. When the host transmits
packets, the proxy intercepts then and looks up their destination
address in the DNS to determine whether the destination is multihomed.
If not, the packet is forwarded as usual and a cache entry is created
that enables to proxy to forward subsequent packets immediately.

If the destination is multihomed, the proxy goes through the negotiation
cycle. The original IP header is then stripped from the packet, and a
new one containing a set of source and destination locators that was
negotiated is added, and the packet is forwarded. No transport layer
information is changed. The reverse is done for packets received from
the multihomed destination network. The proxy monitors the flow of
traffic to determine when a source/destination locator pair stops
working so it can switch to another pair.

Incoming sessions work the same way, except that the other end initiates
the negotiation phase with the proxy.

Iljitsch van Beijnum