Global IPv4 Depletion: Charges Begin Next Month! Developers Struggle to Migrate, Label IPv6 a “Disaster” with No Direct Usability

IPv6 is a “disaster,” and although we may address the difficulties in the future, our current preparation is still insufficient.

IPv4 Faces the Era of Payment:

In July of last year, Amazon Web Services announced that starting from February 1, 2024, all public IPv4 addresses would be charged at a rate of $0.005 per hour, approximately $4 per month, regardless of whether they are attached to a service;
Container-based deployment platform Fly.io also recently updated its community announcement, stating that it will charge about $2 per month for each dedicated IPv4 after February 1;
Open-source data processing service platform Supabase plans to launch a paid add-on service for IPv4, with a monthly fee of $4.

As time approaches, discussions around “IPv4 charges, migrating to IPv6” are becoming more intense.

Recently, Paul Copplestone, CEO and co-founder of the open-source data processing service platform Supabase, initiated a call to “get ready, IPv6 is coming.” However, due to significant differences between IPv4 and IPv6 message headers, these two protocols cannot interoperate. The road to upgrading to IPv6 also faces multiple challenges. Even though some developers have attempted to use it, the conclusion drawn is that IPv6 is a “disaster.” While we may address the difficulties in the future, our current preparation is still insufficient.

01 Global IPv4 Addresses Nearly Depleted, IPv6 Upgrade Takes Center Stage

As the Internet continues to expand, the rapid increase in the number of devices led to the exhaustion of the last IPv4 address space reserve pool on November 25, 2019, at 15:35 UTC +1, as announced by the Réseaux IP Européens Network Coordination Centre (RIPE NCC), responsible for Internet resource allocation in the United Kingdom, Europe, the Middle East, and parts of Central Asia. The 4.2 billion IPv4 addresses globally have been fully allocated.

After depletion, users seeking to continue using public IPv4 addresses mainly rely on the recycling and release of unused address ranges. These addresses either come from defunct organizations or from those that no longer need them when migrating to IPv6.

Acquiring the increasingly scarce IPv4 addresses has become a complex process, leading to a natural increase in costs. Amazon Web Services (AWS) previously revealed that over the past five years, the acquisition cost for a single public IPv4 address increased by over 300% due to the difficulty in obtaining them.

As mentioned earlier, major companies have had to adopt a charging policy, aiming to encourage efficient usage of public IPv4 addresses while promoting the adoption of IPv6 within the industry.

Paul Copplestone stated, “While AWS charges around $4 per month, which is relatively small for individuals, my assumption is that AWS is the infrastructure layer for many infrastructure companies like Supabase. We provide full EC2 instances for each Postgres database, so this will increase our AWS bill by millions.”

Some analysts argue that for any sizable AWS customer, these fees are negligible and might go unnoticed on their bills. However, for many small and medium-sized enterprises and startups, these fees can easily account for 10–30% of their bills.

02 Three Choices

So, when it comes to dealing with this cost, what options do companies have to minimize expenses?

In this regard, Paul Copplestone shared three choices for infrastructure companies on AWS:

Shift the cost to customers. This is quite understandable, similar to what AWS and Fly.io have done. When it comes to renting or purchasing IPv4 addresses, establish new pricing policies, making customers pay for it. For a single IPv4 address, AWS’s new charge is $43.80 per year (0.05 * 24 hours * 365 days).
Provide alternative solutions (such as proxies). Additionally, businesses can offer IPv4 proxy services to customers, mapping IPv6 traffic to IPv4 traffic through proxies. This approach allows IPv6 devices to access IPv4 resources while reducing the direct demand for IPv4 addresses. Alternatively, optimize the utilization of IPv4 addresses through Network Address Translation (NAT) technology. Share a single IPv4 address while using different ports to distinguish between various services or users.
Only provide IPv6, hoping everyone can keep up with its usage.

03 Challenges in the Adoption of IPv6

