This whitepaper is for historical reference only. Some content might be outdated and some links might not be available.
# Designing an IPv6 AWS Cloud network
**Topics**
+ [Amazon VPC design](amazon-vpc-design.md)
+ [Supporting Amazon VPC services](supporting-amazon-vpc-services.md)
+ [Amazon VPC connectivity options for IPv6](amazon-vpc-connectivity-options-for-ipv6.md)
+ [Amazon VPC internet access](amazon-vpc-internet-access.md)
+ [Hybrid connectivity design](hybrid-connectivity-design.md)
+ [Designing DNS for IPv6](designing-dns-for-ipv6.md)
# Amazon VPC design
Planning and implementing network connectivity in AWS is usually one of the foundational tasks you perform when deploying workloads in AWS. Following are some of the aspects typically considered:
+ Amount and nature of Amazon VPCs required
+ Amazon VPC CIDR range and IP address allocation including Bring Your Own IP (BYOIP) for public connectivity
+ Number and type of subnets
+ Number of availability zones to cover
+ Permitted traffic paths
+ Internet incoming and outgoing traffic options
+ Hybrid connectivity
+ Inter-VPC connectivity
+ Scalability and expansion
Although most of these aspects apply equally to both IPv4 and IPv6, existing literature is mostly written in the context of IPv4 only. This section augments these existing resources by providing IPv6 specifics. AWS recommends you read the existing, IPv4-centric material first to get the most out of this content.
## VPC IP address assignment
Your VPC can operate in dual-stack mode—your resources can communicate over IPv4, IPv6, or both. IPv4 and IPv6 communication are independent of each other. You cannot disable IPv4 support for your VPC, but you can have IPv6-only subnets in your dual-stack VPC. To enable dual-stack operation for your VPC, you can associate up to five IPv6 CIDR block ranges per VPC.
### Subnet address assignment
After you have associated an IPv6 prefix to a VPC, you can begin to assign one /64 IPv6 prefix to each subnet. Note that these assignments are configured on a per-subnet basis, and it’s possible to have a mix of dual-stack IPv6, IPv4-only, and IPv6-only subnets within the same VPC. This is useful in scenarios where you require IPv6 capability for a subset of the network as described in the drivers for adoption section, and you need to maintain dual-stack and backwards-compatible deployments in the same VPC.
The address assignment of resource within a subnet occurs at two levels:
+ The Amazon VPC elastic network interface construct configuration
+ A resource’s networking stack configuration
### IP addressing of the elastic network interface
Network-addressable resources deployed within a VPC must have an elastic network interface. Examples of resources include:
+ [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (Amazon EC2) instances
+ Interface VPC endpoints
+ [AWS Lambda](https://aws.amazon.com/lambda/) functions (deployed in VPCs)
+ [Amazon Relational Database Service](https://aws.amazon.com/rds/) (Amazon RDS) database instances
Elastic network interfaces are logical constructs in the VPC which represent a resource’s network adapter at runtime. Each elastic network interface may have one or more IPv4 addresses as well as one or more IPv6 addresses. This means you are not required to provision separate elastic network interfaces for IPv4 and IPv6, and there is no need to configure additional elastic network interfaces on your workloads to enable IPv6.
An elastic network interface placed into an IPv6 enabled subnet may be created with and modified to have an IPv6 address assigned. You can configure this behavior per elastic network interface, and you can choose to either have AWS auto assign one for you or specify an unused address in the subnet’s allocated range. In either case, the address configured remains constant throughout the elastic network interface’s life unless explicitly modified.
![\[This is a diagram that shows a dual-stack Amazon VPC with two availability zones and four subnets.\]](http://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/images/dual-stack-amazon-VPC.png)
### IP addressing at the resource’s networking stack
In IPv4, the preferred method for assigning IPv4 addresses is to use Dynamic Host Configuration Protocol (DHCP). DHCP is based on IPv4’s broadcast mechanism that allows hosts to announce themselves to DHCP servers. These servers can then offer an IP address lease to the client. IPv6 has no concept of broadcast (refer to the [Brief IPv6 overview](brief-ipv6-overview.md) section of this document) and initially did not feature DHCP capability. However, the community has become used to DHCP, and so [RFC 8415](https://datatracker.ietf.org/doc/html/rfc8415) was developed to introduce DHCPv6. In the absence of broadcast capability, DHCPv6 makes use of the well-known multicast address for all DHCP servers/relays, `ff02::1:2`.
Amazon VPC has built in support for address assignment via DHCP for both IPv4 and IPv6. Address allocation works similar to static address reservation in traditional DHCP servers: the IP address assigned to the elastic network interface construct determines the IP address the VPC DHCP infrastructure offers the resource requesting an address. Amazon VPC also offers the ability to configure DHCP option sets which can be used to provide additional configuration information such as domain name or DNS servers to use. In a dual-stack design all IP addresses used in an option set need to be IPv4.
**Note**
Be aware that if you’re trying to add IPv6 to an existing or migrated workload, the host OS may not yet be set up to use DHCPv6. Consult the [documentation](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html#vpc-migrate-ipv6-dhcpv6) to learn how to enable and verify DHCPv6 operation for your chosen operating system. Also, for the IPv6-only EC2 instances in IPv6-only subnets, you need to verify that the OS and AMI you’re using can operate under the specific conditions, without an IPv4 address from the VPC CIDR(s).
**Note**
The use of DHCP is optional, and you may statically configure the host OS with an IP address. However, the VPC anti-spoofing mechanism enforces the IP address configured on the network interface controller (NIC) to match the one configured on the underlying elastic network interface. AWS recommends enabling DHCP, even for resources that require static IP addresses, and managing static IP assignment at the elastic network interface level.
The EC2 instances launched in IPv6-only subnets and the Elastic Network Interfaces (ENIs) attached to them are also assigned IPv6 addresses through the DHCPv6 options set, from the IPv6 CIDR block of your subnet. These instances do not require private IPv4 addresses to be assigned.
# Supporting Amazon VPC services
AWS exposes a set of supporting services within customer VPCs at well-known/reserved addresses. These services are traditionally exposed from the IPv4 link-local address range (`169.254.0.0/16`). For [AWS Nitro System](https://aws.amazon.com/ec2/nitro/) instances, AWS also provides these services using IPv6 ULAs.
## Instance Metadata Service (IMDS)
The instance metadata is information about your instance. Instances can introspect this at runtime by querying the IMDS available to it at `169.254.169.254`. For Nitro-based instances with IPv6 addresses, AWS provides this service at the `fd00:ec2::254` IPv6 endpoint.
For more details, refer to [Use IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html).
## Route 53 DNS resolver
Amazon VPC features a built-in DNS resolver which resides at `VPC_CIDR_BASE + 2` and `169.254.169.253`. IPv6 enabled Nitro instances can access the service via `fd00:ec2::253`. Additionally, for IPv6 to IPv4 backwards-compatibility and communication, you have the option of using the AWS-managed DNS64 services, together with NAT64. Amazon Route 53 Resolver and DNS in general are discussed at greater length in the [Designing DNS for IPv6](designing-an-ipv6-aws-cloud-network.md) section of this document.
## Network Time Protocol server
Amazon VPC provides a Stratum-3 NTP server at `169.254.169.123`. Nitro-based IPv6 enabled instances can reach this server via `fd00:ec2::123`.
## IP-based naming and resource-based naming for Amazon EC2
When you launch an EC2 instance with IP address-based naming (IPBN), the guest OS hostname is configured to use the private IPv4 address. The format for an instance in any AWS Region is `private-ipv4-address.region.compute.internal`
For example: `ip-10-20-14-8.ec2.internal`
Resource-based naming (RBN) is used automatically when you launch EC2 instances in IPv6-only subnets. RBN is not selected by default when you launch an instance in dual-stack subnets, but it is an option that you can select depending on the subnet settings. When you launch an EC2 instance with a resource-based hostname type, the guest OS hostname is configured to use the EC2 instance ID.
The format for an instance in any AWS Region is: `ec2-instance-id.region.compute.internal`
For example: `i-0123456789abcdef.us-west-2.compute.internal`
DNS queries for both IP address-based naming (IPBN) and resource-based naming (RBN) DNS hostnames coexist to ensure backward compatibility and to allow you to migrate from IPBN to RBN. For private DNS hostnames based on IPBN, you cannot configure whether a DNS A record query for the instance is responded to or not. DNS A record queries are always responded to. In contrast, for private DNS hostnames based on RBN, you can configure whether DNS A and/or DNS AAAA queries for the instance are responded to or not.
You can configure the response behavior when you launch an instance or modify a subnet, and you can make the RBN DNS query configuration changes when you launch an instance, create a subnet, or modify a subnet.
For more information, see [Amazon EC2 instance hostname types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html).
# Amazon VPC connectivity options for IPv6
There are a growing number of ways in which Amazon VPCs can connect to each other. Many of these options are detailed in the [VPC to VPC connectivity](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/vpc-to-vpc-connectivity.html) section of the [Building a Scalable and Secure Multi-VPC AWS Network Infrastructure](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html) whitepaper. AWS recommends you read the following subsections alongside, and it follows the same structure while providing additional insight regarding IPv6 operation as both papers cover:
+ VPC peering
+ AWS Transit Gateway
+ VPC subnet sharing
+ AWS PrivateLink
## VPC peering
VPC peering is the simplest method for VPC-to-VPC connectivity. It supports both intra- and inter-Region connectivity. The peering itself is IP protocol agnostic. After you establish peering, you must configure one or more static routes defining which prefixes are reachable. Both IPv4 and IPv6 prefixes may be routed across the same peering.
The following diagram depicts a VPC peering between two VPCs supporting IPv4 and IPv6 simultaneously. The peering is agnostic, and the subnet route tables are the deciding factor for which prefixes are reachable.
![\[This is a diagram that shows dual-stack IPv6 VPC peering.\]](http://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/images/dual-stack-ipv6-vpc-peering.png)
With VPC peering, you can choose to route only the IPv6 CIDRs of your peered VPCs, thus ensuring IPv6-only connectivity. Also, you cannot peer two VPCs together if their IPv4 CIDRs are overlapping and their IPv6 CIDRs don’t overlap. For this use case, you can use the AWS Transit Gateway.
## AWS Transit Gateway
[AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) is a scalable highly available way to establish network connectivity between multiple VPCs. A Transit Gateway is a Regional construct, and attaches VPCs within the same Region. Transit Gateways located in different AWS Regions can establish a peering relationship, enabling global connectivity for your network.
## IPv6 connectivity with Transit Gateway
You use a Transit Gateway attachment to connect a VPC to a Transit Gateway. An attachment deploys an elastic network interface into each subnet you select. Traffic is routed into Transit Gateways using static routes in VPC subnet routing tables with the attachment as the next-hop. The attachments themselves are IP protocol agnostic, and you can route IPv4 and IPv6 prefixes via the same attachment. To support IPv6, the elastic network interfaces used by the attachments need to have IPv6 addresses assigned to them.
**Note**
If you retrofit IPv6 into an existing VPC with a Transit Gateway attachment, its elastic network interfaces won’t be auto-assigned IPv6 addresses; you need to explicitly configure assignment for the elastic network interfaces. If you don’t, IPv6 traffic cannot use the attachment.
**Note**
You cannot create a transit gateway attachment using IPv6-only subnets.
![\[This is a diagram that shows dual-stack AWS Transit Gateway routing.\]](http://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/images/dual-stack-aws-transit-gateway-routing.png)
## IPv6 traffic within and between Transit Gateways
A Transit Gateway attachment is both a source and a destination of packets. You can attach the following resources to your Transit Gateway:
+ VPCs
+ One or more VPN connections
+ One or more AWS Direct Connect gateways
+ One or more Transit Gateway Connect attachments
+ One or more Transit Gateway peering connections
A Transit Gateway has one or more routing tables. A routing table can receive its entries through a combination of static route configuration and dynamic propagations from other attachments (VPC, Direct Connect, Site-to-Site VPN, or Connect Peering). In either case, IPv6 routes are supported.
### AWS Transit Gateway Connect attachments for IPv6
You can create a *Transit Gateway Connect attachment* to establish a connection and dynamic routing between a transit gateway and third-party virtual appliances (such as SD-WAN appliances).
These attachments take the form of IP Generic Routing Encapsulation (GRE) protocol tunnels and enable dynamic exchange of routing information between an EC2 instances in a VPC and a TGW. Route exchange is facilitated by a Border Gateway Protocol (BGP) peering. TGW connect peers support IPv6 using Multi-Protocol BGP (MP-BGP) and a `/125` CIDR block from the well-known `fd00::/8` unique local address range.
Multiprotocol BGP (MP-BGP) is an extension to BGP that enables BGP to carry routing information for multiple network layers and address families. MP-BGP can carry the unicast routes used for multicast routing separately from the routes used for unicast IP forwarding.
![\[This is a diagram that shows AWS Transit Gateway Connect dual-stack IPV6 routing.\]](http://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/images/aws-transit-gateway-connect-dual-stack-ipv6-routing.png)
## AWS PrivateLink
[AWS PrivateLink](https://aws.amazon.com/privatelink/) provides private connectivity between VPCs, AWS services, and customer on-premises networks, without exposing traffic to the public internet. AWS PrivateLink makes it easy to connect services across different accounts and VPCs to significantly simplify your network architecture.
![\[This is a diagram that shows AWS PrivateLink in a dual-stack scenario.\]](http://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/images/aws-privatelink-in-a-dual-stack-scenario.png)
## VPC sharing
VPC sharing allows VPC owners to share a subnet across AWS accounts. You may share dual-stack subnets the same way as IPv4-only ones. IPv6 resources deployed into a shared subnet function identical to those deployed into non-shared subnets.
# Amazon VPC internet access
## Internet reachable IPv6 resources
As previously stated, elastic network interfaces retain their IPv6 addresses throughout their lifetime. For IPv4, elastic network interfaces can have zero or more Elastic IP addresses associated with them. An Elastic IP address defines a static 1:1 NAT relationship between an elastic network interface’s IPv4 address and a public internet-routable address.
![\[This is a diagram that illustrates internet access for a VPC public subnet.\]](http://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/images/internet-access-for-a-vpc-public-subnet.png)
In IPv6, VPC addressing is already globally unique, and therefore Elastic IP addresses are not required. Amazon assigned IPv6 addresses are automatically publicly advertised whereas for BYOIP ranges this is optional. In either case, resources deployed only have IPv6 internet reachability if their subnet’s routing table contains IPv6 destinations (such as `::/0`) via either an internet gateway or outbound traffic-only internet gateway.
![\[This is a diagram that illustrates internet access from a VPC private subnet.\]](http://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/images/internet-access-from-a-vpc-private-subnet.png)
# Hybrid connectivity design
Hybrid connectivity scenarios are a reality for many customers. We offer two methods for addressing these: AWS Direct Connect and AWS managed Site-to-Site VPN.
AWS previously published the [Hybrid Connectivity](https://docs.aws.amazon.com/whitepapers/latest/hybrid-connectivity/welcome.html) whitepaper, which focused on designs and considerations around these solutions, and most of that content remains relevant. However, that paper does not consider IPv6. This section assumes you are acquainted with the aforementioned document, and it focuses only on the best practices and differences compared to IPv4 implementations.
## AWS Direct Connect
[AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) is a cloud service solution that makes it easy to establish a dedicated network connection from customer premises to AWS.
Different aspects of the Direct Connect service deal with different layers of the OSI model. The choice of IPv6 only affects configuration related to Layer 3, so many aspects of Direct Connect configuration such as physical connections, link aggregation, VLANs, and jumbo frame are no different from IPv4 use cases.
Where IPv6 does differ is when it comes to addressing and configuration of BGP peerings on top of a virtual network interface (VIF). There are three types of VIFs:
+ Private
+ Transit
+ Public
The remainder of this section covers all of these.
**Note**
You can provision either 0 or 1 peering per address family on to a given VIF, so it is possible to retrofit IPv6 onto an existing VIF without the need to reprovision or deploy a new one.
**Transit and Private VIF IPv6 peerings** — Whereas in IPv4 you are free to choose your own addressing for the logical point-to-point, in IPv6, AWS automatically allocates a /125 CIDR for each VIF, and it’s not possible to specify custom IPv6 addresses.
### Advertising IPv6 prefixes from AWS
When associating a Direct Connect Gateway directly with a Virtual Private Gateway (VGW) you can specify “Allowed Prefixes”. Think of this like a traditional “prefix-list” filter, controlling the prefixes advertised to your customer gateway. With IPv4, specifying no filter equates to `0.0.0.0/0` — no filtering. With IPv6, not specifying a value here results in all advertisements being implicitly blocked.
Associating a Direct Connect Gateway with Transit Gateway “Allowed Prefixes” acts not as a filter but as static origination of routes advertised to your customer gateway.
**Note**
An “Allowed Prefix” IPv6 CIDR must be of length /64 or less specific, but you cannot specify “`::/0`”.
VGW and Transit Gateway behave differently in regard to the “Allowed Prefixes” parameter, as previously described.
### Advertising IPv6 prefixes to AWS
In terms of advertising prefixes from your on-premises facility to AWS, there are no CIDR restrictions, though standard Direct Connect quotas apply. Any prefix advertised is local to your AWS network and not propagated beyond its boundary.
**Public VIF IPv6 peerings** — As with transit and private VIF peerings, public IPv6 peerings are allocated /125s from AWS owned ranges automatically. These IPs are used to support the BGP peering, and you need to use your own IPv6 prefixes to communicate over the peering.
**Note**
With IPv4 public VIFs, it’s possible to use the AWS assigned public IPv4 /31 in combination with NAT to enable access from privately addressed on-premises resources (to support use cases where you are not in a position to provide public IPv4 address space). With IPv6, however, you must own and specify an IPv6 prefix at creation. Note that if you specify an IPv6 prefix that you don’t provably own, the VIF will fail to provision and remain in the “verifying” state.
### Routing IPv6 over public and private or transit VIFs
If you’re using AWS-assigned CIDR blocks for the VPCs, or BYOIPv6 with CIDRs that are marked as *advertisable* by AWS, you will receive over the public VIF peering the summary prefixes that contain the CIDRs of your VPCs. When using public VIFs in conjunction with private/transit VIFs, take into account that your device will receive the same prefixes (the ones for your VPCs) over both types of VIFs. At this point, route filtering on your customer device needs to be taken into consideration, to ensure symmetric flow of traffic over the different virtual interfaces.
![\[This is a diagram that shows Direct Connect dual-stack support\]](http://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/images/direct-connect-dual-stack-support.png)
## Amazon-managed VPN
AWS Site-to-Site VPN connectivity configuration comprises multiple parts:
+ The customer gateway, which is the logical representation of the on-premises VPN end point
+ The VPN connection
+ The local device configuration on the VPN appliance, represented by the customer gateway
Any AWS S2S VPN connection consists of two tunnels. It is this connection that defines the IP addressing, ISAKMP, IPsec, and BGP peering parameters.
**Note:** AWS supports IPv6 for IPsec tunnels terminating in Transit Gateway VPN attachments only.
### Customer gateways
While AWS supports IPv6 within IPsec tunnels, the underlying connectivity occurs via IPv4. This means that both the AWS and customer VPN terminating devices need to be addressable via public IPv4 addresses. On the AWS side, this IP is automatically allocated from the AWS Region’s public EC2 IP space. On the customer side, this means you require an internet reachable IPv4 address for your appliance.
### VPN connections
A single VPN connection can carry IPv4 or IPv6 traffic, but not both at the same time. When configuring a connection, you specify either IPv4 or IPv6 for use inside the tunnel. You are free to choose this address, or let Amazon generate it. If you choose to specify a CIDR, it has to be a `/126` taken from the unique-local address range `fd00::/8`. If you don’t specify one Amazon selects a `/128` from this range for you. In either case, the Amazon side of the connection is the first and your side the second usable IPv6 address in the subnet.
Another element to consider are the local and remote IPv6 Network CIDR ranges. These can either be `::/0` or specific prefixes. This configuration defines the IPsec Phase 2 Security Association (SA) that can be negotiated. If you specify a prefix, be sure to configure your customer gateway appliance to negotiate this accordingly.
**Note**
Even if you specify a `/126`, the console displays the IPv6 tunnel CIDR as a `/128`. While an IPv4 address is always configured, traffic on this range will not be able to flow, as the SA settings specified only permit negotiating the IPv6 SA.
### Customer gateway configuration
For device-specific configuration of the customer gateway, AWS recommends you consult the vendor’s documentation on how to set up IPv6 VPNs. There are vendor-independent nuances to IPv6 S2S VPNs not present in IPv4, and the remainder of this section outlines these.
AWS provides generated configurations for IPsec to download, but currently this covers only IPv4 configuration. Some settings and configuration parameters are independent of IP protocol version. However, settings related to tunnel addressing, phase 2 SA negotiation, and peering configuration do differ.
When using the AWS templates, be sure to omit IPv4 specific parts, and replace them with the IPv6 equivalents.
When specifying the local and remote CIDRs, make sure to configure your VPN appliance to negotiate the IPsec Phase 2 SA to match the AWS side. If you want to use BGP rather than static routing on the VPN and use LOCAL REMOTE CIDR ranges to scope the Phase 2 SA, then the P2P IPs must be included in the CIDR block. As a result, it is only possible to delimit SA scope if using `fd00::/8` on both sides of the VPN, and if non-unique local addressing is used, the SA has to be negotiated as `::/0`.
When using an AWS-generated tunnel IP, or specifying a `/128` CIDR range establishment of the BGP, peering will fail by default. The reason is that a `/128`, like a `/32` in IPv4, is a host route. You will need to define a static route pointing at the AWS side of the tunnel to establish the BGP peering.
![\[This is a diagram that shows AWS VPN dual-stack configuration.\]](http://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/images/aws-vpn-dual-stack-configuration.png)
# Designing DNS for IPv6
The core concept of DNS is unchanged from IPv4. From a Layer 3 perspective, DNS is just another application, and therefore, by virtue of the OSI/ISO model provided abstraction, agnostic to the chosen network layer protocol.
Regardless of the IP version, there is a deep link between DNS and the IP layer. The DNS specification has adapted and introduced an additional type to accommodate IPv6 addresses. In IPv6 the equivalent of the IPv4 “A” records are AAAA records. This means that it is possible to use IPv4 as the network protocol to connect to a DNS server and resolve an IPv6 (AAAA) record.
## PTR records
A pointer (PTR) record translates an IP address to its domain name. IPv6 addresses are reverse mapped under the domain IP6.ARPA. IPv6 reverse maps use a sequence of nibbles separated by dots with the suffix “.IP6.ARPA” as defined in RFC 3596. For example, the reverse lookup domain name corresponding to the address `2001:db8:1234:1a00:1:2:3:4` would be `4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.a.1.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa`.
## Alias records
[Amazon Route 53](https://aws.amazon.com/route53/) supports alias records. Route 53 alias records are mapped internally to the DNS name of alias targets such as AWS resources. Route 53 monitors the IP address associated with an alias target's DNS name for scaling actions and software updates. The authoritative response from Route 53 name servers contains an A record (for IPv4 addresses) or AAAA record (for IPv6 addresses) with the IP address of the alias target.
## DNS resolution within a host
External configuration aside it is up to a host’s networking stack at runtime to resolve DNS records. When configured as dual-stack, most modern operating systems default to** **preferring IPv6. In other words, when a query for a FQDN returns both an A and AAAA record the OS prefers to use the AAAA record and establishes IPv6 connectivity to the target.
**Note**
It is up to an IPv6 enabled host’s operating system and network stack whether it will attempt to map a given FQDN to an IPv4 or IPv6 address. Ensure that IPv6-enabled hosts are able to resolve AAAA records, and that the network between it and its destination is routable to IPv6. A commonly observed misconfiguration in dual-stack setups is hosts resolving FQDNs to IPv6 addresses, but no end-to-end IPv6 routable path existing between source and destination. [Happy Eyeballs ](https://datatracker.ietf.org/doc/html/rfc6555)(Fast Fallback) is an algorithm published by the IETF which can make dual-stack applications (those that understand both IPv4 and IPv6) more responsive to users by attempting to connect using both IPv4 and IPv6 at the same time (preferring IPv6). This avoids the usual problems faced by users with imperfect IPv6 connections or setups.
## Amazon Route 53 DNS records
In AWS, [Amazon Route 53](https://aws.amazon.com/route53/) provides DNS capabilities. Route 53 provides features for two use cases:
+ Public DNS for externally hosted content
+ DNS capability within a VPC both from a resolver and authoritative name server standpoint
## Public IPv6 DNS resolution
For externally queryable DNS, you can use Route 53 public hosted zones, with both A and AAAA records. Route 53 health checks support health checking IPv6 services. The name servers exist both for IPv4 and IPv6, meaning clients wanting to resolve a FQDN hosted on Route 53 public hosted zone can do so natively.
## DNS resolution within a VPC
Amazon VPC comes with Route 53 Resolver, which provides a built-in capability for resolving DNS names. This resolver is reachable either on `169.254.169.253` or `VPC_CIDR_NETWORK + 2` for IPv4 and `fd00:ec2::253` for Nitro-based IPv6 hosts. Requests sent to this resolver are resolved against the combination of private hosted zones associated with the VPC, and any (shared) resolver rules. For more information, refer to [Resolving DNS queries between VPCs and your network](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html).
**Note:** By default, a VPC’s DHCP option set will specify these VPC Route 53 DNS resolvers to DHCP clients. However, if you don’t want to use AWS provided DNS resolvers, you can change the DHCP options to point clients at self-hosted or third-party DNS resolvers.
## Private DNS resolution
Amazon Route 53 can be configured to act as an authoritative name server for one or more zones. You can configure this by creating Private Hosted Zones (PHZs) and associating it with one or more VPCs. Route 53 supports the creation of AAAA records so that it can be used to resolve FQDNs to IPv6 addresses.
For more information, refer to [Working with private hosted zones](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html).
## DNS64 and NAT64
### DNS64
Your IPv6-only workloads running in VPCs can only send and receive IPv6 network packets. Without DNS64, a DNS query for an IPv4-only service will yield an IPv4 destination address in response and your IPv6-only client cannot communicate with it. To bridge this communication gap, you can enable DNS64 for a subnet and it applies to all the AWS resources within that subnet. With DNS64, the Amazon Route 53 Resolver looks up the DNS record for the service you queried for and does one of the following:
+ If the record contains an IPv6 address, it returns the original record and the connection is established without any translation over IPv6.
+ If there is no IPv6 address associated with the destination in the DNS record, the Route 53 Resolver synthesizes one by prepending the well-known /96 prefix, defined in [RFC 6052](https://datatracker.ietf.org/doc/html/rfc6052) (`64:ff9b::/96`), to the IPv4 address in the record. Your IPv6-only client sends network packets to the synthesized IPv6 address. You will then need to route this traffic to the NAT gateway, which performs the necessary translation on the traffic to allow IPv6 clients in your subnet to access IPv4 services outside that subnet.
DNS64 is a subnet-level setting, which you can enable or disable on IPv6-only subnets using the [modify-subnet-attribute](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-nat64-dns64-walkthrough) using the AWS CLI or with the VPC console. DNS64 works in conjunction with NAT64, which comes built into the Amazon VPC NAT Gateway service.
### NAT64
NAT64 enables your IPv6-only clients in Amazon VPCs to communicate with IPv4-only services in the same VPC (in different subnets), or connected VPCs, in your on-premises networks, or the internet. NAT64 is automatically available on your existing NAT gateways or on any new NAT gateways you create. It's not a feature you enable or disable. Once you have enabled DNS64 and your IPv6-only service sends network packets to the synthesized IPv6 address through the NAT gateway, the following happens:
+ From the `64:ff9b::/96` prefix, the NAT gateway recognizes that the original destination is IPv4 and translates the IPv6 packets to IPv4 by replacing:
+ Source IPv6 with its own private IPv4, which is translated to the Elastic IP address by the internet gateway.
+ Destination IPv6 to IPv4 by truncating the `64:ff9b::/96` prefix.
+ The NAT gateway sends the translated IPv4 packets to the destination through the internet gateway, VPC peering, virtual private gateway, or transit gateway, and initiates a connection.
+ The IPv4-only host sends back IPv4 response packets. Once a connection is established, NAT gateway accepts the response IPv4 packets from the external hosts.
+ The response IPv4 packets are destined for NAT gateway, which receives the packets and de-NATs them by replacing its IP (destination IP) with the host’s IPv6 address and prepending back `64:ff9b::/96` to the source IPv4 address. The packet then flows to the host following the local route.
The NAT gateway enables your IPv6-only workloads in an Amazon VPC subnet to communicate with IPv4-only services anywhere outside the subnet.
![\[This is a diagram that shows DNS64 and NAT64.\]](http://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/images/dns64-and-nat64.png)