Networking & Content Delivery

Bring Your IPv6 Address Space to Amazon VPC IP Address Manager (IPAM)

Introduction

Every device, resource, and workload connected to an Internet Protocol-based network depends on its IP address to communicate. The public and private IPv4 addressing space exhaustion, organizational mandates, and the need to provide service availability to IPv6-only clients drive an increasing number of organizations to adopt IPv6 in their environments. A well-managed IP address space allows for optimal address allocations to Amazon Virtual Private Cloud (Amazon VPC) resources and easier routing and security posture management.

Bring Your Own IP (BYOIP) allows you to bring your own IPv4 or IPv6 address space to AWS for use with your AWS resources, while continuing to own the IP range. BYOIPv4 and BYOIPv6 work, however, in different ways. BYOIPv4 allows you to assign your IPv4 addresses as the “external” IPs for otherwise private VPC resources such as EC2 instances, elastic load balancers, etc., They are Elastic IP addresses, with 1:1 Network Address Translation (NAT) via the use of the Internet Gateway attached to the VPC. With BYOIPv6, on the other hand, the addresses you bring are used as the “native” or internal addresses inside your VPC, with the optional ability to use them to connect to the public Internet. While these IPv6 addresses are publicly routable, that does not mean that using them automatically connects your VPC resources to the Internet. Instead, you have complete control and a number of options for when and how your VPC resources can reach the Internet or be reached by systems on the Internet. AWS-supplied VPC IPv6 addresses are globally unique and routable in the Internet from AWS. With BYOIPv6, you can decide if the CIDRs are advertised to the Internet by AWS or not. Based on this setting, you are able to configure the optional Internet connectivity for your VPC from AWS or your on-premises infrastructure.

Integrating Amazon VPC IP Address Manager (IPAM) with your BYOIPv6 strategy allows you to manage and optimize IPv6 CIDR allocations in your AWS environment. In addition, you can benefit from the robust automation and management of IP address related workflows that Amazon VPC IPAM provides. This blog post focuses on the mechanisms and best practices for managing BYOIPv6 pools with IPAM.

We assume you previously went through the authorization process for your IPv6 addresses, as described in the BYOIP documentation (up to step 4. Provision the address range in AWS, since we will be using IPAM for this) and detailed in this blog post, to prepare your CIDR(s) for configuration. More details about the steps to create your IPAM instance are detailed in the documentation. Before we proceed to the BYOIPv6 with IPAM specific configuration, let’s first have a brief overview of how IPv6 is enabled at the VPC level in the BYOIPv6 context.

BYOIPv6 and the dual stack Amazon VPC

For both existing and new VPCs, to enable IPv6, you simply need to associate one /56 IPv6 CIDR block, either by editing the VPC CIDRs or at VPC creation time. The BYOIPv6 addresses work in the same way as AWS-supplied IPv6 addresses. For example, you can associate these IPv6 addresses to subnets, Elastic Network Interfaces (ENI) and EC2 instances within your VPC. Additionally, you can use your BYOIPv6 for private connectivity to your on-premises networks by advertising them over Direct Connect or VPN.

Fig.1: Dual-stack Amazon VPC

Address management best practices

To simplify network management and operations with BYOIP support in IPAM, consider these following points:

  • The size of the IPv6 block you bring to an Amazon VPC IPAM pool: When designing your regional IPv6 addressing scheme, note that an IPv6 pool that is marked as advertisable from AWS must contain CIDR blocks that are /48 or larger. You can configure IPv6 blocks smaller that /48, down to a /56, by marking them as non-advertisable from AWS.
  • A multi-level hierarchical IPAM design strategy: By assigning contiguous IPv6 addresses to regions, environments and additional hierarchy levels you define, you can better manage the VPC, Transit Gateway, VPN and Direct Connect routing tables.
  • The central management of IPv6 CIDRs: The central management of the BYOIPv6 pools simplifies the control over both VPC addressing and VPC internet connectivity

BYOIP address range preparation – Why does AWS need the ROA and the CIDR authorization?

With BYOIP, your security is top priority. Let’s first review the general process to configure BYOIP and then have a look at the security checks we perform and why. For the detailed steps, please refer to the BYOIP documentation.

