Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
6to4 / RFC 3484 behaviour in OS X
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

6to4 / RFC 3484 behaviour in OS X



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.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.