Hacker News new | ask | show | jobs
by dtech 57 days ago
Apple/iOS is probably one of the biggest individual drivers of IPv6 adoption. They've been requiring that iOS apps work on IPv6-only networks for close to 10 years now
3 comments

> They've been requiring that iOS apps work on IPv6-only networks for close to 10 years now

This was at the behest of mobile network. E.g., T-Mobile US has 140M subscribers, and moved to IPv6-only many years ago:

* https://www.youtube.com/watch?v=d6oBCYHzrTA

The requirement is to support IPv6 only networks with IPv4 transition mechanisms. It does not preclude contacting v4-only servers.
And the higher level libraries mostly do it for you, too, even if you directly specify IPv4 addresses in your code (due to NAT64 [1]). I think it only even requires special work from you as a developer if you're using low-level or non-standard libraries.

[1] https://en.wikipedia.org/wiki/NAT64

The problematic low-level libraries are standard, and effectively impossible to fully deprecate since they're decades old and part of the socket API.

I think currently Apple still helps you with these via "bump in the stack" (i.e. they can translate internal v4 structures and addresses into NAT64-prefixed v6 at the kernel level), but they probably don't want to commit to doing that forever.

If that's the case, how does the Github app work on iOS?
Differential enforcement.
Apple’s App Store enforcement is very arbitrary. For example, if the app developer offends steve jobs, you’re banned for life.
I’m guessing the app works but their prod servers don’t? If they can point the app during review at a “self hosted” GitHub Enterprise server on a test domain with AAAA that would pass the requirement as stated by gp , without requiring GitHub.com actually support ipv6.
The prod servers work. The app does a DNS lookup, receives something like 64:ff9b::140.82.112.5 and 140.82.112.5 from the ISP's DNS servers, and then connects to 64:ff9b::140.82.112.5. Some part of the ISP network translates the connection into a v4 connection to 140.82.112.5.

The requirement is simply that the app does AAAA queries, and that it attempts to connect to them if they exist. It doesn't matter whether the server does v6 natively or if the ISP is covering for a v4-only server via backwards compatibility. (Native v6 will probably perform better, but any site that wants to give up that advantage is free to do so.)

That’s DNS64, which is pretty annoying in practice. (For one thing, you can’t use your own DNS server anymore, but more importantly, anything using v4 literals will 100% break.)

What’s nicer is 464XLAT, or more generally NAT64 prefix announcements. Then your local OS can just synthesize NAT64 addresses from v4 literals, either at the socket library or kernel networking (via “bump in the stack” translation) layer.