apps/www/_blog/2024-01-16-ipv6.mdx
On February 1st 2024, AWS will start charging for IPv4 addresses. This will cost $0.005 per hour - around $4 month.
A more accurate title for this post would be “Brace yourself, IPv4 is leaving”, because I can't imagine many companies will pay to keep using the IPv4 address. While $4 is relatively small for an individual, my hypothesis is that AWS is a foundational layer to many infrastructure companies, like Supabase - we offer a full EC2 instance for every Postgres database, so this would add millions to our AWS bill.
Infrastructure companies on AWS have a few choices:
Let's explore the difficulties of 3.
As a quick primer, an IPv4 looks like this: 93.184.216.34. It is the “address” of a server, similar to a phone number - it tells your computer where to find something on the internet. The problem is there are only ~4.3 billion IPv4 addresses, and we're running out.
An IPv6 looks like this: 2607:f8b0:4006:819::200e. It functions the same as an IPv4, except that there are 340 undecillion of them - that's more than the grains of sand on the planet (by many orders of magnitude). We won't run out any time soon.
IPv6 is clearly a good thing, so what's the challenge? It mostly comes down to:
The biggest challenge to global adoptions is ISP support. Does your Internet Service Provider support IPv6? Probably not.
When you type a website's domain name, it's translated into an IP address. Traditionally, these addresses have been IPv4:
example.com → 93.184.216.34
These domain names will eventually be translated into IPv6:
example.com → 2607:f8b0:4006:819::200e
After your ISP receives this address, it is responsible for routing all traffic to the correct destination. Unfortunately many ISPs simply aren't ready for this - they require newer switches, newer software, and interoperability with IPv4. All of this costs money, and for the past 10 years this investment hasn't been worthwhile.
Here are some of the ways that you will be affected when domains/servers start resolving to IPv6 instead of IPv4, if your ISP doesn't support IPv6:
A lot of developer tools simply aren't set up for IPv6 yet. We can use Supabase as an example - our data team needed to make the following changes to support IPv6 with their toolchain:
These seem small, so to really convey what a PITA this can be, here were the steps for Docker:
1/ Update /etc/docker/daemon.json:
"ipv6": true,
"fixed-cidr-v6": "fd00:ffff::/80",
"ip6tables": true,
"experimental": true
2/ Restart the Docker service:
systemctl restart docker
3/ Create a temporary IPv6 net and test it:
docker network create --ipv6 --subnet fd00:ffff::/80 ip6net
docker run --rm -it --network ip6net busybox ping6 google.com -c3
4/ Check IPv6 iptables config (FORWARD)
ip6tables -L
5/ Add IPv6 network config to the compose config file docker-compose.yaml
# enable IPv6 to default network
networks:
default:
enable_ipv6: true
ipam:
config:
- subnet: fd00:c16a:601e::/80
gateway: fd00:c16a:601e::1
6/ Check if it is working from a container
docker exec -it "airflow_airflow-worker_1" bash
curl -6 https://ifconfig.co/ip
That's … a lot more complicated than it should be for a tool as ubiquitous as Docker.
I suspect that the next few months there is going to be a lot of talk about IPv6.
The fallout from AWS's changes will likely start slow. AWS will simply start charging their customers rather than revoking the IPv4 address. Once that happens, infrastructure companies will notice their bills increasing and start removing IPv4, or providing proxies. Providers might even require some downtime to implement kernel-level changes to support IPv6.
If you want to ensure your company continues to run smoothly, start making as many changes as possible now before the start of February.
If you are a Supabase customer, we have 3 simple solutions: