IPv4 did not run out tomorrow, it ran out years ago

The internet is not waiting for a dramatic day when IPv4 addresses suddenly disappear. That day already arrived in stages. The central global IPv4 free pool was exhausted in February 2011, several regional registries later exhausted or severely rationed their pools, and the remaining IPv4 economy now runs on waiting lists, recovered space, address transfers, leasing, cloud surcharges, carrier-grade NAT, and slow but steady IPv6 deployment. The better question is not “when will IPv4 run out?” It is: which kind of IPv4 supply are we talking about, and how much longer can networks grow while depending on it? The Number Resource Organization announced in 2011 that the free pool of available IPv4 addresses was fully depleted, while RIPE NCC says its remaining IPv4 pool was exhausted in November 2019.

The address shortage is not a future event

IPv4 exhaustion has a strange public life because the phrase sounds like a cliff edge. It suggests that one morning devices will stop connecting, websites will become unreachable, and the internet will freeze because the last usable number has been handed out. That is not what happened. The exhaustion of IPv4 was administrative before it was visible to most users. It meant that the old model of getting fresh, previously unused public IPv4 addresses from the official registry system stopped working.

The central pool run by the Internet Assigned Numbers Authority, or IANA, was depleted on 3 February 2011. At that point, the remaining large blocks were distributed to the five Regional Internet Registries: AFRINIC, APNIC, ARIN, LACNIC, and the RIPE NCC. Those registries then entered different phases of rationing, depletion, waiting lists, and special allocation policies. ARIN’s archived announcement says the remaining last five /8 blocks were allocated to the RIRs on 3 February 2011, in line with global policy.

For ordinary users, the internet did not break because networks had already built layers of workaround. Home routers shared one public address among many private devices. Mobile operators used carrier-grade NAT. Enterprises reused internal address ranges. Cloud providers kept large address inventories. Web companies added IPv6 while keeping IPv4 alive. The scarcity moved behind the interface, into network engineering, business planning, address markets, abuse management, routing tables, and cloud bills.

That hidden character is the reason the public question keeps returning. People still hear that IPv4 is “running out,” then see the internet keep working. Both observations are true. IPv4 has already run out as an abundant registry resource, but it has not run out as a protocol in daily use. Scarcity changed the price and mechanics of growth, not the basic ability of existing IPv4 networks to pass packets.

The tension is now structural. Every new access network, hosting provider, SaaS platform, data center, IoT deployment, VPN service, gaming platform, and security stack still has to reach an internet where much of the server-side world remains reachable over IPv4. At the same time, IPv4 cannot supply enough unique public addresses for every new device, subscriber, virtual machine, container, and service endpoint. The result is not a single global outage. It is a long economic and operational transition.

IPv6 is the intended successor, but it does not replace IPv4 through a clean software update. IPv6 uses a different address format, a different packet header, and a far larger address space. IPv4-only systems and IPv6-only systems do not communicate directly without dual-stack support or translation. That incompatibility explains why the transition has taken decades: the value of a network protocol comes from reachability, and reachability depends on everyone else.

The internet after IPv4 exhaustion is therefore a hybrid internet. Some paths are native IPv6. Some are IPv4. Some are dual stack, where both protocols run side by side. Some use NAT64, DNS64, 464XLAT, proxies, or application gateways to cross between protocol worlds. Some users never notice. Some operators notice every day.

The answer depends on which IPv4 pool is being counted

A precise answer begins by separating four kinds of IPv4 “supply.” The first was the IANA free pool, the central reserve from which large blocks were allocated to Regional Internet Registries. That pool is gone. The second is the ordinary free pool inside each Regional Internet Registry. In most regions, that is either gone or limited to small, rationed allocations. The third is recovered or returned space, which may re-enter registry inventory under strict rules. The fourth is privately held IPv4 space that can be transferred, sold, leased, or reused by organizations that already hold it.

People often collapse those pools into one question. That creates confusion. A startup asking whether it can get thousands of new public IPv4 addresses from its regional registry is asking a different question from a cloud platform deciding how much to charge for public IPv4 addresses. A broadband provider planning new subscribers is asking a different question from a legacy enterprise trying to reclaim unused address blocks from old internal systems. A hosting company looking for clean IPv4 ranges for email delivery is asking a different question from a mobile network that can put customers behind carrier-grade NAT and push most traffic over IPv6.

The “free and easy” IPv4 era is over. The “can I still obtain IPv4 somehow?” era is not over. Addresses still move through markets, mergers, recovery, and policy-based waiting lists. Regional registries still process transfers. Some organizations lease address space. Some cloud providers monetize public IPv4 usage directly. Some governments and universities still hold large historical allocations. Some networks have large reserves because they received addresses early, before conservation became strict.

The practical deadline for any organization is therefore not the same as the global exhaustion date. It is the moment when growth through IPv4 becomes too costly, too slow, too complex, too risky, or too limiting. For a small website, that moment may never feel dramatic because hosting providers abstract it away. For a mobile operator adding millions of users, the moment may have arrived years ago. For a cloud-native company exposing thousands of public endpoints, the moment may appear as a recurring line item on its bill. For an enterprise with overlapping private address space after acquisitions, the pain may come from internal IPv4 scarcity rather than public address scarcity.

This is the central editorial point: IPv4 exhaustion is no longer a prediction. It is an operating condition. The internet now allocates effort around that condition. IPv6 adoption reduces pressure. Address transfers redistribute scarce resources. NAT hides the shortage from users. Cloud pricing makes it visible to finance teams. Security teams inherit the complexity.

The current internet is a negotiated compromise between a protocol that is too small and a successor protocol that is large enough but still unevenly deployed. That compromise is likely to last for many years because existing IPv4 infrastructure has economic value and because many smaller networks, appliances, applications, monitoring tools, and operational habits still assume IPv4.

IPv4 was built for a smaller internet

IPv4’s scarcity starts with a simple design fact: IPv4 addresses are 32 bits long. RFC 791, the original Internet Protocol specification, describes internet addresses as four octets, or 32 bits. A 32-bit field allows 2³² possible values, which equals 4,294,967,296 theoretical addresses. Not all of those can be assigned to public hosts because some ranges are reserved for special uses, multicast, private addressing, loopback, local behavior, documentation, benchmarking, and other purposes.

Four billion addresses once looked enormous. IPv4 emerged from a research and military networking environment, not from a world of billions of smartphones, cloud instances, virtual machines, containers, smart TVs, home routers, industrial sensors, connected vehicles, cameras, payment terminals, and always-on broadband connections. Early allocation practice also reflected that smaller world. Large blocks were assigned to organizations that were early to the internet. Conservation became more disciplined later, after the scale of public growth became obvious.

The internet bought time with several technical and policy changes. Classless Inter-Domain Routing, or CIDR, replaced the older classful allocation model and improved route aggregation and address conservation. Private address space allowed internal networks to use addresses that were not globally routed. Network Address Translation, or NAT, allowed many private devices to share fewer public addresses.

Those measures delayed exhaustion but did not remove the mathematical limit. They changed the shape of demand. Instead of every device needing a unique public IPv4 address, many devices could live behind one. That kept the consumer internet growing through the broadband and Wi-Fi era. It also changed the internet’s architecture. The original end-to-end model, where any host could potentially communicate directly with any other host, gave way to a network full of stateful middleboxes, port mappings, firewall rules, traversal protocols, and application workarounds.

That bargain was acceptable because it was cheaper than replacing the addressing protocol all at once. It also created habits. Many administrators began to see NAT as a security feature rather than an address-sharing workaround. Many applications adapted to NAT. Many enterprise networks built elaborate private IPv4 plans. Many vendors treated IPv6 as optional because IPv4 plus NAT kept the business running.

IPv6 was designed to solve the address limit at the protocol level. IPv6 uses 128-bit addresses instead of 32-bit IPv4 addresses. That size difference is not a small expansion. It changes address planning from conservation to abundance. It gives networks room for hierarchical addressing, cleaner aggregation, direct device addressing where policy allows it, and deployment models that do not require squeezing subscribers or services behind a tiny public IPv4 pool.

The difficulty is not that IPv6 lacks address capacity. The difficulty is that IPv6 is not backward-compatible at the packet level with IPv4. The two protocols can coexist, but one does not magically understand the other. That is why the transition became a long coexistence period instead of a replacement event.

The regional run-out timeline tells the real story

The cleanest way to understand IPv4 exhaustion is to look at the registry timeline. The global free pool ended first. Regional exhaustion followed at different speeds because each region had different demand, policy, allocation history, and conservation rules. A registry can be “out” in the sense that it no longer hands out large ordinary blocks, yet still hold tiny recovered pools, reserved blocks, waiting-list allocations, or special-purpose resources. That is why the details matter.

IPv4 exhaustion timeline by registry

This table compresses a complex policy history into the dates most readers need. It does not mean IPv4 stopped working on those dates. It means the old path to easy new public IPv4 space closed region by region.

The timeline shows why the question “when will IPv4 addresses run out?” has more than one answer. If the question means “when did the central pool run out?” the answer is 2011. If it means “when did my region stop having ordinary new supply?” the answer depends on the RIR. If it means “when will there be no IPv4 addresses anywhere on the secondary market?” there may never be a clean date, because addresses can be traded, returned, reclaimed, subdivided, consolidated, or kept in private inventories. If it means “when will IPv4 become too expensive or awkward to use for growth?” the answer depends on the business.

The registry history also shows the internet’s governance model at work. No single company owns the addressing system. IANA coordinates global allocations, RIRs manage regional distribution, local internet registries and network operators request resources under community-developed policies, and address holders operate within transfer and registration rules. That system did not prevent scarcity because it could not change a 32-bit address field. It did, though, prevent a chaotic collapse. Exhaustion was forecast, policies were built, final pools were rationed, and IPv6 was available long before the final free IPv4 blocks were issued.

The painful part is that policy can ration scarcity but cannot turn scarcity into abundance. APNIC can limit allocations to preserve a pool for new entrants. ARIN can run a waiting list. RIPE NCC can allocate small recovered blocks to eligible networks. LACNIC can warn that waiting times are long. AFRINIC can impose maximum allocation sizes during exhaustion. Those mechanisms keep some fairness in the system, but they do not give every growing network the public IPv4 space it would like.

