Hacker News Reader

Comment by minimaul | Hacker News Reader

Half of the big four ISPs in the UK provide IPv6 now (eg BT, Sky).

Full dual stack or something like v4 CGNAT + native v6 is practical and works well where available.

Big CDNs and content providers typically support v6 - eg Apple does, Netflix does, Google does, the big CDNs like Cloudfront, Fastly, Cloudflare do.

Apple requires app store apps to function on IPv6 only networks since 2016.

The holdbacks are smaller ISPs, ISPs with big legacy v4 allocations, and businesses.

I see more pushback from MSPs etc on IPv6 (and practices like disabling it completely) than any other sector.

edit: for an ISP that enables IPv6, the majority of their traffic will pretty much immediately be over it, as a result of the big CDNs and content providers supporting it. This reduces load on compatibility mechanisms like CGNAT, which is nice too.

View on HN

> Apple requires app store apps to function on IPv6 only networks since 2016.

Oooh, I think that's really big. That basically forces every app company to make sure their main domain at least has an AAAA record that goes somewhere.

I think Apple could force IPv6 adoption alone by extending this policy... An iPhone update could change the behaviour to only connect to a new wifi network if there is working ipv6 connectivity. "new" would be defined as any network whose mac address is not currently in Apples geolocation database.

That would mean anyone getting a new broadband connection or router would see it as not working unless it had IPv6.

Perhaps you can have an override - eg. "Use this legacy network anyway this time (some apps may not work properly)".

> That basically forces every app company to make sure their main domain at least has an AAAA record that goes somewhere

They don't require that. They just require that it works on an IPv6-only network with some kind of NAT64/DNS64-type gateway.

I.e. they require that apps aren't manually using IPv4 addresses internally but either are using the OS APIs that protocol-agnostic, or doing the right thing manually.

What would be the upside to Apple for this?

Apple has a vested interest in IPv6 working on mobile, but benefits nothing from disabling IPv4.

If they can ensure most Apple devices have IPv6 connectivity, there are a bunch of device-to-device connectivity benefits. For example, they can do video calling without having to host expensive proxy/STUN/TURN servers. Peer-to-peer data distribution and storage starts to make sense. Peer to peer gaming stops requiring server infrastructure.

It also means that typically all the other devices in a users home will be able to get IPv6 - so they can for example continue to remote control your Apple TV even if you walk a little out of wifi range.

Sure - for any IPv6 feature they build, they will need IPv4/proxied fallback. But if they can make sure 90% of users use IPv6 and direct connections, then the money and user experience costs of having to run the fallback servers becomes manageable.

I do not think any of those things would even remotely make up for the brand damage and bad will Apple would garner from breaking their customers’ Internet connectivity.

Maybe not, but remember it will mostly be the ISP taking the brand damage. "Hi tech support: The router you sent me isn't working properly! My iPhone won't connect to it, but the iPhone worked fine with the old router!"

No ISP would hesitate for a second to call out Apple on this kind of BS.

Every pundit on the planet would make hay of the matter and everybody and their dog would know to not purchased Apple products since it breaks their Wi-Fi.

All Apple would get out of this is a huge black eye and no upside.

Mobile operators want to deploy something like NAT64/DNS64 and they're the ones pressuring Apple.

You app can require access to IPv4-only servers, as long as if your app looks up the DNS and finds a 64: AAAA record it will connect to that. That is fine by Apple.

Reply on news.ycombinator.com