Why IPv4 Is Running Out and How Companies Can Navigate the Costly IPv6 Migration

IPv4 (Internet Protocol version 4) is one of the most widely used network‑layer protocols, defined in RFC 791 in 1981 with a 32‑bit address space, providing about 4.3 billion unique addresses.

Because the address space is limited, the pool has been exhausted: in 2011 the Internet Assigned Numbers Authority (IANA) announced that the last free IPv4 block was allocated, and since then many providers have begun charging for public IPv4 addresses.

Amazon Web Services (AWS) announced that from 1 February 2024 all public IPv4 addresses will cost $0.005 per hour (≈ $4 per month) regardless of usage.

Fly.io will charge about $2 per month for each dedicated IPv4 address.

Supabase plans a $4‑per‑month add‑on for IPv4 usage.

These charges have sparked intense discussion about the transition to IPv6. Supabase CEO Paul Copplestone warned that “prepare, IPv6 is coming.”

IPv4 Exhaustion Makes IPv6 Upgrade Critical

The RIPE NCC reported that the final IPv4 address block was depleted on 25 November 2019, after 42 billion IPv4 addresses had been allocated worldwide. With the pool exhausted, organizations rely on reclamation, market purchases, or costly allocations, driving up expenses dramatically.

Companies now face three strategic options to mitigate costs:

Pass the cost to customers : Adopt pricing models similar to AWS or Fly.io, charging for IPv4 usage (e.g., $43.80 per IPv4 address per year).

Provide alternative solutions : Offer IPv4‑to‑IPv6 proxy services, NAT sharing, or other mechanisms that reduce direct IPv4 demand.

Offer IPv6 only : Encourage or require customers to adopt IPv6, leveraging its larger address space and simplified header.

Challenges Facing IPv6 Adoption

Despite its advantages—vast address space (~3.4 × 10³⁸ addresses), better support for mobile devices, simplified headers, and higher security—IPv6 adoption is hindered by two major factors:

Insufficient ISP support : Many ISPs lack the necessary hardware, software, and routing updates to handle IPv6 traffic, leading to connectivity failures such as inability to SSH into AWS instances or connect to Supabase databases.

Lack of tooling support : Development tools and platforms often do not have IPv6‑ready configurations. For example, enabling IPv6 in Docker requires multiple configuration steps.

Example DNS resolution difference:

<code>example.com → 93.184.216.34   // IPv4
example.com → 2607:f8b0:4006:819::200e   // IPv6</code>

Enabling IPv6 in Docker

To add IPv6 support to Docker, the following steps are typical:

<code>"ipv6": true,
"fixed-cidr-v6": "fd00:ffff::/80",
"ip6tables": true,
"experimental": true</code>

Restart Docker:

<code>systemctl restart docker</code>

Create and test an IPv6 network:

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

Check IPv6 iptables:

<code>ip6tables -L</code>

Update Docker Compose to enable IPv6:

<code># enable IPv6 to default network
networks:
  default:
    enable_ipv6: true
    ipam:
      config:
        - subnet: fd00:c16a:601e::/80
          gateway: fd00:c16a:601e::1</code>

Real‑World Migration Pain Points

DevOps engineer Mathew Duggan described IPv6 migration as “a disaster” due to lack of out‑of‑the‑box support: SSH connections fail, GitHub does not resolve over IPv6, and services like Datadog and S3 encounter compatibility issues without extensive workarounds.

Workarounds often involve adding IPv4 fallback addresses, using NAT64 services, or manually patching tools (e.g., adding

--edge-ip-version 6

to Cloudflared).

Conclusion

The transition to IPv6 is inevitable as IPv4 addresses become scarce and costly, yet many infrastructures, ISPs, and development tools remain unprepared, making the migration a complex, costly, and operationally challenging process.