We all have our own individual identity in this world. It may be a home address or unique ID card number. But have you ever considered how you are perceived online? Generalizing, have you ever considered how complex or large a system should be to accommodate all unique identifiers around the world, considering devices also interact with the internet?
In this post, we discuss the Amazon Relational Database Service (Amazon RDS) capability to support IPv6-based IP addresses and how operationally it is similar or different compared to the traditional IPv4 IP scheme. Amazon RDS now offers instances with support for IPv4, IPv6, or both in your VPCs. Amazon RDS support for IPv6 and IPv4 at the same time makes migrating from IPv4 to IPv6 easy for existing applications.
An Internet Protocol (IP) address gives an internet-attached device an online identity. It also allows devices to communicate with each other over IP-based networks, such as the internet. Whenever a device is connected to the internet, it’s assigned a unique numerical identifier (for example, 22.214.171.124). When two devices want to share information, the data is first converted into packets, which are then transferred to the destination device with the IP addresses of both devices.
Presently, there are two forms for an IP address:
IPv4 – Internet Protocol Version 4 enables devices to communicate with each other. Many devices currently use IPv4 for communication. An IPv4 address is 32 bits in length (for example, 192.168.0.22).
IPv6 – Internet Protocol Version 6 allows more devices to communicate with each other. The IPv6 address size is 128 bits. An example of IPv6 is 2606:4700::6810:787f.
The internet has run on the IPv4 network protocol for over 30 years now. IPv4 is capable of supporting around 4 billion devices directly (232 addresses per 32-bit address space). Although it may seem that there are plenty of IPv4 addresses to go around, the ongoing growth of internet-based technologies, such as mobile applications, connected devices, and the internet of things (IoT), is exhausting them. The number of devices supported by IPv6 expands by an order of magnitude (340,282,366,920,938,463,463,374,607,431,768,211,456 addresses), providing plenty of addresses to keep up with future internet growth.
To reflect this need, AWS started to support IPv6 capabilities, including an IPv6-only subnet in dual-stack VPCs that brings you virtually unlimited scale in your VPCs. Services that have launched IPv6 capabilities include Amazon RDS, Amazon Elastic Container Service (Amazon ECS), AWS Lambda, AWS PrivateLink, Network Load Balancer, Application Load Balancer, Site-to-Site VPN, and AWS Global Accelerator. Additionally, AWS launched BYOIPv6 and the NAT64 Gateway.
Migrating an RDS instance from IPv4 to dual-stack only takes a few clicks on the AWS Management Console. You choose the database to modify and then select the new dual support option for IPv6 and IPv4 in the connectivity settings. If a VPC and DB subnet group that support dual-stack exist, they’re listed and can be selected. If none exist, you’re prompted to enable IPv6 support in at least one DB subnet group and VPC.
Best practices with dual-stack instances
An RDS DB instance operating in dual-stack mode has both IPv4 and IPv6 addresses associated with the database endpoints, as opposed to the default of only IPv4 addresses. To configure the operation mode of RDS instances, the new API field NetworkType has been introduced, which allows you to choose if you want your instance to be IPv4-only or dual-stack.
Databases that have only IPv6 endpoints are currently not supported by Amazon RDS, and dual-stack databases are only supported in private mode—publicly accessible dual-stack DB instances are not supported.
DB subnet group considerations
DB subnet groups are an essential component of Amazon RDS and allow us to choose the network configuration for DB instances. To support dual-stack databases, the VPC and all the subnets in the DB subnet group must have IPv4 and IPv6 CIDRs attached to them. The DB subnet group can’t have IPv6 native subnets or a mix of IPv6-only and dual-stack subnets. You can find the list of supported network types for the DB subnet group while creating, modifying, or describing the DB subnet group:
For DB instances that are running in dual-stack mode, ensure that the DB subnet group always supports the DUAL network type. If the DB subnet group stops supporting the DUAL network type because of subnet deletion or CIDR disassociation, there is a risk of experiencing an incompatible network state for the existing instance, and the DB subnet group can’t be used to launch more dual-stack instances.
Launching new dual-stack instances
To launch a dual-stack instance, you can use the CreateDBInstance API with NetworkType set to DUAL. Amazon RDS only supports IPv4 and DUAL as valid input arguments for the NetworkType parameter; if not provided, Amazon RDS launches an IPv4-only database by default. If the VPC isn’t configured to support launching a dual-stack instance, an appropriate NetworkTypeNotSupported exception is thrown with an explanation of what is wrong with the API call.
The following screenshot shows your network type options on the Amazon RDS console.
For selecting the right instance class and engine version, you can use the DescribeOrderableDBInstanceOptions API to get the supported network types. For example, the following CLI command lists the supported engine versions and instance classes for Amazon RDS for MySQL:
You can similarly check for other DB engines by substituting the value of the –engine option.
After you launch a dual-stack instance, you can resolve the instance endpoint to get its IPv4 and IPv6 addresses:
To connect to the dual-stack instance, make sure that the client and DB instance are configured appropriately to allow communication over IPv6. The VPC security groups, network ACLs, and route tables should be configured properly to allow the client to connect to the database instance. To ensure that database security isn’t compromised, make sure that RDS DB security groups don’t under-expose or over-expose the database endpoint in terms of which clients can connect to the database. Additionally, the client-side OS stack must allow traffic on the IPv6 address, and OS drivers and libraries must be configured correctly to choose the right default endpoint (either IPv4 or IPv6).
Modifying existing IPv4 instances to dual-stack
To modify an existing RDS instance from IPv4-only mode to dual-stack mode, you first need to make sure that the instance’s VPC and subnets are configured with IPv6. Then you can modify the DB instance using the ModifyDBInstance API with the NetworkType parameter set to DUAL. You can apply this modification immediately or during the maintenance window. There could be a downtime for some network type transitions depending on factors like the engine or Multi-AZ configuration.
Modification of the NetworkType setting is not permitted if there is a Multi-AZ to Single-AZ or Single-AZ to Multi-AZ change pending on the instance. This makes sure that after all the pending operations, the database ends up in a stable state.
Note: While running dual-stack instance, if you delete any IPv6 CIDR blocks associated with the subnets of the DB subnet group that is used to launch the instance, then the instance may go in to Incompatible Network state. In the following sections, we detail the instructions to modify an existing IPv4 instance to dual-stack.
Configure the VPC, subnets, and DB subnet group
You first set up the following configurations:
Identify the VPC of the instance’s DB subnet group and attach an IPv6 CIDR to that VPC.
Attach IPv6 CIDR blocks to all the subnets in your DB subnet group, or create a new DB subnet group using IPv6-enabled subnets.
Confirm that the DB subnet group has picked up the change using the DescribeDBSubnetGroups API—the SupportedNetworkTypes parameter should return IPV4, DUAL.
Modify the DB instance
Modify the DB instance using the ModifyDBInstance API by setting the –network-type parameter to DUAL. For example:
If you created a new DB subnet group in the previous step, set –db-subnet-group-name to the new subnet group name. For example:
Validate the modification
Use the DescribeDBInstances API to validate if the NetworkType of the instance is updated. Check the NetworkType parameter in the response of the API call. For example:
Update the security groups associated with the instance to allow IPv6 communication
If the VPC security groups associated with the DB instance have rules based on source IPs, make sure they’re updated to allow IPv6 addresses of the clients.
Identify the IPv6 address of the RDS instance
Resolve the RDS endpoint to find the IP addresses associated with the DB instance:
Use dig <endpoint> AAAA to get the IPv6 address
Use dig <endpoint> ANY to get both IPv4 and IPv6 addresses
Configure the client
Make sure that the client application endpoint has an IPv6 address. IPv4 client endpoints can’t connect to the IPv6 database endpoints. Also confirm that the client is configured to use IPv6 by default. OS-level drivers also need to be updated to support the desired protocol.
Working with dual-stack instances
Read replicas are treated as independent instances and therefore can have different network types from the primary instance. For an instance operating in dual-stack mode, a read replica can be IPv4-only or dual-stack. To create a dual-stack read replica for a DB instance, specify the NetworkType as DUAL (the DB subnet group of the source instance is chosen by default). For example:
Similarly, you can restore a snapshot of a DB instance to a dual-stack instance by specifying the NetworkType as DUAL and choosing a DB subnet group that supports IPv6:
Dual-stack instances are operationally the same as IPv4-based instances, and all other features of Amazon RDS work the same way as regular RDS instances.
In this post, we discussed the Amazon RDS capability to support IPv6-based IP addresses and compared it to the traditional IPv4 IP scheme. In leveraging IPv6 with Amazon RDS, customers now have an increased number of available IP address ranges, which reduces the need to manage overlapping address spaces within their VPCs. We walked through implementing IPv6 dual stack instances for RDS, reviewed best practices, and presented several AWS CLI commands which can be useful in managing dual stack RDS environments.
If you have questions or suggestions on the content covered in this post, leave them in the comments section below.
About the authors
Anshul Punnaivanam is a Cloud Support Engineer with Amazon Web Services. He works with RDS and Aurora customers to help them troubleshoot complex issues, and with general architectural guidance to implement solutions for their use-cases.
Sundar Raghavan is a Database Specialist Solutions Architect Leader at Amazon Web Services (AWS) with a focus on relational databases. With several years of IT experience in financial services, retail, and healthcare, Sundar & his team deliver technical solutions to a broad range of industries. His team works with customers across multiple verticals and supports Oracle, PostgreSQL, and migration from Oracle to PostgreSQL on AWS. Prior to joining AWS, Sundar worked at Oracle, Cloudera/Horton Works as an architect specializing in database and data platforms. Outside of work, he is passionate about books, movies, playing chess and outdoor activities.
Peter Celentano is a Senior Specialist Solutions Architect at AWS, focusing on managed PostgreSQL. He works with AWS customers to design scalable, secure, performant, and robust database architectures on the cloud.
Read MoreAWS Database Blog