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.
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)".
Apple has a vested interest in IPv6 working on mobile, but benefits nothing from disabling IPv4.
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.
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.
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.
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.
Your proposed anti-spam measure wouldn't work because
- [ ] it assumes mail administrators operate in good faith
- [X] it assumes all systems can be upgraded in a timely manner
- [ ] ...
We could probably have the same for IPv6. The proposed method
- [ ] for an alternative to IPv6
- [X] to avoid the transition to IPv6
- [ ] to allow us to keep using IPv4 indefinitely
would not work because
- [X] it would require replacing all the hardware and updating operating systems anyway
- [ ] it does not expand the address space to the extent required
- [ ] etc.NAT
- [ ] is not a firewall
- [ ] does not provide any additional privacy over IPV6 privacy extensionsIt is gradually becoming acceptable to dismiss IPv6 and suggest searching for a modern, practically minded alternative. Important first step in untangling the mess.
Naturally opinions vary as to what exactly would constitute modern. Common complaint is the significant mixing of OSI layers, in particular application level concerns like significant baggage of encryption & authentication. And then there's my pet peeve of BSD Sockets API incompatibility which was introduced accidentally.
"Nobody will join your IPv6 network if it can't talk to Google, CNN, etc."
IPv6 networks can now talk to Google and CNN, for instance.
So why are we still dredging up this article when the problems have been solved?