RE: The state of IPv6 multihoming development

[Greg Maxwell <gmaxwell@martin.fl.us>]

On Wed, 23 Oct 2002, Iljitsch van Beijnum wrote:

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

Well perhaps this specific filtered, cross announce approach could be
combined with my transport layer ideas as a transitional method.

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

I'm not so sure it's a network layer issue..
The network moves packets to a network location.. when their is a failure
and multihoming comes into play, you are effectivly moving onto a NEW
network location..

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

[snip]

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

I made some long posts to this list a while back, search based on my email
address.  Ascii graphs and such..

I started working on a draft, but it seemed like the consensus was that
"transport layer solutions are outside of the scope of this working
group".. The irony is that everyone with anything to do with transport
protocols said IPv6 and multihoming arn't our bussiness.

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

My concern is that we should make a decision that doesn't tie us in.. If
we decided on an DFZ exploding solution, there will be no going back..

I really don't believe that weak DFZ exploding solutions like I said
might work above (like, announce specifics and filter, and if you want
better then upgrade to transport layer multihoming) are sufficent because
of the current practice of flooding the DFZ with IPv4 (i.e. the filtering
won't happen/people will cry and get it removed when it first annoys
them.. which will work early in IPv6's production deployment becuase it
won't yet be many networks)..

Am I off? Can we really get away with saying 'well, the technoligy allows
you to flood the DFZ like in v4, but policy says you should play nice and
not do so' and actually have that happen?  or must we make a strong stand:
aggregate and solve your multihoming via this non-DFZ exploding method or
cope with being singly homed!