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."
25 or 6to4?
There's also a bug in NTP on 10.6 that causes it to not fall back on IPv4 resolution if it can resolve over IPv6, even if IPv6 is disabled on the machine. So while not an IPv6 hurdle, it is a bug in IPv6 implementation.
RADAR bug is: 6736177
Is this a Chicago reference by the Mac OS X dev team?
"There is a way that seems right to a man, but its end is the way of death." Proverbs 16:25 (NKJV)
I wonder if this is a Mac issue or if IPv6 just isn't proper;y supported "out in the wild" yet? TFA doesn't mention a Windows test.
Hardly. Sounds like something that's pretty simple to fix before IPv4 addresses run out.
An interesting article none the less.
...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?
yes. i used to work for apple. i also like to put my initials at the end so i can feel special. it lets people know that i'm important. who cares that my name would already appear above the post. but to show that putting my initials are justified, i'll post anonymously.
-jcr
Kid, I'm not going to quit initialing my posts no matter how many times you newbs bitch about it. Get over it.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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.)
This presents a reason to avoid IPv6 entirely until it's fixed.
No. It's a reason to avoid (host-based) 6to4, which is too unreliable to be useful.
No. If I'm hosting a Web site, for example, this is a reason to avoid IPv6 entirely, since I can't expect all my n00b users to turn off 6to4 on their Macs.
The problem is that the fallback mechanism apparently takes upwards of a minute to kick in. Clearly the solution is to attempt to connect via both ipv4 and ipv6 simultaneously and then go with which ever connection succeeds first and drop the other one.
Disregard that, I suck cocks.
-jcr
Agreed, it's a reason to avoid IPv6 on the server. It is certainly not a reason to avoid IPv6 on the client altogether.
I ran into this problem a few months ago when trying to connect to a flash media server owned by a client - the media player running on the Mac would take over a minute to connect, and would fail at least once. The client insisted it was a bug in my code (I was the third programmer to be assigned the project after 2 others bailed), but my colleague and I uncovered similar horror stories with Mac OS 10.5, after my version of the player indicated a problem with the connection attempt timing out. The first two programmers couldn't prove this because their error trapping was non existent, so their players simply looked like they were crashing. Ah the joys of cross platform development!
You're sexy when you talk tough.
You are welcome on my lawn.
We'd like the transition to be smooth, such that it's already complete, before IPv4 addresses run out or become rare...
At this point, the transition is either going to be a very bumpy ride, or it's not going to happen at all. Smooth is no longer an option. Get used to it.
jhw
75 seconds by Apple web-browsing standards sounds like a long time. I seem to recall Mr Jobs pointed out that Flash is the only thing responsible for slowing down the Web on a Mac. Now, I have an iMac G5 and Flash doesn't slow down my experience by 75 seconds. So intstead of changing the TCP/IP stack in OSX, or fixing Safari, I think what would please Apple (in getting faster experience on the Web for the customers) would be to ask Adobe to make a Flash IPV6to4 wrapper for their TCP/IP stack.
I don't even know if this would even be possible, in fact I don't think it is. I leave the challenge to Adobe, and the PR to Apple to explain how Adobe fixed their 'problems'!
I have already accepted I used at least 75 seconds of my web browsing experience to write this post!
You're sexy when you talk tough.
Not as sexy as you are when you put on that big funny hat, Your Holiness.
This ain't rocket surgery.
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 :(
The root cause here is multipath confusion, but there are lots of other ways the transition will get bumpy.
Once the IPv4 address exhaustion wave starts to break, the Internet community is going to be dealing with all manner of breakage caused by some parts of the Internet resisting the transition to IPv6 while other parts are being forced into the transition by financial considerations. These different parts will be intermediated by things like NAT64 and DNS64, as well as other evils like DS-Lite and the associated AFTR boxes. Meanwhile, there will still be crazy things like 6to4 and Teredo kicking around. For the transition to go smoothly, all these interlocking parts have to work perfectly... everywhere... and we know from long experience that this just cannot happen.
This will all seem fairly familiar to anyone who survived the transition to IPv4 a generation ago. But if you're a young gun, and all you've ever known is the IPv4 we have now because the old-timers spent a long damned time years and years ago making it rock-solid before you got here, then you're about to be schooled.
Get ready for life during wartime—that's what I say.
jhw
The real problem here is not some obscure technical problem on the Mac, but rather that it took someone obscure in Norway to go look and see if IPV6 works. How this IPV6 cutover is going to proceed with the current level of interest, I don't know.
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.
Yes, but they were only funny the first 500 times. Really, these kind of jokes pop up at the top of *every* article that has even remotely to do with Apple.