The process to configure BYOIP in AWS has three steps:

  • Preparation: For authentication purposes, create an RSA key pair and use it to generate a self-signed X.509 certificate.
  • Regional Internet Registry (RIR) configuration: Upload a Route Origin Authorization (ROA) that defines the desired address range, the autonomous system numbers (ASNs) allowed to advertise the address range, and an expiration date. Upload the self-signed certificate to your RDAP record comments.
  • Amazon configuration: Sign a CIDR authorization context message with the private RSA key that you created, and use that message and signature when you provision the CIDR to AWS (either directly or within Amazon VPC IPAM).

To guarantee that you and only you can bring your IP address space, we perform two security checks, depending on the type of prefix you bring to AWS:

  1. For publicly advertisable prefixes, you must provide Amazon with the authorization to advertise to the Internet the IP address range you’re bringing to AWS – which is the correct ROA configuration
  2. For both publicly and non-publicly advertisable prefixes, you must provide authentication that the account you’re bringing that range to is actually an account owned by you – which is the CIDR authorization context message.

For the first security check, to give us the authorization to advertise your IP address range to the Internet, we ask you to create a Route Origin Authorization (ROA) for AWS ASNs (16509 and 14618 for commercial regions, and ASN 8987 for the AWS GovCloud (US)), and update the RDAP (Registration Data Access Protocol) record in your RIR (Regional Internet Registry) with a self-signed public certificate.

You can create a ROA through your Regional internet Registry (RIR). A ROA tells the world what are the ASNs allowed to advertise your IP address range. Your RIR, such as ARIN, RIPE, or APNIC, makes your ROA publicly available to everyone. You can think of it as declaring your intention to use your IP address range on AWS. After authenticating with your RIR, you can create a ROA for your IP addresses.

For the second security check, when you provision an address range for use with AWS, you also need to confirm you own the AWS account that you are bringing it to. We verify that you own the address range through a signed authorization message. This message is signed with the self-signed X.509 key pair that you used to update the RDAP record. AWS requires a cryptographically signed authorization message, which is in turn verified against the certificate held by the RIR, in the RDAP record comments.

When you bring an IPv6 CIDR in to an Amazon VPC IPAM pool that is configured as publicly advertisable, you need both the ROA and the CIDR authorization context. When you bring an IPv6 CIDR in to an Amazon VPC IPAM pool that is configured as not publicly advertisable from AWS, the ROA is not needed. But, the CIDR authorization context is still needed to verify that the account configuring the CIDR with BYOIP is authorized to do so.

New advertisable BYOIPv6 prefix with Amazon VPC IPAM

For the purpose of demonstrating the integration between BYOIPv6 and Amazon VPC IPAM, let’s explore the following IP addressing scheme, detailed in Fig.2 below, and a new advertisable IPv6 prefix, 2605:9cc0:1ff0::/44.

Note: The prefix used for this blog post is an AWS-owned and authorized IPv6 CIDR, for the blog post purpose.

Fig.2 – BYOIPv6 IPAM blog design

The addressing scheme is based on a simple hierarchical approach, with a top level /44 CIDR block. The Internet connectivity model uses the AWS publicly advertised CIDR blocks, so each pool in each region is assigned a /48 prefix, and marked as publicly advertisable. This will enable each VPC that receives IPv6 CIDRs from these pools to use its own Internet Gateway and the Egress-only Internet Gateway for Internet access. Once pools are shared with the application accounts, the application account owners can create VPCs using /56 CIDR blocks from the shared pools.

The following section describes the detailed steps for configuring a new BYOIPv6 CIDR block in IPAM, using it in a multi-region environment and sharing it with other accounts in your organization:

  1. Create the top-level IPAM pool with the new BYOIPv6 prefix and mark it as publicly advertisable
  2. Create the regional IPAM pools, provision the IPv6 CIDRs within each pool in the respective region and advertise them to the Internet
  3. Share the IPAM pools with the respective AWS application accounts
  4. (Application account owner) Create an Amazon VPC with a /56 CIDR block from the shared pool

Step 1: Create the top-level IPAM pool with the BYOIPv6 prefix

