RE: The state of IPv6 multihoming development

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

On Tue, 22 Oct 2002, Craig A. Huegen wrote:

> The complexity and management of assigning multiple-PA prefixes to my home
> network of 6 segments, or my mother's accounting firm with 20 segments, or
> even a previous employer's network of 100 segments, is vastly different
> than assigning multiple-PA prefixes to a network of tens of thousands of
> segments worldwide, with multiple Internet igress/egress points.

In my original message, which has stirred up a lot of discussion I'm
happy to see, I also mentioned working on a unified tunnelling/aliasing
mechanism.

If we look at a huge enterprise as one example of someone who needs
multihoming, and at a single host with two interfaces or one interface
with two addresses as another, it seems unlikely they could use the same
multihoming mechanisms. However, they could both use a multi address
solution.

For the enterprise, this could be something along the lines of Michel
Py's MHAP where the entire enterprise or good size chunks of it sit
behind clusters of aliasing/tunneling devices that provide the
multihoming functionality by rewriting (or tunnelling) traffic that
can't reach its destination otherwise over a backup address.

For the host, this could be something like Marcelo Bagnulo's extension
header, modified mobility, Peter Tattam's modified TCP or my own "BALTS"
idea. These all boil down to a host having several addresses and being
able to receive packets on a secondary address and trick the transport
layer into thinking it's still using the primary address.

Just recently it occurred to me that these solutions could very well
work together. There are just so many ways you can tunnel or aliaze a
packet, and it's fairly trivial to implement them all for sending. That
means everyone can implement whatever is most convenient for receiving.

For instance, if a multihomed host sends a packet to a multihomed
enterprise its server while the primary address is unreachable, the host
could replace the enterprise's primary prefix with a secondary (PA) one
which is received at a big de-multihoming box which replaces the
original prefix. When the target host (which doesn't have to know about
all of this) sends a packet back, the multihoming box can add a mobility
header and send the packet to the secondary address for the multihomed
host.

I think standardizing the interaction between different multi address
multihoming solutions will make this type of solution much more viable.

It would be great if we could have a discussion about this in Atlanta.