From the dualstack-is-fun department...

[Guillaume.Leclanche at swisscom.com]

> -----Original Message-----
> From: Mark Smith
> [mailto:nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org]
> Sent: Tuesday, March 01, 2011 9:49 AM
> > > 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.

No, I'm not using Fritzbox. The v6 unreachability problem was "in the Internet" (really: Cisco bug on 7600).

Guillaume