The result is an uneven internet. Early holders have assets. New entrants face costs. Large platforms can buy, lease, recover, or architect around the shortage. Smaller operators may accept NAT, use IPv6-mostly designs, or depend on upstream providers. The transition pressure is real, but it is not equally distributed.

The leftover IPv4 supply is rationed, recovered, or traded

After exhaustion, IPv4 did not become impossible to obtain. It became harder to obtain cleanly, cheaply, and predictably. That difference matters. Networks today may still acquire IPv4 through several channels: a waiting list at a Regional Internet Registry, a transfer from another organization, an acquisition of a company that holds address space, a lease arrangement, a cloud provider’s inventory, or internal reclamation.

Each route carries tradeoffs. Waiting lists are slow and usually limited. Transfers require policy compliance, registry approval, contractual work, routing updates, due diligence, and money. Leasing can solve a short-term need but adds dependency, reputation risk, and policy limits in some regions. Cloud addresses are convenient but increasingly priced as scarce resources. Internal reclamation is often the cheapest path, but it may require old application audits, network renumbering, DNS cleanup, firewall changes, and executive patience.

Recovered space also matters, but it is not a miracle pool. ICANN’s post-exhaustion policy established a recovered IPv4 pool at IANA for fragments and addresses returned after exhaustion. Under that policy, allocations from the recovered pool can be distributed to RIRs during defined allocation periods, with a minimum allocation unit of /24. This mechanism keeps some IPv4 moving, but it cannot recreate the old inventory.

That is why RIR language tends to be careful. RIPE NCC says networks in its region can no longer receive “new” IPv4 addresses from the registry that have never been used by another network. ARIN says it can no longer fulfill ordinary requests unless special policy requirements are met. APNIC says members can still get IPv4 under policy, but the maximum amount is small. These are policy-managed remnants, not a return to the old supply model.

The secondary market fills the gap, but it creates its own internet politics. IPv4 addresses began as number resources allocated for network operation. Scarcity turned them into balance-sheet assets. A block that once arrived through administrative allocation can now command real money. That has practical consequences for hosting, cloud, email infrastructure, anti-abuse work, and entry costs. A new provider that needs reputation-clean address space may pay more than an incumbent that received space decades ago.

The market will not disappear while IPv4 remains useful. IPv6 adoption may reduce demand growth, and large unused blocks may still enter the market, but IPv4 retains value because reachability retains value. A public IPv4 address still connects to legacy networks, old devices, conservative enterprises, IPv4-only applications, and abuse-control systems built around IPv4 reputation. Until IPv6 is universal enough that IPv4-only reachability no longer matters, IPv4 addresses will keep a price.

IPv4 will not switch off

The next phase is not the death of IPv4. It is the narrowing of IPv4’s role. IPv4 will remain embedded in networks, operating systems, industrial systems, consumer equipment, internal enterprise environments, virtual private networks, monitoring tools, old appliances, remote access systems, and application code for a long time. Some organizations have no immediate reason to remove it internally. Some cannot remove it because dependencies are unknown. Some will keep it because the cost of change exceeds the benefit.

The internet rarely removes a protocol quickly when that protocol still works and has massive installed base. IPv4 still routes. Routers still support it. Firewalls still inspect it. DNS still returns A records. Content delivery networks still serve it. Cloud load balancers still publish it. Consumer devices still use it. Enterprise change windows still protect it. Operators do not abandon a working protocol simply because a better address model exists.

What changes is the direction of growth. New mobile networks, large access networks, hyperscale environments, and greenfield cloud architectures increasingly have incentives to treat IPv6 as the primary protocol and IPv4 as compatibility. The language used by network engineers has shifted from “IPv6 someday” to “IPv6-mostly,” “IPv6-only with translation,” “dual stack where needed,” and “public IPv4 minimization.” That shift is subtle outside the industry but decisive inside it.

The user experience also hides the transition. A phone may connect to a content service over IPv6 while another app still uses IPv4. A laptop may prefer IPv6 through a connection algorithm when it works and fall back to IPv4 when needed. A home network may receive IPv6 prefix delegation from the ISP but still use IPv4 NAT. A cloud workload may be private IPv4 internally, IPv6 externally, and NAT64 for outbound access to older services. The browser does not announce this to the user.

IPv4 becomes less like the default foundation and more like a compatibility layer. That does not mean it is unimportant. Compatibility layers are often expensive and operationally sensitive. They carry old assumptions. They need monitoring. They create weird failure modes. They must be secured. They may become bottlenecks. They can mask technical debt for years.

A realistic forecast is therefore boring but consequential: IPv4 will stay, but the cost of depending on IPv4 for expansion will keep rising relative to IPv6-native designs. The financial price may go up or down with the address market, but the engineering price remains: NAT complexity, port exhaustion, geolocation errors, reputation problems, logging burden, overlapping private ranges, and transition technology.

The future is not “IPv4 disappears.” The future is IPv4 loses the privilege of being assumed everywhere by default.

NAT kept the internet growing and changed its shape

Network Address Translation is the main reason ordinary users did not feel IPv4 exhaustion as an immediate crisis. NAT lets many private devices share one public IPv4 address. A home router maps internal private addresses and ports to a public address and tracks active sessions. To the outside internet, many devices may appear behind one address. Inside the home or office, devices use private address space, commonly 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.

This preserved public IPv4 addresses, but it also changed how applications work. Direct inbound connectivity became harder. Peer-to-peer systems needed traversal methods. Games, video calls, VPNs, and real-time applications had to handle address and port mappings. Firewalls and NAT devices became central points of policy and failure. Logs needed port information, not just IP addresses. Abuse handling became harder when many users shared one public address.

NAT also trained a generation of operators to equate address hiding with security. That belief is only partly true. A stateful firewall policy can block unwanted inbound traffic; NAT often comes packaged with such behavior in consumer routers. But NAT itself is an address translation mechanism, not a full security model. IPv6 networks can be filtered just as strictly without private-to-public address translation. The security goal is policy control, not address scarcity.

Carrier-grade NAT, or CGNAT, extends the home NAT idea into the provider network. Instead of each customer receiving a unique public IPv4 address, many customers share a smaller public pool through large translation systems. This works, but it is not invisible to every application. Some games fail or degrade. Some VPNs have trouble. Some peer-to-peer systems lose direct reachability. Some abuse systems over-block because many users share one address. Some compliance requests require detailed timestamp and port logs. Some customers cannot host services from home.

The benefit is immediate address conservation. The cost is state. CGNAT boxes must track many sessions, manage port allocation, survive failure, scale under traffic load, and log enough detail for operational and legal needs. When they fail, many users may fail together. When they run out of ports, users see strange partial breakage. When they sit in the path of latency-sensitive services, performance engineering gets harder.

NAT bought time, and the internet needed that time. Without NAT, IPv4 exhaustion would have hit users and providers much earlier. But NAT is not a clean substitute for a larger address space. It is a pressure valve. IPv6 is the structural fix.

Carrier-grade NAT makes scarcity visible in daily life

Most users do not know when they are behind carrier-grade NAT until something breaks. The clues are practical: a home server cannot be reached from outside, port forwarding does not work, online games report strict NAT, remote camera access fails, a VPN behaves unpredictably, or a website incorrectly blocks a user because someone else sharing the same public address abused the service.

For consumer broadband, CGNAT is often the default in markets where IPv4 is tight and IPv6 deployment is incomplete. A provider may offer public IPv4 only as a paid option, a business plan feature, or not at all. That is rational from the provider’s side. A public IPv4 address has opportunity cost. If a single address can support many customers through CGNAT, assigning it to one household is expensive.

For mobile networks, CGNAT became normal earlier. Phones are usually clients, not public servers, and mobile architectures already centralize traffic in ways that make translation easier. Many mobile operators moved aggressively to IPv6, often using IPv6-only access with translation for IPv4 destinations. That is one reason mobile networks have been among the strongest IPv6 adopters in several countries.

The user-facing problem is that CGNAT pushes scarcity into edge cases, and edge cases matter. A family that only streams video and browses the web may never care. A gamer may care. A developer may care. A small business hosting a VPN endpoint may care. A security camera installer may care. A remote worker using legacy enterprise tools may care. A user wrongly caught in an IP reputation block may care deeply.

CGNAT also affects accountability. When one public IPv4 address represents hundreds or thousands of customers, an IP address alone is less useful as an identifier. Providers need precise logs linking public address, port range, private subscriber assignment, and timestamp. Abuse teams need better signals. Websites need to avoid blunt IP-based blocking where possible. Investigators need to know that one IPv4 address is no longer always one subscriber.

This is one of the quiet ways IPv4 exhaustion changed the internet. It reduced the meaning of a public IPv4 address as an identity clue. That matters for fraud detection, rate limiting, login risk scoring, ad tech, content licensing, compliance, and security analytics. IPv6 does not automatically solve every identity problem, but it restores the possibility of more granular addressing without sharing one public address across a crowd.

The policy implication is uncomfortable. If a country or regulator wants better connectivity, fewer access problems, and cleaner attribution, encouraging IPv6 deployment may be more useful than pushing providers to keep stretching IPv4 through more layers of NAT. CGNAT is a symptom. It is not a destination.

IPv6 changes the address economy

IPv6’s address space is the obvious difference, but the economic impact is bigger than the number. IPv4 scarcity turns addresses into inventory. IPv6 abundance turns addressing back into planning. That shift changes network design.

An IPv6 address is 128 bits long. The total space is commonly described as 2¹²⁸ addresses, a number so large that the consumer analogy usually becomes meaningless. The operational point is simpler: IPv6 gives networks enough room to assign prefixes generously, aggregate routes cleanly, and avoid public-address scarcity as a growth constraint. It does not mean every possible address is routed or used. It means network planners no longer need to design around a tiny public pool.

This changes the conversation for ISPs. Instead of deciding how many customers can share an IPv4 address, the ISP can delegate IPv6 prefixes to customers. Instead of saving public addresses for special customers, it can make globally routable addressing ordinary again while using firewall policy to control inbound access. Instead of building ever-larger NAT systems, it can move more traffic natively.

For cloud platforms, IPv6 reduces the need to assign a public IPv4 address to every public-facing resource. Load balancers, APIs, object storage, edge services, Kubernetes ingress, and serverless endpoints can serve IPv6 where clients support it. Private workloads can use IPv6-only subnets in some architectures, with translation for the shrinking set of IPv4-only dependencies. That matters as cloud providers turn IPv4 into a metered cost.

