Multihoming by IP Layer Address Rewriting (MILAR)

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

Before I write up a draft, let me run it by the list.

Considering that:

- using multiple address ranges is the only way disconnect the growth in
  multihoming from the growth of the global routing table

- the transport layer is not the best place to implement multihoming:
  the natural place is layer 3 and implementing it there also avoids large
  amounts of API problems and higher layer changes

- multihoming should work in all stages of a connection, including setup

- tunnels are a Bad Thing: they waste bandwidth, hide the network topology
  and current PMTU discovery standards and implementations easily break in
  the presence of careless tunnel deployment

- a host implementation is a good: no need to change routers and
  multihoming benefits trickle down all the way to the host, unlike
  current IPv4 multihoming

- a router implementation is good: no need to change large numbers of
  hosts

a multi-address multihoming system could work as follows:

Transport layer entities connect to a remote host in exactly the same way
as they do now. However, in the mean time the network layer takes steps to
discover alternative addresses for the destination address.

This can be done using the DNS ip6.int zone, a special ICMP message or
some other means.

When the IP layer decides that the destination address is unreachable or
performance is not what it should be (because it receives an ICMP
unreachable, an ICMP TTL exceeded or a hint from the transport layer), it
chooses one of the alternative addresses, and starts to rewrite the
destination address for packets to the destination host.

Note that this happens for ALL packets to that host, the only exception
being layer 4 sessions that have the new "I know about MILAR and I'll pick
the destination address myself, thankyouverymuch" option in the layer 4 ->
layer 3 interface enabled.

When the destination host receives a packet that is addressed to one of
its alternative addresses, it restores the original destination address
and delivers the packet to the transport layer. (So the TCP pseudo-header
will again produce a valid TCP checksum, among other things.)

The rewriting and/or restoring of the destination address can also be
performed by a router on behalf of a group of hosts.

There is a security problem: a host may think it's communicating with host
with a certain IP address, while it is in fact communicating with a very
different host, which is not the owner of the IP address in question nor
reachable over it using regular routing. This breaks "security by looking
at the IP address", but this was never very secure to begin with anyway.

Iljitsch van Beijnum