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.
jcr, what's the real story behind this? You were heavily involved in the quality assurance of Mac OS X when you worked at Apple, were you not?
Hardly. Sounds like something that's pretty simple to fix before IPv4 addresses run out.
An interesting article none the less.
"Mac OS X, older versions of Opera, and a few Linux distributions exhibited problems"
What? That's like saying my Rolex, Fishing Poll and some other wristwatches have an issue with something. Sometime tells me the OS X in the headline was just for sensationalism.
i have ipv6 disabled on debian and fc13. im not sure if ubuntu has it enabled by default either??
he who controls the spice controls the universe
...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?
couldn't find a juicier and more misleading title? zealous jackass.
This presents a reason to avoid IPv6 entirely until it's fixed. We'd like the transition to be smooth, such that it's already complete, before IPv4 addresses run out or become rare...
I use OS X with ipv6, multiple protocols, intranet and internet. It works for me and I have no idea what they're talking about.
I've read it a few times, now and it just seems to 'bounce off' my brain.
Still not even sure what it's about.
Weird.
The two points seem to be 'OS X is slow in falling back to an IPv4 address' and 'OS X seems to prefer IPv6 to IPv4'. It's perfectly obvious that OS X needs to improve its handling of certain connectivity problems, but how is *either* of these a "block" to IPv6?
A.
(who turns off IPv6 tunneling in his router because the gateways seem to go away a lot)
...bringing you cynical quips since 1998
I see it as a two birds one stone sort of scenario.
Advantage 1 - Upgrade the internet have more IPs for everyone.
Advantage 2 - Stop Macs from polluting our internets with their gay Metro-sexual; Prius driving; Jobs loving; Turtleneck sweatery asses.
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.)
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.
I'll bet iPhone OS doesn't have this problem.
Well the last time i saw Jobs he wasn't looking that great. Once he "becomes more powerful than you can possibly imagine" then you'll need the iOuija accessory - and that won't come cheap.
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!
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!
While Apple (just like Microsoft) charges for major releases (e.g., 10.5 to 10.6), minor releases (e.g., 10.6.2 to 10.6.3) are free of charge
Apple could refuse to fix the defect in 10.5 once it enters whatever Apple calls its counterpart to what Microsoft calls "extended support". Consider this: "Apple has confirmed this behavior as a defect in Mac OS X version 10._. A fix will not be released through Software Update because it is not a security issue." So to get the bug fix, users would have to buy the upgrade to a supported operating system, which in some cases involves buying new hardware.
...then CLEARLY no one needs to use IPv6! Everyone knows that OSX and Macs only provide the functionality you need, not what you think you want...
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
Come on mods. Get some sense of humor. Some things are funny even if they make fun of your favorite toy.
I'm sorry, but having a delayed fallback to IPv4 still doesn't explain how this problem is a "block to IPv6".
A.
...bringing you cynical quips since 1998
Wait till Steve Wonderful Jobs comes out with a PROOF that ipv6 problem on OS X is definitely due to flash. And then see the fanbois in media lap it up.
In fact you are right, as people (besides nerds and enterprise) just started to have IPV6 capability, it wasn't needed until last minute. Now all those heavily modified, millions of different configurations, badly managed ISPs, needless "tweaking", WoW playing machines gets on the IPV6 network, the bugs become visible.
Well, 8 minutes after you posted that flamebait (!!!), someone posted this comment:
"Problems with connecting to flash media server (Score:2, Insightful)"
Now, as you see, it is somehow connected to flash! Steve was right!
It happened with 'curl' , I mean if you want to compile your own, newer curl. There was a severe problem with curl and ipv6 regarding domain resolve on os x and package maintainer and/or curl developers fixed the issue.
I am not that advanced to know the specifics but ntp thing really sounds like similar. I guess it must be on curl's bug database or mailing lists. BTW, stock curl of OS X (don't know 10.6 one) already acts a bit strange especially while resolving domain names.
Have any of you ever tried bringing up a Mac on an ipv6-only network ? Manual config is the only way. Can't even automatically acquire a DNS server without falling back to v4. DHCP6 has been an official standard for how many years now ?
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 :(
due to the problem, server operators delay support for IPv6 to avoid losing customers. it certainly "blocks ipv6 adoption."
For me as a website operator the best solution would be to have this as a DNS option. Some flag that is returned with the DNS request that says to the browser "Connect to IPv4 and IPv6 simultaneously if IPv6 works within X milliseconds of IPv4 note that in the DNS cache and use IPv6 for all subsequent connections otherwise use the IPv4 connection and drop IPv6". If that was an option I would add IPv6 support today. Otherwise it's just a waste of time. It would also be nice if, during the transition period, the OS could figure out if the ISP supports IPv6 and, if not, auto disable it but I can't think of a non hacky way of doing that.
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.
There was a known issue with one of the popular mac browsers used its own async resolver and screwed up IPv4/IPv6 coexistance.
There are people who have gear misconfigured to the extent their operating systems think they have IPv6 connectivity when they don't or they have extremely poorly performing connections via tunnels that are essentially worthless.
There are several software projects who undertook IPv6 implementation projects without fully understanding the problem space (such as not using getaddrinfo)
Older versions of Linux borked up getaddrinfo worse than the MAC problems. Thankfully this has all been fixed.
The only way IPv6 is going to get to production quality is if its actually used. We need to learn our lessons and move on.
Content providers are generally leery of enabling IPv6 on their services, because there's a large number of people with bad IPv6 implementations at some point in the network path that would either experience significant delays, or the Blank Page of Doom.
Take Google. On a host behind a Hurricane Electric tunnel, I can ping6 2001:4860:8005::6a just fine, and even use http://2001486080056a/ to search the Web over v6. But if I do a DNS resolution of www.google.com, I don't get AAAA records, only A. On a host with a Global Unicast address, known to Google to be good, a DNS resolution of www.google.com gets a set of AAAAs, including 2001:4860:8005::6a. Google use DNS tricks to only serve IPv6 to clients they believe can correctly receive it. On the other hand, I can always use http://ipv6.google.com/ and take what I get.
A number of content providers use ipv6.example.com to provide a trial v6 service, because it's safer. Simply going dual stack, even if you mitigate the risks of 6to4 and tunnels, will cause some problems for some clients.
That's why anything that contributes to problems can be considered a block to IPv6 deployment: because it provides an incentive to stick with v4 and expect v6 only clients to pass through a CGN or NAT-PT or similar horrible hack.
Microsoft's implementations. I guess if it didn't work at all, they didn't report on it.
mDNSResponder--which Apple now uses for all DNS resolution--is broken with IPv6. If a cached nonexistent record for IPv4 exists, it won't even try to look up the IPv6 address. More than a few places running IPv6 set those records to expire more quickly, and thus IPv6-only hosts effectively become a black hole to OSX most of the time.
In any case, I had a look at the source, and it is one seriously ugly mess. I can't believe that Apple would replace a critical system component with such a flakey piece of code. (Or rather, I would like to not believe it. As long as it sort of works for most people though, Apple simply won't care.)
Anyway, the IPv6 code is just for show, so they claim it as a "feature." It is clearly obvious that no one at Apple actually uses it though.
X-Rick-Would-Never: Give you up
It would be nice if people read the standards...
FWIW, I'm pretty sure the actual problem is DNS. Specifically, he's misconfiguring things such that IPv4 DNS requests return AAAA records indicating an IPv6 address when there is no end-to-end IPv6 connectivity. A DNS server that is queried via IPv4 should only return IPv4 addresses to the querant. See also http://www.ietf.org/rfc/rfc4074.txt.
So he's basically intentionally misconfigured the DNS server, and then is complaining about IPv6 connectivity "not working" for 6over4 when he's not running dual stacks and Ipv4 bridging of IPv6 traffic on both ends (via proxies or via relay routers; see http://www.ietf.org/rfc/rfc3068.txt for details).
IPv6 will *never* take off if people keep putting bandages on IPv4 to keep it alive instead of configuring things correctly. It's time to shoot IPv4 in the head. Google is completely reachable via the 6bone, and they are configured correctly; pretty much if you are anywhere in Silicon Valley, you probably have 6bone connectivity to Google, Apple, and a number of other companies. Also all U.S. Federal agencies have been upgraded to IPv6 since early 2008.
-- Terry
But how will people learn that their slowness is due to the operating system attempting to use IPv6 over a router or ISP taht supports only v4?
They will look down for the word "Norway" printed on their country...
-- Terry
I've been using 6to4 ever since the 6bone shut down, and I've had no problems with it. In fact, it seems to me there are only two possible problems with 6to4 generally:
1. Bastard ISPs could, if they deeply inspect packets, see 6-in-4 packets generally as different or undesirable or whatever and do bad things like they do with bittorrent.
2. The 6to4 anycast default route as a mechanism to get from 6to4 space to the "real" IPv6 space can sometimes send your packets to a non-optimal gateway. The fix for this is simply for more such gateways to be created - preferably one (or more) per ISP - so that the traffic can be routed optimally.
I wanted to opt into Google over IPv6, but when I wrote them they told me to pound sand because I was using 6to4.
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.
Well you can find RFCs but you obviously need to work on the reading part.
"A DNS server that is queried via IPv4 should only return IPv4 addresses to the querant."
Absoultely not true. The document makes no reference to the underlying transport used to query the DNS server. All its saying is an AAAA record must return an IPv6 address not an IPv4 address which should be pretty obvious.
The computer needs to know if it has IPv6 connectivity so it can decide whether to 1. Send an AAAA query and 2. attempt connection via IPv6. The issue is that some computers think they have IPv6 connectivity when in fact the connectivity is a result of a network misconfiguration or a poor/unusable IPv6 tunnel.
In fact WindowsXP does not and never will support DNS queries via IPv6. For WindowsXP to work in an IPv6 environment requires IPv4 for at least DNS resolution.
Hi,
A few errors here:
/* Steinar */
(This comment is of course GPLed.)
gmhowell, do you even have a CSC or CIS degree? No. What exactly then qualifies you as somekind of expert on this subject then?? Your talking??? LMAO, not. By the way, you fake, what you're speaking of is called a condition being "aysmptotic", you uneducated moron.
As a HE user you can just use their DNS servers for google.com and
you will get AAAA's returned.
zone "google.com" IN {
type forward;
forward first;
forwarders {
2001:470:20::2;
74.82.42.42;
};
Bug and security fixes are free.
Not for all versions. For example, I don't think Apple is still fixing System 7. How many Mac OS versions back does Apple go before declaring end of life?
From a server standpoint, Apple was one of the first commercial companies with IPv6 support on non-server machines - it was in the FreeBSD 4.3 baseline, and Apple was one of the first to enable it by default OOTB (X.2 timeframe, I believe). The problem indicated is only that the fallback from IPv6 to IPv4 is slow on macs (a client issue).
Apple kind of has become the Blizzard of the hardware world - they don't really innovate that much and they usually lag behind the market in terms of features, but they do have a certain polish and consistency (accessibility) in design that other vendors lack. I personally haven't bought an Apple product in over 10 years and don't play WoW, but its hard to deny that both are successful at what they do.
A Linux-based but not totally open OS that only runs dinky JS-based applets?
A better mobile OS already exists, it's Maemo 5, you can install/compile/run/distribute/sell whatever the hell you want, no strings attached. It's mostly open source with a few closed-source components (some of the included apps and drivers) but its successor will be 100% FOSS.
"When information is power, privacy is freedom" - Jah-Wren Ryel
I wonder if this explains why in the last several months Safari on my mac seems to go to sleep, while loading over and over again. I kind of doubt it is the case.
www.Migrainesoft.com - Computer giving you a headache? We can fix that!
Windows XP was end of lifed at the start of the year. Retire the machine already.
That XP doesn't support IPv6 based DNS request is not an argument against IPv6, it's an argument against XP.
-- Terry
due to the problem, server operators delay support for IPv6 to avoid losing customers. it certainly "blocks ipv6 adoption."
So the server operators delay support for IPv6 because ISPs don't support IPv6, and ISPs delay support for IPv6 because server operators don't support IPv6 - and clearly Apple blocks Pv6 because they support IPv6 instead of just using IPv4 like everyone else does to avoid this problem. And by problem we don't mean lacking support for IPv6, but a delay that for whatever reason wouldn't make customers force ISPs and server operators to actually adopt IPv6. Because customers are stupid and certainly wouldn't do something as obvious as this.
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck