IPv4 to IPv6 NAT on AWS

Question

AWS supports connecting to external IPv4-only services from an IPv6-only node using NAT64. Is there an equivalent for the reverse?

For context, I have an EKS cluster, which is currently IPv4-only, all on private subnets. Communication to any external IP is via a NAT gateway (typically for webhooks or similar outbound requests). Now some external services are switching over to IPv6-only. Is there a way to connect to those without migrating the entire cluster over to IPv6? Since EKS doesn't support dual-stack networks, the migration could be quite a big and risky project.

Answer 1

No, IPv4 source IPv6 destination is not nearly as easy. Compared to going the other way, or native IPv6.

DNS64 + NAT64, a transition mechanism used in IPv6 only networks to connect to v4, is simple. A tiny v6 prefix can contain the entire v4 address space. Fancy DNS generates AAAA records in this prefix when the result only has an A record. And the dual stack NAT has a simple stateless 1 to 1 conversion to do, which is fast and does not need configuration.

Contrast to going the other way. Let's say the address of the remote service is 2001:db8:114:6614:240e:6d9d:8a1d:59d3 The entire 32 bit IPv4 address space could only contain the last two digit groups, the 8a1d:59d3 part. So fancy DNS tricks and unmodified applications won't work. Theoretically, a dual stack proxy could terminate the v4 connections and make v6 ones going out. But how are you going to get the v6 addresses through, parse application traffic for names in DNS or TLS? And how to keep the flows going, stateful NAT?

However, Kubernetes has its own ideas about networking, and EKS is no exception. While its not just dropping in a NAT64, EKS has dual stack designs. v6 assigned to pods, but also a host only v4 that gets NATed a couple times in the case of v4 to the internet.

Note how simple v6 on the application to v6 on the internet is, out the egress internet gateway with no NAT. Getting this connectivity with v6 external resources is reason for your organization doing this. In addition to removing concerns about sizing subnets for the number of pods.

Getting this implemented and on the modern internet is a project, yes. The very first thing in on a checklist for IPv6 on EKS is the cluster has to be created with v6.

You can do this project. Create a second cluster with this new design. Start new applications on it, and migrate others when there is a maintenance opportunity. Have a revert plan if there is a problem, to go back to how it was before. In the very worst case, the old cluster could be rebuilt as it was. This is infrastructure as code, after all.

Answer 2

The option is quite hidden away in the docs, but it is possible to do IPv6 egress from an IPv4 EKS cluster. This can be done using the ENABLE_V6_EGRESS option on the vpc-cni addon.

This configures each pod with a node-private address in the "fd00::ac:00/118" range. For external endpoints, the pod then performs NAT via the node.

Technically, this is not "IPv4 to IPv6 NAT", but it does achieve the goal of IPv6 egress on an IPv4 EKS cluster.

Steps required:

1. Assign IPv6 blocks on the VPC and subnets, and enable "Auto-assign IPv6 address" on the subnets. Add an egress-only internet gateway and configure the routing tables appropriately.
2. Rotate out all nodes to get an IPv6 address assigned on each.
3. Make sure the vpc-cni addon is at version 1.13+.
4. Update the vpc-cni addon with the following config: {"env":{"ENABLE_V6_EGRESS":"true"},"init":{"env":{"ENABLE_V6_EGRESS":"true"}}}. Only do this after rotating out all nodes, otherwise the rollout will fail.