Turning 6 (IPv6, that is)

Cloud Hobbyist is now IPv6-only. For now(?). Here's how I did it...

AI generated image. Multiple roads leading to the number 6 set in the middle of an orange disk itself in the middle of a blu

Ok, so first things first... It's been a hot minute since I've posted anything. But I'm actually sort of proud of this one even though as you'll see below, it wasn't actually that hard to pull off.

I moved this blog from IPv4 to IPv6 via a short lived stint as a dual-stack!! This blog has turned 6!

Why, though?

Back in February 2024 (with notice, of course), AWS started charging for IPv4 addresses. I guess the address exhaustion is really real, who would've thought? As I've briefly mentioned before, I try to run my hobbyist cloud infrastructure on as much of a shoestring budget as I can get away with...

... I never did write that blog post on my weird and overly complicated text message service to alert me and my friends when certain NCAA basketball games were starting, or the completely unnecessary and weirdly architected (if I dare claim that much forethought) MyCokeRewards code database, storage, and retrieval web app I made... but those came about almost entirely because I didn't want to pay for a server to be running all the time. And that was before I was charged for an IP (v4) address too!

But I digress. I don't want to pay for services I'm not feeling like I'm using or deriving value from, so when I saw new VPC charges hitting my invoice every month for public IPv4 addresses, it bugged me and I had to fix it. So me being me, I took a couple months to get sufficiently annoyed and over the course of a couple weekends I got it taken care of.

Dual-Stack First

Before cutting over to IPv6, I first wanted to, you know, make sure it worked at all for me and my friends (the primary audience of this blog, frankly). I know my friends have the same ISP I do and we have both IPv4 and IPv6 capabilities (dual stack, if you will). So knowing my clients could reach the blog on either, I had to test it.

(Sorry for few screenshots here, but it's a simple click around exercise, promise.)

First things first, in AWS you can go into the VPC Dashboard, select your VPC, and in the "Actions" menu, select "Edit CIDRs." I wonder if you get IPv6 CIDRs by default now on a new VPC, but mine are old and only had the default private IPv4 CIDR range 172.31.0.0/16. But there's a big button here to add an IPv6 CIDR range (and additional v4 ranges is you're feeling like it). Go ahead and click that and select the Amazon-provided option (unless the other options apply, of course).

A dialog box from the AWS Console titled Add IPv6 CIDR with the "Amazon-provided IPv6 CIDR block option selected.

And there you go, you've turned on IPv6 for your VPC. Next step here is to get it into each of the subnets you want to put it into. That's more or less the same process. You go into your Subnet page within the VPC Dashboard, and for each subnet you select "Edit IPv6 CIDRs" from the Actions menu. It's tedious. What I did was broke out my /56 into /64s for each subnet, no real reason why; I just did.

Once you've done that you need to go update your route tables. Still in the VPC Dashboard, go into the Route tables page and select your route table. From the Actions menu select Edit Routes and add routes for your VPC's IPv6 CIDR block routed to local (this should be automatically there) and another for the ::/0 route (all IPv6 addresses) to the internet gateway (this is a public subnet). This last rule lets your EC2 instances reach and accessible to the Internetv6.

An aside, read the docs for your options here since there's security implications on public/private subnets: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html#vpc-migrate-ipv6-routes

Next you go into your security groups (again from the VPC Dashboard) and make relevant updates to your security group inbound rules (and outbound rules too if you're fancy, but default "allow" rules are added automatically). The "how" on this is exactly the same as from the EC2 Dashboard so just do what you normally do for security groups but with v6 addresses.

All that and we still don't have v6 addresses on our EC2 instances (yikes!), but the hard part is over! I mean, it's still tedious if you have a lot of EC2 instances. Go to your EC2 Dashboard and for each instance click into the Actions > Networking >Manage IP addresses menu (see below).

Menu tree in the EC2 Dashboard showing Actions > Networking > Manage IP addresses.

Once into the instance's IP address management page, you should see an option to assign a new IPv6 address. Click that and let AWS auto-assign it. And there you go! All set! (I mean, save the page of course).

Optionally go to your DNS provider and add AAAA record(s) and give DNS time to do its thing and congrats! You're dual-stacked!

Personally I sat in dual-stack mode for like a week or two just because.

Turning off v4, v6 only!

Ok so you'll have to bear with brevity here since there's tediousness again. The only way I've found to do this is per-instance (ok there's obviously CLI ways but I'm a console guy for the most part) for existing instances and on new instances you can make the same setting change. I believe VPC (or subnet) settings can dictate a default behavior for new instances but I'm cheap (see above) so I'm not spinning up new instances all that often.

Also the only way I saw how to disassociate an IPv4 address from an instance is when it's in the stopped state; so go ahead and do that for each instance you want to go v6-only. Go back into that Manage IP addresses menu, and turn off the "Auto-assign public IP" toggle. Start your instances and you've successfully gone v6 only! (publicly anyway).

The Auto-assign public IP toggle in the off position.

So you're v6 to the world now, congrats! Hope you don't have v4-only clients or other services you need to get to. Sure there's DNS64 and NAT64, but that's for another day, project, weekend. And for v4-only clients you could easily set up Cloudflare or AWS Cloudfront ($) to proxy/CDN your stuff, but that's up to you!

But you still have IPv4

Ok true! But not public ones, not ones AWS will charge me for. So I'm calling this project done.

There are ways to turn off IPv4 for the entire VPC if you want to (or per-subnet). Just go through the same menus and mess with the relevant options, but my focus was on minimizing my hobbyist IT spend and by turning off public IPv4 I've accomplished that. Later gators!