Mac OS X Problem Puts Up a Block To IPv6 204
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."
Why would /. focus on OSX problems?... (Score:5, Informative)
...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 [fud.no] (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."
Help me understand this. (Score:5, Informative)
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?
Re:Mac Issue Or IPv6 Issue? (Score:5, Informative)
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.
Re:Mac Issue Or IPv6 Issue? (Score:5, Informative)
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.
Re:Help me understand this. (Score:0, Informative)
Nope. That's more or less exactly it. And the solution he proposes is basically a more aggressive timeout on IPv6 connectivity. It's not a bad plan, but it's hardly a big deal.
"Multi-protocol service advertises some unreachable nodes, failover works as designed after no more than 75 seconds".
Re:Help me understand this. (Score:5, Informative)
Mostly correct. One additional note: Many ISPs and routers don't do IPv6 well. So even in the "good IPv6 server, good IPv4 backup" case, many people will be hitting these delays because their ISP or router isn't IPv6 friendly. Since the web server can't force your ISP/router to upgrade, they have a choice. Do they serve only over IPv4 and get guaranteed performance, or do they move to IPv6 with an IPv4 fallback, thereby guaranteeing that their site will be dog slow for a fixed percentage of their users? We want them to move to IPv6 so the transition can occur smoothly over time. But a reasonable website operator might put off the move until the absolute last second, hoping that more ISPs and routers will be ready when they do switch. But of course, if no one is serving content over IPv6, ISPs have less motivation to upgrade. Yay Catch-22 situations!
Basically, if these browsers used the IPv4 fallback path smoothly, the IPv6 transition would be more painless; site operators would have one less reason to delay the switch, which would lead ISPs to have one more reason to speed the switch. But it all relies on the damn browsers behaving properly in the first place.
Re:Mac Issue Or IPv6 Issue? (Score:2, Informative)
The issue doesn't show up on Windows 7 at least. I have both v4 and 6to4 connectivity, and tests like this one [ipv6-test.com] show that my default protocol is still IPv4.
Re:Help me understand this. (Score:5, Informative)
not just browsers, two of the reported problems are core library related, not browser related.
6to4 is unreliable (Score:4, Informative)
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 [remlab.net], a Teredo implementation for Unices.
(Some more anecdotical evidence [transmissionbt.com].)
Re:IPv6 resolution with NTP (Score:2, Informative)
It looks like an NTP bug. I have seen this behavior on non-Macos machines.
Re:IPv6 resolution with NTP (Score:3, Informative)
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.
Re:Mac Issue Or IPv6 Issue? (Score:4, Informative)
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.
Re:Help me understand this. (Score:5, Informative)
Do I grok?
Not quite.
If a server is advertised in the DNS as being accessible using both v4 and v6, Unix-like systems (including Mac OS X) will first try v6, and then fall back to v4. This is the case on all Unices, although in the case of Linux it can be worked around by editing /etc/gai.conf.
When v6 is broken, this only works well if v6 sends you an error message in a timely manner. If v6 fails silently, just eats your packets, then you will only find out about it after a timeout -- meaning that it will take ages to fall back to v4.
Most of the time, this is not an issue, since v6 is pretty good at sending good error reports in a timely manner. The one exception is 6to4, which has an unpleasant tendency to fail silently (thus causing a timeout) when there is a v4 connectivity issue (such as a firewall).
The fix is simple -- only prefer v6 to v4 when you have native v6; if you're using 6to4, prefer v4 to v6. Windows does that right.
Re:Why would /. focus on OSX problems?... (Score:1, Informative)
problem occurs on windows too (Score:2, Informative)
Re:6to4 is unreliable (Score:3, Informative)
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.
It's worse than that: 6to4 is architecturally flawed.
A 6to4 CPE router can only monitor the availability of its own 6to4 relay. It can't do anything about the relay required for the reverse path. Service providers aren't sufficiently moved to deploy their own 6to4 relays because content providers and distributors aren't deploying the reverse path relays needed to make the system functional. The content providers and distributors in turn aren't deploying 6to4 relays because there are too damned many IPv4 firewalls that drop all incoming protocol 41 on general principle, so from their perspective, it's not worth the effort.
Worth noting: Teredo suffers from the same basic architectural flaw. Neither 6to4 nor Teredo should be used, if it can be helped at all.
Re:Chicago (Score:5, Informative)
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.
Re:Why the hate for 6to4? (Score:2, Informative)
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 [ietf.org], 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.
Re:It would be nice if people read the standards.. (Score:4, Informative)
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.
Comment removed (Score:3, Informative)