Hi Rémi,
* Rémi Després
> => If there are indeed OS bugs that break connectivity, they should
> justify quick patches like those that concern security.
I think this is wishful thinking, unfortunately. For example, the 30th
of October last year I reported an IPv6-related bug in the Opera web
browser. After a considerable amount of nagging and pestering, even on
their public user forums, a fixed version was finally released on the
2nd of March this year. That was a new major version. IPv6-related
issues did not appear to be a priority for them, and it certainly seemed
out of the question to back-port the fix to the older maintenance-only
branches. I don't expect other vendors to behave much differently.
And even if vendors would fix bugs rapidly in new releases, there's
still the issue of making end users upgrade to them. Now a month has
passed since the Opera bug was fixed, but it continues to be a major
cause of client loss.
> "Gashinsky adds that Yahoo is conducting its own analysis of broken
> IPv6 connectivity, which it will share with the Internet engineering
> community in June."
> => As a minimum, what the problem really is should be documented
> before proposing to adopt any solution to solve it, in particular if
> it is "ugly".
It would certainly be useful to see the conclusions from Yahoo's
measurements - if we know what actually causes the client loss, we might
try to fix the actual problems instead of working around it with DNS magic.
To that end, I've been running my own measurement for quite some time
now. It's very regional in scope (Norwegian end users mostly), so it is
very likely that Yahoo, with their global audience, are observing
problems that I do not, but I'll try to make a summary of my conclusions
from March:
- Total client loss to the dualstacked host is at 0.074%.
- (At least) 95% of the client loss is due to clients choosing to use
inherently unreliable transitional IPv6 (6to4/Teredo) instead of IPv4.
- I've identifed three groups of clients that behave in this way:
1) Users of Opera <10.50, which did not use the RFC 3484-compliant
getaddrinfo() call, at least on Windows. It would prefer any form
of IPv6 connectivity above IPv4. This is especially a problem on
Windows Vista and 7, where 6to4 and/or Teredo are enabled by
default. This accounts for about half of the 95%.
2) Dualstacked Mac OS X users with RFC 1918 IPv4 addresses (using
NAT) and transitional IPv6 addresses. In this case, getaddrinfo()
will sort the IPv6 address above the IPv4 address, causing the
transitional connectivity to be used. This accounts for the other
half of the 95%.
3) Dualstacked Linux users with RFC 1918 IPv4 addresses and
transitional IPv6 addresses, as GNU libc's getaddrinfo()
implementation behaves exactly like the one in Mac OS X. However,
the overall client loss caused by this is miniscule compared to
#1 and #2 (I have problems measuring any at all).
- When disregarding all hits from users in problem groups #1 and #2,
the total client loss is at 0.003% - this is, in my opinion, low
enough to accept. (Of course, other content providers might feel
differently.)
I've informed the vendors in question about the problems (and I
understand others have too, before me). While the Opera issue is
already fixed, the other two reports are here:
http://lists.apple.com/archives/Ipv6-dev/2010/Mar/msg00003.html
http://sourceware.org/bugzilla/show_bug.cgi?id=11438
In the first case, there's no responses from anyone posting from
@apple.com, in the second case, there's no response at all. If the
vendors are considering IPv6 issues a priority, they're not telling.
You can read my entire March report here:
http://lists.cluenet.de/pipermail/ipv6-ops/2010-April/003272.html
> "Only way of knowing the user has working IPv6 connectivity, is if
> the AAAA query came over IPv6!"
> => This DOESN'T WORK :
I agree, not in all cases at least. Your example of IPv6-capable
clients using IPv4 for its DNS queries is one valid case, another would
be when the clients' end stations are not querying the ISPs recursive
resolvers directly, but instead a (caching) DNS forwarder embedded in
their CPE/SOHO device. This kind of setup is very common here in
Norway. There's no guarantee that the DNS forwarder will use the same
IP version as the client did when forwarding the query to the ISP's
recursive resolver - which could either cause a broken end station to
see the AAAA records, or vice verca, that a IPv6 capable end station
will only be presented with A records.
The best way to know if the user has working IPv6 connectivity is to
actually test it as he's visiting a IPv4-only web site. A few days ago
I made a attempt of making such a test, inspired by the so-called
«Norwegian IE6 Spring Cleaning», you can try it here:
http://ajaxtest.fud.no/test.php
It's only partially working, but then again I have no real skills when
it comes to web developement - I'm sure someone would be able to
implement the idea it in a much better way. Even though certainly not
all users would heed the warnings and implement the suggested fixes,
some would, and I think it would increase visibility of the problem
significantly enough so that the end users (or his ISPs tech support)
will know what to do the moment the site is dual-stacked and the user
starts having connectivity problems.
Imagine if several major content providers (Yahoo, Google, MS, ...)
would agree on a common date for deploying IPv6 on their services,
possibly after a common period of testing/warning users. In that case,
the business problem with being an early IPv6 adopter would be somewhat
diminished - as a user experiencing the apparent site down problem would
not be able to jump ship to the competitors, either. And it event would
likely be well publicised, too, so the end user (or his ISPs tech
support) would know what to do. But I guess having competitors actually
cooperate on something like that is an utopian idea.
> If and when the mentioned OS problems are documented, it will be
> possible to fix them with patches in OSes, where they belong.
In that regard I hope you have found my measurements useful. To the
Yahoo people: The sooner we know what the problems are, the sooner we
can start to fix them. Could you provide us with some preliminary
results from your measurements before June?
Best regards,
--
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
