Google's own GCE still doesn't have IPv6 support on the instance level:
https://googlecloudplatform.uservoice.com/forums/302595-comp...
https://googlecloudplatform.uservoice.com/forums/302595-comp...
And yet, even in this position, I think having IPv6 native inside of a production network isn't absolutely necessary (our production env runs in the RFC1918 space too even though v6 would be available at both ends):
Access to the private production network should all happen over an encrypted and authenticated VPN and all access form the production network to the public network (if needed at all) should go through a filtering proxy server.
Which means that the addressing used in your internal network becomes completely irrelevant and can easily be IPv4.
This only becomes an issue once you need more hosts than the /8 offered by the 10/8 RFC1918 network, but the days when you need (and can afford) more than 16.7M nodes on a cloud computing provider are probably still a ways off.
If you want instance level IPv6 in order to access an instance directly or in order to access a resource directly, you're probably doing something wrong.
Then again, as services become v6 only (which will still be a few years off) and you need to access them from your production network, then your frontend proxy will of course need access to the v6 network. At that point, yes, instance level v6 becomes necessary too.
And the days when you need 16M nodes all of which need to talk to each other directly are probably even further off.
(In fact, I would go even further and say that if you find yourself ever facing that situation you've done something badly wrong in your architectural design.)
In contrast, even if you use "private" IPv6 addresses (ULA), the address space is large enough that everyone can have their own prefix. Or better, just use public IPv6 addresses and firewall them.
NAT66 does exist and over time more software and hardware will support it. But you don't need NAT if you are using ULA; instead you would configure each system with both its ULA address and the global address from your provider (SLAAC can advertise multiple prefixes). Traffic to other internal systems would use the ULA addresses, while traffic to the Internet would use the global address.
For one, you don't need NAT to use ULA internally. You just use ULA for internal stuff and global addresses for everything else.
But really, if renumbering is a problem in the first place, you are doing something fundamentally very wrong. Renumbering should be a matter of adding a new prefix of the same length to your addressing plan and replicating in it the exact same subnet structure you had before, then deprecating the old prefix (so it's not used for new outbound connections), waiting a bit, and then removing the old prefix. If your problem is hard-coded addresses everywhere, that is also a problem with your system design. Almost all of your configuration should only contain host names, and your DNS should either use dynamic updates so that hosts register their current primary addresses with the DNS server, or some other mechanism that generates records from an addressing plan of sorts and a prefix. There should be very few places where you need to change addresses in order to switch prefixes.
"Access to the private production network should all happen over an encrypted and authenticated VPN"
IPsec, likely the same thing that'd be encrypting your VPN, can just be used directly between hosts without complication if you have all public addresses.
"and all access form the production network to the public network (if needed at all) should go through a filtering proxy server."
Why does it have to be a proxy? Why not just a firewall sitting in the route path? Again, the way you're use to working around a limited address space is leading to complicated solutions to problems easily solved by having more addresses.
In computing very little is "necessary" but it doesn't mean it makes much sense for it to be that way the same as programming your cloud application with NAND logic doesn't make sense.
Not necessary, but it could be quite useful. The 64bit suffix of ULA addresses lets you group your containers into separate blocks with static prefixes. E.g. you could always have the :0000 - :FFFF block be your reverse proxies, the next block the storage shards and so on.
For example, I've been working on contributing IPv6 support to GitLab.com [0], which is hosted on GCP. Turns out it's impossible for the main site right now, because none of the global load balancer types allow port 22, which is used for Git traffic. I've no idea why there are even such restrictions, but there's of course a "feature" request for allowing port 22 [1]. I was able to repurpose the work for other parts of GitLab.com, but I've yet to get even those to work, due to the load balancers gobbling up HTTPS/SSL requests [2].
[0] https://gitlab.com/gitlab-com/gitlab-com-infrastructure/merg...
[1] https://issuetracker.google.com/issues/77944636
[2] https://gitlab.com/gitlab-com/gitlab-com-infrastructure/merg...
Because while there is a 10/8, once you start subnetting that and advertising it from multiple sites and start running labs that look and act like production that /8 goes quick.
Give me IPv6 any day.
It's not that you require more than a /8 can provide, it's more a function of convenience. I have 10 customers, each one of those has 4 environments (Dev, QA, Stage, Prod) and each of these environments need to live in 3 regions, and each region has 3 AZs, and each AZ has 6 subnets. Splitting that up with a 10.0.0.0/8 gets complicated. I would much rather say 2006:abcd:0001:::: is customer A, ::0002::: is customer B, etc. IPv6 gives me plenty of room to maneuver and eliminates the need to worry about IP exhaustion.
Worse, Kubernetes as a model doesn't use IPv6 internally when it should. No reason not to use e.g. ULAs.