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. :) )
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?
"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.
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.
"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!)
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".
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)
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.)
> "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.
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.
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.
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?
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.
Ok then we are left with my original question. What if my ISP does not own any routers implementing NAT64? Will iOS send IPv4 packets? I think the answer is yes.
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.
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.
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.
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.
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.
> 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 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.
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.
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?
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.
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).
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.
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.
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.
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:
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.
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.
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
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.
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'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.
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.
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.
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.
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.
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.
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...
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.
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!
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?