With BYOIPv6, IPAM will use the ownership validation check already defined by BYOIP to onboard the public IPv6 addresses. For the purpose of this blog post, we’re using the default public IPAM scope to provision the publicly advertisable BYOIPv6 pool and CIDR block. First, we need to create the IPAM top level IPv6 pool, either in the AWS Console, or using the AWS CLI (Command Line Interface):

aws ec2 create-ipam-pool --ipam-scope-id ipam-scope-0c18cf41027a7747b --address-family ipv6 --publicly-advertisable --region=us-east-1
{
    "IpamPool": {
        "OwnerId": "<account-id>",
        "IpamPoolId": "ipam-pool-08c6fe6fbd7bb7105",
        "IpamPoolArn": "arn:aws:ec2::<account-id>:ipam-pool/ipam-pool-08c6fe6fbd7bb7105",
        "IpamScopeArn": "arn:aws:ec2::<account-id>:ipam-scope/ipam-scope-0c18cf41027a7747b",
        "IpamScopeType": "public",
        "IpamArn": "arn:aws:ec2::<account-id>:ipam/ipam-093e6b9cbea89b688",
        "IpamRegion": "us-east-1",
        "Locale": "None",
        "PoolDepth": 1,
        "State": "create-in-progress",
        "AutoImport": false,
        "PubliclyAdvertisable": true,
        "AddressFamily": "ipv6",
        "Tags": []
    }
}

Once the top-level pool is created, we can provision the BYOIPv6 CIDR, using the IPAM API:

aws ec2 provision-ipam-pool-cidr --ipam-pool-id ipam-pool-03d5f616b5747ea84 --cidr 2605:9cc0:1ff0::/44 --cidr-authorization-context 'Message=*******, Signature=*******' --region=us-east-1
{
    "IpamPoolCidr": {
        "CidrBlock": "2605:9cc0:1ff0::/44",
        "State": "pending-provision"
    }
}

To verify that the CIDR is provisioned, you can use the CLI:

aws ec2 get-ipam-pool-cidrs --ipam-pool-id ipam-pool-08c6fe6fbd7bb7105 --region=us-east-1
{
    "IpamPoolCidrs": [
        {
            "Cidr": "2605:9cc0:1ff0::/44",
            "State": "provisioned"
        }
    ]
}

Or the AWS Console:

Fig. 3 – AWS Console IPAM Pool CIDR state

Step 2: Create the regional IPAM pools, provision the the IPv6 CIDRs within each pool in the respective region and advertise them to the Internet

The IPAM control plane is associated with the region you created your IPAM instance in, so in order to manage IP space across multiple regions, you need to create IPAM pools associated with each region.

For the us-east-1 pool we will configure:

  • Name: US-EAST-1-POOL
  • Source Pool: the top-level BYOIPv6 pool ID
  • Locale: us-east-1
  • Service: EC2/VPC
  • CIDR to provision: 2605:9cc0:1ff0::/48
  • Allocation settings:
    • Minimum, Default and Maximum allocation netmask length: /56
  • Tag requirements:
    • Key: Region, Value: us-east-1

Let’s have a look at how we can configure these settings in the AWS Console. We first need to name the pool and add an optional description, and specify the top level pool based on the pool hierarchy:

Fig. 4 – Create IPAM pool settings

Locale is set to us-east-1 as the pool will be used for VPC CIDR allocations in that region. Since IPv6 addresses will be directly allocated to VPC resources from this pool, the Service-type is EC2/VPC. If the service type EC2/VPC is selected, you cannot use this pool as a source pool.

Fig. 5 – Create IPAM pool settings – continued

According to our IPAM design, the first /48 in the BYOIPv6 CIDR is allocated to the us-east-1 pool:

Fig. 6 – IPAM pool CIDR provisioning

For setting the allocation rules, we need to configure this pool to be used for VPC CIDR allocations:

Fig. 7 – Use IPAM pool for VPC CIDR allocation

As a best practice, we will be automatically importing discovered resources to IPAM:

Fig. 8 – Allow IPAM to import of VPC CIDR allocations

