IPv6 is such a massive headache it’s kind of mind boggling. I used to be super enthused - but it is absolutely less useful and more annoying than it’s worth.
IPv6 just works. Amazon, Github, and Azure don't. That's not really a problem in most cases (very few people go IPv6 only because it's just not necessary with CGNAT, and even then network translation tricks can put up IPv6<->IPv4 bridges easily). In Amazon's case, they don't even need to bother setting up a real network, they could abuse an fd00::/8 network to mimic their 10.0.0.0/8 network if they wanted to.
Amazon is terrible at implementing modern standards. Just look at how long it took them to support DNSSEC on their domains, and even that didn't exactly roll out great the first time.
Only via the herculean efforts of a bunch of people having to literally reinvent the world to deal with it. Everything needs IPv6 support specifically. It's such a mess, if IPv6 has just been identical to IPv4 but with larger addresses we would be on it by now. But no they had to make it their religious crusade to eliminate NAT (and now we have NAT66 so clearly a winner) put IPSec in there which is hilarious in the era of Wireguard and eliminate DHCP which is actually insane and makes a stupid number of assumptions about hosts being able to communicate with one another and actually complicates DNS registration.
Can you imagine how trivial it would have been if you could support both v4 and v6 by just supporting v6 and having 0::v4addr be literally equivalent to ipv4? It would be more difficult to not support v6.
Remember the error "This program cannot be run in DOS mode"?
IPv4 and IPv6 are unidirectionally compatible using NAT64. The fact that you can make an IPv6 to IPv4 TLS connection using a packet-level translator without breaking the endpoints is quite remarkable, and it wouldn't have been possible if the protocols were too dissimilar.
What you need to support dual stack? Who would do that…
And how are you supposed to get the packets back when the client has an address outside that range? You still need to add support everywhere, or have NAT gateways into the areas that lack support.
Automatic mapping of IPv4 addresses exists but it requires support infrastructure just as much as any other method of allowing access to IPv4 devices.
There is a reason well resourced companies like google cloud have been slow w IPv6 - and it can be even more hair pulling in smaller settings.
Then you pick your shortest prefix length and use that for your network configuration, no? Nothing in NPT is forcing you to use a /48 or a /56, if your failover uplink only provides you with a /80 for some stupid reason you'll still be able to do translation.
DHCPv6 is supported just fine by everything but Android (for some annoying reason). Even with SLAAC, IP addresses shouldn't rotate, unless you enable Privacy Extensions on your server.
If this were the bakery just around the corner we're talking about, I would've accepted these problems as illogical to even try to overcome, but these are billion dollar companies selling network access. When networking is one of your major streams of revenue, I expect better.
Every other episode seems to be about a different new RFC that's replacing another RFC because the original ended up having a bunch of holes and edge cases. That's somewhat understandable for a new protocol but the protocol have been around for almost 30 years and is just so overly complex that it's rife with these situations.
As an example the most recent such episode was on rfc6724[0] which describes these convoluted algorithms systems are supposed to follow to determine which of their many assigned IPv6 addresses to use for a particular connection and also which of many possible destination addresses to use. Just reading the introduction makes your eyes water with how overly complex and prone to nasty failure cases (what if the source address isn't what you expect and somehow the connection routes around your firewall?) the whole situation they've created is.
I use IPv6 since 2006 and I just can't see how it can give you "a massive headache". I read a blog post about how overly complex HTTP/3 is. Better ignore it forever and never implement it then. ;-) Also, which successful RFC protocol doesn't have a see of follow-up RFCs?
* if the app specifies a source use that.
* do a route lookup, if the route has a src use that
* if you get no hint, use the first address.
That said, EVs are mostly better than ICEVs - "mostly" because performance-heavy applications like long-haul trucking and tractors still benefit heavily from fossil fuels, and in most other applications EVs are still more expensive than ICEVs.
The headache are vendors that still refuse to properly implement IPv6, in 2023.