Follow Slashdot stories on Twitter


Forgot your password?

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, Redpill Linpro did an experiment with regard to IPv6 on one of the largest online newspapers there ( 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."
This discussion has been archived. No new comments can be posted.

Mac OS X Problem Puts Up a Block To IPv6

Comments Filter:
  • Chicago (Score:5, Funny)

    by Anonymous Coward on Tuesday May 04, 2010 @05:55PM (#32091488)
    25 or 6to4?
    • Re:Chicago (Score:5, Funny)

      by Anonymous Coward on Tuesday May 04, 2010 @06:56PM (#32092074)

      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.

      • Re:Chicago (Score:5, Funny)

        by exomondo ( 1725132 ) on Tuesday May 04, 2010 @07:19PM (#32092260)

        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

        • Re: (Score:3, Insightful)

          by Anonymous Coward

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

          Ahh yes your right, It has to have Apple's very affective from of marketing voodoo attached to it.

          1) Wait until IPv6 is rolled out across the internet
          2) Wait another 5 years for the rest of the industry to be using it without any problems
          3) Hold a press conference showcasing a prototype of a Mac running on IPv6
          4) Claim it as a new innovation that the world has never seen and generate ridiculous amounts of unnecessary media hype
          5) ?????
          6) Profit

  • by Anonymous Coward on Tuesday May 04, 2010 @05:55PM (#32091490)

    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

    • Do I even want to know how NTP, presumably running largely in userspace(if OSX behaves like other unixes in that regard) is even capable of resolving over IPv6 if IPv6 is disabled?

      Does OSX interpret "disabled" to mean "enabled; but politely instruct userspace programs to ignore that fact"?
      • Re: (Score:2, Informative)

        by Mike Rice ( 626857 )

        It looks like an NTP bug. I have seen this behavior on non-Macos machines.

      • Re: (Score:3, Informative)

        by Anonymous Coward

        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.

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

      • by WarJolt ( 990309 )

        DNS using ipv4 resolves ipv6 addresses over ipv4.

  • Chicago? (Score:3, Funny)

    by DarkKnightRadick ( 268025 ) <> on Tuesday May 04, 2010 @05:55PM (#32091496) Homepage Journal

    Is this a Chicago [] reference by the Mac OS X dev team?

  • by WrongSizeGlass ( 838941 ) on Tuesday May 04, 2010 @05:57PM (#32091520)
    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.
    • by wisnoskij ( 1206448 ) on Tuesday May 04, 2010 @06:11PM (#32091684) Homepage

      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.

      • by Savage-Rabbit ( 308260 ) on Tuesday May 04, 2010 @09:51PM (#32093330)

        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.

        • Re: (Score:3, Informative)

          by falcon5768 ( 629591 )
          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.
    • by Anonymous Coward on Tuesday May 04, 2010 @06:23PM (#32091790)

      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 ( ), 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: (Score:2, Informative)

      by Anonymous Coward

      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.

    • by ekhben ( 628371 ) on Tuesday May 04, 2010 @08:59PM (#32092990)

      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 [] for details.

      • 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 [].

        So he's basically intentionally misconfigured the DNS server, and then is complaining about IPv6 connectivity "not w

        • by ekhben ( 628371 ) on Wednesday May 05, 2010 @03:04AM (#32094958)


          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.

        • by Sesse ( 5616 )


          A few errors here:

          • The host has fully working IPv6 connectivity on the AAAA record it advertises. You could easily have checked this given the data in the report.
          • This is a 6to4, not 6over4, which is something completely different.
          • The 6bone has not existed for years.

          /* Steinar */

      • by Sesse ( 5616 )

        No, the reality is that getaddrinfo() on most platforms actually follow RFC3484 and prioritize IPv4 over 6to4. (There's a clear distinction in the RFC between 6to4 and other forms of IPv6.) OS X doesn't and uncritically tries IPv6 -- that is, of course, assuming you don't crash into any of the other resolver bugs they introduced in 10.5.

        It should be said that if you follow RFC3484 to the letter, 6to4 will be preferred over NAT-ed IPv4. However, that was most likely just an oversight in the standard (the dra

  • puts up a "block"? (Score:3, Insightful)

    by BitwiseX ( 300405 ) on Tuesday May 04, 2010 @05:58PM (#32091534)
    Hardly. Sounds like something that's pretty simple to fix before IPv4 addresses run out.
    An interesting article none the less.
    • 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...

      • Re:Not so simple (Score:4, Interesting)

        by klapaucjusz ( 1167407 ) on Tuesday May 04, 2010 @06:45PM (#32092002) Homepage

        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.

        • Re: (Score:3, Interesting)

          by XanC ( 644172 )

          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.

          • Re: (Score:3, Insightful)

            Agreed, it's a reason to avoid IPv6 on the server. It is certainly not a reason to avoid IPv6 on the client altogether.

      • Re: (Score:3, Insightful)

        by j h woodyatt ( 13108 )

        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.

        • by XanC ( 644172 )

          ...Why? Certainly from the end-user perspective, it could still be quite smooth, if not for an issue like this.

          • Re: (Score:3, Funny)

            by j h woodyatt ( 13108 )

            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 a

  • by sznupi ( 719324 ) on Tuesday May 04, 2010 @06:07PM (#32091638) Homepage

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

    • by the_humeister ( 922869 ) on Tuesday May 04, 2010 @06:22PM (#32091782)

      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.

      • Re: (Score:2, Troll)

        by hitmark ( 640295 )

        or attempt to behave like one even tho the market share should not indicate that the behavior fits.

      • by iluvcapra ( 782887 ) on Tuesday May 04, 2010 @08:24PM (#32092770)

        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.

    • Re: (Score:3, Insightful)

      by OnlyJedi ( 709288 )

      Because OSX is an entire operating system used by 7.95% of users [], while Linux is used by only 2.34% of users. Opera is just a web browser used by only 1.42% of users.

      For those 1.42% using Opera, it's rather easy to upgrade to a new version. As already stated there are versions available that fix the problem, and only requires a simple application install. Even if Opera never released a patched version, moving to Safari/Firefox/Chrome/(gasp!)IE isn't too hard, at least when compared to moving to a new OS.


      • Re: (Score:2, Interesting)

        If you leave corporate america out of those stats OS X is doing rather well. And they dominate the notebook market. I love OS X, I really do. But I dream of the day that Linux gets a really great GUI, and the Adobe Suite. I'd be a desktop Linux user in a second. I was pretty stoked about KDE4. But I tried it. Still just not there. Oh, add a full featured stable DAW, and video editor to that as well. I'll pay for pro apps on Linux, no problem.

        Give me Adobe, Logic Pro/Pro Tools, Final Cut Pro, and KDE 12,
        • I was pretty stoked about KDE4. But I tried it. Still just not there.

          It does seem to get closer all the time. But yeah, if you tried it around the actual v4.0 release, it was a clusterfuck.

          add a full featured stable DAW, and video editor to that as well.

          Ardour is getting better, and I remember Film Gimp being used by ILM.

          • Re: (Score:3, Funny)

            by gmhowell ( 26755 )

            Linux as a whole gets halfway there with each passing year. I'm sure they'll eventually make it all the way.

            (Wish I could find a link to the math problem I'm thinking of)

    • kdawson

  • by DdJ ( 10790 ) on Tuesday May 04, 2010 @06:10PM (#32091676) Homepage Journal

    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.


    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: (Score:3, Insightful)

      Problem meets Nutshell.
    • by ShadowRangerRIT ( 1301549 ) on Tuesday May 04, 2010 @06:29PM (#32091848)

      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.

      • by hitmark ( 640295 ) on Tuesday May 04, 2010 @06:42PM (#32091974) Journal

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

      • by ceoyoyo ( 59147 ) on Tuesday May 04, 2010 @07:47PM (#32092496)

        The problem is, no website is going to ONLY serve over IPv6, so there's no incentive for ISPs to support it. The incentive HAS to come from something new. That can either be new websites (or ISP subscribers) that can't get an IPv4 address, in which case we have a crisis, or some new client-side application that people would like to use.

        A nice regulation requiring that ISPs serve unique IP addresses to any subscriber device that asks for one would get them to switch to IPv6 in a hurry, and we'd all have easy remote access to all our machines.

        • ...and we'd all have easy remote access to all our machines.

          And who would want such a thing?

          OK, you would, obviously. I, too, would appreciate it. Most /.-readers might find it useful. and just about everyone else would hate it, since it would diminish the (perceived) security of their machines.

    • by Trepidity ( 597 ) <> on Tuesday May 04, 2010 @06:30PM (#32091862)

      It seems like it depends on the connectivity of the host as well. If the server has good IPv6 and good IPv4 connectivity, this problem can still manifest itself if the client has good IPv4 connectivity, but crappy IPv6 connectivity only via a 6to4 tunnel. In that case, OSX will prefer the 6to4 tunnel rather than the native IPv4 connection. If it were all native connections (native IPv6 and native IPv4), it'd be much less of a problem; it really seems to be preferring the tunnel that's causing all the reliability issues. The fix (applied to glibc, among others) seems to be to distinguish between native IPv6 connectivity and tunnel-based connectivity, and deprioritize tunnel-based connectivity.

    • It's an issue as we (the entire Internet, not Slashdot readers) slowly crawl towards IPv6 adoption over the next century.

      Or did you think there was going to be another big switch []?

    • by klapaucjusz ( 1167407 ) on Tuesday May 04, 2010 @07:21PM (#32092276) Homepage

      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.

    • by ekhben ( 628371 ) on Tuesday May 04, 2010 @08:19PM (#32092738)


      IPv6 tunnels, firewalls set to drop ICMP, removal of router fragmentation in IPv6, and application name resolution behaviours combine to cause a noticeable number of IPv6 connections to open successfully, but not send data.

      If you have the choice, avoid tunnels, both by using a native v6 connection yourself, and by only peering with known-good native v6 entities, which is what Google do.

      If you have the choice, avoid dual stack. Test it, by all means, so you're ready to provide service should v6 actually work, but avoid presenting AAAA and A records for the same name.

      If you have no choice, set your interface MTU to 1280 bytes, which resolves a large number of the problems.

  • 6to4 is unreliable (Score:4, Informative)

    by klapaucjusz ( 1167407 ) on Tuesday May 04, 2010 @06:43PM (#32091980) Homepage

    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 [].)

    • Re: (Score:3, Informative)

      by j h woodyatt ( 13108 )

      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

    • by Morth ( 322218 )

      It's easy to make 6to4 more reliable for your site though. What you have to do is add a local 6to4 router instead of relying on the free ones provided by who knows who... You still have to rely on someone else for the packets to reach you from the client, but in my experience that way is much more likely to work.

      Same goes for teredo. You'll have a much more reliable connection if you run a local teredo relay. That's what the consultants should consult, not sure they do.

      • by Trepidity ( 597 )

        6rd is a 6to4 replacement/extension pretty much designed to make that tunnel-for-a-single-site approach work reasonably

  • by NoSleepDemon ( 1521253 ) on Tuesday May 04, 2010 @07:08PM (#32092182)
    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!
  • by failedlogic ( 627314 ) on Tuesday May 04, 2010 @07:43PM (#32092468)

    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!

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

  • 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
    • It's so common on windows (especially with specialized network services like flexlm) that we've had to completely disable ipv6 via GPO. Clients would never failover.
  • Real problem (Score:3, Insightful)

    by countach ( 534280 ) on Tuesday May 04, 2010 @10:18PM (#32093490)

    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.

  • 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 c

  • BTW, if you check out the HTTP headers for, you'll find out you've been rick-rolled.

    X-Rick-Would-Never: Give you up

  • 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 i

    • Re: (Score:2, Informative)

      by j h woodyatt ( 13108 )

      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 pat

God made the integers; all else is the work of Man. -- Kronecker