Amazon VPC IPAM facilitates tracking VPC addressing compliance across your environments, through Netmask, Tag and Locale settings. Since the Amazon VPC currently supports /56 IPv6 CIDR blocks, we will reflect that in the Netmask compliance configuration:

Fig. 9 – IPAM pool compliance settings

For Tag compliance, all VPCs that will be created using CIDR blocks from this pool must be tagged accordingly with the “Region” pre-defined key and value. If our initial hierarchy would entail more levels (environment, business unit), we would be able to reflect that in the tag requirements for the VPCs, by adding tags like “Environment”, “BU (Business Unit)”, etc.

Fig. 10 – IPAM pool compliance settings – continued

The Locale is set automatically through the pool locale:

Fig. 11 – IPAM pool locale settings

After creation, you can verify the US-EAST-1-POOL status and the CIDR provisioning state, which must be “Provisioned”:

Fig. 12 – IPAM configuration review

If the top level pool is marked as --publicly-advertisable, then the the sub-pools in the hierarchy are also publicly advertisable.

For the CIDR blocks provisioned in --publicly-advertisable pools, you can control their Internet announcement status individually, by starting or stopping it using the CLI. By default, the CIDRs are not announced to the Internet from AWS when provisioned, which means they are not publicly accessible over the Internet. Therefore, we need to announce the CIDR in the US-EAST-1-POOL to the Internet. When you run the command below, note that the value for --region matches the --locale option of the pool.

aws ec2 advertise-byoip-cidr --region us-east-1 --cidr 2605:9cc0:1ff0::/48
{
    "ByoipCidr": {                                                                 
        "Cidr": "2605:9cc0:1ff0::/48",                                              
        "State": "advertised"                                                      
    }                                                                              
} 

Next, we must create the pools for the other regions with the following settings (service-type and allocation settings will be the same as for the US-EAST-1-POOL):

Verify in the console that your pools are configured accordingly:

Fig. 13 – IPAM configuration review – continued

If you scroll to the right in the console you’ll be able to also see additional information regarding the pools, such as Locale, Size, percentage of Allocated, Available and Assigned prefixes, etc.

Fig. 14 – IPAM configuration review – continued

You must also configure the announcement to the Internet from AWS for each of the CIDRs in each pool above.

Step 3: Share the IPAM pools with the respective AWS application accounts

IPAM has native support for AWS Organizations, so you can share the IPAM instance with your entire organization or with specific accounts, at a pool level, based on the needs and restrictions you want to enforce. For the purpose of this blog post, we’ll be configuring specific sharing policies for each pool, to keep accounts separately allocated. To configure this, we need to create a Resource Access Manager (RAM) resource share for each pool, by specifying the application account IDs.

Start by creating a resource share in Resource Access Manager (RAM):

Fig. 15 – IPAM pool RAM resource share details

The resource share type is “IPAM Pools” and you must select the IPAM Pools you want to share. We will be sharing our us-east-1 pool with an account in the AWS Organizations:

Fig. 16 – RAM resource share – IPAM pool selection

The default permissions for the IPAM pool are described under the AWSRAMDefaultPermissionsIpamPool policy:

Fig. 17 – IPAM pool RAM resource share – permissions

Since we are sharing the pool with an account in our AWS Organization, we need to specify the Account ID:

Fig. 18 – IPAM pool RAM resource share – Accounts

Step 4: Create an Amazon VPC with a /56 CIDR block from the shared pool

Once you shared the IPAM pools with the accounts in your organization, the application developers, or VPC owners, can use them to allocate /56 CIDR blocks to VPCs. You can use Amazon VPC IPAM to manage both IPv4 and IPv6 VPC CIDRs, so this will be reflected in our VPC configuration below.

For this purpose, we’re using IPAM to manage the VPC IPv4 CIDR allocations too, alongside the IPv6 ones, and we have already created regional pools for the IPv4 hierarchy. To create a VPC in us-east-1, we will first to select the IPv4 CIDR for the VPC, from the respective regional IPAM pool:

Fig. 19 – VPC creation with IPAM pools – IPv4

Then, we allocate the IPv6 CIDR from the regional IPAM pool that we created above, as part of the walkthrough, and set the correct Tag value as configured in the allocation policy for compliance:

