On killing IPv6 transition mechanisms

[Tore Anderson]

Hi Gert,

> 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
another device.

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
1875
$ grep '^2002:.*Mac OS X' vg_log-20100315 | grep -v Opera | wc -l
1816

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!

BR,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27