IPv6 adoption strategies on AWS

Back in 2019, RIPE NCC announced that they have allocated the last block of IPv4 address, leaving them with no IPv4. In addition to that, other internet registries (IANA, ARIN) have no block of IPv4 addresses. The exhaustion of IPv4 addresses brings the demand for adoption of IPv6 addresses. In this blog post, we will explore different strategies you can use to start adopting / deploying IPv6 in your environment on AWS.

In the past 10 years, the world has seen a rise in adoption of IPv6, going from 1.66% to 36.44% with over 1.55 billion estimated users. Aside from the exhaustion of IPv4 addresses that is driving the adoption of IPv6, there are several challenges that IPv6 addresses. See next section for more about the challenges IPv6 solves.

Expansion and market growth: we have seen several markets going with IPv6 first mentality to address challenges of smaller CIDR blocks. An example of this is IoT markets. In addition to this, Mergers and Acquisitions get simplified as IPv6 CIDR Blocks are larger and globally unique, hence addressing the challenges we face with overlapping CIRDs when using IPv4 CIDRs.

Policy, Technical and Cost: Mandates and policies requires keeping the internet current and up to date, this involves the government and corporate bodies, for example: Apple requires all applications that will be uploaded to the Apple play store to support IPv6 only communication. While not all applications must be modified to enable IPv6 communication, for applications developed to support IPv4 only traffic, they must be modified. Another example is the US Government that requires "All newly acquired networked Federal information systems shall be IPv6-enabled at the time of deployment to ensure the IPv6 only requirement is met no later than FY 2023". When we look at the technical perspective, internet routing tables get simplified when using IPv6, and IPv6 addresses enable large numbers of unique node addresses. In addition, as IPv6 are public by default, it takes away the need for NAT, hence reducing the hops in between networks and in turn reduces latency with increases performance. Finally, when we look at using IPv4, they are becoming costly to use, in fact AWS is now charging for every public IPv4 address you have in your account. But more on this in the next section.

In 2023, AWS Announced that by 2024 1st February, there will be charges associated to all public IPv4 you have in your account. Regardless of the IP address being attached to a resource or not. This decision was driven by the scarcity of IPv4 addresses. However, what does this mean for you and I as users of AWS? Well simply, the cost comes as $0.005 per IP per hour which totals to $43.8 annually per IP. Looking at this, if you have are a network heavy company, you can imagine the amount of money you will be spending on IP addresses. To avoid spending more than you are supposed to do, you have to be frugal with the use of IPv4 addresses. This can be done in several ways:

- You can leverage bringing your own IP (BYOIP) addresses for your use-cases.

- You can use Public IP Insights to monitor, analyse and audit public IPv4 usage all across your AWS organizations, this way you can delete addresses you are not using.

- Finally, a business justification for you to accelerate your adoption of IPv6, which we will take a look in coming sections.

In this section, we will take a look at how AWS approaches the support of IPv6 for different services. Starting off, a lot of AWS services have been supporting IPv6 and more will be supporting IPv6 in the future. Services in Compute, Network, Storage, AI/ML, Data Analytics and more are supporting IPv6 on AWS. However, how does AWS approaches customers’ requests? When our customers make a request for IPv6 support in a given services, AWS look at it in 3 different ways:

1. IPv6 Support for public management endpoint: This is when a customer wants the service to support IPv6 at the edge. Meaning when a client makes a request from outside AWS to a resource in AWS, the protocol IPv6 will be supported.

2. IPv6 Support for VPC endpoints: A VPC endpoint allows you to connect to AWS services privately without traversing the public internet from your VPC. In this case, IPv6 will be supported for a service for private connectivity between your private VPC and AWS service.

3. IPv6 Support for in-VPC resources: This is for all service that can be deployed in a VPC. Hence when a customer request for a service to support IPv6 and the service can be deployed in a VPC, then you will have to use dual stack mode on your VPC to enable the usage of IPv6 when a service is supporting IPv6.

