On killing IPv6 transition mechanisms
tore.anderson at redpill-linpro.com
Tue Mar 16 16:03:20 CET 2010
> Oh, good point. Yes, it seems to be enabled-by-default, and since
> the operating system on the client system does not *know* that it's
> 6to4 (for the client, it's just "IPv6 that someone announced a RA for
> on the local LAN"), it can't properly (de-)prioritize it...
Actually, an RFC 3484-compliant getaddrinfo() implementation should be
able to determine that, since it looks at its own source IP address used
for the potential outgoing connection. If it's within 2002::/16, it's
6to4 and thus sorted below IPv4 alternatives in getaddrinfo()'s output.
It should not matter if the actual proto-41 encapsulation is done by
However, there's still quite a bit of 6to4 traffic. Yesterday it was
30,281% of all IPv6 traffic for me, when ignoring Opera. Mac OS X seems
_way_ overrepresented though:
$ grep '^2002:' vg_log-20100315 | grep -v Opera | wc -l
$ grep '^2002:.*Mac OS X' vg_log-20100315 | grep -v Opera | wc -l
Hmmm... It seems Mac OS X isn't RFC 3484-compliant, or that Safari and
Firefox don't use getaddrinfo() on that platform (of those 1816 hits,
1374 are Safari and 442 Firefox). Wonder how the hell I could have
missed this earlier...
Does anyone have a Mac OS X machine and a 6to4 LAN with SLAAC they can
use to verify this with? I'd really appreciate more info on this!
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
More information about the ipv6-ops