[AusNOG] IPv6

[Geoff Huston]

Hi Mark,

> If you had deployed IPv6 on your network, the latencies if the two protocols would be equivalent and you'd be sending and receiving about half of your household traffic over IPv6 just like the rest of us without needing to tweak any Happy Eyeballs settings.


I suspect you live on a Mac - right?

On a Mac with OSX and Safari the Mac keeps a track of average rtts in the forwarding table (nettop -n -m route) - it even has an rtt for default (!). If the host has an active IPv6 interface it will send A and AAAA queries into the DNS as close to back to back as it can. When it gets back one answer it waits for a small time (can't find the DNS wait time - I think its less than 100ms), and if it gets both DNS answers it uses the RTT estimate in the forwarding table to select the lowest RTT. IN THEORY this is meant to turn the Mac to the fastest protocol. In practice I've found its pretty random and half / half is about what I see. But if you live behind a IPv6 tunnel the Mac to lean away from the tunnel due to the higher RTT.

But if you use any other browser on your mac, or you use some other host then you are going to get a different result. 

Safari waits 300ms for a response to the outbound SYN. If nothign happens in 300ms it fires off a SYN in the other protocol

The traditional method - which I think is still used by Windows and Explorer - uses a static preference list, set in some registry entry or other. Explorer on Windows will also fire of back-to-back A and AAAA queries and if it gets back answers within a wait time (> 10ms but again I am not sure of the precise timer value) it will then use the preference list to determine which protocol it will start up. 

Explorer waits 21 seconds (and sends two further SYNS) before flicking over to the other protocol. SO you your Windows/Explorer thinks its is connected to IPv6 AND the reference setting biases IPv6 higher than IPv4 AND the IPv6 connection is not working THEN connecting to dual stack sites will be exceptionally painful.

Linux by default will behave like Windows, but with a 180 second failure timer on the SYN attempt. Its good that most browsers on Linux use a far more aggressive failover and do not rely on the OS timers.

FreeBSD is only a little better and uses a 75 second failure timer. Again what saves the day is browser behaviour.

Chrome and Firefox are the other popular browsers.

In Firefox I have network.http.fast-fallback-to-IPv4 set to TRUE. I am not sure if this is the default value but its this value that makes Firefox work well. What happen in Firefox is that it fires off the DNS queries back to back, IN IPv6 as soon as it gets a DNS answer if fires off a SYN. IN IPv4 as soon as it gets a DNS answer it starts a 300ms timer, and then fires off a SYN. The first SYN+ACK received determines which protocol to use. So IPv6 can be up to 300ms slower and Firefox will still prefer it.

Chrome is similar to this, firing off IPv6 first, waiting 300ms and if there is no response then firing off a IPv4 SYN.

So if the latencies are similar for both protocols and you are heading to a dual stack site then the selected protocol to use will be IPv6 for Chrome and Firefox, based on the local host pref settings for Windows+Explorer and random for Mac OSX + Safari.

Which may or may not be more than you ever wanted to know.

Geoff