Multi-6 [WAS: OT - Vint Cerf joins Google]

Iljitsch van Beijnum iljitsch at muada.com
Tue Sep 13 19:19:29 UTC 2005


On 13-sep-2005, at 0:22, Igor Gashinsky wrote:

> :: I must be missing something, but there's a good chance that the  
> requester is
> :: going to have to wait for a timeout on their SYN packets before  
> failing over
> :: to another address to try.   Or is the requester supposed to  
> send SYNs to all
> :: addresses for a hostname and race them off?

This aspect isn't nailed down yet, but basically there are two  
options: depend on the application do try all addresses (which apps  
should do anyway, but I for one wouldn't want to wait for all these  
timeouts), or have the shim detect that the first address doesn't  
work and repair the failure. This adds additional complexity, though,  
and there is still a timeout, although it isn't a full TCP SYN timeout.

> Or, on top of that, how traffic engineering can be performed with  
> shim6..

For outgoing traffic there is no difference with the current  
situation (as long as there are nog ingress filtering issues). For  
incoming traffic, it basically starts with DNS load balancing, and  
the shim itself will have priority mechanisms to choose between  
different address pairs but this will generally not come into play  
because the idea is that the shim doesn't do anything unless there is  
an outage.

> And people wonder why more "content" isn't available for v6. Maybe  
> when
> content providers start asking for a /32 *per datacenter* (ie a /26  
> or so
> of initial allocation) those issues might get solved... then again,
> probably not.

So how is that going to help? The whole idea behind shim6 is that we  
can't give people all the independent address blocks that they may  
possibly ask for.

> (firmly in the shim6 does not adress *most* of the issues camp)

So where were you the past years in multi6 and months in shim6?  
Please be part of the solution and not part of the problem. (That  
goes for John Payne and Daniel Senie too.)

I'll be happy to continue any and all discussions of multihoming in  
IPv6 off-list, but having them on the NANOG list doesn't seem to be  
very productive.



More information about the NANOG mailing list