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.
This is one example where it's clear IPv6 isn't the problem, actually. A lot of problems with AWS would disappear if they would just support IPv6 like your average budget ISP does.
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.
> 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.
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.
Yes I'm not qualified to really argue the point but naively it never made sense to me that IPv4 was not backwards compatible with IPv6 addressing. You'd think the people on the committees would have foreseen the trouble that would avoid. Telephone companies didn't make you dial the area code for local numbers. Microsoft bent over backwards to make sure that old DOS software still worked on Windows. Linux has a mandate to never break userland. This is not an unfamiliar concept.
IP is a bidirectional protocol, so the correct analogy would be if Microsoft had to make DOS software run on Windows, and Windows software run on DOS.
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.
WAN failover is not fun with ipv6 - npt doesn’t solve things because prefix lengths are variable. You end up back with NAT with basic networks again but with ridiculously large address space. Firewall rules a trickier- you need to both let ICMP through but be careful because some can drive network reconfig. DHCP is second class, and the network can do weird things when port isolations are on. The number of (rotating) ipv6 addresses per host gets silly and makes logging / accountability/ trace back systems more convoluted. Then you’ve got neighbor discovery threats, header extension manipulation stuff. And if multicast isn’t working because of a security configuration that breaks assumptions but you also have multicast amplification stuff.
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.
> npt doesn’t solve things because prefix lengths are variable
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.
Amazon doesn't support DNSSEC on their domains. If you mean that it's possible to DNSSEC-sign a Route53 domain, yes, but AMAZON.COM isn't signed. Very few tech companies have signed their domains; it's a net negative.
I've been listening to a very good IPv6 related podcast with knowledgeable hosts (IPv6 Buzz) and all it's done is convince me that IPv6 is a poorly thought out mistake.
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.
This somehow reminds me of some anti EV (Electric Vehicle) people. They accept ICEVs (Internal Combustion Engine Vehicle) as given and normal (ICEVs just exist, the fuel falls from the sky) but dig really deep into an anti EV mindset. They follow anti EV blogs and podcasts. They will tell you how bad EVs are for the environment, how mutch water and cobalt and what not is used for the production without acknowledging that the same is true for ICEVs.
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?
There's a nugget of truth in anti-EV comments, namely 1) EVs are in many ways a mediocre solution (EVs will increase batteries etc needed), and 2) pursuing EVs carries an opportunity cost (public transport will reduce emissions far more than EVs and be substantially cheaper than cars as well, and a $1000 EV subsidy could instead be a free ebike).
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.
It’s really not a headache in and of itself. The technology is beautiful and enables lots of cool things - just look at all the awesome stuff the fly.io team makes it do.
The headache are vendors that still refuse to properly implement IPv6, in 2023.
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.