Originally on tonym.us
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
- Update VPC with an IPV6 allocation
- 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
- Update the routing tables to add the V6
::/0route - Update your security groups to add your client-side WAN IPV6 IP
- 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
- Stop (do not terminate) each instance
- Choose
Actions → Images & Templates → Create Image - create AMI
- Launch new instance with AMI. Test IPV6 address & confirm no IPV4 address was allocated
- [optional] If the instance has multiple volumes, detach the volume & re-attach to the new instance with the same device ID
- 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)
Top comments (0)