For enterprises, IPv6 changes merger and acquisition pain. Large private IPv4 networks often overlap. Two companies may both use 10.0.0.0/8 internally, making integration painful. VPNs, routing, identity systems, and security tools then need translation or renumbering. IPv6 does not remove all integration work, but it gives space for cleaner, non-overlapping plans.

For the public internet, IPv6 can reduce dependency on port sharing and address reputation crowding. It also shifts security work from NAT traversal and shared public IP management toward proper firewalling, neighbor discovery protection, router advertisement control, DNS hygiene, IPAM, logging, and monitoring across a much larger address space.

IPv6 is not magic. Badly run IPv6 networks fail like badly run IPv4 networks. Firewalls can be misconfigured. DNS can be wrong. Applications can bind only to IPv4. Monitoring can miss IPv6 paths. Security tools can ignore extension headers or neighbor discovery. Help desks can misdiagnose dual-stack failures. Address abundance solves the scarcity problem, not every network problem.

Still, the long-term economics are clear. IPv4 makes growth depend on conservation, sharing, and markets. IPv6 makes growth depend on deployment discipline. One model fights the address space. The other uses the address space that was built for the internet’s actual size.

Dual stack is the bridge most users never notice

Dual stack means running IPv4 and IPv6 at the same time. A device has both IPv4 and IPv6 connectivity. A website publishes both A records for IPv4 and AAAA records for IPv6. The client chooses a working path. If IPv6 works well, traffic can flow over IPv6. If not, IPv4 remains available. This is the dominant transition model for much of the public internet because it avoids forcing a clean break.

The beauty of dual stack is compatibility. The cost is duplication. Networks must route both protocols, filter both protocols, monitor both protocols, secure both protocols, troubleshoot both protocols, document both protocols, and train staff on both protocols. DNS must be correct for both. Load balancers must listen on both. Certificates may not care about IP version, but reachability does. Logs must record both. Abuse systems must understand both. Application owners must test both.

Dual stack also creates subtle performance questions. A client may try IPv6 first, but if IPv6 is broken or slow, the user should not wait through long timeouts. Modern connection logic reduces user-visible delays on dual-stack hosts by racing or staggering connection attempts.

For large content providers, dual stack is necessary because the audience is mixed. Some users have excellent IPv6. Some have none. Some have broken IPv6. Some corporate networks block it. Some mobile networks prefer it. A public service that drops IPv4 today would cut off too many users. A public service that ignores IPv6 leaves performance, reachability, and future readiness on the table.

Dual stack is also how many organizations begin without a full internal redesign. They add IPv6 at the edge first: DNS, CDN, web front ends, load balancers, VPN concentrators, authoritative DNS, mail gateways, and public APIs. Then they move inward toward application networks, service meshes, container platforms, observability, and internal identity services. That staged approach limits risk.

Yet dual stack is not the final answer for every environment. Running two protocols forever has cost. Some mobile and cloud architectures now prefer IPv6-only internally, with translation for IPv4 destinations. That reduces internal IPv4 demand and avoids duplicating every internal network plan. The edge may remain dual stack while the core becomes IPv6-mostly or IPv6-only.

A sensible rule emerges: dual stack is the bridge, not the destination for every network. It is often the safest public-facing transition step. It is not always the cleanest long-term internal architecture.

IPv6-only with translation is becoming normal

The phrase “IPv6-only” sounds risky until the translation pieces are understood. An IPv6-only client can still reach many IPv4-only services through NAT64 and DNS64. NAT64 translates traffic between IPv6 clients and IPv4 servers. DNS64 synthesizes IPv6 AAAA records from IPv4 A records so an IPv6-only client can initiate a connection by name.

That architecture matters because it lets operators build new access networks without giving every client IPv4 service in the old way. The client runs IPv6 natively. For IPv6-capable destinations, traffic stays IPv6. For IPv4-only destinations, translation handles compatibility. Mobile networks have used related designs at scale because they need to support huge numbers of devices without huge public IPv4 pools.

464XLAT adds another layer for applications or devices that still expect IPv4 locally. It combines customer-side translation with provider-side translation so IPv4-only applications can operate over IPv6-only access networks. It has become important in mobile and IPv6-mostly environments.

These tools do not make IPv4 irrelevant. They reduce the amount of IPv4 required at the edge. One public IPv4 address at a translator can support many IPv6 clients reaching IPv4 servers, subject to port capacity and state. That is still address sharing, but it pushes the network’s native direction toward IPv6 rather than deeper IPv4-only NAT.

The limitations are real. NAT64 works best for client-initiated connections to named destinations using protocols that behave well through translation. Literal IPv4 addresses embedded in applications can break. Some peer-to-peer systems need extra support. Some enterprise VPNs and legacy protocols resist translation. DNSSEC interactions need care when DNS64 synthesizes records. Logging and troubleshooting require IPv6 and IPv4 visibility across the translation point.

Even with those limits, IPv6-only plus translation is now more than a lab model. It is a practical answer to new-network growth. A provider can give users modern internet access without assigning each customer a public IPv4 address. A cloud team can build IPv6-only subnets and use egress translation for older services. An enterprise can reduce internal IPv4 sprawl while keeping access to external IPv4 resources.

The strategic shift is that IPv4 becomes the exception path. That is different from dual stack, where IPv4 and IPv6 are peers. In IPv6-only designs, the native network is IPv6, and IPv4 is reached through compatibility systems. That pattern is likely to expand because it matches the economics of scarcity.

Cloud pricing turned IPv4 scarcity into a monthly bill

For many businesses, IPv4 exhaustion became real only when cloud invoices changed. Engineers had discussed address scarcity for decades, but finance teams notice recurring charges. AWS announced that, effective 1 February 2024, it would charge USD 0.005 per IP per hour for all public IPv4 addresses, whether attached to a service or not. AWS said IPv4 addresses were increasingly scarce and that the cost to acquire a single public IPv4 address had risen more than 300% over the previous five years.

This changed behavior. A public IPv4 address that once felt free inside a cloud architecture became a billable design choice. A small monthly cost per address may look minor, but at scale it becomes meaningful. Hundreds or thousands of public endpoints across development, test, staging, production, Kubernetes nodes, load balancers, NAT gateways, bastion hosts, and forgotten resources can add up.

The effect is useful because it forces inventory. Many organizations discover unused public IPv4 addresses, idle Elastic IPs, development systems exposed by habit, old NAT gateways, abandoned load balancers, and architectures that assign public IPs to instances that could sit behind private networks or IPv6-capable front ends. Cost pressure becomes hygiene pressure.

Cloud pricing also reframes IPv6 from a standards project into cost control. A team that supports IPv6 at the edge may reduce dependence on public IPv4 addresses. A team that moves administrative access to private connectivity may stop exposing public addresses for SSH or RDP. A team that consolidates ingress through shared load balancers or CDNs may reduce address count. A team that builds IPv6-only internal services may avoid future IPv4 expansion.

There is a danger, though. Cost pressure can lead to quick fixes that deepen NAT complexity rather than improve architecture. A company may remove public IPv4 from instances but push more traffic through expensive NAT gateways or fragile egress points. It may hide systems behind proxies without improving IPv6 readiness. It may centralize failure. The better response is not just “use fewer public IPv4 addresses.” It is design public reachability deliberately and make IPv6 part of the default path.

Cloud providers have a double role. They feel IPv4 scarcity because they operate enormous infrastructure. They also shape customer behavior through product support and pricing. If IPv6 support is complete, documented, observable, and easy, customers move faster. If IPv6 support is inconsistent across services, customers keep IPv4 longer. Cloud pricing can push the market, but platform maturity decides how far customers can go.

The 2024 pricing changes were therefore a milestone. They did not mean IPv4 had run out that year. They meant one of the world’s largest infrastructure markets started charging in a way that made IPv4 scarcity explicit.

The IPv4 market is now infrastructure, not trivia

The secondary IPv4 market exists because addresses remain useful and scarce. Its mechanics are now part of internet infrastructure. Buyers need addresses for hosting, access networks, VPN services, cloud infrastructure, email systems, content platforms, and enterprise expansion. Sellers may have unused or underused allocations, often from historical assignments, mergers, restructuring, bankruptcies, or strategic decisions to monetize assets.

A public IPv4 block is not just a number range. It carries registry history, routing reputation, abuse history, geolocation data, route object records, RPKI status, blacklist status, and operational baggage. A cheap block with poor reputation may cost more in cleanup than it saves in purchase price. A clean block may command a premium. Smaller blocks may behave differently from larger blocks because demand and routing usability differ.

The market also interacts with governance. RIR transfer policies determine what can move and how registration is updated. Some regions permit inter-RIR transfers under conditions. Some require needs justification. Some treat leasing differently from transfers.

Prices have not moved in one straight line. They rose sharply during periods of intense scarcity expectations, then softened in some block sizes as supply entered the market and buyers adjusted. A falling price does not mean IPv4 scarcity is solved. It may mean more supply appeared, buyers became price-sensitive, IPv6 and NAT reduced demand growth, or large blocks cleared at lower prices. The deeper point is that IPv4 is no longer an administrative free good. It is a constrained resource with market liquidity, regional rules, due diligence requirements, and risk.

This matters for competition. Incumbents that hold large address inventories have an advantage. New entrants pay cash, accept NAT-heavy designs, depend on cloud providers, or move faster to IPv6. That can affect hosting markets, ISP expansion, and regional internet development. Address scarcity is not only a protocol issue. It is also a market-entry issue.

The market will probably persist for years because IPv4 reachability remains valuable even as IPv6 grows. The end of the market would require IPv4 demand to fall so far that addresses lose strategic value. That is possible only after IPv6 is near-universal across users, content, enterprise systems, devices, and operational tooling. The internet is not there.

Search, advertising, abuse systems and IP reputation still depend on IPv4

IPv4 scarcity is also felt in systems that were built around IP reputation. Email delivery, fraud detection, bot management, account protection, web application firewalls, rate limiting, ad verification, geolocation, streaming rights, affiliate tracking, and cybersecurity workflows often use IP addresses as signals. They rarely rely on IP alone, but IP reputation remains part of the stack.

