Slashdot Mirror
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.
The issue doesn't show up on Windows 7 at least. I have both v4 and 6to4 connectivity, and tests like this one show that my default protocol is still IPv4.
All Unices prefer 6to4 to v4, not just Mac OS X. At least Linux, FreeBSD and Solaris do.
The real bug, of course, is not that 6to4 is preferred, it is that 6to4 is unreliable. 6to4 does not monitor its tunnels -- it just assumes that a tunnel will work if there is a global IPv4 address. Which is obviously not necessarily the case in the presence of a v4 firewall.
Do yourself a favour -- disable the 6to4 functionality on your Mac and run Miredo, a Teredo implementation for Unices.
(Some more anecdotical evidence.)
It looks like an NTP bug. I have seen this behavior on non-Macos machines.
I suspect (but have no proof) that this involves an ipv4 dns connection that receives AAAA records. When NTP sees that there are ipv6 servers available, it doesn't fallback to ipv4 even when ivp6 networking is disabled. So nothing weird going on, just a bug.
Interesting, never realised such a site existed...
It says that i have "global unicast" address type, no 6to4 mapping, and it even tells me my mac address that was used to calculate the v6 address...
The speedtest also indicates that both protocols are roughly the same speed, and my machine defaults to v6 if it can.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
It may be less prevalent, but we have observed similar behavior on windows when the client thinks it has IPv6 connectivity but does not for whatever reason. in our environment, I believe it was due to moving from wired to wireless network (our braindead wireless system only supports ipv4). My testing about a year ago showed that firefox on mac or windows waited 3 seconds PER HTTP HIT before falling back to IPv4; it was too dumb to cache the fact that v6 wasn't working, and repeated the 3sec wait over and over. Safari on mac acted similarly but 5 seconds per hit. I don't remember about IE but I think it was similar. Camino had no such problem; it didn't support IPv6 at all :(
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.
Hi, Nick...
Yes, it would be better if Google were to deploy their own 6to4 relays, but when I asked their IPv6 operations people why they won't do that, their answer was basically that it would be a lot of work and it still wouldn't solve their problem. There would still be too many hosts behind 6to4 tunneling routers that are, in turn, behind firewalls that block returning protocol 41.
You should look at 6RD, which fixes all the really bad problems with 6to4 and gives service providers a proven upgrade path that doesn't force them to forklift upgrade all their IPv4-only edge router gear. We should start seeing consumer home gateway equipment and provider provisioned CPE routers that support 6RD in the not-too-distant future. Comcast is planning to use 6RD in its upcoming trials, and Google is supportive of it as well.
jhw
Um.
A request to an authoritative name server made over IPv4 should return an answer based only on the contents of the QUERY section. If the QUERY section requests an AAAA record, the server should either return RCODE 0 (NOERROR) and one ANSWER section per AAAA record (including 0, if there are none) if the label exists, or it should return RCODE 3 (NXDOMAIN) if the label does not exist.
That is what RFC 4074 states.
And the very first two sentences in RFC 4074 are, I quote with added emphasis, "This memo provides information for the Internet community. It does not specify an Internet standard of any kind."
So to refute your statements, (1) this is not a standard, (2) the behaviour you describe is neither recommended by the informational memo, and (3) the behaviour you describe has been discussed in DNSOPS and the consensus as I have read it is that you should not do that, since you are only testing IPv6 connectivity to the resolver, not to the client.
I may be wrong, if so, please let me know what part of that RFC I've missed or misread, or in which way I've misinterpreted your post.
I myself have had this issue with Linux and OS X clients in dealing with ISA. At first look its simply OS X screwing up, but when you take the time to go looking through it you realize that OSX is passing credentials perfectly fine to ISA and it is just how Microsoft designed the program that causes the issues.
"Slashdot, where telling the truth is overrated but lying is insightful."