IPv4 exhaustion: the short answer
IPv4 exhaustion means the pools of unallocated IPv4 space can no longer satisfy ordinary demand under the allocation policies that once applied. It does not mean every IPv4 address is active, that IPv4 stopped working, or that a single worldwide counter can show how many usable addresses remain.
IANA allocated the last five blocks from its central free pool to the Regional Internet Registries (RIRs) on 3 February 2011. The RIRs then reached their own policy milestones at different times. Recovered space, tightly limited RIR allocations, provider assignments, transfers, leasing, reclamation, address sharing, and IPv6 are now separate ways of meeting different needs.
What does IPv4 address exhaustion mean?
IPv4 uses 32-bit addresses, so there are 232, or 4,294,967,296, possible bit patterns. That is not a count of public addresses available for organizations to acquire: some ranges are reserved for private networks, documentation, multicast, loopback, shared address space, and other special purposes, while much of the globally routable space is already allocated or assigned.
The word exhaustion applies to an allocation pool and policy, not to the protocol itself. Four facts can all be true at the same time:
- IANA has no central free pool for ordinary allocations to RIRs.
- An RIR may distribute small amounts of recovered space under a waiting-list or final-allocation policy.
- Organizations may hold allocated addresses that are not visible in the global routing table or not currently used on hosts.
- Eligible parties may obtain existing address space through a registry transfer, a provider assignment, or a time-bounded lease.
These are different inventories with different authority, eligibility, routing, cost, and continuity implications. Read the RIR guide for the roles of IANA, the five RIRs, ISPs, and end users.
How many IPv4 addresses are left in 2026?
There is no single accurate global “IPv4 addresses left” number. For ordinary top-level allocation, IANA's answer is effectively zero: its central free pool was depleted in 2011, and in 2019 it made the final equal allocations from the recovered-address pool then available. At the RIR level, the answer depends on the region, policy, applicant eligibility, wait-list position, and what address space has been recovered since the last distribution.
| Inventory | What it measures | Why it is not a global availability count |
|---|---|---|
| IANA central pool | Unallocated space available for top-level distribution to RIRs | The ordinary free pool is exhausted; it does not track every address held or used below the RIR level |
| RIR available or recovered pool | Space one registry may issue under its current policy | Amounts and eligibility differ by region and change when space is returned, revoked, reserved, or distributed |
| Allocated but unannounced space | Registered prefixes not currently visible in the global BGP table | Unannounced does not mean unowned, unused, transferable, reachable, or available |
| Transfer or lease supply | Existing holders willing and able to transfer or authorize use of a prefix | Supply is offer-specific and subject to authority, policy, contract, technical, and due-diligence checks |
| Addresses behind NAT | Private or shared addresses used inside networks | Address sharing reduces public demand for some applications but does not add globally unique IPv4 space |
A defensible capacity decision therefore starts with the exact CIDR size and intended use, then checks current RIR policy or current offer-specific evidence. It should not subtract a routing-table estimate from 4.3 billion and call the result “available IPv4.”
IANA and RIR IPv4 exhaustion status
The milestones below were reviewed against official IANA and RIR material on 3 September 2026. “Exhausted” does not have one identical operational consequence in every registry; the current policy page controls.
| Registry | Milestone | Practical status |
|---|---|---|
| IANA | Central free pool depleted on 3 February 2011; final recovered-pool distribution made in 2019 | No normal top-level IPv4 inventory for allocation to RIRs |
| APNIC | Entered its final /8 policy on 15 April 2011 | Eligible members can request only limited space under current policy; additional needs generally require other supply paths |
| ARIN | Declared its IPv4 free pool depleted on 24 September 2015 | Limited recovered space may be distributed through the waiting list; transfers and specified reserved uses are separate paths |
| RIPE NCC | Made the final /22 allocation from its remaining pool on 25 November 2019 | Recovered /24 blocks may be issued to eligible new LIRs through a waiting list, if space becomes available |
| LACNIC | Progressed through phased exhaustion and announced depletion of its available pool in 2020 | Any distribution is governed by the current final-phase or reserved-space policy, not ordinary pre-exhaustion allocation |
| AFRINIC | Entered exhaustion phase 2 on 13 January 2020 | Remaining inventory and maximum allocation are policy-limited and dynamic; verify the current statistics and policy before planning |
Do not treat a milestone date as a promise that a registry has no address records, no reserved space, or no mechanism for returned addresses. Likewise, a small pool shown on a statistics page is not proof that a particular applicant will qualify or receive it.
What caused IPv4 exhaustion?
- A finite 32-bit address space: IPv4 was designed before today's Internet scale, cloud platforms, mobile networks, and always-connected services were foreseeable.
- Early allocation practices: classful networks and some historically large allocations used address space less efficiently than later CIDR-based policies.
- Rapid Internet growth: more networks, services, regions, and customers required globally reachable endpoints.
- A long transition: IPv6 removes the address-scale constraint, but applications, customer networks, security controls, procurement, and operations have not moved at the same speed.
NAT did not cause exhaustion. It slowed consumption by allowing several private endpoints to share public IPv4 addresses. CIDR, reclamation, transfers, and stricter allocation rules also prolonged the useful life of the installed base, but none can enlarge the 32-bit protocol space.
IPv4 exhaustion vs 512K Day
512K Day was a routing-scale event, not the day IPv4 addresses ran out. On 12 August 2014, the global IPv4 BGP table exceeded roughly 512,000 routes. Some older routers had divided forwarding memory in a way that left room for about 512K IPv4 entries, so they could fail to install routes or forward traffic correctly.
IPv4 pool exhaustion asks whether an allocation authority has unallocated addresses available under policy. Routing-table growth asks whether routers can store and process the prefixes networks announce. Deaggregating one allocated block can increase the route count without creating or consuming new addresses; aggregating routes can reduce entries without returning any address space. APNIC's routing-table review explains why later table-size thresholds require the same separate capacity planning.
Is IPv4 still used after exhaustion?
Yes. Exhaustion did not invalidate existing allocations or make IPv4 packets stop routing. Websites, enterprise networks, hosting, access providers, cloud services, and customer equipment still depend on IPv4, often alongside IPv6.
IPv6 uses 128-bit addresses and is the long-term protocol solution to address-scale pressure. Deployment is usually coexistence rather than an instant replacement: dual-stack networks run IPv4 and IPv6 together, while translation and proxy mechanisms can bridge specific gaps. An IPv6 launch still needs routing, DNS, security, observability, application, and support readiness. See the IPv6 adoption guide.
How IPv4 scarcity affects networks and businesses
- Cost and lead time: address space may require transfer, leasing, provider fees, approval, integration, and ongoing operations instead of a routine free-pool request.
- Architecture trade-offs: CGNAT and dense address sharing can conserve space but may complicate inbound reachability, attribution, port use, logging, troubleshooting, and some applications.
- Due diligence: registry authority, transfer eligibility, routing history, RPKI, IRR, reverse DNS, geolocation, reputation, and abuse history need separate checks.
- Continuity risk: a lease, provider assignment, or upstream-dependent prefix needs renewal, return, replacement, route withdrawal, and incident plans.
- IPv6 work: postponing IPv6 can preserve a growing dependency on scarce IPv4, but deploying it without application and operational validation creates different failure modes.
Practical IPv4 exhaustion solutions
| Option | What it helps solve | Important limitation |
|---|---|---|
| Deploy IPv6, often with dual stack | Creates scalable end-to-end address capacity and reduces future IPv4 dependency | Does not remove today's IPv4 requirement where users, partners, software, or networks remain IPv4-only |
| NAT or CGNAT | Lets multiple endpoints share a smaller public IPv4 pool | Can affect inbound services, port availability, attribution, logging, abuse response, and application compatibility |
| Reclaim and renumber | Finds stranded capacity and improves utilization inside an existing estate | Requires accurate inventory, dependency discovery, migration effort, and change control |
| Buy through an eligible transfer | Can provide longer-term control of existing address space | Requires capital, registry eligibility, seller authority, transfer approval, technical handover, and operational due diligence |
| Lease IPv4 address space | Can provide time-bounded access without purchasing the asset | Availability, routing authority, allowed use, reputation, renewal, return, and continuity are contract- and prefix-specific |
| Use provider-assigned addresses | Can meet smaller or service-bound needs through an ISP, host, or cloud platform | Addresses may not be portable and can couple the service to that provider or architecture |
The best answer is often a portfolio: deploy IPv6 where end-to-end support exists, conserve and reclaim IPv4, then acquire only the public IPv4 capacity the application still requires. Leasing and transfers are continuity tools, not technical fixes for the finite protocol space.
Checks before you buy or lease IPv4 space
- Define the requirement: exact prefix size, public endpoints, growth reserve, region, duration, portability, inbound reachability, and whether multiple blocks are acceptable.
- Verify authority: current RIR record, registered holder, transfer eligibility or lease authority, source history, encumbrances, and the identity of every contracting party.
- Plan routing: announcing ASN, LOA, RPKI ROA, IRR route object, upstream filters, propagation, reverse DNS, geofeed, monitoring, and rollback.
- Test operational fit: dated reputation and blocklist evidence, geolocation differences, reachability, previous announcements, application acceptance, and abuse contacts. No prefix can be guaranteed “clean” across every third-party dataset.
- Model the full term: price unit, setup and transfer costs, registry or platform fees, support, renewal, price changes, return, quarantine, replacement capacity, and exit work.
Use current, offer-specific evidence rather than assuming that scarcity makes every prefix equally usable or valuable. The IPv4 block risk assessment and marketplace listings provide the next verification steps.
IPv4 exhaustion FAQ
What is IPv4 exhaustion?
IPv4 exhaustion is the depletion of unallocated address pools under IANA or RIR policy. It does not mean every address is active or that the IPv4 protocol no longer works.
When did IPv4 addresses run out?
There is no single worldwide date. IANA depleted its central free pool on 3 February 2011, while each RIR reached later policy milestones at different times. Small recovered or reserved pools can still be handled under region-specific rules.
How many IPv4 addresses are left in 2026?
There is no meaningful single total. IANA has no ordinary central free-pool inventory, while RIR recovered pools, reserved space, provider assignments, transfer offers, and lease supply are distinct and change over time.
Are all 4.3 billion IPv4 addresses usable on the public Internet?
No. IPv4 has 4,294,967,296 possible bit patterns, but special-purpose ranges and protocol rules mean that figure is not a count of globally routable addresses available for acquisition or unique hosts.
Is IPv4 still used?
Yes. Existing IPv4 allocations continue to route, and many services still need IPv4 reachability. Networks commonly use IPv4 and IPv6 together while reducing their remaining IPv4 dependency.
Did 512K Day cause IPv4 exhaustion?
No. 512K Day concerned the number of IPv4 routes some routers could hold in forwarding memory. Address-pool exhaustion concerns unallocated addresses. Route count and address supply are related operational pressures but different measurements.
Can NAT solve IPv4 exhaustion?
NAT and CGNAT conserve public addresses by sharing them, but they do not create new globally unique IPv4 space. They also introduce reachability, port, logging, attribution, and application trade-offs.
Should a business buy, lease, or replace IPv4 with IPv6?
The answer depends on duration, control, capital, portability, application reachability, and operational readiness. Deploy IPv6 where practical, reduce unnecessary IPv4 use, and compare a transfer, lease, or provider assignment only for the capacity that still needs IPv4.