When many users share one IPv4 address through CGNAT, the signal gets noisier. One abusive user can affect others. A website may throttle or challenge an address because suspicious activity came from the same public IP. A streaming platform may misread location. A security system may flag a login because the shared address has a poor history. An email sender may inherit reputation problems from a previously used block.

Address transfers add more complications. Geolocation databases may lag. A block moved from one country or provider to another may still appear in old databases. Abuse contacts may be stale. Reverse DNS may need repair. RPKI route origin authorizations may need updates. Blacklists may retain old history. Some of these issues are solvable, but they require operational work.

IPv6 changes the signal model. There are far more addresses, and users may receive prefixes rather than one shared public address. That can support cleaner attribution, but it also requires new reputation methods. Blocking a single IPv6 address is often meaningless if an attacker has a whole prefix. Blocking too large a prefix can harm innocent users. Security teams need prefix-aware policies, not IPv4 habits copied into a larger address space.

This is one reason IPv6 deployment is not just a network-layer project. Application security, fraud, email, analytics, compliance, and customer support teams need to understand the change. Logs must store IPv6 correctly. Databases must support 128-bit addresses. User interfaces must display them without truncation. Rate limiting must work by prefix. SIEM tools must parse them. Threat feeds must cover them. Customer support scripts must not assume dotted-decimal IPv4.

The post-IPv4 internet rewards organizations that treat IP addressing as data infrastructure. Those that treat it as an invisible network detail will be surprised by reputation errors, broken allowlists, incomplete logs, and inconsistent policy enforcement.

Security teams inherit two protocols

IPv6 deployment can fail inside organizations because security teams are asked to approve it after design choices have already been made. That is backwards. IPv6 changes addressing, neighbor discovery, router advertisements, firewall policy, logging, scanning assumptions, asset discovery, VPN behavior, and incident response. Security needs to be built into the transition plan from the start.

The first risk is shadow IPv6. Many operating systems support IPv6 by default. Devices may create link-local IPv6 addresses even when the organization thinks it is “IPv4-only.” If firewalls, endpoint tools, and monitoring systems ignore IPv6, traffic may exist outside normal visibility. Disabling IPv6 everywhere is sometimes used as a quick control, but it delays readiness and may break modern services. A better approach is explicit policy: know where IPv6 is allowed, where it is blocked, how it is monitored, and who owns it.

The second risk is inconsistent filtering. Teams may carefully manage IPv4 firewall rules but leave IPv6 rules permissive or untested. Public cloud security groups may differ between IP versions. On-premises firewalls may need separate IPv6 policy objects. Load balancers may expose AAAA records before backend controls are ready. A service that is private over IPv4 but public over IPv6 is a real failure mode.

The third risk is poor logging. Incident response depends on accurate addresses. IPv6 addresses are longer, often shortened in notation, and may include privacy extension behavior. Systems must normalize and store them. NAT64 and CGNAT add translation logs. Without correct timestamps, ports, prefixes, and correlation, investigations become weaker.

The fourth risk is scanning mentality. IPv4 networks are small enough to scan routinely. IPv6 subnets are too large for brute-force scanning in the same way. Asset discovery must rely more on IPAM, DNS, DHCPv6 or SLAAC data, network telemetry, endpoint inventory, flow logs, and control-plane integration. Attackers adapt too; they use DNS names, certificate transparency, application leaks, and predictable addressing patterns rather than blind scanning of huge ranges.

The fifth risk is training. Many security professionals can read IPv4 quickly but hesitate over IPv6 notation, prefix lengths, extension headers, ICMPv6, neighbor discovery, router advertisements, and multicast behavior. That gap causes bad decisions. ICMPv6, for example, cannot be blocked blindly without breaking core IPv6 functions. Teams need protocol knowledge, not superstition.

The safe transition is not “turn on IPv6 and hope.” It is “make IPv6 a first-class security domain.” That means policy, tooling, tests, runbooks, and accountability across both protocols.

Enterprise networks face an inventory problem first

For enterprises, the hardest part of IPv6 is often not packet forwarding. It is inventory. Large organizations rarely know every application, appliance, script, vendor dependency, firewall rule, monitoring probe, hard-coded address, VPN profile, partner connection, and database field that assumes IPv4. The transition exposes years of shortcuts.

A practical IPv6 program starts with facts. Which public services already have IPv6? Which DNS zones publish AAAA records? Which load balancers support dual stack? Which firewalls inspect IPv6 at the same depth as IPv4? Which SaaS providers support IPv6? Which partners require IPv4 allowlists? Which identity and access systems log IPv6? Which databases store IP addresses as strings too short for IPv6? Which monitoring tools test IPv6 reachability? Which incident response runbooks include IPv6 evidence?

The next layer is address planning. IPv6 abundance does not remove the need for structure. Enterprises still need prefix hierarchy, site allocation, environment separation, summarization, firewall zones, documentation, and IPAM. A messy IPv6 plan can create operational pain even when addresses are plentiful. Good planning makes routing, security policy, and troubleshooting easier.

Then comes public exposure. Many enterprises should start by making customer-facing websites, APIs, DNS, email gateways, VPN portals, and CDN-backed services reachable over IPv6. This provides external value without requiring every internal network to change at once. It also forces security and observability tools to mature.

Internal deployment can follow by segment. New networks are easier than old ones. New cloud environments, Kubernetes clusters, lab networks, and office sites can be built dual stack or IPv6-mostly. Legacy manufacturing systems, medical devices, building controls, and old appliances may remain IPv4 longer, but they should be documented rather than ignored.

Procurement is a powerful lever. Every new network product, security tool, SaaS contract, IoT platform, and enterprise application should be evaluated for IPv6 support. “Supports IPv6” should not mean a checkbox on a datasheet. It should mean feature parity: management, logging, APIs, policy, monitoring, high availability, documentation, and vendor support.

The enterprise lesson is direct: IPv6 migration is less a one-time network project than a cleanup of technical assumptions. The organizations that treat it that way will move steadily. Those that wait for a forced deadline will discover dependencies under pressure.

Mobile networks show the path to IPv6-mostly design

Mobile operators had strong reasons to move early. They serve huge device populations, manage centralized packet cores, control customer equipment more tightly than fixed broadband providers, and face intense address pressure. A smartphone usually does not need a unique public IPv4 address for inbound connections. It needs reliable outbound reachability, low latency, app compatibility, and roaming support.

That made IPv6-only or IPv6-mostly mobile designs attractive. Traffic to IPv6-capable services can stay native. Traffic to IPv4-only services can pass through NAT64/DNS64 or 464XLAT. The operator reduces public IPv4 demand while keeping app compatibility. Users rarely know unless an app embeds IPv4 literals, uses unusual protocols, or mishandles translation.

This model influenced the wider internet. When large mobile networks enabled IPv6, major content platforms had stronger incentives to serve IPv6. When phones generated large volumes of IPv6 traffic, CDNs, cloud platforms, analytics vendors, and app developers had to test IPv6 paths. Mobile adoption helped turn IPv6 from an engineering ideal into production traffic.

The mobile example also clarifies a misconception. IPv6 adoption does not require every device to be a public server. IPv6 gives devices globally unique addresses, but firewall policy can still block inbound traffic. Mobile networks can run IPv6 at scale without exposing every handset to unsolicited inbound connections. The difference is that address abundance no longer forces massive IPv4 sharing for normal outbound use.

The model is not perfect. Translation still requires capacity. Some legacy apps fail. Roaming and enterprise APNs can complicate design. Lawful intercept and logging systems need correct handling. Device support varies less than it once did, but old devices and embedded modules still exist. Yet the direction is clear: where operators control the environment and face strong growth pressure, IPv6-mostly designs win.

Fixed broadband can follow parts of this path, though it has different constraints. Homes contain more diverse devices, users expect port forwarding in some cases, and routers vary widely. Still, many fixed providers already deliver IPv6 prefixes while using IPv4 NAT or CGNAT. The gap is often not technical possibility but operational priority, customer-premises equipment quality, and support readiness.

Consumer broadband depends on the ISP more than the user

A home user cannot deploy public IPv6 alone if the internet provider does not offer it. The ISP must route IPv6, delegate prefixes, support customer routers, maintain DNS and reverse DNS practices where needed, monitor performance, train support staff, and avoid broken default configurations. Users can buy an IPv6-capable router, but access depends on the provider.

This creates uneven adoption by country and network. Some providers moved early and now carry large shares of IPv6 traffic. Others remain weak. Google’s IPv6 statistics showed global user access over IPv6 at 45.39% on 13 May 2026, while Internet Society Pulse reported that native IPv6 access to Google first exceeded 50% on 28 March 2026, reaching 50.10%.

Those numbers tell a mixed story. IPv6 is no longer niche. Around half of Google-visible users can reach Google over IPv6 on some days. At the same time, half cannot. Some countries are far above global averages; others remain very low. Measurements differ because each provider sees a different slice of the internet.

For consumers, the best outcome is boring: IPv6 should work by default, IPv4 should remain available where needed, and applications should not care. If IPv6 is broken, users blame the internet, not the protocol. That is why providers must treat IPv6 quality as a production metric. Latency, packet loss, DNS behavior, routing, CDN mapping, and help-desk diagnostics all matter.

Users can check whether they have IPv6 through public test sites, router settings, or operating system network details. They can choose providers that support IPv6, request public IPv4 if they need inbound services, or use VPN and tunnel services for special cases. But the heavy lift belongs to the access network.

This has market consequences. Providers with strong IPv6 can reduce CGNAT pressure and improve future readiness. Providers without IPv6 may need more IPv4 purchases, heavier CGNAT, or more customer restrictions. In competitive markets, IPv6 support should become a quality signal. In less competitive markets, regulation or public procurement may need to push.

Content providers cannot wait for every access network

Content providers face the opposite side of the reachability problem. They do not control user access networks, but they can control whether their services are reachable over IPv6. For large public sites, APIs, SaaS platforms, media services, and e-commerce systems, IPv6 support is now a baseline expectation, not a novelty.

The reason is simple. If a user has good IPv6 and a service supports IPv6, traffic can avoid some IPv4 scarcity machinery. It may bypass CGNAT. It may map better to modern mobile networks. It may reduce pressure on public IPv4 load balancers. It may improve performance in networks where IPv6 is well engineered. It also signals operational maturity.

