Mac OS X Problem Puts Up a Block To IPv6
An anonymous reader lets us know of an experiment conducted in Norway to determine real-world problems in using IPv6 today (Google translation; Norwegian original). "According to a Norwegian article in digi.no, Redpill Linpro did an experiment with regard to IPv6 on one of the largest online newspapers there (www.vg.no). They added a hidden iframe that pointed to an IPv6-enabled domain to test real-life problems about the reported IPv6 holes. The result was that mainly Mac OS X, older versions of Opera, and a few Linux distributions exhibited problems. For Mac OS X it took 75 seconds to time out before failing back to IPv4." From the consultant's report: "Mac OS X has a problem in that it will prefer 6to4-based IPv6 over IPv4-based connectivity, at least if its local IPv4 address is an RFC 1918-based private address as commonly found in NAT-ed home network environments. This is unfortunate, as 6to4 has shown itself to be much less reliable than IPv4."
...when, most notably, also Opera versions prior to 10.50 are affected!
OK, OK, and apparently many Linux distros prior to recent patch of glibc. From the original source (love the url): "Also I'd like to thank Opera Software for working with me and fixing the problem in their browser, and Fedora, Canonical, Gentoo, Novell, Mandriva, and Debian for applying my patches to glibc in their respective Linux distributions."
One that hath name thou can not otter
So, I'm not 100% sure I understand what's going on here. Let's check.
It sounds like the problem is: if you've got a server that according to DNS is available both via IPv6 and IPv4, and the IPv6 address is not working, and the IPv4 address is working, the systems in question will fail to connect to it, even though they could if they'd just fall back to IPv4.
If a given server is IPv6-only, it works fine. If a given server's IPv6 connectivity is more reliable than its IPv4 connectivity, that's also fine. If a given server is IPv4, that's also fine. The problem only manifests when the server is available both via IPv4 and IPv6, and the IPv4 connection is more reliable than the IPv6 connection.
Yes?
And then on top of that, the author observes that on a system reachable both ways, it is typically the case today that the IPv4 version is considerably more reliable than the IPv6 version, and so in practical terms this issue actually does come up in the real world.
Yes? Do I grok, or have I made an error in reading?
How is their a difference? if Mac did not properly support IPv6 then it is their problem.
And I assume it did not mention Windows because they had no problems, the site seemed to just be listing problems.
Troll is not a replacement for I disagree.
Depends on how you phrase it. Yes , it is an ipv6 issue .. An issue on how Apple implemented IPv6 on OS X. Is this a problem with the way IPv6 was deployed in the test realized by Redpill Linpro or that IPv6 just isn't supported in the wild yet? I doubt that. We've replicated his results on several tests in the wild and in the lab. In fact, we run constant monitoring of these things and we saw clearly when Opera fixed the problem in their browser as we saw a clear drop in brokenness as reported by our experiments. AFAIK, Google runs some experiments on this as well (https://e-learning.ripe.net/ripe/meetings/ripe-57/presentations/Colitti-Global_IPv6_statistics_-_Measuring_the_current_state_of_IPv6_for_ordinary_users_.7gzD.pdf ), so I wouldn't be surprised if their whitelist-only method for receiving AAAA records is because of that.
Also, have you wondered why IPv6 isn't deployed by all the big sites just yet? Think of the number of hits a big site such as google, msn, cnn, etc gets. If you consider a 0.1% brokenness rate, this means a considerable number of users will have problem and this will damage the reputation of those sites (let's be honest.. How many non-geek users will know how to debug IPv6? In some cases, like the users who get IPv6 via 6to4 thanks to their Airport Express, they won't even know that they have IPv6 and they will just blame those sites). On all our tests, we've been actively collecting data and, when we identify the cause, we give this data back to vendors so they can fix their crap. It's a slow process, but we're seeing progress.
I think in general, Apple is probably doing more in house engineering now then they did long ago. Back during the PowerPC days, they designed chipsets, cases, and motherboard layouts and thats about it. Now, they make new processes for batteries, case manufacturing, CPU packaging (A4), low level firmware on cellular devices, and so on.
OS wise, OS X started as NeXTStep, and it took a lot of work to add the Mac part into it. The continue to develop new things there that apply to their entire product line. Grand Central Dispatch is a good example here, built into OS X with 10.6, open sourced for anyone to use, and now being baked into iPhone OS 4. OpenCL is another big one recently. Apple doesn't take things from the community and close source them, they participate in many open source projects, and make a number of new ones. Basically anything below the UI layer tends to be open and remains that way. Some of Apple's work even become fully certified standards, mDNS, and the container for MPEG 4 are recent ones.
They are still pretty unique in the industry, in many ways.