Pekka Savola (1-12/1-31/200x) 11/12/08 9:09 PM:
If an implementation implements RFC3484 and the user is not using
custom address selection policy, all compliant RFC3484 implementations
should prefer v4 when connecting to native from 6to4 (rule 5 of
destination address selection AFAIR).
Can we derive from this that Google's IPv6 address is necessarily 6to4
(most of its US customers using it are 6to4), and that Google has
therefore a guaranteed path toward other 6to4 hosts?
Besides, isn't this a strong reason in favor of native IPv6 (albeit like
Free did it with 6rd on its IPv4 infrastructure) vs 6to4?
RD
FWIW, in Linux this was changed as the default maybe about 2-3 years
ago. I suppose may other operating systems, especially recent ones,
also operate in this manner. For Linux, some info is here:
http://people.redhat.com/drepper/linux-rfc3484.html
This has been discussed on v6ops and ipv6 lists but unfortunately I
can't find the threads despite search attempts.
Maybe someone else with better memory could provide better references.
This is why observing ipv6 traffic on a dual-stack hostname will
mostly just in observing those that use native v6 (with Mikael, this
was 0.5% of users).
Except if the dual stack server, like that of Google, uses different
URLs for IPv6and IPv4, right?
If you're interested in wider picture of IPv6 penetration, you'll put
the content on v6-only hostname (with Mikael, this was reachable by 6%
of users). If you want to also cover for Vista users with Teredo,
you'd put the content on a site and refer to it using a numeric
address instead of a hostname (this would result in even a higher
percentage).
So, if you're interested in any kind of IPv6 connectivity at all (even
6to4, teredo, ...), at least in some user communities (p2p users), I'm
pretty sure IPv6 penetration is already over 10%. At least 6% is
already proven by measurements :-)
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf