12 ms·
iOS Supporting IPv6-Only Networks
- 0x0 10y agoIs 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?
- giovannibajo1 10y agoThey 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 10y agoAre 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 10y agoT-Mobile already runs an IPv6 only network in the US for most (all?) LTE APNs.
- JoshGlazebrook 10y agoVerizon also is pretty high up there in IPv6 deployment
- simon_vetter 10y agoThey're doing dual stack, not ipv6-only with nat64/dns64.
- simon_vetter 10y agoRequiring 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 10y agoDoes this mean all backends that an app communicates with need to be accessible over IPv6?
- deleted 10y ago[deleted]
- subway 10y agoNo. The device only needs to be able to function on IPv6-only networks where NAT64 and DNS64 are present.
- aaron42net 10y agoRecent 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 10y 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
- X-Istence 10y agoThe 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.
- verelo 10y agoHow 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 10y agoThis 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 10y agoThis is the way i read it too. No big deal really.
- X-Istence 10y agoApple includes the ability to easily set up an IPv6 only hotspot. Using NAT64 and DNS64. https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW16 https://developer.apple.com/library/ios/documentation/Networ...
- ay 10y agoThe 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).
- sandstrom 10y agoUntil AWS, Azure and GC support native IPv6 there won't be many apps that can use this.
- kuschku 10y agoOVH’s cloud supports native IPv6.
- ryao 10y agoThe HE tunnel broker can be used there.
- vetinari 10y agoThese 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.
- sandstrom 10y agoGood 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.
- deleted 10y ago[deleted]
- mrweasel 10y agoAnd 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 10y agoAlmost 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 https://www.google.com/intl/en/ipv6/statistics.html
- nashashmi 10y agoCan someone change title to "iOS apps supporting ..."
- deleted 10y ago[deleted]
- ProAm 10y agoApple breaking the world, one update at a time.
- c1641287 10y agoThey are trying to fix something that was known to be broken more than 30 years ago.
- ProAm 10y agoWhat 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?
- eloy 10y agoThe 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 10y agoDNSSEC 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 10y 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.
- ay 10y ago464XLAT (https://tools.ietf.org/html/rfc6877 https://tools.ietf.org/html/rfc6877), is a stateless NAT46 on the phone, coupled with a stateful NAT64 on the headend, and sometimes with DNS64. This (edit: 'this' being the presence of stateless translation on the device) means the device has to do extra translation work on a per-packet basis, which would not help the battery life, and also the apps remains IPv4-only. I.e.: it is technical debt. Apple has a stronger influence on the developers + a lot of address-family independent APIs, so they could exercise this option of allowing operation on IPv6-only access networks while also progressing towards all applications being future-proof.
- joeseeder 10y agoIt'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 10y agoCould 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 10y agoI 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.
- 3pt14159 10y agoI'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.
- robert_tweed 10y agoMisleading title. Crucial bit from TFA: "Starting June 1, 2016 all apps submitted to the App Store must support IPv6-only networking."
- chatmasta 10y agoPeople 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 10y agoYou 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 10y agoOr "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"?
- Dylan16807 10y agoI 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?
- prdonahue 10y agoHe's trying to imply that one would actually read this as "no smoking [IS] allowed".
- Dylan16807 10y ago"No smoking is allowed." is the correct message.
- hobarrera 10y agoI'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 10y agoFor 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 10y agoDies 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)?
- ozarius 10y agoDoes 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 10y agoI've found there is a related StackOverflow question, so I have answered in detail there: http://stackoverflow.com/questions/31938536/reachability-and-ipv6 http://stackoverflow.com/questions/31938536/reachability-and... Short answer: Just Try The Connection.
- askyourmother 10y agoI 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 10y agoIn 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 10y agoAnecdotes 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 10y agoFantastic. Finally seeing a bit of a push. Incidentally, Australian IPv6 usage jumped from 2% to 4% just this month.
- morbidhawk 10y agoDoes anyone knows what this means for NSURLConnection APIs? Will code using that API have to be replaced with NSURLSession?