RE: The state of IPv6 multihoming development

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

On Sun, 27 Oct 2002, Tony Hain wrote:

> > I don't see any relationship with interdomain multicast, so
> > the fact that this has been hard to deploy in the past (and
> > unless I'm mistaken the scalability problems have now been
> > largely solved) doesn't say anything about translation mechanisms.

> Passing around state between administrative entities is always a trust
> problem.

I don't think we are doing that here, unless you count the fact that the
administrative domains where each endpoint is located contain state that
must match that in the other, but this is normal TCP behavior.

Compare to NAT: usually, both the NAT box and the host sitting behind it
are part of the same administrative domain, or there is another reason
there is implicit trust. (For instance, the NAT box is located at a
service provider and you pay your service provider to be trustworthy to
some degree.)

Obviously, having the multihoming functionality in a potentially hostile
box isn't going to fly.

> > And if for the truly huge networks this solution isn't
> > viable, they can always use IPv4-style multihoming. (But
> > they'd still need to implement all of this in order to be
> > able to talk to others who use multi-address
> > multihoming.)

> We will end up with a system that looks like IPv4 muti-homing to the
> sites that want that, but scales better for the service providers.
> Anything less on either front is a non-starter.

Truly huge in this context would be fortune 500 or something like that.

For smaller, but still reasonably large sites, having the multihoming
functionality in each host is still too much headache, that's why I
think it's important to be able to offload the necessary processing to a
relatively small number of boxes at the edges of the network. To the
internal network this will look like traditional IPv4-style multihoming,
to the service providers it looks like single homing. The only downside
is that the other end has to implement something similar. That's why we
also need to have it in the host stacks, even for hosts that don't
multihome themselves.