Content providers usually start with DNS and edge architecture. A CDN may make IPv6 easy for static content and web traffic. Load balancers may need dual-stack listeners. Origin servers may remain IPv4 for a while if the CDN terminates IPv6 at the edge, though full end-to-end IPv6 is cleaner. APIs need testing. Web application firewalls need IPv6 rules. Bot management needs IPv6 reputation handling. Logs need parsing. Rate limits need prefix logic.

Email is trickier. IPv6 email delivery exists, but reputation, reverse DNS, SPF, DKIM, DMARC, abuse handling, and receiver policy need care. Many senders continue to rely heavily on IPv4 for outbound mail because IPv4 reputation systems are mature and because poor IPv6 mail setup can cause deliverability problems. That does not mean IPv6 mail should be ignored. It means it should be deployed deliberately.

APIs and partner integrations also require attention. Many enterprise partners still provide IPv4 allowlists. Some webhook receivers do not accept IPv6. Some security vendors charge or configure separately for IPv6 ranges. Some old software libraries mishandle IPv6 literals or URL formatting. A content provider may be IPv6-ready for users but still IPv4-bound for back-office integrations.

The strategic point is that content providers should not wait for universal IPv6 access before enabling IPv6. That would create a stalemate. Access networks need content. Content networks need users. World IPv6 Launch in 2012 broke part of that stalemate by encouraging major providers, ISPs, and equipment manufacturers to enable IPv6 permanently.

The same logic still applies. Every major service that adds IPv6 improves the usefulness of IPv6 access. Every access network that adds IPv6 improves the value of IPv6 content. The transition moves through mutual reinforcement, not one final decree.

Governments and regulators can reduce friction

Governments cannot repeal IPv4 scarcity, but they can reduce transition friction. Public procurement can require IPv6 support in networks, software, hosting, security tools, and digital services. Telecom regulators can measure and publish IPv6 adoption. Cybersecurity agencies can publish guidance for secure IPv6 deployment. Digital government portals can serve IPv6. Education and research networks can train engineers. Spectrum and broadband programs can include IPv6 readiness in technical expectations.

The public sector has leverage because it buys technology at scale. If government contracts require real IPv6 support, vendors improve. If public websites and APIs support IPv6, citizens and businesses get more IPv6-reachable services. If regulators publish network-level adoption data, market pressure increases. If national cybersecurity guidance treats IPv6 as ordinary, not exotic, security teams become less likely to block it blindly.

Policy should avoid simplistic mandates that ignore operational reality. A rule saying “turn on IPv6 by date X” without testing, training, funding, or procurement standards may create checkbox deployments. A better approach defines measurable outcomes: public services reachable over IPv6, ISP adoption reporting, equipment certification, government network readiness, incident response support, and procurement language with feature parity.

There is also a development dimension. Regions with limited IPv4 holdings face higher barriers to internet growth. If new ISPs, hosting providers, universities, and startups must pay scarce-address prices while incumbents elsewhere hold historical allocations, the playing field is uneven. IPv6 can reduce that structural disadvantage, but only if deployment is treated as infrastructure policy rather than optional modernization.

Regulators should also understand CGNAT side effects. Shared IPv4 addresses affect consumer rights, competition, lawful attribution, abuse response, and service quality. A provider that puts users behind CGNAT without IPv6 may deliver a more limited internet connection than one that provides IPv6 plus clear options for public IPv4 where needed. Transparency matters. Customers should know whether they receive public IPv4, CGNAT, IPv6 prefix delegation, or paid static address options.

The right policy target is not to preserve IPv4 forever. It is to keep the internet open, reachable, competitive, and secure while IPv6 becomes the default growth path.

Slovakia and Central Europe sit inside the RIPE scarcity zone

For Slovakia and neighboring Central European markets, the relevant registry is the RIPE NCC, which serves Europe, the Middle East, and parts of Central Asia. That means the regional IPv4 free pool story is clear: RIPE NCC exhausted its remaining IPv4 pool in November 2019 and no longer has fresh, unused IPv4 addresses for normal growth. RIPE NCC still operates mechanisms such as waiting lists and transfers, but the old allocation model is gone.

This matters for Slovak ISPs, hosting companies, SaaS providers, agencies, enterprises, and public institutions. A local organization that needs more IPv4 space will likely face the same choices as others in the RIPE region: transfer market, provider assignment, cloud inventory, internal reclamation, or IPv6 deployment. None is as simple as requesting a large fresh block from a deep pool.

The business implication is practical. Slovak websites, e-shops, SaaS tools, media services, public-sector portals, and agencies should support IPv6 even if much of the local audience still uses IPv4. Their audience is not only domestic. Google, mobile users, international visitors, crawlers, partners, and cloud traffic may arrive over IPv6. At the same time, local access providers and enterprise networks need to improve IPv6 reachability so domestic users do not remain locked into IPv4 scarcity.

For small businesses, the first steps are not exotic. Choose hosting and CDN providers with IPv6 support. Make DNS dual stack where the platform supports it. Verify that web, API, and mail infrastructure behaves correctly. Ensure analytics and security tools log IPv6 addresses. Avoid buying equipment or services that treat IPv6 as an afterthought. Ask ISPs about IPv6 prefix delegation and static options. These choices compound.

For larger Slovak enterprises, the RIPE context should shape planning. New offices, cloud environments, VPN platforms, and public services should be built with IPv6 support. Internal IPv4 cleanup should begin before it becomes urgent. Procurement should demand IPv6 feature parity. Security teams should include IPv6 in controls and tests. Public institutions should treat IPv6 as part of digital sovereignty and service availability.

The local story is the global story in miniature: IPv4 scarcity is already here, IPv6 adoption is uneven, and the organizations that move early will face less pressure later.

The next five years will not be a shutdown

A realistic five-year forecast starts with continuity. IPv4 will still be widely used in 2031. Many websites will still serve IPv4. Many enterprises will still run internal IPv4. Many access networks will still support IPv4 through NAT or CGNAT. Many security tools will still display IPv4 first. Some legacy systems will remain IPv4-only because nobody wants to touch them.

The change will be in defaults. More mobile and broadband networks will carry larger IPv6 shares. More cloud services will charge for public IPv4 or encourage IPv6-only designs. More SaaS platforms will support IPv6 because customers and governments demand it. More new architectures will avoid public IPv4 per workload. More IPv4-only assumptions will break during audits and migrations.

IPv6 will likely pass more public milestones. Google-visible IPv6 already crossed 50% on a specific day in March 2026 according to Internet Society Pulse, even if daily and weekly numbers move. Google’s own public measurement showed 45.39% total IPv6 on 13 May 2026. The direction is clear: IPv6 is no longer marginal. It is a major share of global internet use.

The hard part is the lagging half. Some countries, providers, enterprise networks, and hosting environments remain low. Their reasons vary: old equipment, lack of demand, weak competition, limited expertise, low priority, vendor gaps, regulatory silence, or fear of security mistakes. The result is a long tail of IPv4 dependency.

This long tail means IPv4 will keep value. Public services that want full reach still need IPv4. Translation systems still need IPv4 pools. Cloud providers still need public IPv4 inventory. Email senders still care about IPv4 reputation. Enterprises still maintain IPv4 allowlists. The market may soften or fluctuate, but reachability keeps demand alive.

The better five-year prediction is not “IPv6 replaces IPv4.” It is IPv6 becomes the normal path for more traffic, while IPv4 becomes a paid, shared, translated, or legacy path. That is already happening. The question is how quickly each network segment moves.

For users, the transition may feel uneventful. For operators, it will shape budgets, architecture, procurement, and staffing. For policymakers, it will affect competition and digital infrastructure. For businesses, it will separate those that planned from those that discover IPv4 dependency during a crisis.

The real deadline is reachability

The most useful deadline is not the date the last IPv4 address is sold. It is the date when an organization’s services, customers, employees, partners, or devices cannot grow cleanly because of IPv4 dependency. That date may already have passed for some networks. For others, it may be years away. But every organization can measure warning signs.

One sign is public IPv4 cost. If cloud bills, hosting contracts, or broker quotes are shaping architecture, IPv4 scarcity is already a business constraint. Another sign is CGNAT complaints. If users need paid public IP options for normal applications, scarcity is affecting product quality. Another sign is overlapping private IPv4 space. If mergers, VPNs, and cloud networks require awkward translation, internal IPv4 exhaustion is real. Another sign is vendor delay. If a critical product still lacks IPv6 support, future options are constrained.

Reachability is the core requirement. Can customers reach the service? Can employees reach internal systems? Can devices connect securely? Can partners integrate? Can logs identify activity? Can security policy apply consistently? Can growth happen without buying scarce addresses? These questions matter more than abstract protocol preference.

IPv6 readiness should therefore be assessed service by service. A corporate homepage with IPv6 is useful but not enough. APIs, authentication, payment flows, CDN configuration, WAF rules, mobile apps, webhooks, DNS, email, VPN, monitoring, and support workflows all need review. A single IPv4-only dependency may force a larger system to keep IPv4 longer than expected.

The same applies to access networks. Advertising IPv6 is not enough if routing is poor, DNS fails, customer routers break prefix delegation, or support teams tell users to disable IPv6. Quality matters. Users and applications follow the path that works.

The internet does not reward protocol ideology. It rewards reachability that works. IPv6 wins when it works better, cheaper, and more predictably than stretching IPv4. The transition accelerates when that is true for enough users and services.

A practical migration plan for organizations

The practical answer after IPv4 exhaustion is not panic. It is a staged plan. The first stage is inventory. Count public IPv4 addresses, cloud public IPs, NAT gateways, load balancers, VPN endpoints, firewall rules, DNS A records, partner allowlists, internal private ranges, and applications that store or validate IP addresses. Include shadow environments and old projects. Most organizations find waste.

The second stage is public IPv4 cleanup. Remove unused addresses. Consolidate public ingress. Put services behind shared load balancers or CDNs where appropriate. Replace public administrative access with private connectivity, zero-trust access, or VPN designs. Review NAT gateway usage. Fix old DNS records. This saves money and reduces attack surface even before IPv6 expands.

