This whitepaper is for historical reference only. Some content might be outdated and some links might not be available. # Internet Protocol version 6 Internet Protocol version 6 IPv6 is the next generation IP address standard intended to supplement and eventually replace IPv4, the original and ubiquitous IP address scheme. Every computer, mobile phone, home automation component, IoT sensor, and any other device connected to an IP-based network needs a numerical IP address to communicate with other devices. Public reachable IPv4 addresses are in short supply due to their widespread usage and constantly increasing demand stemming from the proliferation of connected devices globally. The last available block of new IP version 4 (IPv4) addresses was allocated back in 2011, and from that time on, everyone has been reusing a finite set of available addresses. IP version 6 (IPv6) is the replacement for IPv4, and it is designed to address the depletion of IP addresses, and change the way traffic is managed. **Topics** + [ # Brief IPv6 overview ](brief-ipv6-overview.md) + [ # IPv6 addressing ](ipv6-addressing.md) + [ # IPv6 adoption strategies and mechanisms ](ipv6-adoption-strategies-and-mechanisms.md) + [ # Interoperability ](interoperability.md) + [ # Planning IPv6 adoption in the AWS Cloud network ](planning-ipv6-adoption-in-the-aws-cloud-network.md) # Brief IPv6 overview Brief IPv6 overview The Internet Layer of the TCP/IP model aligns with the Layer 3 (Network) of the Open Systems Interconnection model (OSI model) and is used for transmitting data between the two nodes communicating over the IP. The IPv4 addressing scheme, with a 32-bit address field, provides around 4,000,000,000 possible addresses, which cannot fulfill the task of addressing the rapidly increasing number of the hosts on the internet. IPv6 offers the following significant features: + A larger address space — 128-bit long addresses vs 32-bit long addresses in IPv4 + A large block of globally unique and hierarchically assigned addresses, based on prefixes rather than address classes, to keep routing tables small and backbone routing efficient + A mechanism for the auto-configuration of network interfaces + Support for encapsulation of itself and other protocols + A class of service that distinguishes types of data + Improved multicast routing capabilities (in preference to broadcasting) + Built-in authentication and encryption + Methods to adopt IPv6 and maintain interoperability with IPv4 IPv6 uses the term node for any system that runs IPv6; that is, a host or a router. An IPv6 host is a node that does not forward IPv6 packets that are not explicitly addressed to it. A router is a node that forwards IP packets not addressed to it. Some considerations regarding the main differences between IPv4 and IPv6 follow: + **Headers** — IPv6 uses two distinct types of headers: + Main/regular IPv6 header + IPv6 extension headers The main IPv6 header is equivalent to the basic IPv4 version, despite some field differences that are the result of lessons learned from operating IPv4. IPv6 has a fixed 40-byte header that allows for faster processing of IP datagram. + **Flow labeling** — Flow labeling is a new field used by a node to label packets of a flow. A flow label of ‘0’ (zero) is used to indicate that packets have not been labeled. Packet classifiers can use the flow label, source address, and destination address fields to identify to which flow the packet belongs. Packets are processed in a flow-specific way by the nodes that are able to do it in a stateless manner or that have been set up with a flow-specific state. + **Address assignment** — IPv6 address can be assigned statically, using DHCPv6 and through Stateless Address Auto-Config (SLAAC), which makes use of the Media Access Control (MAC) address of the network interface to derive an IPv6 address for the node. + **Error correction** — IPv6 does not support header checksum capability, as it considered redundant, being processed both at the lower layer protocol (Ethernet) and upper layer protocols (TCP/UDP). + **Neighbor Discovery Protocol** — IPv6 defines Internet Control Message Protocol v6 (ICMPv6) messages to take the place of IPv4's ARP and other network discovery functions. It provides many improvements over IPv4, which includes Neighbor Unreachability Detection (NUD), improving packet delivery in the presence of failing routers, links, or mobile nodes. # IPv6 addressing IPv6 addressing The IPv6 address space is organized by using format prefixes, that logically divide it in the form of a tree so that a route from one network to another can easily be found. The main categories of IPv6 addresses are: + Aggregatable global unicast addresses (GUA) — `2000::/3` + Unique-local unicast addresses (ULA) — `FC00::/7` + Link-local unicast addresses — `FE80::/10` + Multicast addresses — `FF00::/8` Note that the rest of the IPv6 addresses are reserved by the IETF (Internet Engineering Task Force) and may be used for new technologies or to augment these space allocations in the future. # IPv6 adoption strategies and mechanisms IPv6 adoption strategies and mechanisms Working with customers, AWS observed the following two main drivers for IPv6 adoption. + Network Address Translation is no longer sufficient to work around exhaustion and poses significant challenges with overlapping IP addresses. + There are numerous organizational or regulatory mandates to adopt IPv6. Following is a summary of IPv6 adoption drivers: + **Mandated IPv6 endpoints** — Either mandated by a government policy or an industry regulator, and not necessarily tied to a particular use case. + **Interoperability with IPv6 networks** — The last years have seen a growing population of IPv6-only clients, and as a result so have the number of organizations wanting to cater to this user base. With the number of mobile IPv6-only users, many companies find they can’t afford to lose that section of their potential user base. + **Public IPv4 exhaustion** — As public IPv4 addresses become more scarce, allocating contiguous IP address ranges for public routing becomes more difficult and costly. + **Private IPv4 exhaustion** — As private IPv4 (RFC1918) addresses become exhausted and too fragmented within organizations’ private networks, IPv6-only networks offer opportunities to address additional nodes. At the time of this writing, global IPv6 adoption is primarily driven by the major internet providers, network device manufacturers, and organizations that need to grow their number of internet-reachable devices. Beyond these, rate of adoption is significantly slower. Reasons for this include the prevalence of NAT, and proxies used in combination with reusable private IPv4 address space (defined in RFC1918) which greatly reduces the number of unique internet-routable IP addresses. Also, the native lack of backwards compatibility between the two versions of IP protocol present barriers to adoption. Although your drivers will likely be similar to the needs of other organizations, each organization also has some unique requirements. Accordingly, best practices and design guidance in this paper are intended to offer guidance rather than a one-size-fits-all solution to IPv6 adoption. The design of your IPv6 network on AWS may differ from the examples provided in this document. However, this paper can help you make informed decisions as you embark to adopt IPv6. IPv6 adoption strategy depends on the driving force behind it. You may have an immediate goal such as addressing private IPv4 exhaustion, or the ability to provide IPv6 service endpoints as per government mandate, with the long-term goal of fully converting to an IPv6 only network. Following are the four main driving forces, and the corresponding adoption strategy: + **Private IPv4 exhaustion** — The goal is to provision new nodes and allocate routable IP addresses without IP overlap, and without the challenge of sourcing contiguous and usable IP addresses. **Adoption strategy** — Configure IPv6-only routing between dual stack network segments, to facilitate communication using the IPv6 stack. Provide IPv6 to IPv4 interoperability layer, such as dual-stack load balancers. You can configure IPv6-only subnets in your dual-stack Amazon VPCs, to accommodate for scale and growth, with NAT64 and DNS64 for backwards compatibility to IPv4-only parts of your network. + **Public IPv4 exhaustion** — The goal is to support IPv6-only clients connecting to your public endpoints. As an example, you may have an API endpoint for data upload from IoT devices which are connected to an IPv6-only network. The IoT devices have IPv6 addresses, and the network does not provide interoperability layer to IPv4. Other devices may operate in IPv4 networks. **Adoption strategy** — Create dual-stack VPCs and subnets. Configure AWS services such as load balancers and edge service in dual-stack mode with corresponding DNS record on the AWS Cloud. Optionally, provide separate endpoints for IPv4 and IPv6 in dedicated IPv4-only or IPv6-only deployments. + **Interoperability with IPv6-only networks** — The goal is to support connectivity to IPv6-only nodes from your IPv4-only network. This is a less frequent use case, because most endpoints operate in dual-stack mode and provide an interoperability layer. **Adoption strategy** — Create dual-stack VPCs and IPv6-only subnets as part of those VPCs. Use the AWS NAT Gateway with the integrated NAT64 capability, and DNS64 to maintain an interoperability layer. Full dual-stack adoption is often not practical, so providing backwards compatibility to IPv4 networks is required. + **Mandated IPv6 endpoints** — The goal is to support interoperability with IPv6-only nodes connecting to your services, and avoid building technical debt in new services. Have a plan and complete transition of older services which do not have a dedicated IPv6 or dual-stack capability. **Adoption strategy** — Create dual-stack VPCs and subnets. Configure AWS services such as load balancers and edge service in dual-stack model with corresponding DNS records on the AWS Cloud. Optionally, provide separate endpoints for IPv4 and IPv6 in dedicated IPv4-only and IPv6-only stacks. Your organization should be prepared to operate in heterogeneous mode for many years to come. For over 20 years, IPv6 coexisted side-by-side with IPv4, and it will continue to do so. The long-term goal is to be IPv6 everywhere and retire the IPv4 stack, but you don’t need to rush it. Instead, work backwards from your business requirements and act accordingly. If you are just starting with IPv6, small steps along with the power of the AWS Cloud will give you the needed confidence to transition more of your network to IPv6-only mode. # Interoperability Interoperability Although operating in dual-stack mode solves a lot of the problems with IPv4 and IPv6 interoperability, it creates management overhead. For example, security becomes harder because you have to manage two sets of security rules, one for each network stack. Routing and troubleshooting become harder, and you have to maintain additional records to existing DNS names. You may be able to avoid making the entire network dual-stack by focusing on implementing dual-stack at your border via load balancers. Existing segments of your network can continue to operate as IPv4 in most cases, and new segments are built with IPv6. Focus on implementing and operating interoperability layer where AWS services such as dual-stack VPC and load balancers, to help you solve interoperability challenges. The adoption of IPv6-only subnets in dual-stack VPCs enables you to expand and grow your network beyond the limited capabilities of the IPv4 space, and interoperability is ensured by the cloud-native Amazon VPC NAT Gateway with NAT64 and DNS64 integration. # Planning IPv6 adoption in the AWS Cloud network Planning IPv6 adoption in the AWS Cloud network Elastic network interfaces in an IP network could operate in three different modes: + **IPv4-only mode** — Your resources can communicate over IPv4, and if communicating to IPv6 nodes, require an interoperability layer. + **IPv6-only mode** — Your resources can communicate over IPv6, they do not require an IPv4 address, and if they are communicating to IPv4 nodes, they require an interoperability layer achieved through NAT64 and DNS64. + **Dual-stack mode** — Your resources can communicate over both IPv4 and IPv6. A separate interoperability layer is not required. ## IPv6 addressing plan on AWS IPv6 addressing plan on AWS Coming up with an IPv6 addressing plan is one of the most important initial tasks for any organization proceeding with IPv6 adoption. For most organizations, IPv6 is deployed in parallel with IPv4 in existing IPv4 AWS and hybrid networks. IPv4 addressing plans tend to grow over time, and consequently may be highly fragmented, not contiguous, or not big enough. Simply duplicating the IPv4 addressing scheme in some fashion in IPv6 might initially prove advantageous. However, any temporary advantage gained by such a shortcut will ultimately be surpassed by the ease and efficiency of operation and design offered by a proper IPv6 addressing plan that incorporates the key benefits of the larger allocations possible with IPv6. The virtually limitless scale of the IPv6 address space allows for an addressing plan no longer constrained by the scarcity of IPv4 addresses. Techniques like Variable Length Subnet Masking (VLSM) (previously required in IPv4 to economically match subnet size to host count on a given network segment) can be seen as unnecessary and obsolete in IPv6. Instead, it’s possible to adopt a consistent addressing plan by assigning significance to groups of VPCs according to network and segmentation needs. In AWS, IPv6 address space assigned to VPCs is assigned from the *globally unique unicast* address range. There are two options for IPv6 address assignment: + AWS-assigned IPv6 VPC classless inter-domain routings (CIDRs) + Bring your own IPv6 CIDR Blocks (BYOIPv6) **Note** [Amazon VPC now supports unique local address (ULA) CIDRs and private global unicast addresses (GUA).](https://aws.amazon.com/about-aws/whats-new/2024/08/aws-private-ipv6-addressing-vpcs-subnets/) **Amazon VPC IP Address Manager (IPAM)** Amazon VPC IPAM is a VPC feature that makes it easier for you to plan, track, and monitor IP addresses for your AWS workloads. You can also use IPAM's automated workflows to more efficiently manage both IPv4 and IPv6 addresses. With IPAM, you can track and have an inventory of the AWS-supplied IPv6, and you can also have granular control over your IPv6 prefixes configured in AWS with the Bring Your Own IPv6 (BYOIPv6) feature. Choosing AWS-assigned IPv6 addresses or BYOIPv6 addresses influences your ability to summarize prefixes, as well as to control the multi-account, multi-region addressing scheme. For more information, refer to [IPAM documentation](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) and the [Managing IP pools across VPCs and Regions using Amazon VPC IP Address Manager](https://aws.amazon.com/blogs/networking-and-content-delivery/managing-ip-pools-across-vpcs-and-regions-using-amazon-vpc-ip-address-manager/) blog post. ## AWS-assigned IPv6 VPC CIDR AWS-assigned IPv6 VPC CIDR By default, Amazon provides one fixed size (/56) IPv6 CIDR block to a VPC. This range is assigned by the service, and consequently, you can’t assign contiguous IPv6 CIDR blocks to VPCs in the same Region or based on other custom-defined criteria. For customers that have a large VPC footprint in AWS and prefer to use IP route summarization to simplify their overall environment, bring your own IPv6 (BYOIPv6) described, in the next section, may be the preferred solution. ## BYOIPv6 VPC CIDR BYOIPv6 VPC CIDR Alternatively, if you own an IPv6 address space, you can import it into AWS using the Bring Your Own IPv6 service. The smallest IPv6 address range that you can bring is /48 for CIDRs that are publicly advertised by AWS, and /56 for CIDRs that are not publicly advertised by AWS. You can also choose to bring a /48 and mark it as non-advertisable, keeping control of IP advertisements on your on-premises setup. After importing it, you can assign /56 ranges from the space to individual VPCs in the same account. For the process on how to “Bring Your Own IP (BYOIP),” refer to [Configure your BYOIP address range](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html#byoip-requirements). As summarization can be easily configured with contiguous IPv6 blocks, for multi-Region deployments, you can bring one or more /48 or larger prefixes to each Region. Consider route summarization at the VPC route table level, as well as when using AWS connectivity options such as [AWS Transit Gateway](https://aws.amazon.com/transit-gateway), [AWS Direct Connect](https://aws.amazon.com/directconnect/), and [Site-to-Site VPN](https://aws.amazon.com/vpn/). ## VPC subnet addressing VPC subnet addressing Although you can assign one /56 IPv6 CIDR block to a VPC, the VPC subnets are /64 fixed in length. This yields to the interface ID being /64 in length, in accordance with the general format of the IPv6 unicast addresses. Given the fixed size of the VPC CIDR and the subnet prefix, you have 8 bits for subnet allocation in the VPC, enabling you to create 256 subnets in the VPC. You can allocate IPv6 /64 CIDRs to dual-stack subnets (which allow you to run both IPv4 and IPv6 workloads), and to IPv6-only subnets (which allow you to run IPv6-only enabled resources).