RE: The state of IPv6 multihoming development

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

On Wed, 23 Oct 2002, Greg Maxwell wrote:

> Lets say that everyone who mutihomes will take their provider based
> address and announce it to other providers.. This would work..
> But it would also explode the DFZ..

> Okay, so people could filter the smaller routes... effectively
> de-multihoming the multihomer.. so filtering is not a reasonable solution
> to multihoming caused DFZ inflation.

If nothing changes, this is exactly what will happen. This is also quite
common in v4 today: it is very close to impossible to get a small PI
block, so many multihomers take addresses from one ISP and announce them
over both. This provides a reasonable degree of multihoming if the ISP
they take addresses from accepts the announcement from the alternate
ISP. Then, if the multihomer's connection to the primary ISP goes down
and their more specific is filtered, the traffic ends up at the primary
ISP thanks to the aggregate, and the primary ISP sends it to the
secondary ISP who in turn delivers it to the multihomer. This doesn't
protect the multihomer from all failure modes for the primary ISP, but
it sure beats single homing.

> If we do care about preserving aggregation (one of the stated goals of
> IPv6), then we can NOT permit *any* multihoming aggregation busting and
> multihoming must be provided either by transport layer enhancements (my
> favor, see archives) or via tunnel hacks.

> I got tired of discussing the matter because of the group's unwillingness
> to seriously consider transport layer modifications (wah wah outside of
> the scope blah.. I thought my argument for prefix flowthrough and SCTP
> was compelling.. No DFZ busting, the only catch was that legacy apps
> wouldn't be multihomed: a good reason to upgrade them).. If you simply can
> not do anything but break aggregation then fine, stop waffling and
> declare it already. The problem isn't just going to go away.

Personally, I feel this is a network issue so it should be dealt with at
the network layer. However, I'll take a good solution at any other layer
over a bad one at the network layer any day of the week.

A more compelling reason to do it at the network layer is that we have
many boxes that can do stuff at the network layer, while all the
transport layer decisions are (should be) made by the end hosts. See
Craig's problem with host solutions.

Also, keeping a single address for the transport layer (essentially
promoting this one to an identifier) and a possibly large set of
alternate addresses that are hidden from it (these would be locators)
keeps the transport protocols simple (= the same as they are now).

But in order to make it all work efficiently, there must be tight
integration between TCP and the multi-address engine, because TCP knows
when sessions start and end, and when there are (potential) reachability
problems.

Do you have a pointer to your transport layer ideas, BTW?

> The only thing worse then making a bad decision is wasting a lot of time
> making a bad decision.

The ship has sailed on making a good decision fast, so let's focus on
making a good decision period.

Iljitsch