Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE

> Snap initially considered migrating to IPv6, but concerns about application readiness and interoperability led them to adopt dual-stack GKE nodes and GKE pods (IPv6 + Class E IPv4). This solution mitigated IP exhaustion and provided Snap with multiple years of IP address scale needed to support future growth and reduce operational overhead. In addition, this approach also aligned with Snap’s long-term strategy for migrating to IPv6.

Yet another horrible hack to avoid having to actually learn IPv6.

Re: Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE

#7

Post by hypeatei » Wed, Oct 23, 2024, 4:56 PM UTC

Interesting read, but it seems like a waste of time to keep finding little tricks and band aids with IPv4 when v6 exists.

> However not all enterprises or applications are ready for IPv6 yet

Ah yeah, there it is. Please, just fucking prioritize upgrading to IPv6 and be done with it. Frustrating.

Cloud providers need to hurry up as well, Azure still doesn't fully support v6 on their app services (web servers) either. It's in public preview but has been a roadmap item for longer. It also comes with certain caveats like what tiers can use it.

Re: Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE

#8

Post by dangerlibrary » Wed, Oct 23, 2024, 5:04 PM UTC

It never made sense to me why the authors of the IPv6 standard chose to use an entirely different address format, instead of extending address space in a backwards-compatible way. Why not just append/prepend the 12 additional bytes onto existing IPv4 addresses, and write the standard such that all valid IPv4 addresses are also valid IPv6 addresses?

I'm not an RFC author, but something like "All existing IPv4 addresses will be reachable under the 0.0.0.0.0.0.0.0.0.0.0.0 prefix in the IPv6 Standard" seems like it would've made migration relatively trivial.

The draft standard is 26 years old. The official standard is 7 years old, and we are still reading articles about how "not all enterprises or applications are ready for IPv6 yet."

This question is coming from a place of genuine confusion and curiosity - I really don't get it. Did the authors of the standard just assume that migration and adoption would be easier than they've turned out to be? Was it a fairness issue where somehow this would have granted dominion over huge swaths of the new address space to existing players?

Re: Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE

#9

Post by ianburrell » Wed, Oct 23, 2024, 5:10 PM UTC

dangerlibrary wrote: post #8

It never made sense to me why the authors of the IPv6 standard chose to use an entirely different address format, instead of extending address space in a backwards-compatible way. Why not just append/prepend the 12 additional bytes onto existing IPv4 addresses, and write the standard such that all valid IPv4 addresses are also valid IPv6 addresses? I'm not an RFC author, but something like "All existing IPv4 addresse…

Because writing the addresses is not the important part. You can write IPv6 addresses as dotted decimal. The length is the problem, IPv6 format is more compact. Addresses are not the hard part in upgrading.

The embedding doesn't help with compatibility. IPv4 still can't access IPv6. IPv6 can't access IPv4. It actually breaks NAT64, which depends on special prefix.

Also, extending IPv4 address space has the problem that bake the misallocation into IPv6. IPv4 is broken in the small chunks that makes the routing table large. It also means that new organizations will have a hard time getting address space cause they need to get IPv4 addresses.

Re: Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE

#10

Post by ianburrell » Wed, Oct 23, 2024, 5:11 PM UTC

ddtaylor wrote: post #2

Anything but IPv6 it would seem.

I wish that Kubernetes had started as IPv6-only or IPv6-first. IPv6 is perfect for giving each pod its own address. There is more space for giving each host a subnet, or giving each pod its own address in the subnet.

That would have gotten rid of the CNI overlay networks. It would also made barrier between the internal and external networks. It would require running NAT64 and DNS64 in most clusters.