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."

20 of 204 comments (clear)

  1. Chicago by Anonymous Coward · · Score: 5, Funny

    25 or 6to4?

    1. Re:Chicago by Anonymous Coward · · Score: 5, Funny

      I just got off the phone with some one of my connections in Apple's product development department.

      Apparently the math required to implement IPv6 uses far too much battery and processor resources so Jobs opted to abandon its implementation.

    2. Re:Chicago by exomondo · · Score: 5, Funny

      Apparently the math required to implement IPv6 uses far too much battery and processor resources so Jobs opted to abandon its implementation.

      And it's not shiny, maybe one day they'll implement it as iPv6

    3. Re:Chicago by dr.+chuck+bunsen · · Score: 4, Interesting

      Nope, no iPhone here, Android. And even then I think that WebOS has the best mobile interface by far, just shitty hardware and no community. But I did leave my Linux desktop collecting dust ever since the OS X public beta disc arrived in my mailbox. But please, bash Apple all you want. The more they start to slowly ignore OS X in favor of fucking around with these silly mobile distractions, the less I like them. In fact, I was never what you would consider a fanboy, no iPod, iPhone, iAnything...I simply recognized the beauty of their nix offering and made the switch on merit alone. I did get excited when they released the Xserve line and the Xserve RAID. Had they followed through with that opportunity I feel like it could have been huge, but they ignored it, and it was never more than poop in a box. Of course, they had a huge obstacle trying to build a better server OS than Linux, as the GUI means nothing in that world. They probably recognized they couldn't win the server market with a bad ass GUI, and left it at that. Anyway, to be on topic, this isn't exactly news. It's already been documented, and can easily be fixed, and will work properly in a future update out of the box. I mean fuck, really? It's 2010, does the fucktards really think they are the first ones to do this, and that they've uncovered some major fuck up that is going to ruin the future of the internet. I doubt it. I think some asshole massaged a summary of a non-news story to get a bunch of fucktards like me to waste their time discussing it. At least they've supported IPv6 for a long while now, unlike some other OS companies... Quick, mod me down for not playing along!

    4. Re:Chicago by Drakino · · Score: 4, 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.

  2. IPv6 resolution with NTP by Anonymous Coward · · Score: 5, Interesting

    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

  3. Why would /. focus on OSX problems?... by sznupi · · Score: 4, 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 (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
    1. Re:Why would /. focus on OSX problems?... by the_humeister · · Score: 4, Insightful

      Apple is now hated slightly less than MS, which is pretty significant given how maybe a decade ago they were not hated at all. That's what happens when you become a corporate behemoth.

    2. Re:Why would /. focus on OSX problems?... by iluvcapra · · Score: 5, Insightful

      Apple is now hated slightly less than MS, which is pretty significant given how maybe a decade ago they were not hated at all.

      They weren't hated, they were held in contempt for making closed boxes that no one wanted to buy. What truly enrages the ilk of slashdot is that over the past ten years is that Apple has made a killing selling closed boxes, when all of the "common sense" of open source evangelism told them this was unpossible.

      --
      Don't blame me, I voted for Baltar.
    3. Re:Why would /. focus on OSX problems?... by larkost · · Score: 4, Insightful

      No, it wasn't. It was a large re-architecting of a lot of subsystems. This does not mean a lot for most users, thus they only announced a couple of user-visiable feautres. Not the same thing at all.

      For developers Snow Leopard was a rather feature-rich update.

  4. Help me understand this. by DdJ · · 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?

    1. Re:Help me understand this. by ShadowRangerRIT · · 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.

      --
      $_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
    2. Re:Help me understand this. by hitmark · · Score: 4, Informative

      not just browsers, two of the reported problems are core library related, not browser related.

      --
      comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
    3. Re:Help me understand this. by klapaucjusz · · 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.

  5. Re:Mac Issue Or IPv6 Issue? by wisnoskij · · Score: 4, 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.

    --
    Troll is not a replacement for I disagree.
  6. Re:Mac Issue Or IPv6 Issue? by Anonymous Coward · · 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.

  7. Re:John C. Randolph, give us the real story. by Anonymous Coward · · Score: 5, Funny

    Disregard that, I suck cocks.

    -jcr

  8. Here's a quick solution, say in a Flash? by failedlogic · · Score: 4, Funny

    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!

  9. Re:Mac Issue Or IPv6 Issue? by ekhben · · Score: 4, Insightful

    Almost certainly the latter.

    The article, and the accompanying 'raw' data, are not sufficiently detailed to draw the conclusion that OS X is at fault. The observation is that browsers with Mac OS X in the User-Agent string are more commonly using 6to4 addresses. The faulty assumption is that Mac OS X prefers 6to4 addresses to RFC1918 addresses.

    The reality is that getaddrinfo() on several platforms prefers IPv6 addresses over IPv4, if the host OS has an active IPv6 service. This is not unique to OS X, nor is it a bug.

    The interesting part is that the only CPE devices which support IPv6 are Apple Airports - the Extreme and Express models. They use 6to4 if there is no native IPv6 address provided. No ADSL modems available to consumers support IPv6 out of the box, ergo, almost every Airport user has 6to4 enabled. If one assumes that most Airport users are also Mac users, then the observation that excluding Mac OS X User-Agents from the result set also excludes the bulk of IPv6 users is not surprising.

    If Apple has an issue, it's that they enable 6to4 by default on a consumer device, when 6to4 is a known-bad mechanism that should be avoided.

    If one is running dual stack services, one should be aware of the most common pitfalls: see http://www.potaroo.net/ispcol/2010-05/v6hints.html for details.

  10. Re:Mac Issue Or IPv6 Issue? by Savage-Rabbit · · Score: 4, Insightful

    How is their a difference? if Mac did not properly support IPv6 then it is their problem.

    I'm not sure quite what he meant by "properly supported in the wild" but it sounded like he was trying to point out that sometimes you do get bugs because you implement things correctly but somebody else screwed up their implementation. A while back I had a problem connecting Linux and OS X based VPN daemons to some Microsoft VPN servers. At first it seemed obvious that this was Apple screwing up. After some considerable wiresharking and digging in Apple's source code I found out that Microsoft's VPN server sends malformed protocol messages which the Linux/OS X based counterparts try to parse according to the letter of the specification and exit with an error when they run into problems. Not that I'm trying to absolve Apple of all blame they can fuck up like everybody else and do so regularly, however that doesn't change the fact that it's entirely possible to render your software unusable by implementing it according to specifications. In a situation like that you can either change your software to take the buggy implementation by <insert name of manufacturer> into account or stick to your guns and piss off your users.

    --
    Only to idiots, are orders laws.
    -- Henning von Tresckow