From the dualstack-is-fun department...

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Tue Mar 1 09:49:08 CET 2011


Hi Guillaume,

On Tue, 1 Mar 2011 08:16:53 +0100
<Guillaume.Leclanche at swisscom.com> wrote:

> > -----Original Message-----
> > From: ipv6-ops-
> > bounces+guillaume.leclanche=swisscom.com at lists.cluenet.de [mailto:ipv6-
> > ops-bounces+guillaume.leclanche=swisscom.com at lists.cluenet.de] On
> > Behalf Of Daniel Roesen
> > Sent: Monday, February 28, 2011 11:34 PM
> > To: ipv6-ops at lists.cluenet.de
> > Subject: From the dualstack-is-fun department...
> 
> 
> > DS-Website having one AAAA RR:  ~3 minutes time to IPv4 fallback(!)
> 
> I analyzed this behavior, the reason is that the browser is calling the connect() API from the OS. This function will then try the complete TCP opening process, including TCP retries. Linux (at least debian flavour) will do 5 retries, with exponentially growing time between them.
> 
> You can play with the number of retries; I put it down to 2, and the fallback-to-ipv4 time was roughly 10s.
> 
> I opened a feature request on the kernel bug tracker to request the possibility to tune this parameter for dualstack websites, and put it by default to 2, but nothing happened afaik.
> 
> The request :
> https://bugzilla.kernel.org/show_bug.cgi?id=23242
> 
> The sysctl control is tcp_syn_retries (sorry forgot the hierarchy, you'll have to grep :)
> 

Are you using a Fritzbox 7390? When you enable IPv6, they enable ULAs
by default (although their ULAs aren't (near-)unique because the unique
id is all zeros!), and don't issue ICMPv6 Destination Unreachables then
they don't have an IPv6 default route. So with an IPv4 only WAN link,
this problem occurs on all dual-stack websites. According to RFC4443,
they SHOULD be issuing ICMPv6 Destination Unreachables, No route to
destination.

Regards,
Mark.



More information about the ipv6-ops mailing list