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."
Chicago (Score:5, Funny)
Re:Chicago (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.
Re:Chicago (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
Re: (Score:3, Insightful)
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
Re: (Score:3, Funny)
5) "..and Boom!"
Re:Troll? (Score:4, Insightful)
Re:Chicago (Score:4, Interesting)
Re: (Score:2)
We are getting off base here but i think it holds a shadow of relevancy to the article as far as following suit is concerned.
When can we label Apple as being a vendor vs reseller, similar to the likes of dell / hp? Aside from MacOS these days their "sexy" consolidation of their hardware, is becoming more and more stock standard, e.g. their move over to Intel, etc. As far as MacOS development goes the more *nix implementation takes place the more they seem to be chipping away their own development and implem
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: (Score:2)
I would imagine they would supply a fair amount of effort in the Open Source community, I really didn't think about that till you mentioned it though.
For me, what would allow me to place Mac as brand I'd buy in my own mind would not so much be the source of their technology because lets face it, you can buy American cars with German built engines as its typical for vendors to source components from different suppliers.
More so how much of the computer was actually created by Mac, it's interesting to see beca
Re: (Score:3, Interesting)
At least they've supported IPv6 for a long while now, unlike some other OS companies.
Yeah, I was surprised when I read the summary. It made it sound like Apple was refusing the implement IPv6, or worse: maybe they were doing something crazy to black IPv6?
I was surprised because I kept seeing IPv6 settings in Apple products for several years now. I remember being surprised the first time I saw IPv6 settings in OSX; I don't remember when it was, but it was a while ago. I thought, "Huh, neat that they have that. Too bad I can't do anything with it." Apple has even had IPv6 support in the
IPv6 resolution with NTP (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
Re: (Score:2)
Does OSX interpret "disabled" to mean "enabled; but politely instruct userspace programs to ignore that fact"?
Re: (Score:2, Informative)
It looks like an NTP bug. I have seen this behavior on non-Macos machines.
Re: (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.
curl had same issue (Score:2)
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.
Re: (Score:2)
DNS using ipv4 resolves ipv6 addresses over ipv4.
Chicago? (Score:3, Funny)
Is this a Chicago [wikipedia.org] reference by the Mac OS X dev team?
Re: (Score:2)
What? No, 6to4 has been part of ipv6 for awhile. It's not an OSX-only thing by a long shot.
Mac Issue Or IPv6 Issue? (Score:3, Insightful)
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, 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 [apple.com] 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)
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: (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: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:Mac Issue Or IPv6 Issue? (Score:5, 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 [potaroo.net] for details.
It would be nice if people read the standards... (Score:2)
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 [ietf.org].
So he's basically intentionally misconfigured the DNS server, and then is complaining about IPv6 connectivity "not w
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.
Re: (Score:2)
Hi,
A few errors here:
/* Steinar */
Re: (Score:2)
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
Re: (Score:2)
My apologies, you are quite right on the other CPE devices supporting 6to4, and I will happily take your word for it that you must enable 6to4 by default, in which case I would amend my original statement to note that I think there is no issue on Apple's plate at all.
puts up a "block"? (Score:3, Insightful)
An interesting article none the less.
Not so simple (Score:2)
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)
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)
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)
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.
Re: (Score:2)
...Why? Certainly from the end-user perspective, it could still be quite smooth, if not for an issue like this.
Re: (Score:3, Funny)
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
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."
Re:Why would /. focus on OSX problems?... (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. That's what happens when you become a corporate behemoth.
Re: (Score:2, Troll)
or attempt to behave like one even tho the market share should not indicate that the behavior fits.
Re:Why would /. focus on OSX problems?... (Score:5, Insightful)
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)
Because OSX is an entire operating system used by 7.95% of users [w3counter.com], 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.
Upd
Re: (Score:2, Interesting)
Give me Adobe, Logic Pro/Pro Tools, Final Cut Pro, and KDE 12,
Re: (Score:2)
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)
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)
Re: (Score:2)
kdawson
Re: (Score:2, Insightful)
It's always worth pointing out when those who are so smug about being superior to Microsoft fux something up that Microsoft got right.
Re: (Score:2)
Because it's cool to hate Apple, or at least 'typical' Apple customers
There's also a bit of hate on opera. While there's not as much compared to apple, when you factor in market shares, they're probably a lot closer.
To make a car analogy, you don't see much hate on the Malaysian Proton Wira [wikipedia.org] in the states, but compared with how many there are driving around, there's probably a good amount of hate compared to a Ford Taurus.
Re: (Score:2, Flamebait)
Of course the 'typical' Apple customer is hated, when he complains about unfair press for a problem doesn't affect the current version of any other major piece of software.
Re: (Score:2, Insightful)
Because it's cool to hate Apple
Or, as per his post, because they are the only ones that haven't actually fixed the problem yet?
Re: (Score:2, Insightful)
Apple charges for security/bug fixes? Since when?
Oh, right, no they don't.
Re:Why would /. focus on OSX problems?... (Score:5, 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.
Re: (Score:2)
I'm using it and, despite what you may have heard, it does have several new features. But, primarily, it's a major optimization (somewhat akin to Win7 vs Vista, although Win7 got bigger interface changes, at least as I understand their design team [gizmodo.com]). That's particularly true in the Finder which was lagging way the hell behind the rest of the OS in performance -- for example, it's quite obvious they're now rendering all of the icons asynchronously rather than the f'd-up synchronous way they were before. They
Re: (Score:2)
I completely forgot to add that they really horked QuickTime. Major downgrade. Maybe they counted that as a negative against new features and called it a net new feature set of zero.
End of mainstream support (Score:2)
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.
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: (Score:3, Insightful)
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:Help me understand this. (Score:5, Informative)
not just browsers, two of the reported problems are core library related, not browser related.
Re:Help me understand this. (Score:4, Interesting)
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.
Re: (Score:2)
...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.
Re:Help me understand this. (Score:4, Insightful)
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.
Re: (Score:2)
You can tell by the destination address: 6to4 addresses are all in the 2002::/16 prefix.
Re: (Score:2)
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 [livinginternet.com]?
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:Help me understand this. (Score:4, Insightful)
Yes.
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)
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: (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
Re: (Score:2)
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.
Re: (Score:2)
6rd is a 6to4 replacement/extension pretty much designed to make that tunnel-for-a-single-site approach work reasonably
Problems with connecting to flash media server (Score:3, Interesting)
Here's a quick solution, say in a Flash? (Score:5, 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!
If OSX doesn't handle it properly... (Score:2)
Good joke but true (Score:2)
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.
problem occurs on windows too (Score:2, Informative)
Re: (Score:2)
Real problem (Score:3, Insightful)
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.
Strangely, they don't seem to mention... (Score:2)
Microsoft's implementations. I guess if it didn't work at all, they didn't report on it.
6to4 aside, mDNSResponder is a mess... (Score:2)
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
HTTP Header Rick-Rolled (Score:2)
X-Rick-Would-Never: Give you up
Why the hate for 6to4? (Score:2)
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)
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 pat
Re: (Score:2, Offtopic)
Re: (Score:2, Insightful)
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
Re: (Score:2, Funny)
Re:John C. Randolph, give us the real story. (Score:5, Funny)
Disregard that, I suck cocks.
-jcr
Re: (Score:3, Funny)
You're sexy when you talk tough.
Re: (Score:3, Funny)
You're sexy when you talk tough.
Not as sexy as you are when you put on that big funny hat, Your Holiness.
Re: (Score:2, Troll)
Re: (Score:2)
If you don't want your Mac to use IPv6, all you have to do is unselect it in the network prefs pane.
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" (Score:2)
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
Re: (Score:3, Insightful)
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.
Re: (Score:2)
I'm sorry, but having a delayed fallback to IPv4 still doesn't explain how this problem is a "block to IPv6".
A.
Re: (Score:2)
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 perio
Re: (Score:2)
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/ [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 ho
Re: (Score:2)
It is, kind of (Score:2)
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!