I'm curious. Does anyone know if Apples statement actually means you must fully support IPv6 or if you just can't submit an app with hardcoded IPv4 addresses?
I just tested one of our apps that uses IPv4 only domain names and it passed according to the setup here "Test for IPv6 DNS64/NAT64 Compatibility Regularly":
"Happy Eyeballs" (aka Fast Fallback) was created and named by Dan Wing and Andrew Yourtchenko of Cisco. And yes, "Happy eyeballs" is the official name (named because of how happy the eyes of the users will be when they see how fast their IPv6 connection falls back to an IPv4 connection when connecting to a host that does not support IPv6).
Happy Eyeballs is primarily designed let users with broken networks continue connecting to dual-stack web servers. In some cases, it also covers up brokenness on the server end (e.g. publishing AAAA records to nowhere), but that's arguably more of a bug than a feature.
Back in 2011, content providers were terrified of enabling IPv6, because the data showed that ~0.1% of users would drop off the map due to broken networks. Happy Eyeballs helped to break the logjam.
Android 4+ supports IPv6 on both the cellular and wireless Ethernet interfaces. It only supports stateless address auto-configuration (SLAAC), however, and does not support DHCPv6 at all. (There's a 3+ year old Android DHCPv6 bug that was declined/closed late last year for, IMHO, unconvincing reasons.)
> CloudFlare’s graph shows a 1.07 increase in IPv6 requests under iOS9:
I'm curious: is this written correctly? The number of IPv6 request did go up by 1.07%. But the way it's phrased I would think they'd be referring to the percentage compared to before... a 33% increase.
Is this one of those cases where English can be ambiguous? Or to be correct does it need to be changed to something like "CloudFlare’s graph shows an additional 1.07% of requests use IPv6 under iOS9"?
"Per-milleage" [0] points (same relation to per-mille as percentage points are to percent; 1 percentage point = 10 per-milleage points = 100 basis points.)
[0] I have no idea if there is a standard term for this, and if there is, that's probably not it.
Your re-written version is definitely the correct way to phrase it. As written in the article, one would expect IPv6 to have moved from 2.92% to 2.95% (1% of 2.92 being 0.03), which is clearly not the case.
UK's at about 2% :-( mainly thanks to major ISPs like BT not supporting IPv6 for their residential customers. Although that looks like it'll change[1] by 2016.
I've visited http://test-ipv6.com/ using iOS9 and the results both over my mobile and cable operators are the same:
"No IPv6 address detected [more info]
It looks like you have only IPv4 Internet service at this time. Don't feel bad - most people are in this position right now. Most Internet service providers are not quite yet ready to provide IPv6 Internet to residential customers."
Obviously it's not the computers or mobile phones that are the problem.
Anyone have reading suggestions for an operationally minded infrastructure engineer who is paranoid about security and hates breaking production but still wants to take the IPv6 plunge?
For preparing your applications for the eventual flip-the-switch transition; pay particular attention to sections 4.2, which describes a strategy (supported by Linux) for handing off the grunt-work of dual-stack to the kernel while making your userspace code only speak IPv6: https://tools.ietf.org/html/rfc4038
For a quick overview of the process of making your infrastructure dual-stack (with an aim to eventually phase out IPv4); note that most of the burden is on your networking-equipment vendor to make this work, unless you make your layer-3 equipment in-house. So it's mostly a deployment challenge, rather than a development challenge. http://www.networkworld.com/article/2285078/tech-primers/ipv...
If I might recommend a good tunnel broker for allowing you to deploy IPv6 internally and get connectivity to the global v6 internet even without ISP support, take a look at Hurricane Electric.
Turn it on in your office first, then deploy to production. You'll gain working experience by turning up your office first. Experience with basic tools like netstat (you need -w now), experience with SLAAC and DHCP lite, quickly reading v6 addresses in :: notation, getting familiar with link local addresses (What do you mean every default router in the company is fe80::1?), etc.
I maintain many Debian VPS for my product and I had to ditch all IPv6-enabled servers because they were so slow. Like, they couldn't pass the apt-get step.
Which researching before posting this answer, I just noticed that it is due to DNS timing out for IPv6 requests [1]. IPv6 is hard to set up.
Is it that difficult to setup, or are people biased against it when something they've got works, and something new doesn't?
When IPv6 doesn't work, it's easy to blame it, turn it off and stick with IPv4 because it works. When IPv4 doesn't work it's a problem that has to be fixed to access the vast majority of services online.
If your DNS can't resolve A records, you'd immediately complain and get it fixed.
When was this? For a long time IPv6 suffered from people running services over tunnels via tunnel brokers, which resulted in horrible performance, MTU issues, timeouts and so on.
I have noticed recently that the situation has improved a lot, with more and more "real", native deployments coming online.
Interestingly, my iPhone 6 on Verizon's LTE in the US is running on IPV6. Fascinating that my campus computer is behind the times, relative to my cell phone.
Cell phones have felt the IPv4 exhaustion pressure a lot more strongly than most networks: network address translation is an interesting feat when the device may be moving in three dimensions at highway speeds. Thus the LTE networks have especially been pushing handset manufacturers to support IPv6 first and foremost and deprecate IPv4-centric APIs/applications/software as much and as fast as possible.
It's interesting too that you mention a campus computer in comparison: most American Universities were early adopters and thus got very large blocks of IPv4 addresses assigned to them, so in some cases they may be the last to deal with IPv4 exhaustion. (To be fair, though, many have given big blocks back for reassignment, doing what they can to have kept us from an exhaustion crisis before.)
Hmm. I don't own a modern iOS device myself, but my understanding was that the kernel support has been there for a long time, but until iOS 9, IPv6 wasn't actually enabled on cellular data networks. Upon investigating a bit more, it looks like that may have only been true for T-Mobile. But it's hard to find definitive statements one way or the other.
iOS8 has been reported to be dual stacked (v6 + v4 addresses) on the cellular side of things on Verizon and a bunch of other (mostly European) networks.
What Apple did with iOS9 is improve its address selection algorithm to prefer ipv6 in a majority of cases (if both the device and the server are dual stacked and unless v6 path latency is much greater than its v4 counterpart, v6 will be used).
In contrast, ios8 would prefer v4 over v6 when both endpoints were dual stacked.
Also, from what I've seen, iOS devices won't provision ipv6 addresses on their cellular interface unless their Carrier Profile says they should, so you might have encountered devices not getting ipv6 addresses even though they were connected to a dual stack network. Wifi always uses v6 if the network supports it.
IPv6 is good for anyone who want to identify individuals... NSA, FBI, Apple, Google, advertisers, trackers, etc. So happy to see rapid adoption and my fellow hacker news readers are excited about this too!
Even with privacy extensions, you can't "clear your cookies" start fresh with another IP address. There is no incognito mode with IPv6. There is not anonymous NAT.
It's no surprise to me that the companies pushing IPV6 the hardest are also the ones most interested in your personal data.
WTF?! - "When Apple add or remove a port or protocol such as a floppy drive, a disk drive or Adobe Flash support from its mainstream tech output, worlds change" ... chill out.
This is a classic case of correlation vs. causation.
iOS 9 users are apparently more likely to use IPv6, but there is nothing in the article or in the original blog post that supports the claim from the headline that iOS 9 "drives IPv6 uptake". A more likely explanation is that IPv6 is primarily used by tech savvy people, who are also more likely to upgrade quickly to the newest version.
Your explanation is also flawed, iOS adoption does not follow other software. It's already got a ridiculous number of users: http://www.digitaltrends.com/mobile/ios-9-adoption-rate-day-... and Apple is even more in your face with this update than past ones; there's a few regular popups, and they even let you schedule it for the night when you aren't using your phone.
Thanks for pointing to a source that actually explains what's happening. Now I understand.
I read the original article and the cloud flare post, and it seemed that they drew their conclusions from the pie charts; but in reality they just didn't reveal their sources.
I'm on a work retreat in a beach house right now with several coworkers, all with different roles in the company. I can tell you with absolute certainty that the folks with iPhones do not know what IPv6 is or anything meaningful about it, while the folks that do know about IPv6 are all using either a Nexus or Samsung phone. That isn't to imply Android users are more technical, but you really can't draw conclusions like the one you have drawn. Being technical does not mean you're guaranteed to drive adoption either. Hell, a plurality of the seriously techy folks I know are more likely to not fuck around with it for the fact that they know shit's gonna break and that's just one more thing to debug before calling $BigTelco to piss and moan about service.
1. They updated the Happy Eyeballs algorithm[1], which is what's caused the jump in the article.
2. Apple will mandate IPv6 support in all apps starting early 2016[2].
[1] https://www.ietf.org/mail-archive/web/v6ops/current/msg22455...
[2] https://developer.apple.com/news/?id=08282015a