Earlier quoted context omitted.
The only "problem" here that is caused by IPv6 is the SD-WAN / multi-provider scenario. Even that is solvable. There are so many IPv6 addresses that your local router can have a unique routable range that it can hand out to the local network, "masking" the external internet provider addresses in the same way that IPv4 routing does it. That's not NAT, that's just routing. E.g. I have a customer that uses a non-RFC1918…
y u so mad? > Literally counterproductive in the case of Azure, where turning on IPv6 anywhere will break unrelated IPv4 functionality! not just on azure; smartphones seem to be the only environment were v6 is doing its job (lots of smartphones need lots of addresses. ipv6 has a lot of addresses, problem solved) and i guess it's because they are most user-centric client-device imaginable, the actual users don't care…
The painting has been on the wall for decades. IPv4 exhaustion was predicted to the week.
Did anyone do anything about it? No.
There are people talking about how Kubernetes is the "future" on this very forum, yet it simply does not work with IPv6. Instead, it uses NAT and RFC1918 ranges... but you've got to be careful not to accidentally overlap those subnets with the rest of your network!
I have a customer that screwed this up and now they're facing a rebuild of 3 out of 4 of their clusters. Fun times.
I have another customer undergoing mergers, where renumbering their IPv4 RFC1918 ranges is going to cost them on the order of $10M.
IPv4 is the legacy, and its costing real money to keep it going decades after its expiry.