The third stage is IPv6 at the edge. Enable IPv6 on websites, APIs, CDN zones, authoritative DNS, public load balancers, and monitoring checks. Test from multiple networks. Make sure WAF, DDoS protection, bot management, rate limiting, analytics, and logs handle IPv6. Do not publish AAAA records before the security path is ready.

The fourth stage is operational parity. Add IPv6 to runbooks, dashboards, alerts, incident response, vulnerability scanning, asset inventory, IPAM, configuration management, and support scripts. Train network, security, platform, and application teams. Create test cases for dual-stack behavior and IPv6-only clients.

The fifth stage is internal design. Decide where dual stack makes sense and where IPv6-only or IPv6-mostly is better. New cloud environments may be easier to build IPv6-first. Legacy networks may stay dual stack or IPv4-only until replacement. Avoid forcing every old system through a risky conversion at once. Prioritize growth areas.

The sixth stage is procurement. Require IPv6 feature parity from vendors. Ask for evidence, not promises. Can the product manage IPv6 policies? Does its API support IPv6 objects? Does logging preserve full addresses? Does support understand IPv6? Does licensing differ? Does the product work in IPv6-only environments with NAT64?

The seventh stage is measurement. Track the share of user traffic over IPv6, the number of public IPv4 addresses, cloud IPv4 charges, CGNAT complaints, IPv6 incidents, partner dependencies, and services with AAAA records. Use these metrics to prove progress.

Post-exhaustion operating models

These models often coexist inside one organization. The right question is not which model is purest, but which model gives each service reliable reach with the lowest long-term complexity.

The migration plan should be owned by both technology and business leadership. IPv4 scarcity affects cost, risk, customer experience, acquisitions, vendor selection, and product reach. Treating it as a narrow network task almost guarantees slow movement.

The metrics that show real progress

IPv6 progress can be faked with easy numbers. An organization may say it has IPv6 because one website supports it. An ISP may say IPv6 is available because a small customer segment has it. A vendor may say it supports IPv6 because the data plane works while management, logging, and APIs remain IPv4-only. Better metrics are needed.

For a content provider, useful metrics include the share of traffic served over IPv6, percentage of public hostnames with AAAA records, IPv6 error rates, latency by protocol, CDN IPv6 coverage, bot and abuse decisions by IP version, and support tickets tied to IPv6. For an ISP, useful metrics include percentage of subscribers with IPv6, percentage of traffic over IPv6, prefix delegation success, router model compatibility, CGNAT load, IPv4 port pressure, and customer complaints. For an enterprise, useful metrics include public IPv4 count, IPv6-enabled services, internal IPv6 segments, vendor readiness, security control parity, and incident response coverage.

Global measurements also need interpretation. Google measures users reaching Google over IPv6. APNIC Labs measures IPv6 capability through its own method. Cloudflare measures traffic to Cloudflare-enabled properties. Internet Society Pulse aggregates and explains deployment indicators. These views differ because they see different slices of the internet. None is the single truth; together they show direction and unevenness.

The most valuable internal metric may be the shrinking role of IPv4 in new growth. Are new applications launched with IPv6 support by default? Are new cloud networks designed without public IPv4 per instance? Are new vendors required to support IPv6? Are new customer access services IPv6-capable? Are new security rules created for both protocols? If the answer is yes, transition is real.

A second useful metric is cost avoidance. How much public IPv4 spend was removed? How many addresses were reclaimed? How many NAT gateways were eliminated or right-sized? How many services moved behind IPv6-capable edges? This turns IPv6 into measurable business value.

A third metric is failure reduction. Fewer CGNAT complaints, fewer overlapping-address incidents, fewer geolocation errors after address transfers, fewer IPv4 allowlist emergencies, and fewer public IP exposures all show progress.

IPv6 maturity is not a badge. It is a measurable reduction in IPv4 dependency without breaking reachability.

The internet after IPv4 scarcity will be less symmetrical

The post-exhaustion internet will not be uniform. Some networks will be IPv6-rich and IPv4-light. Some will remain IPv4-heavy. Some will use translation heavily. Some will keep dual stack for decades. Some countries will lead; others will lag. Some cloud platforms will make IPv6 easy; some services will still require IPv4. Some enterprises will modernize; others will carry old assumptions.

This unevenness will shape user experience. A user on a strong IPv6 mobile network may reach major platforms natively, while a local enterprise portal remains IPv4-only. A developer may build an IPv6-ready service but depend on third-party APIs that still require IPv4 allowlists. A small ISP may want IPv6 but struggle with old customer routers. A security vendor may inspect IPv4 deeply but treat IPv6 as a basic pass-through. These mismatches are the transition.

The internet has handled uneven transitions before: HTTPS, DNSSEC, RPKI, HTTP/2, HTTP/3, TLS 1.3, and BGP security improvements all moved at different speeds. IPv6 is harder because it sits below so much else and because IPv4 remains functional. A broken security protocol creates urgency. A scarce address protocol creates chronic pressure.

Chronic pressure is easier to postpone. That is why IPv6 took so long. NAT made postponement possible. Address markets made postponement purchasable. Cloud abstraction made postponement invisible. But postponement is now less attractive because the costs are clearer: public IPv4 charges, CGNAT limitations, internal overlap, market prices, compliance logging, and growth constraints.

The likely end state is not a ceremonial retirement of IPv4. It is a gradual loss of relevance. IPv4 will remain where needed, but fewer new systems will depend on it as the primary design assumption. IPv6 will carry more ordinary traffic. Translation will bridge the remaining gaps. Public IPv4 will be reserved for compatibility, edge services, special customers, and legacy dependencies.

That future is already visible in mobile networks, cloud architectures, and global traffic measurements. It is not evenly distributed, but it is not theoretical.

The short answer for readers asking when IPv4 will run out

The short answer is this: IPv4 addresses have already run out at the global free-pool level. IANA’s central free pool was exhausted in 2011. In the RIPE region covering Europe, including Slovakia, RIPE NCC exhausted its remaining IPv4 pool in November 2019. Other regional registries reached their own exhaustion or rationing stages at different times. What remains is not abundant new IPv4. It is rationed, recovered, transferred, leased, reclaimed, or sold.

What happens next is not an internet shutdown. Existing IPv4 addresses keep working. Websites keep serving IPv4. ISPs keep using NAT and CGNAT. Cloud providers keep assigning public IPv4, often for a fee. Address brokers keep moving blocks between organizations. But the growth path shifts.

IPv6 is what comes after IPv4 scarcity. It is not coming as a sudden replacement. It is arriving through dual stack, IPv6-only mobile networks, NAT64/DNS64, 464XLAT, cloud IPv6 support, public-sector procurement, and gradual application readiness. The more IPv6 grows, the less pressure falls on IPv4. The less IPv6 grows, the more networks must pay for, share, and work around scarce IPv4.

For users, the right expectation is continuity with occasional symptoms: CGNAT, public IP surcharges, gaming or hosting limits, VPN quirks, and better IPv6 support from modern providers. For businesses, the right response is active planning: audit public IPv4 use, enable IPv6 at the edge, demand vendor support, update security tooling, and build new networks with IPv6 in mind.

The internet is not running out of addresses in the sense that it cannot grow. It ran out of old-style IPv4 abundance. The next phase depends on how quickly networks stop treating IPv6 as optional.

Address abundance does not remove the need for discipline

IPv6 solves the address-count problem, but abundance can create its own mistakes. A network with a poor IPv6 plan can become harder to operate than a constrained IPv4 network. Prefixes may be assigned without hierarchy. Firewall rules may become inconsistent. DNS may drift. Monitoring may ignore half the paths. Engineers may choose memorable but structurally bad addressing shortcuts. Security teams may be handed a huge address space with little context.

Good IPv6 design keeps hierarchy. A provider aggregates. An enterprise maps prefixes to regions, sites, environments, and zones. A cloud team documents which prefixes belong to which accounts and workloads. A security team understands where boundaries are enforced. An operations team can look at an address and infer something useful without relying on tribal knowledge.

Address abundance also changes scanning and asset management. In IPv4, many teams discover assets by scanning known ranges. In IPv6, that method is insufficient. The address space inside a single /64 is too large for ordinary brute-force discovery. That pushes organizations toward authoritative inventory: DHCPv6 logs where used, SLAAC monitoring, router neighbor tables, DNS records, endpoint agents, cloud APIs, certificate logs, load balancer inventories, and IPAM integration.

Privacy extensions add another layer. Client devices may rotate interface identifiers to reduce tracking. That is good for users, but logs and policies need to account for changing addresses within stable prefixes. Security teams must learn to reason about prefixes, devices, identities, and sessions rather than assuming one IP equals one host forever.

For service providers, abundance does not mean careless delegation. Prefix size choices affect customer experience. Residential users may need enough space for multiple internal networks. Business customers may need stable delegations. Renumbering should be avoided where possible. Customer-premises equipment must handle prefix changes gracefully. Support teams need scripts and diagnostics.

IPv6 also depends heavily on ICMPv6 for normal function. Blocking it blindly breaks path MTU discovery, neighbor discovery, and other behavior. This is a common IPv4 habit that does not transfer cleanly. A secure IPv6 network filters intelligently rather than copying old “block ICMP” folklore.

The lesson is balanced: IPv6 removes artificial address scarcity, but it does not remove engineering responsibility. The organizations that deploy it well will gain simpler growth. Those that deploy it carelessly will replace one problem with another.

IPv4 exhaustion changed the meaning of public internet

In the early public internet, a public IP address suggested direct reachability. A server had an address. A client could connect to it if routing and policy allowed. That model still exists for servers, but for many users the public internet now sits behind layers. A household may have private IPv4 behind a home router, then shared IPv4 behind a provider CGNAT. A mobile user may have IPv6 natively and IPv4 through translation. A cloud workload may have no public address at all, only a load balancer, proxy, or outbound NAT.

This layered reality changes product design. Applications should not assume inbound reachability. Peer-to-peer features need relay options. Remote access should use brokered or identity-aware systems. Customer support should understand public versus private versus shared addresses. Security products should correlate identity, device, session, and network signals rather than leaning too heavily on public IPv4.

At the same time, IPv6 reopens the possibility of direct addressing. That does not mean every device should accept inbound connections. It means policy can decide, rather than address scarcity deciding. A home user could host a service if the ISP delegates a stable prefix and the router firewall allows it. An enterprise could address internal systems cleanly across sites without overlapping private ranges. An IoT deployment could use structured prefixes instead of NAT mazes.

