The recent announcements on IPv6 support for the Network Load Balancer and Fargate reminded me of AWS’s steady progress towards more widespread coverage for the current version of IP. The EC2 networking team deserves credit for the advances made since IPv6 was first supported on the Classic Load Balancer back in 2011. I believe that success should not be measured in IPv4/IPv6 parity alone. The end state that we need is a fully viable IPv6-only VPC.

Why IPv6-Only

A dual stack network configuration is an intermediate step. This gives customer experience with IPv6; however, that the IPv4 stack remains is a crutch. Can you download OS packages from an obscure Ubuntu PPA over IPv6? Can you ship your logs to your favorite third-party logging service? You probably don’t know in a dual stack environments. These IPv4 dependencies are cloaked when you have an IPv4 stack to fall back on.

Dual stack represents added operational overhead and complexity. Now your security groups, NACLs, WAF rules and S3 bucket policies must permit access from the appropriate IPv4 and IPv6 prefixes. Your automation that processes LB logs must handle both IP versions. Your network security tools must include policies for IPv4 and IPv6. Your Route 53 domains require A and AAAA records for every resource. During troubleshooting, Ops has to take into account two protocol stacks and possibly unforeseen and browser-dependent interaction between them (think the Happy Eyeballs algorithm)).

Dual stack does nothing to solve IPv4 depletion. For workloads running in AWS VPCs, AWS is well-positioned to shield its customers from IPv4 address depletion. According to a recent blog post by Andree Toonk, Amazon owns approximately 100M IPv4 addresses. That’s a ton! One could argue that running workloads on the AWS VPC platform helps extend the lifetime of IPv4 with its massive collection of public IPv4 addresses and the ease of using multiple private IPv4 addresses from the RFC1918 and RFC6598 address blocks. This argument has validity; however, the abundance of IPv4 addresses within AWS won’t help your workloads communicate with end systems that only have an IPv6 address. The regional Internet registries do not have additional IPv6 prefixes to allocate. New deployments would need to find IPv4 addresses from the transfer market or must be able to scale NAT.

Required Enhancements

AWS doesn’t currently provide the capability to launch an IPv6-only VPC. It can’t. Crucial gaps exist in IPv6 support.

Here are a few examples.

• EC2 metadata
• CloudFront fetch from the origin
• API service endpoints
• Load balancer to instance traffic including health checks
• Route 53 resolver
• Lambda ENIs

I want to address the lack of support for IPv6 on the Lambda ENIs that are instantiated when Lambda is launched in a VPC. This is an important one for me as I frequently us Lambda to monitor and maintain VPC infrastructure. From health checks to reporting, I see Lambda as crucial in keeping the infrastructure functioning.

There are many other services that currently lack IPv6 support, and I’m sure all IPv6 proponents have their respective “want” lists.

Getting to an IPv6-only VPC involves more than enabling IPv6 on all AWS services. We need a way to set a flag such that the EC2 mapping service is completely turned off for IPv4. I believe this is a better approach than attempting to use SGs or NACLs to prevent IPv4 communication. This would eliminate the IPv4 stack as an attack vector.

Even though modern OSes will prefer IPv6, I’d like to see popular AMIs tweaked such that they do not configure IPv4 addresses. Sure, you can bake your own AMIs that do this. Why not make it easy?

Use Cases for IPv6-Only VPCs

While an IPv6-only service is not suitable for public web applications, there are services that do not need IPv4. The Internet of Things (IoT) is one example. IPv6 allows IoT devices to overcome the limitations of NAT and restores end-to-end reachability. This means any device can communicate directly with any other device and IPv6 servers on the Internet can initiate connections. Recall that NAT forces the devices with private IPv4 addresses to initiate the communication. Inbound connectivity in the IPv4 world requires port forwarding that has very poor scaling properties. If are building services in AWS that need to communicate with IoT devices, considering architecting a solution based on IPv6 transport.

Telecoms have been leaders in IPv6 deployments. The benefits of running IPv6 workloads in the VPC for managing mobile infrastructure mirror that of IOT: end-to-end reachability and the avoidance of NAT complexity. Network monitoring, compliance, performance analytics and handset management are functions that can be performed more elegantly and at reduced cost over IPv6 when compared to IPv4. The alternative is often re-using RFC1918 IPv4 addresses to create confederations that cannot communicate with one another without NAT.

Conclusion

The legacy IP protocol plays an outsized role in the VPC platform. As the world continues its march toward a ubiquitous IPv6 Internet, I expect AWS to continue to IPv6-enable its services. For workloads that do not need to communicate with the long tail of IPv4-only endpoints, AWS customers would benefit from the ability to instantiate IPv6-only VPCs. AWS prides itself for adding features based on customer demand so let’s encourage the company to put resources behind this enhancement.