iOS Supporting IPv6-Only Networks

https://developer.apple.com/news/?id=05042016a

by r4um • 10 years ago

205 108 10 years ago

developer.apple.com

0x0• 10 years ago

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?

scurvy• 10 years ago

Probably possible with ND proxy if they add it in?

Good question.

djrogers5• 10 years ago

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

giovannibajo1• 10 years ago

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.

asdfaoeu• 10 years ago

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.

subway2• 10 years ago

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

JoshGlazebrook• 10 years ago

Verizon also is pretty high up there in IPv6 deployment

simon_vetter2• 10 years ago

Requiring all apps to work on ipv6-only DNS64/NAT64 networks will let Apple do without 464xlat entirely, as no ipv4-only app will be left on the app store.

lucaspiller• 10 years ago

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

subway2• 10 years ago

No. The device only needs to be able to function on IPv6-only networks where NAT64 and DNS64 are present.

aaron42net• 10 years ago

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.

djrogers5• 10 years ago

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

btown• 10 years ago

NAT64/DNS64, presumably run by any ISPs who desire to provide only IPv6 addresses to their clients, would allow those clients to connect to IPv4 backends by dynamically responding to DNS queries for IPv6 addresses with a requisitioned mapping address. Apple explains it well in the link in the OP:

https://developer.apple.com/library/tvos/documentation/Netwo...

Sadly, it seems this breaks WebSockets in certain cases. Most WebSocket apps have fallbacks, BUT sometimes these long-polling fallbacks are unreliable on PaaS systems that timeout HTTP(S) connections, such as Heroku. I think that Heroku keeps connections alive if there's a heartbeat, so Meteor apps on Heroku will likely still work. But there are definitely apps out there that roll their own WebSocket connections without well-designed fallbacks, and it's likely they will no longer be accepted.

verelo• 10 years ago

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?

qjighap• 10 years ago

This is oddly worded to me and likely going to cause grief as it sounds like your app can only run on IPV6. I would interpret is as your app must be able to run internet connected when IPV4 is not available. This likely includes your local loopback if you are using 127.0.0.1 (which I infer from the hard code statement).

Or another weird to put it, your application must be IPV6 with the option of a IPV4 add-on.

easytiger• 10 years ago

This is the way i read it too. No big deal really.

X-Istence7• 10 years ago

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

https://developer.apple.com/library/ios/documentation/Networ...

ay6• 10 years ago

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

ay6• 10 years ago

I've written a small doc on how you can set it up (not going into the process of the IPv6 network itself, but just talking about setting up NAT64...): http://docwiki.cisco.com/wiki/IPv6_only_setup_with_NAT64

If your ISP does not give you IPv6, you can get it for example at tunnelbroker.net - though beware that the properties of that connection, primarily when talking about MTU will be slightly different than from the "native" one.

Feel free to give a read and leave the feedback - I'll be happy to tweak the document to make it more friendly/useful.

sandstrom2• 10 years ago

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

kuschku• 10 years ago

OVH’s cloud supports native IPv6.

ryao• 10 years ago

The HE tunnel broker can be used there.

vetinari• 10 years ago

These apps can use it anyway.

It is for carriers to be able to deploy IPv6 only networks. If your service is hosted on IPv4-only host, from the perspective of the device, you will be behind NAT64.

If your service is on IPv6-reachable host, you will get the bonus in the form of a direct connection.

sandstrom2• 10 years ago

Good point, thanks for adding this!

Still, I think it's sad that none of the three large cloud providers have IPv6 support.

Digital Ocean, OVH and a few other has it though. Still, most are with one of the big three.

mrweasel• 10 years ago

And until there are apps that can use IPv6, there won't be a need. I think it's fine that Apple attempts to push IPv6, because no one else seems to be doing anything, well no big companies at least.

davorb• 10 years ago

Almost 12% of internet users are accessing Google over IPv6, and that figure is growing exponentially[0]. The users are already there, and our apps need to start using IPv6 more.

[0] https://www.google.com/intl/en/ipv6/statistics.html

Neil44• 10 years ago

It's coming, I noticed that my Linodes and Rackspace boxes started sending mail to Google and 365 via straight IP6 recently. I didn't have to do anything, I only noticed because my IP6 PTR's were wrong. It's the future!

r4um2• 10 years ago

AWS ELBs are reachable over IPv6 http://docs.aws.amazon.com/ElasticLoadBalancing/latest/Devel...

jvolkman2• 10 years ago

Only if you're still using classic.

t0mas88• 10 years ago

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

kalleboo• 10 years ago

Only in EC2-Classic, which is only supported by legacy AWS accounts that signed up before December 2013. Anyone who signed up for AWS in the past 2 years can not use IPv6.

nashashmi• 10 years ago

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

ProAm2• 10 years ago

Apple breaking the world, one update at a time.

c1641287• 10 years ago

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

ProAm2• 10 years ago

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?

eloy5• 10 years ago

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-Istence7• 10 years ago

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.

eloy5• 10 years ago

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.

gsnedders• 10 years ago

What makes it a better transition method than operator-level NAT for IPv4 (and no NAT for IPv6)? Like, what do you gain by having the client not ever speak IPv4 directly?

eloy5• 10 years ago

It's less ugly than Dual Stack. Just one address per device, nothing more. This should be the long term goal too.

joeseeder2• 10 years ago

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• 10 years ago

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.

