iOS Supporting IPv6-Only Networks(developer.apple.com)
developer.apple.com
iOS Supporting IPv6-Only Networks
https://developer.apple.com/news/?id=05042016a
21 comments
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. :) )
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.
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"?
"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"?
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?
You are allowed to be "no smoking." It doesn't say that you can't smoke, which is the only possible interpretation of the second option.
You cannot be "no smoking". You can be "not smoking". You can be "non-smoking". "no smoking" is not an adjective.
"No smoking" is a gerundive phrase which serves as the sentence's subject, with the copulative verb "is" implied: "No smoking [is] allowed".
Considered differently, the sentence is not in the imperative mood with an implied subject. The sentence is in the declarative mood with an implied verb.
The possible misunderstanding is that this declarative sentence merely identifies one action (of many) which is allowed, "no smoking", which does not necessarily prohibit other activities including "smoking", "singing", "no singing", "dancing", etc.
EDIT: grammar and readability
Considered differently, the sentence is not in the imperative mood with an implied subject. The sentence is in the declarative mood with an implied verb.
The possible misunderstanding is that this declarative sentence merely identifies one action (of many) which is allowed, "no smoking", which does not necessarily prohibit other activities including "smoking", "singing", "no singing", "dancing", etc.
EDIT: grammar and readability
I strongly disagree. "not smoking" is an action. "no smoking" is not an action. You cannot parse the sentence as allowing a specific action without replacing the word "no" with something else.
Edit: Also, I treat the sentence as being declarative with an implied 'is' even when interpreting it correctly.
Edit: Also, I treat the sentence as being declarative with an implied 'is' even when interpreting it correctly.
You are splitting hairs and are mistaken.
"Smoking" is the noun form of the verb "to smoke", also known as a gerund.
"No" is an adjective (quantity) modifying "smoking".
In the unintended misinterpretation, the phrase "no smoking" is an action that is permitted. The misinterpretation is possible because the negative is an adjective on the gerund which allows for ambiguity with regard to the sentence's predicate.
This is a feature of the English language. Colloquially, most English speakers understand the intended meaning.
The ambiguity can be removed by 1) writing "Smoking [is] not allowed" thus asserting the negative as an adverb in the predicate, 2) removing the predicate nominative "[is] allowed" (leaving only a gerundive phrase, not a full sentence), and/or 3) using a diagram like a prohibition symbol atop a burning cigarette [0]
EDIT: grammar and sense (this is getting complicated!)
[0] http://images.mydoorsign.com/img/lg/S/no-smoking-sign-s-9584...
"Smoking" is the noun form of the verb "to smoke", also known as a gerund.
"No" is an adjective (quantity) modifying "smoking".
In the unintended misinterpretation, the phrase "no smoking" is an action that is permitted. The misinterpretation is possible because the negative is an adjective on the gerund which allows for ambiguity with regard to the sentence's predicate.
This is a feature of the English language. Colloquially, most English speakers understand the intended meaning.
The ambiguity can be removed by 1) writing "Smoking [is] not allowed" thus asserting the negative as an adverb in the predicate, 2) removing the predicate nominative "[is] allowed" (leaving only a gerundive phrase, not a full sentence), and/or 3) using a diagram like a prohibition symbol atop a burning cigarette [0]
EDIT: grammar and sense (this is getting complicated!)
[0] http://images.mydoorsign.com/img/lg/S/no-smoking-sign-s-9584...
> You are splitting hairs
I think the point of this conversation thread was to split hairs. :)
> "Smoking" is the noun form of the verb "to smoke", also known as a gerund.
Yes.
> "No" is an adjective (quantity) modifying "smoking".
Yes.
> "no smoking" is an action
That does not fit with my understanding. "Uncle Bob is no smoking." is not valid English. "No" is a word used when talking about sets of things/actions. To make an action that is the opposite of smoking, you have to use "not".
I think the point of this conversation thread was to split hairs. :)
> "Smoking" is the noun form of the verb "to smoke", also known as a gerund.
Yes.
> "No" is an adjective (quantity) modifying "smoking".
Yes.
> "no smoking" is an action
That does not fit with my understanding. "Uncle Bob is no smoking." is not valid English. "No" is a word used when talking about sets of things/actions. To make an action that is the opposite of smoking, you have to use "not".
[deleted]
FWIW, I agree with Dylan16807. Compare "quickly planning" to "quick planning". Why are both an adjective and an adverb allowed in the same position? Because the adverb is part of the subordinate clause implied by the gerund (where it's treated as a verb), while the adjective is part of the main clause and modifies the gerund (as a noun). "No" is (syntactically) an adjective, so unless it fits into a known colloquialism or special case that bends grammar rules for the sake of brevity, its role in "no smoking" must be the latter - part of the main clause. But then the gerund is treated no differently from any other noun, and "no" does the same trick it always does: "no X does Y" is (always) shorthand for "(an X which does Y) does not exist". "No smoking is allowed" is no different from "no help is available" or "no money has been taken".
(edit: changed first example to something more idiomatic)
(edit: changed first example to something more idiomatic)
[deleted]
This is amusing but absurd, especially if you're serious about this phrase being confusing or malformed. "You may not smoke": does this mean, to you, that either smoking or not smoking is permitted? If the answer is yes, I think the solution may be to cease applying the logical rules of programming to human languages, where it is meaning and tradition that matter.
I was going to write that the answer your question is "no" because your version is unambiguous but then I parsed it a few more times.
One way to remove the ambiguity is to recast your sentence using "must": "You must not smoke". But that version is stilted to most modern English speakers raised outside the UK.
This side-discussion is probably one of the reasons people wish HN had collapsible threads, so after this comment I will refrain from further contributing to it.
(Nice job, btw, on highlighting the ambiguity in a version where the negative is in the predicate.)
EDIT: grammar
One way to remove the ambiguity is to recast your sentence using "must": "You must not smoke". But that version is stilted to most modern English speakers raised outside the UK.
This side-discussion is probably one of the reasons people wish HN had collapsible threads, so after this comment I will refrain from further contributing to it.
(Nice job, btw, on highlighting the ambiguity in a version where the negative is in the predicate.)
EDIT: grammar
You no smokey!
Didn't Smokey say "Only you…"? [0]
[0] https://en.wikipedia.org/wiki/File:Smokey3.jpg
[0] https://en.wikipedia.org/wiki/File:Smokey3.jpg
He's trying to imply that one would actually read this as "no smoking [IS] allowed".
"No smoking is allowed." is the correct message.
But "smoking isn't allowed" or "smoking is prohibited" is a clearer way of putting it...
"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.
(!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.
"Apple bans apps that don't support IPv6". It isn't that hard.
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.
Fuck common usage. Ignorant fools drag everyone down.
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.
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.
> 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.
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.
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?
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?
If your ISP doesn't have NAT64 it will continue to use IPv4, and packets will continue to flow as normal. Apps however can't be IPv4 ONLY.
Ah okay. So the point of prefixing IPv6 with IPv4 is that if the ISP has only IPv4 switching, it will only grab the first 32 bits of the IPv6 address... which is the IPv4 address. So no ISP changes needed.
That's unlikely to be correct because this would require carriers to support IPv6 which many do not do.
From that link: "Major network service providers, including major cellular carriers in the the United States, are actively promoting and deploying IPv6."
That's nice for the US but that does not apply for many other countries. Case in point: Austria does not have a practical IPv4 shortage currently so motivation for deploying IPv6 is low and customers actively refuse it.
Out of curiosity, why would anyone use Unix or BSD sockets on iOS if Apple provides way better APIs?
Think game engines or legacy C++ projects there were ported to the platform and already have their own network implementation.
Why the downvote? Everything I stated is factually accurate.
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.
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.
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.
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.
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.
T-Mobile in the USA is currently using such a network, which is the best transition method in my opinion.
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.
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.
> 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.
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.
>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.
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.
464XLAT (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.
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.
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?
It's less ugly than Dual Stack. Just one address per device, nothing more. This should be the long term goal too.
Indeed. Also, in 3GPP until Release 9 there had to be two PDP contexts per device - one for IPv4 and one for IPv6, thus resulting in performance issues, and licensing costs for some vendors too. This was fixed in later releases when a new type was added, IPv4v6, which combined both stacks within a single context, but I heard this created issues with roaming if the "guest" operator network did not support this context type.
But indeed just one address family is less overhead, and less work for the device. Thus, potentially better battery life.
But indeed just one address family is less overhead, and less work for the device. Thus, potentially better battery life.
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?
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?
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/Networ...
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).
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).
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.
Try FTP.
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.
Or another weird to put it, your application must be IPV6 with the option of a IPV4 add-on.
This is the way i read it too. No big deal really.
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.
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.
Does this mean all backends that an app communicates with need to be accessible over IPv6?
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.
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.
No. The device only needs to be able to function on IPv6-only networks where NAT64 and DNS64 are present.
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.
This is called DNS64/NAT64 and has some small performance penalty. Making content directly accessible by IPv6 removes the penalty.
> 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
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
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.
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.
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.
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.
That NAT in many cases happens on the same edge router that'd be dropping your packets off on the internet anyway, so it doesn't have to add an extra hop.
[deleted]
Until AWS, Azure and GC support native IPv6 there won't be many apps that can use this.
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.
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.
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.
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.
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!
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.
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
[0] https://www.google.com/intl/en/ipv6/statistics.html
AWS ELBs are reachable over IPv6
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/Devel...
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.
Not when using VPC, which almost any modern AWS deployment is.
True, though ClassicLink is an option. Launch ELB in EC2 classic and add instances in VPC over classlink.
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...
Only if you're still using classic.
The HE tunnel broker can be used there.
OVH’s cloud supports native IPv6.
[deleted]
Misleading title. Crucial bit from TFA: "Starting June 1, 2016 all apps submitted to the App Store must support IPv6-only networking."
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.
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.
See you all on the bright side of the Internet.
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.
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.
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.
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.
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.
1.
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.
2.
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".
3.
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...
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.
2.
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".
3.
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...
1. I'm not talking about botnets, I'm talking about sites that crawl your content to copy your database and mine competitive intelligence on it.
2. Clients should be running firewalls anyway, yeah, yeah. 99% of the security holes online are because of "shoulds". In the wild many, many, many people will assume their IP is unguessable and then it will leak _somehow_. A single hacked device on the other side of the firewall, or a misconfigured firewall, etc.
3. Well that might be true for your home internet, but it's almost certainly not true for your mobile phone unless you live somewhere weird.
2. Clients should be running firewalls anyway, yeah, yeah. 99% of the security holes online are because of "shoulds". In the wild many, many, many people will assume their IP is unguessable and then it will leak _somehow_. A single hacked device on the other side of the firewall, or a misconfigured firewall, etc.
3. Well that might be true for your home internet, but it's almost certainly not true for your mobile phone unless you live somewhere weird.
1. Same thing, ban the entire /64, or /48. Now it's similar to banning an IPv4 address.
2. Hacked device on the other side of the firewall has been an issue even with NAT. NAT + firewall is not some magic unicorn, if someone gains access to a device behind your NAT + firewall they are still on your local network. No change there.
3. Most users will use Wifi at home, thus have an IP address that can be tracked. My exit IP for my T-Mobile phone is almost always the same too when I am in the same location...
2. Hacked device on the other side of the firewall has been an issue even with NAT. NAT + firewall is not some magic unicorn, if someone gains access to a device behind your NAT + firewall they are still on your local network. No change there.
3. Most users will use Wifi at home, thus have an IP address that can be tracked. My exit IP for my T-Mobile phone is almost always the same too when I am in the same location...
Can someone change title to "iOS apps supporting ..."
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.
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.
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);
// IN_LINKLOCALNETNUM is defined in <netinet/in.h> as 169.254.0.0.
localWifiAddress.sin_addr.s_addr = htonl(IN_LINKLOCALNETNUM);
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.
Short answer: Just Try The Connection.
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.
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.
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)?
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.
T-Mobile already runs an IPv6 only network in the US for most (all?) LTE APNs.
Verizon also is pretty high up there in IPv6 deployment
They're doing dual stack, not ipv6-only with nat64/dns64.
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.
Does anyone knows what this means for NSURLConnection APIs? Will code using that API have to be replaced with NSURLSession?
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?
Fantastic. Finally seeing a bit of a push. Incidentally, Australian IPv6 usage jumped from 2% to 4% just this month.
[deleted]
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!
Apple breaking the world, one update at a time.
They are trying to fix something that was known to be broken more than 30 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?
I might be misunderstanding what you are stating though?