RE: The state of IPv6 multihoming development

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

On Thu, 24 Oct 2002, J. Noel Chiappa wrote:

>     > 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 .. they could both use a multi address
>     > solution.

> This is an excellent point, part of one I was about to make myself, actually,
> as a result of my previous message mentioning the difference between "site
> multi-homing" and "host multi-homing".

> If you have a host which is multi-homed to widely spaced points in the
> topology, there's unlikely to be a routing-based solution, i.e. one where that
> host has only one address.

Disagree with you there, but I think that's nothing new by now.

Maybe we should have a look at source routing?

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

> Two points. First, Craig Huegen seems to think that any solution involving
> multiple addresses is infeasible for a large organization. What's your reply
> to him?

I was talking specifically about a multihomed host in the above. Looking
at a large multihomed organization as simply a collection of individual
hosts that are all multihomed is unmanagable. So remove the multihoming
processing to the edges where you can control it. I think that could
work well.

> Second, I seem to recall some people objecting to multiple addresses because
> it's too much code/complexity.

My objection is that it will take too long to develop to simply wait for
it, we must have something in the mean time. But other than that I don't
think the complexity is too bad.

> It would seem to me that once you have
> multiple addresses, the details on exactly how they are used are somewhat in
> the noise; whether one tricks the transport layer, or gets it to understand
> the possibility of multiple addresses, there's a certain amount of code
> involved.

Well, yes, sort of.

> About the only way I could see it making a difference is if you can figure out
> some way to do all on the multi-homed end.

I don't see this happening. If the destination is multihomed using
several addresses, and the source is single homed, the best we can do is
move the necessary processing from the source to a box a little
upstream. This could be a router/firewall or maybe ISPs can do this for
their customers. But if the destination has several addresses and the
one used becomes unreachable, someone somewhere will have to switch to a
secondary address.

> Some multiple-address schemes
> involve both ends, which is obviously more perturbing. The downside, of
> course, is that then there are probably things you can't do it you only
> involve the multi-homed end. (Too tired to figure them all out right at the
> moment - although I suppose you could use the "aliasing/tunneling devices"
> at the non-multi-homed end to get around this.)

> Of couse, then it starts to get ugly pretty quickly... lots of different hacks
> and kludges.

It's no worse than mobility. And have a look at the v4 routing table,
that's not exactly a thing of beauty either.