joeseeder2• 10 years ago

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.

3pt141592• 10 years ago

I'm not so sure that IPV6 is the necessarily the bright side of the Internet. Major problems:

1. Even more distributed crawlers than before. You used to need to at least know how to cycle through IPs or get a botnet up and running, now either the domain bans the entire subnet or it does other shitty things like putting up captchas. 2. People thinking obscure IPs in the IPV6 space are secure because "nobody could guess them so I don't need security" when in reality it's already an active attack vector due to the way clocks get adjusted leaking the IP. 3. It used to be that you couldn't just track someone forever because the IPs needed to get recycled. Now until I destroy a device there is a decent chance it can have the same IP for good, even if I run browsers in VMs with adblockers and scrambled browser fingerprints.

Obviously we all like a larger address space, but it's coming with some downsides.

X-Istence7• 10 years ago

Banning a /64 prefix is not a bad idea if you are getting hit hard by botnets running on IPv6 that are within that same /64, maybe go up to /48 if required.

Officially a /64 is a single site, you can equate it to a single IPv4 address that is being used as NAT gateway.

You mean the "fake" NTP servers that record the information? Clients should be running firewalls anyway, and endpoint security is as important as before. Also, CPE should be running an firewall that disallows all incoming traffic, and only allows outgoing. NAT-PMP or UPNP can be used to open up ports as necessary. Although the standard does need to get fleshed out a little more.

None of this has changed BTW, in IPv4 this was and is best practice too, NAT/Firewall on the edge does not protect devices, and devices inside should all be running firewalls and the like as necessary.

Clients like OS X/Windows/Linux that are running desktops should be using privacy addresses, this would allow them the ability to move from IP to IP over time thereby alleviating the "one static IP for life".

Except that in a lot of cases ISP's will happily give you a lease for a DHCP that can be renewed over and over. I've had my current IP from Comcast for a little over 2 years now. No recycling going on there...

Recycling IP's is a false sense of security anyway. IPv6 with privacy addresses makes this simpler though. Hop away... now you can have a new IP address every 10 minutes...

robert_tweed• 10 years ago

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

chatmasta4• 10 years ago

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. :) )

Aloha• 10 years ago

You hit the nail on the head - and as someone who works in the telecom industry (and an early advocate of IPv6) I'm pleased to see it.

jdeibele• 10 years ago

Or "Apple bans apps that support only IPv4."

"Apple bans apps that support IPv4 only." could be interpreted as banning apps that support IPv4. Although that'd be reaching.

Want to hear my rant about "No smoking allowed" when it should be "Smoking not allowed"?

Dylan168076• 10 years ago

I don't see how you could parse the smoking message the wrong way. "Non-smoking allowed" would be the wrong message. With "No smoking allowed", can you explain the problem?

headShrinker• 10 years ago

"No smoking is allowed."

(!smoking == true)

It's short hand.

"Apple bans apps that support IPv4 only." could be interpreted as banning apps that support IPv4.

the word 'only' is quite important in english. If an app supports IPv4 they will not be banned. That's not what we are measuring here. If they "don't" support IPv6, they will be banned.

AckSyn• 10 years ago

No one learns proper contextual clues in written media OR grammar usage anymore. Christ, it was bad when I started university in the late 90s and it's only gotten worse!

Fuck common usage. Ignorant fools drag everyone down.

copperx• 10 years ago

"Apple bans apps that don't support IPv6". It isn't that hard.

Negative14• 10 years ago

That's incorrect. Check out figure 10-3 here: 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.

eloy5• 10 years ago

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

chatmasta4• 10 years ago

Oh I see. So Apple is moving all its local sockets to IPv6 format? That's what you mean by "no longer have network connectivity?"

You seem to be implying that every IPv4 packet will go through a carrier NAT64... but what if my ISP does not use NAT64? Will my iPhone send a regular IPv4 request, or will it prefix IPv6?

songgao• 10 years ago

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.

This will only happen 1) in the test environment that helps ensure that your App will work fine in a IPv6-Only (as opposed to dual-stack) network; 2) your carrier has IPv6 and NAT64.

If I understand correctly, the higher level APIs should be able to choose IPv6 or IPv4 accordingly based on network configuration. If, for example, your carrier doesn't support IPv6, apps using these APIs will continue function well using IPv4. And I doubt Apple will ban IPv4 entirely before all carriers support IPv6 and NAT64/DNS64. So "for now" will likely be several years.

There are many components that need upgrades in order to move to an IPv6 only Internet. Preparing applications for it is an important part, and this is a nice step in this part.

the_mitsuhiko2• 10 years ago

That's unlikely to be correct because this would require carriers to support IPv6 which many do not do.

Negative14• 10 years ago

Why the downvote? Everything I stated is factually accurate.

hobarrera• 10 years ago

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.

danielrhodes• 10 years ago

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• 10 years ago

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)?

masklinn2• 10 years ago

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

jvdh• 10 years ago

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

ozarius• 10 years ago

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);

ay6• 10 years ago

I've found there is a related StackOverflow question, so I have answered in detail there: http://stackoverflow.com/questions/31938536/reachability-and...

Short answer: Just Try The Connection.

askyourmother• 10 years ago

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!

makecheck• 10 years ago

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• 10 years ago

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.

elktea• 10 years ago

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

morbidhawk• 10 years ago

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

iOS Supporting IPv6-Only Networks

Related Stories