From a long-term perspective, the third option, “only providing IPv6,” is the most cost-effective solution that addresses concerns. As a successor to IPv4, IPv6 offers better support for mobile devices, more flexible address allocation, simplified header structures, and improved security.

It’s worth noting that the address space of IPv6 is exceptionally vast, providing approximately 3.4 x 10³⁸ addresses. Some humorously remark, “IPv6 gives every grain of sand a unique address,” highlighting its vast quantity compared to IPv4, thus meeting the growing demands of future internet-connected devices.

The advent of IPv6 is undoubtedly positive. However, according to Google’s statistics, as of January 15, 2024, more than a decade after the introduction of IPv6, the percentage of internet users utilizing IPv6 has not reached fifty percent, standing at 41.23%.

Regarding the reasons behind this, Paul Copplestone attributes it to two factors:

Insufficient support from Internet Service Providers (ISPs).
Lack of tool support.

04 ISP Support Insufficient

“Does your Internet Service Provider support IPv6?”

According to Paul Copplestone, the most significant challenge in global IPv6 adoption lies in the support from Internet Service Providers (ISPs).

In simple terms, when you enter a website’s domain name, it gets translated into an IP address. Traditionally, these addresses were IPv4 addresses:

example.com → 93.184.216.34

These domain names will eventually be translated into IPv6:

example.com → 2607:f8b0:4006:819::200e

Once the ISP receives this address, it is responsible for routing all traffic to the correct destination.

Unfortunately, many ISPs are not adequately prepared for this transition. They require updated switches, updated software, and interoperability with IPv4 — all of which incur costs that, in the past decade, have not seemed justified.

If your Internet service provider does not support IPv6, you may experience the following impacts and errors when domain names/servers start resolving to IPv6 instead of IPv4:

If you have set up a web server in AWS, you won’t be able to connect to it via SSH.
If you are connecting directly from a local computer to a Supabase database, you need to use a connection pool, which will resolve to IPv4 (the provider will pay for these IPv4 addresses).
If you are connecting from Vercel to any AWS servers and don’t set an IPv4 address for the server, the connection will fail quickly.

05 Lack of Tool Support

Additionally, many developer tools have not yet been configured for IPv6. Paul Copplestone uses his open-source Firebase alternative, Supabase, as an example. He explains that for their data team to make their toolchain IPv6-compatible, they need to make the following changes:

Add IPv6 support to the VPC network.
Add IPv6 support to the Airflow VM.
Add IPv6 support to Docker and Compose.

While these steps may seem straightforward, implementing them is actually quite challenging. Here are the steps to configure 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 network and perform testing:

docker network create --ipv6 --subnet fd00:ffff::/80 ip6net
docker run --rm -it --network ip6net busybox ping6 google.com -c3

4. Check IPv6 iptables configuration (FORWARD):

ip6tables -L

5. Add IPv6 network configuration to the Docker Compose file:

# 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’s running inside the container:

docker exec -it "airflow_airflow-worker_1" bash
curl -6 https://ifconfig.co/ip

For ubiquitous tools like Docker, these configurations are undeniably complex.

06 Moving to IPv6, Numerous Challenges

While talking about the actual process of attempting IPv6 migration, DevOps engineer Mathew Duggan admits that the difficulties encountered in moving to IPv6 were daunting: “There’s almost nothing that works out of the box. Major dependencies immediately stop functioning, and workarounds are insufficient for production needs. The team’s journey into IPv6 migration has been quite rough, primarily because very few have undertaken this work. We haven’t done this work in years, and now we’re paying the price.”