Fig. 20 – VPC creation with IPAM pools – IPv6 and Tag setting for compliance

The same configuration steps apply for VPCs in the other regions where we’ve created IPAM pools and had them shared with application accounts. As a final step, you can verify your pool allocation status. For example, for the us-east-1-pool:

Fig. 21 – IPAM pool allocation check

Advantages of using BYOIPv6 with Amazon VPC IPAM

Let’s review the advantages of using BYOIPv6 space for addressing your VPCs with Amazon VPC IPAM, in a multi-account environment, and the benefits that come with using contiguous IPv6 CIDR ranges:

  1. Optimized BYOIPv6 allocation mechanisms – Managing your BYOIPv6 pools and CIDRs through IPAM allows you to optimize the IPv6 allocation space. You can use the built-in sharing capabilities to manage the IPv6 space across multiple accounts within your organization, and therefore avoid fragmentation of the IPv6 space.
  2. Enhanced cross-account sharing capabilities – You can use IPAM enhanced cross-account sharing capabilities to overcome these limitations with maintaining separate IPv6 addresses allocation for each AWS account. Once enabled, you can share your IPAM instance within your organization so that other accounts can benefit from the IPAM capabilities for assigning IPv6 addresses, while you manage CIDR blocks centrally. By providing the IPAM service with permissions to monitor IP usage across all your accounts, you can enable organization-wide monitoring of your whole IP space, ensuring consistency across the AWS environment
  3. Simplified management of your existing BYOIPv6 pools – With IPAM, you can easily manage your existing BYOIPv6 pools, without any downtime or resource re-configuration.
  4. Optimized management of routing and security domains – With Amazon VPC IPAM you can organize your BYOIPv6 space consistently with the enterprise defined hierarchy (region, routing domain, business unit, etc.). By allocating CIDR blocks from your BYOIPv6 space to each region, environment and business unit, you can optimize route table management, and configure summarization across the network.

Summary

Some considerations regarding BYOIPv6 in IPAM you need to be aware of:

  • You can configure a BYOIPv6 pool as advertisable or not. This is specified by using --publicly-advertisable flag. (For more information, check out this IPAM tutorial on how to configure this flag)
  • When you bring a CIDR in a pool that is publicly advertisable from AWS, you also need to provide route origin authorization (ROA) to authorize AWS to advertise in in the Internet.
  • When you bring an IPv6 CIDR in a pool that is not publicly advertisable from AWS, then ROA is not needed. But, the ‘cidr-authorization-context’ is still needed to verify that the account configuring the CIDR with BYOIP is authorized to do so.
  • 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, and consider route summarization at the VPC route table level, as well as when using AWS connectivity options such as Transit Gateway, Direct Connect and VPN.
  • You can move IPv6 addresses from pools with --publicly-advertisable=true in chunks of /48 or larger, as they need to be advertisable. As long as IPv6 CIDRs are /56 or larger, you can move them between pools with publicly-advertisable=false without restrictions.
  • A BYOIPv6 pool has a single CIDR, whereas an IPAM pool can have multiple CIDRs. Further, you can attach an allocation policy to an IPAM pool, which allows you to control IP addresses allocated by IPAM. You can also attach a refill policy to an IPAM pool, allowing IPAM to automatically refill a pool from another pool.

Conclusion

With IPAM, you easily organize your BYOIPv6 address pools, based on your routing and security needs and business rules to govern IPv6 CIDR block assignments, across the entire organization. Using IPAM for BYOIPv6, you can centrally manage your BYOIPv6 CIDRs and enforce compliance and tagging for each VPC in each AWS account in your Organization. IPAM makes it easy for you to centrally configure the BYOIPv6 CIDRs and define the IP allocation design that best suits your organization’s needs and growth strategy. If you have questions about this post, start a new thread on the Amazon Networking and Content Delivery Forum or contact AWS Support.

Alexandra Huides

Alexandra Huides is a Senior Networking Specialist Solutions Architect within Strategic Accounts at Amazon Web Services. She focuses on helping customers with building and developing networking architectures for highly scalable and resilient AWS environments. Outside work, she likes traveling, discovering new cultures and experiences, hiking, and reading.