Tore, Many thanks for the detailed information you disclose. Further comments below.
Le 1 avr. 2010 à 15:42, Tore Anderson a écrit : > 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.) These 95%+ problems, being related to 6to4 and Teredo, don't concern ISPs that offer native IPv6 addresses (independently from whether they offer them with 6rd, like Free did in 2007, or otherwise). Note that this is consistent with Free's users not encountering such problems. Would you have some information about the 5%- remaining losses? >> "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. A "way of knowing" that doesn't work all the time is not a real "way of knowing", right? >> 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. I did, and thanks again. > 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? +1 Regards, RD _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