Mathew Duggan attempted to migrate his blog (https://matduggan.com/ipv6-is-a-disaster-and-its-our-fault/) to IPv6 using CDN to manage IPv4 traffic.

He states, “The actual setup was straightforward. I configured a Debian device and selected ‘IPv6.’ Then, I got the first ‘surprise.’ The device didn’t get an IPv6 address but received a /64 address, which is 18,446,744,073,709,551,616. The good news is that my small ARM server can run all the network infrastructure of every company I’ve worked for on all public addresses.”

However, when he tried to set it up like a regular server, problems arose.

Issue 1: Unable to SSH (Secure Shell Protocol) Login

“This was a foreseeable problem,” says Mathew Duggan, as his work or home ISP does not support IPv6, requiring him to set up his server, which now doesn’t work at all.

So, Mathew Duggan had to attach an IPv4 address first, log in via SSH, and then set up Cloudflared to run the tunnel.

To his disappointment, the Cloudflare system doesn’t handle the conversion itself. So, when he removed the IPv4 address, the tunnel unexpectedly crashed.

By default, the Cloudflared tool uses IPv4, and the systemd service file needs to be edited to add: — edge-ip-version 6. This way, the tunnel can start normally, and Mathew Duggan can log in via SSH.

Issue 2: Unable to Use GitHub

When Mathew Duggan’s server started running, he tried to run a server setup script, but it immediately resulted in an error. It was attempting to access the installation script for hishtory, which is a great shell history tool. It was trying to fetch the installation file from GitHub but failed.

Mathew Duggan was puzzled, “This can’t be right. GitHub surely supports IPv6?”

Unexpectedly, he found out that GitHub, the widely used software release service, does not support IPv6.

In the end, Mathew Duggan used the TransIP Github proxy server, and it worked well. But then Python encountered urllib.error.URLError: .

“Well, I give up. I guess the Python 3 version in Debian doesn’t like IPv6, but I don’t feel like troubleshooting it now,” says Mathew Duggan.

Issue 3: Unable to Set Up Datadog

Next, Mathew Duggan wanted to set up Datadog to monitor the server.

The bug reappeared, and when he accessed Datadog, logged in, and started working, the system crashed immediately. He simply set up by running curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh, and now that S3 supports IPv6, where could the problem be?

After troubleshooting, Mathew Duggan found that the problem was not with S3 or the server because he could use the S3 connection test provided by AWS without any issues. Later, he manually fixed the issue through apt.

By this point, Mathew Duggan realized that there was no future in pure IPv6 usage. Almost nothing works properly without proxies and technical patches.

Later, to access IPv4 resources from IPv6, he opted for the NAT64 service (https://nat64.net/) as support.

Additionally, he searched for many tools and found that most of them are no longer functional. Links in the Dresel list below do not work; Trex encountered problems during testing; August Internet disappeared entirely; most Go5lab test devices are offline; Tuxis works but seems not to have been upgraded since its launch in 2019. Only Kasper Dupont’s support remains functional.

07 IPv6 Adoption: A Long and Challenging Road Ahead

While the time has come for the transition to IPv6, most infrastructure and software are still unprepared for this change.

Training and preparation for IPv6 will be a significant challenge for digital professionals.

Many developers share the sentiment, and users from HN have expressed their frustration:

“I’m still cursing the designers of IPv6 for not making it backward-compatible with IPv4. The design of IPv6 is undoubtedly superior, but due to the lack of backward compatibility, transitioning to IPv6 is an absolute challenge. I know the designers thought the transition would only take a few years, but it’s been almost 30 years… and here we are.”
IPv6 does not truly solve the problem of address exhaustion unless IPv6 addresses become first-class citizens. This will only happen when we no longer need to rely on IPv4 addresses.

Without migrating to IPv6 and sticking with IPv4, it may not meet the growing demands, leading to performance degradation and unstable services. Many organizations adopt NAT technology to share limited IPv4 addresses, adding complexity to network management and potentially restricting the functionality of some applications or services.

In light of these challenges, an increasing number of organizations are joining the wave of implementing IPv6 migration.

Reference Links:

Stackademic

Thank you for reading until the end. Before you go:

Please consider clapping and following the writer! 👏
Follow us X | LinkedIn | YouTube | Discord
Visit our other platforms: In Plain English | CoFeed | Venture