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