
iOS Supporting IPv6-Only Networks - r4um
https://developer.apple.com/news/?id=05042016a
======
chatmasta
People commenting here need to work on their reading comprehension. Apple is
not dropping support for IPv4. They are simply requiring that all apps _also_
support IPv6. The headline is confusing because of "only." But it's way
different than if it read "iOS supporting only IPv6" as some comments seem to
be implying. The change is that when a network is IPv6 only, apps must
function properly, whereas previously Apple tolerated apps that only worked on
IPv4. A better headline might be "Apple bans apps that only support IPv4."
(*Edited, guess it's not so easy to write the headline. :) )

~~~
Negative1
That's incorrect. Check out figure 10-3 here:
[http://j.mp/1NkSBaF](http://j.mp/1NkSBaF)

If your App does not support IPv6 on the official rollout then you will no
longer have network connectivity. If you use native platform functions you're
fine. If you use unix/bsd sockets, you're in trouble.

From the backend perspective however, IPv4 will be allowed... for now.
Basically what happens is the client is expected to send an IPv6 packet to the
phone carrier which then will translate it to IPv4 if needed. Since many big
cloud providers (like Amazon) still don't support a proper IPv6 solution this
approach will likely be around for quite some time.

~~~
eloy
Out of curiosity, why would anyone use Unix or BSD sockets on iOS if Apple
provides way better APIs?

~~~
mosburger
Maybe familiarity? Porting existing UNIX code to iOS (seems like that'd be
pretty rare)?

~~~
eloy
Hmm, good point. I guess that most of the apps that use BSD/Unix sockets are
libraries then.

------
makecheck
In some sense it is nice to see a push for progress on IPv6. And yet, it is
also _painfully_ clear that these networks are not ready, even for the big
sites like Google.

For instance, there are Google machines that are apparently IPv6 only. Over
the last several _months_ I have had major issues reaching Google domains like
Google.com, YouTube, etc. from my home Internet. It will either work
seamlessly, or hang seemingly forever when trying to look up one of the URLs
(which is oh so fun when I am trying to search Google frequently). It only
hangs for Google domains.

I dug up a forum post that was over a YEAR old where people finally figured
out that all of this crap was due to _IPv6_! They were literally turning off
IPv6 entirely on their Macs in order to make Google searches work again. The
symptom is a trace-route stumbling on the way to 1e100.net (one of Google’s
backbone domains). Sadly, I can imagine people screaming at their ISPs over
stuff like this.

I haven’t gone as far as to kill all of my IPv6 connections but I do have to
turn off WiFi and turn it back on to force some kind of a network reset
whenever this shit starts happening on my MacBook. Even then, the problem will
eventually return, and is pretty much guaranteed to return by closing the lid
and coming back later (how foolish of me to expect the Internet to be useful
when I open the lid?). Networking on the Mac is a mess, to say the least. Even
if this isn’t entirely Apple’s fault, it is entirely their problem for having
poor fault-tolerance. For instance, if I were them the first thing I’d do is
write a script to turn off the WiFi and turn it back on in case of a problem,
since that seems to solve 90% of issues all by itself.

~~~
ianlevesque
Anecdotes are anecdotes, IPv6 from Mac to Google has been stable for months
here :-/

Apple's happy eyeballs are specifically designed to counteract the present but
terrible IPv6 problem. It's difficult to tell if yours is IPv6 or just apples
notoriously unreliable wifi.

------
eloy
The negative thing about this is that they don't use a XLAT464 resolver. With
DNS64, they break DNSSEC. Android has an built-in XLAT464 resolver since
version 4.1 IIRC. So a carrier can't choose for this as long as there is a
vendor (Apple) that don't support it.

T-Mobile in the USA is currently using such a network, which is the best
transition method in my opinion.

~~~
X-Istence
DNSSEC would only matter to the end client (the iPhone in this case) if it
actually verified DNSSEC responses on the client, but it doesn't.

So unless your application contains a full DNS resolver that can walk the
roots itself, you are relying on the DNS server from your provider to provide
you with DNSSEC validated results. In this case the provider can simply return
results without any of the DNSSEC results and things will be more than happy
to continue on.

XLAT464 is not some sort of panacea, and requires a bunch of extra software
running on the device to properly function. NAT64 with DNS64 means you ignore
all of that, and only the provider has to know that translation is happening,
from a device perspective it looks like it is running on top of a IPv6 only
network with all endpoints only being IPv6. It's simpler, and maybe just the
push providers need to roll out IPv6 more aggressively.

~~~
eloy
> DNSSEC would only matter to the end client (the iPhone in this case) if it
> actually verified DNSSEC responses on the client, but it doesn't.

If you tunnel the DNS resposes over a TLS connection, then it would be secure.
This has been specified in an RFC recently.

And about XLAT464: Apple could've just added that to iOS, instead of this.
Google did the same a few years ago. If all the vendors would apply the same
transition mechanism, that would make it a lot more easier for carries to
deploy IPv6.

~~~
djrogers
>If all the vendors would apply the same transition mechanism, that would make
it a lot more easier for carries to deploy IPv6.

The nice thing about NAT64/DNS64 is that there is no support for anything
beyond IPv6 required on the client - it's entirely handled by the network, and
is completely transparent / invisible to the endpoints.

------
verelo
How do people plan to test their apps continue to work when this change goes
out?

I guess running the phone on an IPV6 only network and confirming it works
would be all it takes?

I'm sure there are things I'm missing, what are others doing?

~~~
X-Istence
Apple includes the ability to easily set up an IPv6 only hotspot. Using NAT64
and DNS64.

[https://developer.apple.com/library/ios/documentation/Networ...](https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW16)

~~~
ay
The only small caveat that should go along with that: that there is no native
IPv6 connection to the Internet, i.e. it is an IPv6-only hotspot with an
IPv4-only uplink to the Internet.

So, while the basic behaviour should be fine, it's best to set up a full-
fledged IPv6-only access network, to ensure you can test the usage of the
native IPv6 by the app as well, and verify there are no unexpected issues. (If
the app talks to the resources that are IPv6-enabled, that is).

~~~
djrogers
NAT64/DNS64 is completely invisible to the endpoint - there is zero
differentiation between how a client talks to a native IPv6 resource and an
IPv4 resource. All of the translation is handled by the network/DNS, so if
your app works with your device configured with only a v6 IP address while
supported by a NAT64/DNS64 network, you're good to go.

~~~
ay
Try FTP.

------
lucaspiller
Does this mean all backends that an app communicates with need to be
accessible over IPv6?

~~~
aaron42net
Recent Android on T-mobile US uses IPv6-only transport. T-mobile's DNS servers
are only asked by these devices to translate hostnames to IPv6 addresses. If
they can't find an IPv6 address, they will look up the IPv4 address for a
hostname, and pack it into the bottom 32 bits of an IPv6 address that routes
to a IPv6-to-IPv4 NAT device at T-Mobile.

This is called DNS64/NAT64 and has some small performance penalty. Making
content directly accessible by IPv6 removes the penalty.

~~~
djrogers
> This is called DNS64/NAT64 and has some small performance penalty.

While there may be some implementations that have a small performance penalty,
certainly not all of them do. The NAT can be done in FPGA or ASIC, and there's
not any difficult work being done to translate the DNS response.

* I've been installing NAT64 networks for several years

~~~
X-Istence
The performance penalty is that now my packets travel:

Phone -> T-Mobile -> NAT -> T-Mobile -> Internet -> My hosting provider

Whereas with IPv6:

Phone -> T-Mobile -> Internet -> My hosting provider

That NAT is an extra step, and will add a small amount of latency.

~~~
Dylan16807
The NAT, if set up right, would not cause the packets to take a different
route.

Changing the packet format requires nanoseconds, no more than normal packet
processing.

It's possible to set up anything wrong, but there's nothing about this
technology that would introduce latency when done correctly.

------
sandstrom
Until AWS, Azure and GC support native IPv6 there won't be many apps that can
use this.

~~~
r4um
AWS ELBs are reachable over IPv6
[http://docs.aws.amazon.com/ElasticLoadBalancing/latest/Devel...](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-
internet-facing-load-balancers.html#internet-facing-ip-addresses)

~~~
t0mas88
Not when using VPC, which almost any modern AWS deployment is.

~~~
r4um
True, though ClassicLink is an option. Launch ELB in EC2 classic and add
instances in VPC over classlink.

~~~
jvolkman
New accounts (as of 2013-12-04) don't even support classic.

[http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-
vpc...](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-vpc.html)

------
robert_tweed
Misleading title. Crucial bit from TFA: "Starting June 1, 2016 all apps
submitted to the App Store must support IPv6-only networking."

------
giovannibajo1
They have postponed a little bit the deadline, I think it was originally set
for September 2015. I saw they added some features in getaddrinfo() in iOS 9.2
and OS X 10.11.something, so they were probably postponing to make sure
developers had all the right tools for the different situations.

------
joeseeder
It's not like I'm a fan of Apple, but this is bold bold move.

See you all on the bright side of the Internet.

~~~
shortstuffsushi
Could you expand on that? It seems to me that it's just them saying "we want
people to start migrating," it doesn't actually push anyone off IPv4, and in
most cases (assuming you're using DNS resolution instead of direct IP
addresses), this is all under the hood changes that will "just work" for
consumers of their SDK.

~~~
joeseeder
I will expand. In the world of billions of devices online we are stuck to
hacks and magic over IPv4, when there is a simple IPv6 working already. All
because of uneducated and lazy IT personnel not doing their job.

Nowadays IT personnel is more inclined to create monsters of a fudge, than use
some tech which was not "invented" in last 5 minutes.

And I'm glad that Apple says "enough with this crap" and makes App Developers
think about portability.

App devs really don't need to do much more than put their APIs behind a DNS
with AAAA which works and use a hosting/cloud/caching/distribution provider
which is not stuck in 80s networks.

------
nashashmi
Can someone change title to "iOS apps supporting ..."

------
hobarrera
I've been using NAT64 at home for a few years now. Most apps out there handle
IPv6-only just fine, with steam and videogames being the exception.

A few older android phones had some issues, and I believe not MS product has
ever worked (but these were all guests, so I didn't really bother much).

I'm amazed that this requirement is coming so late to iOS, seeing how
(supposedly), apple tends so much to the quality of their apps.

------
ozarius
Does this impact the reachabilityForLocalWiFi method in apple's Reachability
sample, which appears to use an IPV4 address internally:

// IN_LINKLOCALNETNUM is defined in <netinet/in.h> as 169.254.0.0.

localWifiAddress.sin_addr.s_addr = htonl(IN_LINKLOCALNETNUM);

~~~
ay
I've found there is a related StackOverflow question, so I have answered in
detail there: [http://stackoverflow.com/questions/31938536/reachability-
and...](http://stackoverflow.com/questions/31938536/reachability-and-ipv6)

Short answer: Just Try The Connection.

------
danielrhodes
For those confused on how to add IPv6 support:

Assuming no hosting issues, when you find out your IPv6 address, simply add it
as a AAAA record in your DNS entry like you would for an A record.

------
takeda
Dies this mean that once the deadline approaches all apps that are no longer
maintained will be removed? Even if they work fine (minus IPv6 support)?

~~~
masklinn
Unlikely, Apple doesn't generally remove applications from the store.

~~~
jvdh
They will run into it when they submit an update however.

~~~
masklinn
GP specially mentioned unmaintained applications (e.g. old games and the like)

------
asdfaoeu
Are any providers running iPhones on ipv6 only? It seems like they will avoid
turning it on until the very latest as it doesn't support 464xlat.

~~~
subway
T-Mobile already runs an IPv6 only network in the US for most (all?) LTE APNs.

~~~
JoshGlazebrook
Verizon also is pretty high up there in IPv6 deployment

~~~
simon_vetter
They're doing dual stack, not ipv6-only with nat64/dns64.

------
morbidhawk
Does anyone knows what this means for NSURLConnection APIs? Will code using
that API have to be replaced with NSURLSession?

------
0x0
Is there a way to share DNS64/NAT64 when the internet is on the mac's wifi, if
you use usb or bluetooth to connect the iphone?

~~~
djrogers
SImply follow the instructions, but swap the "Share Internet From" interface
and "To Computer Using" interface.

------
elktea
Fantastic. Finally seeing a bit of a push. Incidentally, Australian IPv6 usage
jumped from 2% to 4% just this month.

------
askyourmother
I would be glad if apple products supported any network without all the
constant disconnects and link level problems. Especially shocking as the BSD
underlying stack is robust, it is all the Cupertino crap on top, the "helper"
daemons that are to blame!

------
ProAm
Apple breaking the world, one update at a time.

~~~
c1641287
They are trying to fix something that was known to be broken more than 30
years ago.

~~~
ProAm
What are they trying to fix? Apple is deleting content that is not associated
with content in iTunes. They think it an accurate delete but are 100% wrong
and have no DR or backup plan for this.... It would be simple enough for them
to use a shazzam like algorithm to verify what they are deleting matches what
is in iTunes and if not leave it.

I might be misunderstanding what you are stating though?

