[lgbr]

Security aside, this is even useful for new deployments of IPv6. It seems a lot of people have IPv6 networks that are less favorable for some traffic than their IPv4 networks. Some are running their IPv6 through tunnels. As soon as you enable IPv6 on your desktop, suddenly Firefox or Chromium will prefer IPv6 for any website with a AAAA record, which adds a ton of latency and reduces bandwidth.

But theoretically, I could enable IPv6 for sshd (where I stand the most benefit) and leave it off for wget and browsers with this.

[dfc]

At home my HE tunnel is snappier than the plain ipv4 from rr. The weird thing is it is not just a case of user perception (mine). One of the upstream s1 ntp boxes I sync with has ipv4 and ipv6 and is relatively close. I set one of my s1s to sync with both the ipv4 and ipv6 addresses of the machine and the ipv4 clock displayed a lower delay and less jitter while the offsets were seasonably close.

[dfc]

argh, for posterity's sake the last line should read:

"the ipv6 peer entry displayed a lower delay and less jitter while the offsets were reasonably close."

[wmf]

IPv6 is no longer necessarily preferred due to happy eyeballs. http://tools.ietf.org/html/rfc6555

[IgorPartola]

I did something independent of happy eyeballs (I consider my implementation actually superior in some ways as it aims to improve connection latency on all networks), but when I tried to get in front of some browser developers (by posting on HN), I was told by a Chrome networking dev that they tried it and decided that it wasn't worth it. He cited something about how the performance was actually worse than before. The impression that I got was that Happy Eyeballs was not actually widely adopted.

[justincormack]

You can always just drop ipv6 packets for certain destination ports (eg 80) with iptables if you know the application (like a browser) will be ok. Which is much simpler.