IPv4 runs out, the 30-year scarcity timeline
IPv4 runs out, the 30-year scarcity timeline
Field note. Why getting a static IP is hard, why CGNAT exists, and why we still mostly use an address space designed for four billion devices fifty years ago.
The IPv4 address space has 4.3 billion addresses. By the 1990s, anyone paying attention could see they would run out. Anyone could predict roughly when. The transition to IPv6 was supposed to solve it. The transition started in 1996 and is still incomplete in 2026.
This article is the timeline of how IPv4 ran out, what was done about it, and what the slow IPv6 transition looks like in detail.
The 30-year IPv4 scarcity timeline
The early signs (1980s)
When IPv4 was finalized (RFC 791, 1981), the internet had thousands of computers. 4 billion addresses seemed like enough for centuries.
Almost immediately, problems emerged. The classful addressing scheme allocated addresses in fixed sizes:
- Class A: /8 (16.7 million addresses).
- Class B: /16 (65,536 addresses).
- Class C: /24 (256 addresses).
A small organization needing more than 256 addresses had to get a Class B. Most of which (with 65,000 addresses) was wasted. By the late 1980s, the wastage was massive: maybe 30-50 percent of allocated addresses sat unused.
Internet engineers saw the problem coming.
CIDR and the first reprieve (1993)
In 1993, the IETF standardized Classless Inter-Domain Routing (CIDR), eliminating the Class A/B/C boundaries and letting addresses be allocated in arbitrary-sized blocks.
Suddenly:
- An organization needing 1,000 addresses got a /22 (1,024 addresses), not a /16.
- Existing blocks could be subdivided.
- Allocations became closer to actual need.
CIDR delayed exhaustion meaningfully. The growth rate of consumed addresses slowed.
The first IPv6 work (1995-1998)
The IETF began designing IPv6 in 1994-1995. Several proposals competed (SIPP, TUBA, others). In 1995, the IPv6 design (formerly "IPng," next generation) was largely finalized. RFC 1883 in 1995, updated to RFC 2460 in 1998.
The design: 128-bit addresses, simpler header, mandatory IPsec support (later relaxed), built-in autoconfiguration.
The IETF had clear-eyed predictions about IPv4 exhaustion. The transition needed to happen. They expected it to be done by ~2000 or 2005.
This expectation was off by decades.
NAT spreads (1994-2005)
The 1990s saw the rapid spread of NAT (Network Address Translation) in home and small office networks. Originally a workaround, NAT became normalized.
Effect: each "endpoint" in NAT-using networks didn't consume a public IP address. Households of 10 devices used 1 IP. This dramatically reduced IPv4 demand.
NAT bought decades for IPv4. It also broke end-to-end connectivity in subtle ways. The internet became less "everyone is reachable" and more "clients reach servers."
The 2000s: growth strains the pool
Through the 2000s, demand for IPv4 grew steadily:
- Broadband adoption.
- Server proliferation (cloud era starting 2006).
- Mobile devices.
- IoT (eventually).
The regional internet registries (ARIN, RIPE, APNIC, LACNIC, AFRINIC) tracked their pools carefully. Predictions converged: exhaustion in the early 2010s.
ARIN, RIPE, and APNIC all published depletion countdowns. Workshops, conferences, papers, all warning that the world had to move to IPv6 quickly.
The world mostly didn't.
IANA exhaustion: February 3, 2011
The global pool: IANA (the Internet Assigned Numbers Authority) holds the master pool, allocates /8 blocks (16.7M addresses each) to RIRs.
February 3, 2011. IANA gave its last /8 blocks to RIRs (one to each of the five). A small ceremony was held. The global IPv4 pool was empty.
After this point, RIRs had to live on their own remaining pools. New allocations had to come from existing holdings.
RIR exhaustion: 2011-2017
Each RIR exhausted at different times:
- APNIC (Asia-Pacific): April 15, 2011. Just 71 days after IANA. APNIC instituted strict policies; new members get a /22 (1,024 addresses) max.
- RIPE (Europe): September 14, 2012. Similar /22 policy.
- LACNIC (Latin America): June 10, 2014.
- ARIN (North America): September 24, 2015.
- AFRINIC (Africa): exhausted 2017, with ongoing controversy over remaining allocations.
After each RIR's exhaustion, the only sources of new IPv4 in that region were:
- Returns from members who had unused space (rare).
- Transfers between members.
The transfer market was born.
The transfer market (2012-present)
When IPv4 became scarce, owners started selling. Prices were initially modest:
- 2014: ~$7 per address.
- 2017: ~$15 per address.
- 2020: ~$25 per address.
- 2023: ~$50 per address.
- 2026: ~$40-50 per address (with some volatility).
A /24 (256 addresses) now costs about $10,000 to $13,000. A /22 (1,024 addresses) costs $40,000 to $50,000.
Brokers emerged (Hilco Streambank, IPv4.Global, AddrEx, etc.) to facilitate sales. RIRs developed transfer policies governing who can buy and sell.
Some early /8 holders sat on gold mines. MIT sold half its /8 to Amazon in 2017 for an undisclosed sum (rumored hundreds of millions). The U.S. Department of Defense's /8s have largely sat unused; whether to "give them back" is a periodic policy debate.
The slow IPv6 deployment
In parallel, IPv6 deployment crept forward:
- 2000: 0.01 percent of internet traffic.
- 2010: 0.3 percent.
- 2015: 5 percent.
- 2020: 30 percent.
- 2026: ~40 percent.
The pattern: very slow start, then accelerating. The first 15 years of IPv6 were the hard climb.
What helped:
- Major content providers (Google, Facebook, Netflix) enabling IPv6 to give push back to networks that didn't.
- Mobile carriers running IPv6-only internally (because cellular networks had no other option for adding more devices).
- World IPv6 Day (2011) and World IPv6 Launch (2012), industry-wide campaigns to encourage enablement.
What hurt:
- Inertia. Most networks work fine on IPv4.
- Operational complexity of dual-stack.
- Specific software bugs that took years to fix.
- Conservative service providers waiting for the next operator to go first.
CGNAT becomes mainstream (2010s)
ISPs facing IPv4 exhaustion deployed Carrier-Grade NAT (CGNAT) at scale. By 2026, CGNAT is the default for most mobile carriers and many residential ISPs.
Effect: many households "share" a public IPv4 with hundreds of others. The illusion of "each customer has an IP" is maintained, but the underlying reality is shared.
CGNAT works but degrades the internet in specific ways (covered in the CGNAT article). It's a real cost of IPv4 scarcity.
What's left
In 2026:
- Major RIRs have small reserves for specific purposes (new entrants, transition tech).
- The transfer market is the only source of new IPv4 at scale.
- Prices stable at ~$40-50/address.
- IPv6 traffic at ~40 percent, slowly growing.
- IPv4 is here to stay for another 10-20 years minimum.
The slow transition continues. There's no flag day. There's just gradual change.
Why didn't this work better?
A few angles:
The IETF's design was correct. IPv6 solves the address problem. The protocol works. Where IPv6 is deployed, things are fine.
The transition mechanisms were too complex. Dual-stack, tunneling, NAT64 / DNS64, 6to4, Teredo, 464XLAT. Multiple ways to transition, none simple. Operators had to learn many things.
The economic incentives were weak. Running IPv4 worked. Adding IPv6 added cost without obvious immediate revenue. Networks deferred.
Backward compatibility was missing. A pure IPv6 host can't talk to a pure IPv4 host. You need dual-stack on both ends, or a translator. This made "just upgrade everyone" impossible.
The chicken-and-egg problem. Content providers waited for users to have IPv6. Users waited for content to support IPv6. Each side waited for the other.
Looking back, the transition could have been smoother if:
- IPv6 had been designed to be backward-compatible (technically very hard).
- Government mandates had pushed adoption (some countries did this; results mixed).
- Carriers had been pushed to deploy IPv6 from the start.
None of these happened broadly.
The lessons
A few:
Predictable scarcity is hard to handle. Everyone saw IPv4 exhaustion coming for 25 years. Most networks did nothing until they had to.
Backward compatibility matters more than purity. A backward-compatible IPv4 extension would have shipped 20 years earlier. The clean redesign of IPv6 paid a price in deployment friction.
Critical infrastructure changes very slowly. Operating systems, network equipment, applications, and operator practices all needed updates. Each ecosystem had its own timeline.
Markets find solutions. The transfer market is a real adaptation. Imperfect but functional.
What this means for hosting
For game hosting and other internet businesses in 2026:
IPv4 is a real cost. $40-50 per address, factored into hosting prices. Some hosts charge IPv4 surcharges for additional addresses.
Dual-stack is the right posture. Support both. Don't go IPv6-only yet; users with IPv4-only paths can't reach you.
Anycast IPv4 still valuable. A handful of well-placed IPv4 anycast prefixes can reach billions of users efficiently.
Long-term, IPv6 dominance is inevitable. Plan for it. Train your team. Document your IPv6 setup.
For users: most of this is invisible. Things work. Behind the scenes, hosting companies pay for IPv4, ISPs deploy CGNAT, and the slow IPv6 transition continues.
Conclusion
IPv4 exhaustion is the longest-running predicted infrastructure crisis in modern computing. Everyone saw it coming. The solution (IPv6) was designed 30 years ago. The deployment is still incomplete.
The internet survived by combining:
- CIDR (1993).
- NAT (mid-1990s onwards).
- CGNAT (2010s).
- Transfer markets (2012+).
- Slow IPv6 adoption.
These together let the internet keep growing despite a finite address pool. The price has been increasing complexity, some loss of end-to-end connectivity, and a slow march toward IPv6.
The next decade will likely see IPv6 cross 50 percent of traffic and continue rising. IPv4 will linger indefinitely. The transition isn't dramatic anymore; it's just slow.
Coming up
The final article in Series C: today's centralization, the shift from the internet's originally decentralized vision to the modern reality of a few mega-platforms.
Hosting your game server with AndroHost means we handle most of what's in this post for you automatically: tier sizing, SRV records, off-site backups, DDoS protection.
Keep reading
Why your server's IP being public is fine, and when it isn't
A game server has an IP address. Players connect to it. The IP is, by definition, reachable from the internet. Many server owners feel uneasy about their IP being known, often because they don't know what risk it actually represents.
What a DDoS actually looks like to a Minecraft server, and what protection means
"DDoS protection" is on every hosting marketing page. Most people who pay for it don't know what it does, how attacks actually work, or what level of protection is enough. This article explains, in honest terms, what to expect.
Why "ping to server" can lie, and how to measure properly
The number next to a server in your game's server list (the "ping" or latency display) is convenient. It's also frequently misleading. This article explains what it actually measures, when it's wrong, and how to get a real number.