|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Hi list, in the last few months I've (with the assistance of some of Norway's largest web sites) been running some experiments that attempts to uncover the impact of dual-stacking content. >From what I've been able to determine, Mac OS X-based clients is responsible for a large amount of the page views that appear to fail towards the dualstacked test host. Some numbers from yesterday: * Total breakage (failed page views): 0.053% * Total breakage with Mac OS X excluded: 0.029% The 0.029% is mostly caused by Opera <10.50 on Windows Vista/7. This problem is however rapidly diminishing as version 10.51 is being rolled out these days through Opera's automatic update function. But we're currently left with 0.024% of breakage that's apparantly caused by Mac OS X behaviour. If I calculate the numbers but only including Mac OS X-based clients, I get a breakage percentage of 0.547%. The reason for this appears to be a unusually high preference for 6to4-based IPv6 connectivity, which is inherently less reliable than IPv4: * IPv6 percentage of all hits from OS X: 1.152% ...of which 85.964% is 6to4 * IPv6 percentage of all hits excluding OS X and Opera: 0.062% ...of which 3.429% is 6to4 (I also excluded Opera, because it has a known bug that makes it, in versions older than 10.50, prefer 6to4 on Windows Vista/7 (which auto-configure such tunnels). Drilling into all of these 6to4 hits from OS X, I can tell by looking at the addresses in question, that: - 85.66% are from SLAAC-configured 6to4-addresses - 0.30% are from other 6to4-addresses Obviously these are the page views that actually succeeded, but the percentages gives an insight into the cause of the brokenness too. I believe the users that lose connectivity, have a router/CPE device on their network that terminate a 6to4 tunnel and announce it on the local network using SLAAC. There's no way for me to determine it, but have a strong suspicion the Airport Extreme is involved in most of these. Now, the behaviour of OS X is actually RFC 3484-compliant, as far as I'm able to understand. This is because the RFC says private IPv4- addresses (RFC 1918) is to be considered locally scoped, while the local 6to4 address (as well as both the IPv4 and IPv6 addresses of the web server in question) are globally scoped. And since addresses with matching scope are to be preferred, the 6to4 address is used. However, the RFC does unfortunately not take into account the existence of IPv4 NAT at all. It is quite obvious that IPv4(RFC 1918)-to-IPv4 is much more reliable than IPv6(6to4)-to-IPv6, so this is a serious omission in the RFC. <http://tools.ietf.org/html/draft-arifumi-6man-rfc3484-revise-02> aims to fix it, by simply changing RFC 1918- based addresses to the global scope. I believe other RFC 3484- implementers like Microsoft have already made such an adjustment, due to the fact that this is only really a problem with OS X. Other platforms (with the mentioned exception of Opera on Windows) generate miniscule amounts of 6to4 traffic in comparsion, and have barely any problems with accessing dual-stacked web sites. The problem is not specific to any single version of OS X. All in all, this makes it very difficult to convince my content-providing customer to dual-stack their web sites. They're understandably enough rather concerned about making their sites unavailable for a considerable amount of OS X users. And with no IPv6 content being made available, ISPs have less incentive to deploy native IPv6 service. So it ends up slowing down the entire IPv6 rollout. By this message I'm just hoping to raise some awareness of the problems, and hopefully make Apple consider changing their RFC 3484 implementation according to the mentioned draft in a future OS X patch/release. Also, if anyone have any suggestions on how to work around this problem in a scalable way, or have any other comments, I would appreciate hearing them very much. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 _______________________________________________ Do not post admin requests to the list. They will be ignored. Ipv6-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
Visit the Apple Store online or at retail locations.
Copyright © 2011 Apple Inc. All rights reserved.