The public internet is becoming more policy-defined and less address-defined. IPv4 scarcity forced sharing. IPv6 allows reachability, but firewalls and identity systems govern access. This is healthier than confusing NAT with security. It separates the question “does this node have an address?” from “is this traffic allowed?”

That distinction matters for the next decade. A secure IPv6 internet is not one where every device is exposed. It is one where every device can be addressed within a clear policy model. Scarcity should not be the thing protecting users. Security architecture should.

Legacy systems will keep IPv4 alive inside companies

Even after public traffic shifts toward IPv6, internal IPv4 will linger. Industrial control systems, printers, cameras, medical equipment, building management systems, old UNIX hosts, licensed appliances, storage arrays, backup systems, and vendor-managed devices may remain IPv4-only for years. Some cannot be upgraded. Some are certified only in existing configurations. Some are too risky to touch. Some vendors no longer exist.

This does not invalidate IPv6 migration. It means migration plans need containment. Legacy IPv4 segments can be isolated, monitored, proxied, or translated where necessary. New systems should not be forced to inherit old constraints. The mistake is allowing a small number of old dependencies to block every new IPv6-capable design.

Enterprises should classify legacy IPv4 systems by risk and role. Is the system business-critical? Is it externally reachable? Does it require partner access? Can it sit behind an application proxy? Can it be replaced during the next hardware cycle? Does it use hard-coded IP addresses? Does it support DNS names? Is there a vendor roadmap? This inventory turns vague fear into a plan.

For some systems, IPv4 will remain indefinitely inside a controlled zone. That is acceptable if the zone is documented, segmented, and not allowed to dictate the architecture of modern services. For other systems, replacement is cheaper than prolonged translation complexity. For still others, dual stack may be possible after firmware or OS upgrades.

The end of IPv4 dependence will not be uniform inside companies. Public web services may be IPv6-ready while internal manufacturing remains IPv4. Cloud-native products may be IPv6-mostly while corporate VPNs remain IPv4. The goal is not ideological purity. The goal is to prevent legacy IPv4 from blocking growth and increasing risk.

IPv4 should become a managed exception, not an inherited default.

The business case is now stronger than the technical argument alone

For years, IPv6 advocates led with technical necessity: IPv4 has too few addresses, IPv6 has enough. The argument was correct, but many organizations postponed action because NAT worked and customers did not demand IPv6. The stronger case now combines cost, risk, growth, and competition.

Cost is clearer because public IPv4 addresses have market prices and cloud charges. Risk is clearer because CGNAT, overlapping private ranges, and IPv4 reputation problems affect operations. Growth is clearer because new users, devices, cloud workloads, and markets cannot depend on abundant IPv4. Competition is clearer because providers with good IPv6 can scale more cleanly.

There is also a talent and process case. Organizations that delay IPv6 also delay staff learning. When a forced migration arrives, they lack experience. The first IPv6 incident happens during a production emergency. Security teams improvise. Vendors disappoint. Logs fail. This is avoidable. Running IPv6 in controlled phases builds muscle.

For digital agencies, hosting companies, SaaS vendors, and e-commerce platforms, IPv6 readiness can become a credibility signal. It shows that the provider understands modern infrastructure, international reach, mobile networks, and search crawler access. It also avoids embarrassing exclusions where users on IPv6-preferred networks hit slower or more fragile paths.

For CFOs, the business case should not be framed as “buy a new protocol.” It should be framed as reducing dependency on a scarce paid resource, avoiding future migration pressure, improving reachability, and cleaning up network exposure. IPv6 deployment can pair with cloud cost management, zero-trust access, CDN modernization, DNS cleanup, and asset inventory. It fits into work the organization should already be doing.

For CEOs and boards, the risk is strategic complacency. IPv4 will keep working long enough to make delay tempting. Then costs and constraints appear in scattered places: cloud bills, acquisition integration, customer support, market expansion, security tooling, and vendor selection. A planned transition is cheaper than a rushed one.

IPv6 deployment must include DNS

DNS is where many IPv6 rollouts become real. Publishing an AAAA record tells IPv6-capable clients they may connect over IPv6. If the service path is broken, users suffer. If the service path is fast and secure, users benefit. DNS is the switchboard of dual-stack reachability.

A good rollout starts with authoritative DNS support. The DNS provider itself should be reachable over IPv6. Zone management should support AAAA records. Monitoring should check both A and AAAA paths. TTLs should be chosen to support safe rollback during early phases. CDNs and load balancers should be configured consistently.

Reverse DNS matters for some services, especially mail and network operations. IPv6 reverse zones are different and can be more tedious because of nibble format. Automation helps. IPAM integration helps more. Manual reverse DNS management does not scale well in large IPv6 deployments.

DNS64 adds another role in IPv6-only networks. It synthesizes AAAA records from A records so IPv6-only clients can reach IPv4-only servers through a translator. That behavior is powerful but must be understood. Some DNSSEC-validating scenarios require care. Some applications that use literal IPv4 addresses bypass DNS and therefore bypass DNS64. Teams must know which path a connection uses before troubleshooting.

DNS-based traffic steering also changes. CDNs, global load balancers, and geo-routing systems need accurate IPv6 client handling. If geolocation databases are poor for IPv6, users may be sent to suboptimal locations. If monitoring tests only IPv4, IPv6 failures may go unnoticed. If health checks differ by protocol, DNS may publish a path that is healthy for one protocol and broken for another.

IPv6 without DNS discipline is not production readiness. The protocol may route, but users reach names, not address plans.

The role of RPKI, routing and address legitimacy

IPv4 scarcity increased the value of address blocks, which increases the importance of routing security and registration accuracy. If an address block is worth money, hijacks, mistaken announcements, stale records, and fraudulent transfers become more costly. IPv6 does not remove routing risk; it expands the set of prefixes that need correct management.

Resource Public Key Infrastructure, or RPKI, allows address holders to create route origin authorizations that state which autonomous systems may originate specific prefixes. This helps networks reject invalid route announcements when route origin validation is deployed. In an address market with transfers and changing holders, keeping RPKI records current matters.

Routing databases and registry records also matter. A transferred IPv4 block may need updated WHOIS registration, route objects, abuse contacts, reverse DNS, and RPKI ROAs. If those are wrong, traffic may fail, filters may block announcements, abuse reports may go to the wrong party, and trust may suffer. Address due diligence is therefore operational, not just legal.

For IPv6, good aggregation is a major benefit. The huge address space allows hierarchical assignment that can reduce routing table growth if operators plan well. Wasteful deaggregation can still happen. Multihoming, traffic engineering, DDoS mitigation, and business needs may create more-specific announcements. The address space is large, but the global routing system still benefits from discipline.

This is another reason IPv6 deployment should involve senior network engineers, not just application teams. Addressing and routing decisions made early can last for decades. A poor prefix plan becomes hard to unwind. A good plan gives clean summarization, policy boundaries, and operational clarity.

The internet after IPv4 scarcity will depend on both address abundance and route legitimacy. The two should move together.

Consumer devices and routers are a quiet bottleneck

IPv6 support depends heavily on customer-premises equipment. A broadband provider may run IPv6 in its core, but if home routers mishandle prefix delegation, firewall defaults, firmware updates, DNS, or Wi-Fi integration, users get a poor experience. The same applies to small-business firewalls and low-cost routers.

The home router is where many assumptions meet: ISP provisioning, DHCPv6 prefix delegation, SLAAC, DNS resolver behavior, firewall policy, UPnP expectations, guest networks, mesh Wi-Fi, parental controls, IoT devices, and support scripts. If the router gets IPv6 wrong, users may see intermittent failures that are hard to explain.

Equipment manufacturers therefore matter. World IPv6 Launch included home networking equipment makers because access alone was not enough. Routers needed IPv6 enabled by default and implemented correctly. That remains true. A technically ready ISP can still be slowed by old installed equipment.

IoT devices create another challenge. Some support IPv6 well. Some do not. Some use cloud relays and never need inbound reachability. Some assume IPv4 literals. Some have poor update mechanisms. Some sit on networks for a decade. The consumer transition is therefore uneven at the device layer too.

For small businesses, the router or firewall replacement cycle is a chance to fix this. Buying equipment without full IPv6 support in 2026 is buying future friction. The same applies to managed service providers: IPv6 should be part of standard network templates, not a special request.

A hidden bottleneck is help-desk training. If support agents respond to every strange problem by telling users to disable IPv6, adoption suffers. Sometimes disabling IPv6 hides a real provider or router bug. Sometimes it creates a slower path. Better diagnostics are needed: check prefix delegation, DNS, routing, MTU, firewall, and protocol-specific reachability.

The consumer internet becomes IPv6-ready only when the boring devices are ready. Routers, modems, set-top boxes, firewalls, printers, cameras, and support scripts matter as much as core routers.

Developers need to stop assuming IPv4 literals

Application code can preserve IPv4 dependence long after networks support IPv6. Common mistakes include storing IP addresses in fields too short for IPv6, validating only dotted-decimal formats, using IPv4 literals in configuration, binding services only to 0.0.0.0, failing to listen on ::, mishandling bracketed IPv6 literals in URLs, assuming one IP per user, or using regex patterns that reject valid IPv6 notation.

These are not glamorous problems, but they break real deployments. A database column sized for 15 characters cannot store an IPv6 address. A firewall automation script that accepts only IPv4 CIDRs cannot manage dual-stack policy. A logging parser that splits on colons may mangle IPv6. A rate limiter that keys on a full IPv6 address may be useless. A UI that truncates addresses may hamper incident response.

Developers should use proper IP address libraries, not hand-written parsers. They should store addresses in binary or sufficiently large normalized formats. They should test with IPv6-only networks, dual-stack networks, and NAT64 environments. They should avoid embedding IP literals where names should be used. They should design allowlists and rate limits around prefixes and identities where appropriate.

Containers and microservices add their own layers. Some clusters are IPv4-only by default. Some support dual stack. Some CNI plugins handle IPv6 better than others. Service meshes, ingress controllers, observability agents, and network policies must be checked. A platform team may enable IPv6 at the cluster level only to discover that a sidecar, plugin, or vendor tool assumes IPv4.

