With the news that AWS will be now charging about $4 / instance-month for public IPv4 addresses, many developers who procrastinated ipv6 migration are finally updating both ends of their development setup.

It’s a great time to migrate, as all the intermediate infrastructure now supports IPV6 readily. Moreover, you’ll benefit from permanent , global addresses for your development instances.

Pros

  • A single, global, stable address for EC2 instances that never changes. No need for dynamic DNS and other hacks
  • No need to pay for Elastic IP addresses on dev instances
  • Global addressing for mutual duplex services (no more NAT needed)
  • Better flexibility and clarity for addressing, including Link Local & local addresses

Cons

  • Time needed to migrate infra to IPV6
  • Clumsier & less-memorable addresses, with unfamiliar idioms (e.g. no more using 127.0.0.1 or 192.168.1.1 – though there are replacements) inherent
  • Bugs in legacy code that assumes 32 bit & string-representations of ipv4 addresses

Concepts & Approach

In theory, IPV6 uses 128bit addresses in place of 32 bit. Most of the intermediate infra (ISP, backbone) is now compatible. The two areas of attention for developers would be the server side with AWS , and the client side with your home/office network.

The two subject areas needing attention for developers are addressing & routing. On the server side this means dealing with addressing on EC2, VPC, VPC subnets & routing tables, and on your home/office network updating your home router config to obtain & allocate IPV6 addresses.

Updating the Client Side

Home routers within the past 5 years support IPV6 in settings, though usually disabled for simplicity. Once enabled the WAN & LAN will receive two addreses.

Be sure to select NATIVE instead of PASSTHROUGH to get complete IPV6 support

Test your config using Test IPV6 . At this point you should have an IPV6 address for your WAN. This will be necessary for routing & security groups on the AWS side

VPC Changes

AWS provides a thorough guide for migrating to IPV6

  1. Update VPC with an IPV6 allocation
  2. Update each subnet with a IPV6 subnet allocation – be sure to resize and order the subnets to the scale needed . Be sure to disable IPV4 auto address allocation, and enable IPV6 address allocation
  3. Update the routing tables to add the V6 ::/0 route
  4. Update your security groups to add your client-side WAN IPV6 IP
  5. Choose an instance to update to IPV6 addressing. this will help you test the e2e VPC routing & addressing config

At this point you should be able to ping & SSH to the test instance using all IPV6 addressing

EC2 Changes

The EC2 change above will work to add IPV6 addresses to instances, but they will still acquire IPV4 addresses until they are re-launched. This means you’ll still be paying for public IPV4 IPs – about $4 additional per instance-month

To release public IPV4 IPs, the instances will need to be re-launched.

Quickly Relaunch EC2 Instances Using AMI

  1. Stop (do not terminate) each instance
  2. Choose Actions → Images & Templates → Create Image
  3. create AMI
  4. Launch new instance with AMI. Test IPV6 address & confirm no IPV4 address was allocated
  5. [optional] If the instance has multiple volumes, detach the volume & re-attach to the new instance with the same device ID
  6. Mark the old instance for termination on a later date

Review IPV4 Address Allocation & Billing

Once the EC2 migration is complete, review IPV4 address usage using VPC IP Address Manager and AWS Billing Cost Explorer (group by API to see EC2 networking costs)

More Resources & Guides