Re: Transport level multihoming

[Brian E Carpenter <brian@hursley.ibm.com>]

Ramakrishna Gummadi wrote:
> 
> > We invented IPv6 to avoid the need for address translation and all its
> > attendant problems. The argument for a multi6 solution at transport level
> > is to *deal with* the existence of multiple addresses and precisely to avoid
> > translation. There is an alternative, which is the type of architected
> > address translation implied by 8+8, GSE etc but please let's avoid painting
> > ourselves into a corner that requires both transport layer gymnastics and NAT;
> > that would be a catastrophe.
> 
> I think the question is: should multi6 also deal with provider
> multihoming? If it should, then address translation like 8+8 would be
> required because the multi6 requirements draft says that the architecture
> should provide for policy-based multihoming---if untranslated addresses
> are used directly by the provider's sites (single- or multi-homed), the
> site is pretty much dictating the routing, and load-sharing policies.

I think that's a complete non sequitur. The fact that the multihoming needs
to be under policy control doesn't imply anything of the kind. It simply
implies that the multihoming decision point must be configurable by some
policy management system. It's quite orthogonal to the rest of the
solution; the range of possible policies will be determined by the solution.

> If 8+8 or GSE or some such is used, this would preclude a transport-level
> or app-level
> solution because we don't want routers to modify addresses in the payload
> as well. That leaves us only with network-level solutions.

Yes, I think the 8+8/GSE class of solutions do indeed hide the multihoming
decision point from transport and applications, although there might still
be some indirect influence via address selection. For example if DNS returns
two AAAA records, one of which is a provider-based address like today and the
other is a GSEbis address, which one the transport layer chooses to use
would have significant effect on multihoming.

   Brian