Testing matters. Developers often test from networks with strong IPv4 and no IPv6, missing IPv6-only users. A simple CI check that reaches services over IPv6 can catch many issues. Mobile testing should include IPv6-preferred networks. API clients should be tested against AAAA-enabled endpoints. Monitoring should alert on IPv6 failure separately.

The developer rule is straightforward: IP version should not be a hidden assumption in application code. Treat it as compatibility work, just like Unicode, time zones, and TLS versions. The sooner it is built in, the less dramatic the transition becomes.

The environmental angle is indirect but real

IPv4 exhaustion is not usually discussed as an energy issue, but network complexity has costs. Large NAT systems consume hardware, power, rack space, cooling, engineering effort, and operational attention. Duplicated dual-stack infrastructure can add complexity. Inefficient routing or translation paths can add latency and equipment load. These are not the main reasons to deploy IPv6, but they are part of the infrastructure picture.

IPv6 does not automatically reduce energy use. A poorly designed IPv6 network can waste resources. Dual stack can increase operational overhead during transition. Translation systems still consume capacity. Yet a mature IPv6 deployment can remove some pressure from CGNAT infrastructure, simplify address management, and reduce dependence on complex workarounds.

Cloud architecture adds another dimension. Public IPv4 minimization often pairs with private networking, shared ingress, edge consolidation, and better inventory. Those practices may reduce exposed resources and waste. IPv6-only subnets can support cleaner designs when platform support is mature. The sustainability benefit comes from disciplined architecture, not from the protocol alone.

The more concrete benefit is lifecycle efficiency. Networks designed for IPv6 growth are less likely to require emergency purchases of scarce IPv4, awkward NAT expansions, or repeated renumbering. Planning reduces churn. Reduced churn reduces waste.

This should not be oversold. IPv6 is primarily an addressing and reachability necessity. But infrastructure simplicity has operational and resource value, and IPv4 scarcity pushes networks toward complexity. That complexity has a cost beyond money.

The user question has a human answer

The user asking “when will IPv4 addresses run out, and what then?” usually does not want a registry lecture. They want to know whether something will break, whether they need to act, and whether IPv6 is now urgent. The honest answer depends on who they are.

For a normal home user, nothing dramatic happens on a specific date. Their ISP may already use CGNAT. Their phone may already use IPv6. Their router may already have IPv6 enabled. They should care if they need port forwarding, self-hosting, remote access, gaming features, or a static public address. They can ask their ISP whether they receive IPv6 and whether their IPv4 address is public or shared.

For a small business, action is worthwhile. Choose hosting, DNS, CDN, VPN, and security providers that support IPv6. Check whether the company website has IPv6. Make sure logs and analytics handle IPv6. Avoid paying for public IPv4 addresses out of habit. Ask vendors direct questions.

For a developer, the answer is to test applications in IPv6 and IPv6-only environments. Remove IPv4 assumptions. Use DNS names. Store addresses correctly. Make rate limiting and security controls prefix-aware.

For an ISP or hosting provider, the answer is strategic. IPv4 scarcity affects growth, support, pricing, and competitiveness. IPv6 is not optional for long-term scale. CGNAT can bridge, but it is not a clean future.

For policymakers, the answer is to measure adoption, require IPv6 in procurement, and treat shared IPv4 limitations as a quality and competition issue.

For everyone, the post-IPv4 world is not science fiction. It is the network they already use, only unevenly distributed.

IPv4 scarcity is a solved problem only for those who act

The technical solution to address scarcity exists. IPv6 has existed for decades, and it is now deployed at major scale. The operational solution is still incomplete because the internet is not one network. It is millions of networks, vendors, applications, contracts, habits, and incentives.

Scarcity creates two paths. One path keeps stretching IPv4 through NAT, CGNAT, transfers, leasing, address cleanup, and cloud charges. That path remains necessary in places, but it becomes more awkward as growth continues. The other path moves traffic, services, and new designs to IPv6 while maintaining IPv4 compatibility where needed. That path requires work, but it aligns with the internet’s size.

The correct posture is neither alarmism nor complacency. Alarmism is wrong because IPv4 will not vanish overnight. Complacency is worse because the easy years already ended. The organizations that wait for a single deadline will miss the real deadlines scattered through budgets, product launches, acquisitions, customer complaints, security audits, and cloud migrations.

IPv4 did not run out tomorrow. It ran out years ago. What remains is the transition bill. The sooner networks pay it through planned IPv6 deployment, the less they pay through scarcity workarounds.

Practical outlook for the rest of the decade

By the end of this decade, the internet will likely be more IPv6-heavy but still not IPv6-only. Major consumer platforms, mobile networks, CDNs, and cloud services will carry large IPv6 volumes. Public IPv4 will remain common at the edge because universal reach still requires it. New access networks will use more IPv6-mostly designs. More cloud services will encourage or require careful public IPv4 use. Address markets will continue, though prices may fluctuate.

The biggest risk is not that IPv6 fails. It is that adoption remains uneven enough to keep the internet paying for both scarcity and transition complexity longer than necessary. Uneven adoption burdens everyone: content providers maintain IPv4 for lagging networks, access providers maintain CGNAT for IPv4-only destinations, enterprises maintain dual policies, and users experience strange edge failures.

The biggest opportunity is that IPv6 deployment has crossed from theory to normal traffic. Around half of Google-visible users reached services over IPv6 at the March 2026 milestone reported by Internet Society Pulse. Google’s own public IPv6 statistics continue to show IPv6 as a large share of real access traffic.

The remaining work is practical. Make services reachable. Make tools IPv6-aware. Make security controls equal. Make procurement strict. Make public IPv4 use deliberate. Make new networks IPv6-first where possible. Make old IPv4 dependencies visible.

The internet has already chosen the direction. The pace is now an operational and economic decision.

Reader-focused answer in one paragraph

IPv4 addresses have already run out in the only sense that matters for new global supply: the central IANA pool was depleted in 2011, and regional registries later exhausted or rationed their remaining pools. Existing IPv4 addresses will keep working, and organizations can still get IPv4 through transfers, waiting lists, recovered blocks, leasing, cloud providers, or internal cleanup, but it is now scarce and often costly. What comes after is a long coexistence period where IPv6 carries more traffic, IPv4 remains for compatibility, NAT and CGNAT hide shortages, and modern networks move toward dual stack, IPv6-only, NAT64/DNS64, and 464XLAT. The internet will not stop; the growth model changes.

Questions readers ask about IPv4 exhaustion and IPv6

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

IANA IPv4 Address Space Registry
Official IANA registry showing the allocation of IPv4 address space to registries and special uses.

Free Pool of IPv4 Address Space Depleted
Number Resource Organization announcement from 3 February 2011 confirming depletion of the IANA IPv4 free pool.

What is IPv4 Run Out?
RIPE NCC explanation of IPv4 run-out in Europe, the Middle East and parts of Central Asia.

The RIPE NCC has run out of IPv4 Addresses
RIPE NCC announcement from November 2019 explaining the final allocation from its remaining IPv4 pool.

IPv4 Addressing Options
ARIN guidance on options after IPv4 free-pool depletion, including waiting lists, transfers and IPv6 adoption.

The IANA IPv4 Address Free Pool is now Depleted
ARIN archived announcement documenting the 3 February 2011 IANA free-pool depletion event.

IPv4 exhaustion
APNIC’s official page explaining IPv4 exhaustion, allocation limits and transfer options in the Asia Pacific region.

IPv6-Mostly: The Key Strategy in the Face of IPv4 Exhaustion
LACNIC article explaining the region’s formal IPv4 exhaustion status, waiting-list pressure and IPv6-mostly strategy.

AFRINIC enters IPv4 Exhaustion Phase 2
AFRINIC announcement describing the start of Exhaustion Phase 2 and the resulting policy limits.

AFRINIC IPv4 Exhaustion statistics
AFRINIC statistics portal for tracking available, reserved and policy-reserved IPv4 resources.

IPv4 Address Report
Geoff Huston’s IPv4 address report with current RIR pool status and historical exhaustion data.

Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA
ICANN policy describing the recovered IPv4 pool and post-exhaustion allocation mechanism.

RFC 791 Internet Protocol
Original IPv4 protocol specification defining 32-bit internet addresses.

RFC 8200 Internet Protocol, Version 6 Specification
Current IPv6 specification defining the 128-bit IPv6 address model.

RFC 1918 Address Allocation for Private Internets
Best Current Practice defining private IPv4 address space used inside enterprise and home networks.

RFC 4632 Classless Inter-domain Routing
CIDR address assignment and aggregation strategy for conserving IPv4 space and controlling routing growth.

RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space
Specification of 100.64.0.0/10 shared address space for carrier-grade NAT deployments.

RFC 6146 Stateful NAT64
Standards-track document describing NAT64 translation from IPv6 clients to IPv4 servers.

RFC 6147 DNS64
Standards-track document describing DNS64 synthesis of AAAA records from A records.

RFC 6877 464XLAT
Informational RFC describing the 464XLAT architecture for IPv4 service across IPv6-only networks.

RFC 8305 Happy Eyeballs Version 2
Specification for reducing user-visible delays on dual-stack hosts.

IPv6 Adoption
Google’s public measurement of the percentage of users accessing Google services over IPv6.

IPv6 Measurement Maps
APNIC Labs measurement dashboard tracking IPv6 capability by country and region.

18 Years Later, IPv6 Reaches Majority
Internet Society Pulse analysis of the March 2026 milestone when native IPv6 access to Google first exceeded 50%.

Enabling Technologies
Internet Society Pulse dashboard tracking current support for major enabling internet technologies including IPv6.

World IPv6 Launch
Archived World IPv6 Launch site documenting the 2012 permanent IPv6 enablement effort by ISPs, equipment makers and web companies.

New AWS Public IPv4 Address Charge and Public IP Insights
AWS announcement of public IPv4 address charging from February 2024 and the rationale tied to IPv4 scarcity.

Pricing updates for external IPv4 addresses in use by VMs
Google Cloud announcement of external IPv4 pricing changes for virtual machines.

IP addresses through 2025
APNIC Blog analysis of IPv4 and IPv6 allocation trends, including IPv4 market price behavior.

Cloudflare Radar 2025 Year in Review
Cloudflare analysis of global internet adoption and usage trends, including IPv6 adoption data.