We will take a look into what is dual stack mode and how it enables you to start adopting IPv6. In the meantime, here is AWS IPv6 Support Dashboard. You can find all AWS services that supports IPv6 in either public management endpoint, VPC endpoint or even dual-stack mode.

Before we take a look into dual-stack mode, I will briefly explanation the difference between notation of IPv4 and IPv6.

Above is an example of IPv4, IPv4 is divided into 4 octets separated by dots. It is represented in decimal to make it easy for humans to remember.

While IPv4 is represented in decimals, IPv6 is represented in hexadecimals. As you can see a sample of IPv6 above, it is divided into 8 hextets separated by columns. As this might be huge to for humans to remember, there is a way for compressing an IPv6 to make it easy for humans. Below is a compressed version of the above IPv6.

The compression is done by removing any leading zeros. Now that we understand how IPv6 will appear in our architectures, let’s take a look at dual-stack VPC and the subnet types in a dual-stack VPC.

In the above architecture, we show a dual-stack VPC, however what makes it dual-stack? Well, the VPC have both IPv4 and IPv6 CIDRs attached to it. Note that you cannot create a VPC without an IPv4 CIDR, hence if you want to support IPv6, you must create the VPC with IPv4 and then add an IPv6 CIDR to the VPC. You can add up to 5 IPv6 CIDRs to a VPC and your IPv6 CIDRs from AWS CIDR pool will start from /44 to /60. Hence you can attach IPv6 CIDRs to same VPC with Increments of /4. When you have dual-stack VPC, you have 3 ways of creating subnets:

1. IPv4 only Subnets: you can create a subnet in the VPC and assign only IPv4 CIDRs, hence this subnet will only host IPv4 resources.

2. Dual-stack Subnets: the dual-stack subnets allow you to attach both IPv4 and IPv6 to the subnet. Hence allowing you to host resources that support both IPv4 and IPv6 in the subnets.

3. IPv6 only Subnets: with this subnet, you only assign an IPv6 CIDR to it, which will allow you to host resources that support IPv6 and hence protocol for communication to this subnet is going to be IPv6 only.

When we are ready to start adopting IPv6, we need to plan and strategize on how to go about it, well firstly we will need to choose our addressing scheme. When it comes to choosing our addressing scheme for IPv6 on AWS, we have 3 main options which are explained below:

1. Design your IPv6 addressing strategy using Amazon VPC Ip address Manager also known as IPAM. IPAM is a VPC component that allows you to design your IP pools across all your accounts and across all regions, making is a single pane for IP management.

2. Choose between bring your own IP (BYOIP) or use AWS provided CIDR blocks.

3. Contiguous IPv6 blocks the BYOIP or AWS Provided CIDRS

The design above is a representation of how you will allocate CIDR blocks to different pools when bringing you IP. In this case we have workloads in 3 regions and we want to provide IPv6 CIDR blocks to these regions, hence we give 00 to US region, 01 to EU region and 02 to Asia Pacific region. Subsequently in each region we broke down the CIDRs from /52 to /54 to different environments, hence now our VPCs can choose from these pools and assign to themselves a /56 address.

IPv6 Design with Amazon provided CIDRs:

In this stage, instead of bringing our own Ip, we want to use Amazon provided CIDRs, hence, you choose from Amazon pool of CIDRs and then the design will be same as it was done in the first stage when you use BYOIP. We have now understood what dual stack is, and how to design strategies for IPv6 on AWS, further we will look into adoption strategies of IPv6 on AWS.

In this blog post, we have seen the global exhaustion of IPv4 and cost as the driver for adoption of IPv6 and how AWS is enabling customers to adopt IPv6 by supporting IPv6 on several AWS services. While AWS provide support for IPv6 on multiple services, it is important for customers to understand how to design and plan for the adoption of IPv6 at scale. We have seen two main strategies, the outside in and the inside out strategy. In the next blog post we will see in details how to use AWS services to plan and implement this strategies.