Understanding dual-stack VPC in AWS
IPv4 has been the primary protocol for identifying and communicating with devices on the internet for many years. IPv4 addresses consist of 32 bits, allowing for approximately 4.3 billion unique addresses, which was initially sufficient when IPv4 was introduced. However, as the number of internet-connected devices has grown, and to address the problem of address exhaustion, IPv6 was developed with 128-bit addresses, providing a vastly larger address space.
Although IPv6 has been available for many years, its adoption has been slow, with IPv4 remaining the dominant protocol until recent years. The exponential growth of connected devices, including IoT, has significantly accelerated the shift towards IPv6. IPv6 offers not only a larger address space but also additional features that simplify aspects of address configuration and network renumbering. Furthermore, IPv6 helps reduce costs associated with IPv4, as the acquisition costs for IPv4 addresses continue to rise. This makes IPv6 a more cost-effective and scalable solution in the long term.
If you want a future-proof AWS infrastructure that takes advantage of the protocol’s benefits and prepares for the inevitable increase in IPv6 traffic, you can begin by creating a dual-stack VPC in which you can create IPv6-only subnets.
In this article, I will present dual-stack VPC and explain the changes compared to VPCs with only IPv4 CIDR blocks, which I discussed in my first article about VPCs.
Dual-stack VPC
A VPC must have an associated IPv4 CIDR block. Optionally, you can associate additional IPv4 CIDR blocks and one or more IPv6 CIDR blocks. Your VPC can have up to five IPv6 CIDR blocks. In AWS, you cannot create an IPv6-only VPC, but you can create a dual-stack VPC with IPv6-only subnets.
For both existing and new VPCs, enabling IPv6 involves associating one /56 IPv6 CIDR block. You can allocate the IPv6 CIDR from the Amazon pool of IPv6 addresses or use a /56 from a BYOIPv6 (Bring Your Own IPv6) pool defined with IPv6 addresses you own.
If you no longer want IPv6 support in your VPC but still want to use your VPC for IPv4 resources, you can remove the resources created with the IPv6 CIDR block and then remove the IPv6 CIDR block.
Dual-stack VPC Route table
In a dual-stack VPC, each route table has default local routes for both IPv4 and IPv6 CIDR blocks. This ensures that resources within the VPC can, by default, find each other and communicate using either IPv4 or IPv6 .
Dual-stack VPC Subnets
In a dual-stack VPC, you have the flexibility to create a mix of subnet types based on your requirements. You can have IPv4-only subnets, IPv6-only subnets, or dual-stack subnets, all within the same VPC. For each of these types, you can choose to make it public or private. This allows you to tailor your network configuration to accommodate both systems that rely on IPv4 and modern applications that benefit from the expanded address space and features of IPv6.
IPv4-Only subnets
When configuring an IPv4-only subnet, you need to select a CIDR block from one of the IPv4 CIDR blocks associated with your VPC. The subnet will handle IPv4 traffic and is suitable for resources that do not require IPv6 connectivity.
IPv6-Only subnets
For IPv6-only subnets, the CIDR block must be chosen from one of the IPv6 CIDR blocks associated with your VPC. This setup enables the subnet to support IPv6 addresses exclusively, facilitating communication over IPv6 networks.
Dual stack subnet
Dual-stack subnets are designed to support both IPv4 and IPv6 traffic simultaneously. When creating a dual-stack subnet, you must select two CIDR Blocks: one CIDR block from the IPv4 CIDR blocks and one from the IPv6 CIDR blocks associated with your VPC. This configuration allows resources within the subnet to have both IPv4 and IPv6 addresses, enabling seamless communication over both protocols.
Communication between resources of dual-stack VPC
Resources (ENIs) in a dual-stack subnet can communicate over both IPv4 and IPv6. Resources in an IPv4-only subnet can communicate only over IPv4, meaning they can interact with resources in IPv4-only subnets or dual-stack subnets using IPv4. Similarly, resources in an IPv6-only subnet can communicate only over IPv6, allowing interaction with resources in IPv6-only subnets or dual-stack subnets using IPv6.
Communication between IPv4-only and IPv6-only resources in a VPC is not possible by default, as there is no direct compatibility between the IPv4 and IPv6 protocols. For addressing this challenge in a dual-stack environment, solutions such as enabling DNS64 and NAT64 for IPv6-only subnets are available. I will not cover these solutions in this article, but you can find more details in 1, 2 and 3.
In the rest of the article, when I refer to communication within the VPC, it is assumed that all necessary compatibility layers are set up and communication between different IP protocols is possible.
Dual-stack VPC gateways
Internet Gateway
The Internet Gateway (IGW) can handle both IPv4 and IPv6 traffic. You need only one Internet Gateway attached to your VPC to manage traffic coming from the Internet to public resources and going from local public resources to the Internet, regardless of the type of IP traffic.
NAT Gateway
The NAT Gateway handles only IPv4 traffic and you need it for your private IPv4 resources to reach the Internet.
Egress-Only Internet Gateway
An Egress-Only Internet Gateway is a horizontally scaled, redundant, and highly available VPC component that allows outbound IPv6 communication from your VPC to the Internet. It functions similarly to a NAT Gateway but for IPv6 traffic. You need only one Egress-Only Internet Gateway per VPC for all your outbound IPv6 traffic from your private resources.
Dual-stack VPC public subnets
You have the possibility to launch a public IPv4-only subnet, a public IPv6-only subnet or public dual-stack subnet
Public IPv4-only subnet
You need an Internet Gateway (IGW) attached to the VPC, a route to this IGW ID for IPv4 internet traffic in the route table associated with the subnet, and elastic IP or public IP attached to the subnet resources.
For more details, you can refer to my first article, as the conditions for making an IPv4-only subnet public in a dual stack VPC remain unchanged compared to public subnets in VPCs with only IPv4 CIDR blocks.
Public IPv6-Only subnet
You need to attach an IGW to the VPC to handle IPv6 internet traffic. Next, add a route in the subnet route table for IPv6 internet traffic pointing to the IGW ID. The route must have the destination ::/0 and the target set to the IGW ID.
With these configurations, the subnet is now public and resources can interact with Internet.
Unlike IPv4 subnets, where you need to assign a public IP or Elastic IP to your resources to be publicly reachable, resources with IPv6 addresses can be publicly reachable by default.
Remark: The IPv6 addresses for VPCs are by default routable on the internet, but that doesn’t mean all IPv6 addresses used inside your VPC will actually be able to reach or be reachable from the internet. You need to allow this by configuring the gateways, the route tables and SG and NACL rules.
Public dual-stack subnet
Running subnets as dual-stack means that nodes have both IPv4 and IPv6 addresses simultaneously. The two types of traffic need to be treated independently.
For public traffic, you need to attach an IGW to the VPC. Then, update the route table attached to this subnet by adding two routes to direct both IPv4 and IPv6 public traffic through the IGW to reach the Internet.
- The first route has the destination 0.0.0.0/0 (all IPv4 traffic) and the target set to the IGW ID.
- The second route has the destination ::/0 (all IPv6 traffic) and the target also set to the IGW ID.
Public dual-stack subnet resources have a private IPv4 address, a public IPv4 address, and an IPv6 address. The private IPv4 address is used for internal IPv4 VPC communication, the public IPv4 address for IPv4 internet communication, and the IPv6 address for both IPv6 VPC and internet communication.
Dual-stack VPC private subnets
You have the possibility to launch a private IPv4-only subnet, a private IPv6-only subnet or private dual-stack subnet.
Private IPv4-only subnet
Subnets are private by default and resources in an IPv4-only subnet can communicate with other resources within the VPC. If you need your IPv4-only resources to initiate traffic to the Internet, you need a NAT Gateway in a public IPv4 subnet, associated with an Elastic IP address, and a route pointing to the NAT Gateway for IPv4 internet traffic in the route table of the private IPv4-only subnet.
For more details, you can refer to my first article, as the conditions for allowing an private IPv4-only subnet resources to send traffic to the Internet remain unchanged compared to private subnets in VPCs with only IPv4 CIDR blocks.
Private IPv6-only subnet
Private resources can communicate by default within the VPC. If you need your resource to initiate IPv6 traffic to the internet, you need to attach a IPv6 Egress-Only Internet Gateway to the VPC and add a route to the private IPv6-only subnet to point to the Egress-only Internet Gateway for IPv6 internet traffic (::/0)
Private dual-stack subnet
A private dual-stack subnet is designed to handle both IPv4 and IPv6 traffic within the VPC. To enable your private resources to initiate internet traffic, you need to configure different gateways for IPv4 and IPv6 traffic and update the route table of the subnet.
For IPv6 traffic, attach an Egress-Only Internet Gateway to your VPC. Update the route table associated with the private dual-stack subnet to include a route for ::/0, pointing to the Egress-Only Internet Gateway ID. This setup ensures that internet IPv6 traffic from your private instances is routed to the internet through the Egress-Only Internet Gateway.
For IPv4 traffic, create a NAT Gateway in a public IPv4 subnet and associate it with an Elastic IP address. Then, update the private dual-stack subnet route table by adding a route for 0.0.0.0/0, directing traffic to the NAT Gateway.
Private resources within a dual-stack subnet will have both private IPv4 and IPv6 addresses for internal communication. The private IPv4 addresses will be translated to the Elastic IP of the NAT Gateway for outbound IPv4 internet traffic, while the IPv6 addresses will be used directly for traffic passing through the Egress-Only Internet Gateway to the internet.
Diagram of dual-stack VPC key elements
Dual stack VPC traffic control
Security Groups (SG) and Network Access Control Lists (NACL) continue to play a crucial role in controlling traffic within a VPC.
For more information about NACLs and SGs, please refer to my first article.
NACL
You should configure NACLs to allow or deny communication between subnets from different CIDR blocks and protocols. Ensure that your NACL entries include rules for both IPv4 and IPv6 traffic.
The default NACL allow all IPv4 and IPv6 traffic in a dual-stack VPC.
Security Groups
Update your security group rules to include entries for IPv6 addresses. This enables IPv6 traffic to flow to and from your instances effectively.
AWS services that support IPv6
If you are seeking an IPv6-only solution on AWS, it is not possible at this time to completely avoid using IPv4. While many AWS services support IPv6, there are still some that do not or support it with some restrictions. For example, Amazon EC2 supports IPv6, but this support is restricted to instance types based on the Nitro system. You find in 1 and 2 details about services that support IPv6.
Given the current state of IPv6 support, a dual-stack configuration is the best step at the moment. This approach allows you to leverage the benefits of IPv6 while maintaining compatibility with services dependent on IPv4.
Enable IPv6 on an existing public EC2 instance
If you want to enable IPv6 on your existing instances, you need to configure it at the VPC, subnet, and instance levels. Here are the steps:
- Add a new IPv6 CIDR block to your VPC
- Asscoiate an IPv6 CIDR block to the subnet where your EC2 instance is located.
- Associate an IPv6 address to your EC2 instance.
4. Add a new route to the route table of the EC2 instance subnet that point Internet IPv6 traffic to the IGW ID attached to the VPC
5. Modify the SG linked to your EC2 instance to allow IPv6 traffic on the required protocol and port
Testing traffic in a dual-stack VPC
Here are some tests done in a dual-stack VPC. If you want to reproduce them, ensure that the instance types are based on the Nitro system (all instance types, except C1, M1, M2, M3, and T1) to handle IPv6 traffic. The route tables should be configured to route internet traffic to the appropriate gateway. The security groups of the instances should allow the traffic from the internet or between instances within the VPC, and the NACL should not deny traffic.
IPv6 traffic from public dual-stack instance to the Internet
IPv4 and IPv6 traffic from the Internet to public dual-stack instance
To test this, run the following commands on your EC2 instance:
sudo yum install httpd -y
sudo service httpd startIPv4 and IPv6 traffic from public dual-stack instance to private dual-stack instance
IPv6 traffic from public dual-stack instance to private IPv6-Only instance
IPv6 traffic from private IPv6-Only instance to the Internet
For this test, I SSHed from apublic dual-stack instance to the private IPv6-only instance, then launched IPv6 traffic to the internet from the private instance.
I hope this article gave you a clear overview of dual-stack VPCs and helps you make informed decisions for your AWS infrastructure.
AWSharing: Together, We Keep Growing! ❤️💪🚀
