"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"?
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
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 
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.
> "No" is an adjective (quantity) modifying "smoking".
> "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".
(edit: changed first example to something more idiomatic)
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.)
(!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.
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.
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.
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?
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.
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.
T-Mobile in the USA is currently using such a network, which is the best transition method in my opinion.
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.
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.
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.
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.
But indeed just one address family is less overhead, and less work for the device. Thus, potentially better battery life.
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?
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).
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.
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.
This is called DNS64/NAT64 and has some small performance penalty. Making content directly accessible by IPv6 removes the 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
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.
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.
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.
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.
See you all on the bright side of the Internet.
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.
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.
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...
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. 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...
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.
// IN_LINKLOCALNETNUM is defined in <netinet/in.h> as 169.254.0.0.
localWifiAddress.sin_addr.s_addr = htonl(IN_LINKLOCALNETNUM);
Short answer: Just Try The Connection.
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.
I might be misunderstanding what you are stating though?