When 20% of the Internet Went Dark: A Business Leader’s Guide to Understanding Infrastructure Risk

Executive Summary: What You Need to Know

Why Should a Non-Technical Leader Care About a “Technical” Outage?

Let me start with a simple scenario that probably happened in your organization on November 18, 2025. Your marketing team couldn’t access their design tools in Canva. Your customer service platform went dark. Your developers couldn’t reach ChatGPT or Claude to assist with coding. Your employees couldn’t book time off because the HR system was down. And if you operate retail locations, your self-service kiosks might have displayed error pages instead of taking orders.

All of these failures-across completely different companies and platforms-had a single root cause: Cloudflare, the invisible infrastructure company that routes approximately 20% of all internet traffic, experienced a catastrophic technical failure that lasted nearly six hours. Think of Cloudflare as the electrical grid for the modern internet. When the grid goes down, it doesn’t matter how well-designed your building is or how much you’ve invested in your operations-the lights simply won’t turn on.

In simple terms, cloud infrastructure providers like Cloudflare are the digital equivalent of utilities-invisible until they fail, but absolutely critical to business operations. They determine whether your customers can reach your website, whether your applications function properly, and whether your digital services remain accessible during crucial business hours. When they go down, your business goes down with them, regardless of how much you’ve invested in your own technology.

What makes this particular incident a watershed moment is not just its scale-though affecting hundreds of millions of users and causing billions in losses certainly qualifies-but what it reveals about the hidden architecture risks in modern business operations. We’ve consolidated so much of our digital infrastructure around a handful of providers that their failures now cascade across entire sectors of the economy simultaneously. Understanding this concentration risk and preparing for it is no longer optional-it’s a fundamental business continuity requirement.

In this guide, I’ll break down what happened on November 18, 2025, translate the technical complexity into business language, explain why this matters for your strategic planning, and provide a clear roadmap for protecting your organization from similar disruptions in the future. Let’s start by understanding how we arrived at this precarious situation.

How Did We Become So Dependent on a Handful of Infrastructure Companies?

To understand today’s infrastructure vulnerability, I need to take you back to the early days of the commercial internet in the 1990s. Imagine the internet as a small town where every business ran its own servers, managed its own security, and handled its own traffic routing. This approach worked fine when there were thousands of websites, but it required significant technical expertise and capital investment that most businesses couldn’t sustain.

From Individual Generators to a Shared Power Grid

As the internet exploded in scale-from thousands of websites to billions-a natural consolidation occurred. Companies like Cloudflare, Amazon Web Services, and Microsoft Azure emerged as the “electrical utilities” of the digital age. They offered to handle all the complex infrastructure work-security, speed optimization, traffic routing, DDoS protection-so businesses could focus on their core competencies rather than managing servers.

This shift was enormously beneficial. A small e-commerce startup could access the same enterprise-grade infrastructure as Fortune 500 companies for a fraction of the cost. Websites loaded faster. Security improved dramatically. The technical barriers to launching a digital business dropped considerably. Think of it like moving from every building having its own generator to everyone connecting to a reliable power grid-it was more efficient, more cost-effective, and generally more reliable.

However, this consolidation created a new category of risk that we’re only now fully appreciating. When everyone connects to the same grid, a failure in that grid affects everyone simultaneously. Twenty years ago, as infrastructure expert Mike Chapple notes, individual service outages were common-you might go a week with at least one IT service down. But each outage affected only that one company. Today, we’ve achieved remarkable aggregate reliability through consolidation, but we’ve created a new risk: when one of these infrastructure giants stumbles, 20% of the internet goes down at the same time.

The numbers tell the story of this concentration. Cloudflare alone handles 81 million HTTP requests per second under normal conditions. Approximately 35% of Fortune 500 companies depend on their services. About 32% of the 10,000 most-visited websites globally utilize their infrastructure. We’ve essentially put a substantial portion of the global digital economy on a single platform-which is wonderful for efficiency but terrifying for resilience.

What Actually Happened on November 18, 2025?

Let me translate the technical failure into a business analogy that captures what went wrong. Imagine you run a global logistics company with 330 distribution centers worldwide. Every five minutes, your central headquarters sends updated shipping instructions to all centers. These instructions are normally a manageable size-about 60 pages of directions.

The Configuration File That Grew Too Large

On the morning of November 18, a well-intentioned change to your database security settings inadvertently caused the system to pull shipping data from two sources instead of one. Suddenly, those instruction files doubled in size to over 200 pages-exceeding what your distribution centers were designed to handle. The system at each center tried to load these oversized instructions, exceeded its memory capacity, and crashed completely. No orders could be processed. No shipments could go out. The entire operation ground to a halt globally.

This is essentially what happened to Cloudflare. At 11:05 UTC, they made a routine database permissions change intended to improve security-the equivalent of upgrading your locks. This change triggered an unexpected consequence: a configuration file used by their Bot Management system began pulling duplicate data. The file size exploded from about 60 features to over 200 features. This oversized file was automatically distributed to all 330+ data centers within seconds via their rapid deployment system.

Why Speed Became the Enemy

Here’s where the efficiency gains of modern infrastructure became a liability. Cloudflare’s deployment system can propagate changes globally in approximately seconds-an impressive engineering achievement that enables rapid security responses. But this same speed means errors also propagate instantly across all data centers before human operators can intervene. By the time anyone noticed the problem at 11:31 UTC-just 11 minutes after the first errors appeared-the defective configuration had already been distributed worldwide multiple times.

Adding to the diagnostic complexity, the failure pattern was intermittent. Services would work for five minutes, then fail for five minutes, then work again. This alternating pattern mimicked the characteristics of a cyberattack, leading the incident response team to initially investigate the wrong cause. It took until 14:24 UTC-more than three hours after the outage began-to identify the root cause and stop the automated system from generating oversized configuration files.

The Human Cost of Technical Failure

The scope of disruption extended far beyond what you might expect from a “technical” problem. Major platforms like X (Twitter), ChatGPT, Spotify, Discord, Zoom, and Shopify all went offline simultaneously. But the really striking impacts were in physical businesses: McDonald’s restaurants couldn’t take orders through their kiosks. Daycares couldn’t check children in or out electronically. Transit systems lost their real-time information displays. Corporate employees couldn’t access HR systems to request time off.

Even the monitoring systems failed. DownDetector-the website people use to check if other sites are down-itself went offline because it also relied on Cloudflare. This created a surreal situation where users had no reliable way to confirm whether their problems were isolated or part of a broader outage, contributing to confusion and anxiety across social media platforms.

What Is the True Business Cost of Infrastructure Dependency?

When I discuss this incident with business leaders, the first question is always: “How much did this actually cost?” The answer reveals why infrastructure resilience must be a board-level concern, not just an IT issue.

The Hidden Multiplier Effect of Simultaneous Failure

Research on downtime costs shows that 93% of large enterprises experience downtime costs exceeding $300,000 per hour, while 48% report costs exceeding $1 million per hour. But these figures reflect individual company outages. When thousands of companies go offline simultaneously, the economic impact doesn’t add up-it multiplies.

Analysts estimate the aggregate economic damage at $5 to $15 billion per hour across all affected businesses. Over the six-hour duration, this translates to potential total losses in the hundreds of millions to several billion dollars. Let me break down where these costs accumulate:

The Forex Trading Sector: A Detailed Case Study

To make this concrete, consider the impact on foreign exchange and CFD brokers. These platforms facilitate approximately $1.58 billion in trading volume every three hours under normal conditions. During the Cloudflare outage, multiple brokers including Monaxa, Skilling, Xtrade, and FXPro experienced complete operational paralysis. Traders couldn’t access their positions, couldn’t execute trades, and couldn’t respond to market movements. The entire trading volume for that three-hour window-roughly equivalent to 1% of their typical monthly volume-simply evaporated.

Similarly, cryptocurrency exchanges reported significant declines in trading volumes during the peak outage period. NFT market activity contracted nearly to zero. Some blockchain Layer 2 networks that relied on Cloudflare for API connectivity became completely inaccessible, exposing the irony that “decentralized” applications often depend on centralized infrastructure.

Why “It’s Not Our Fault” Doesn’t Protect Your Business

Here’s the uncomfortable truth that keeps me up at night as an advisor: customers don’t care whose fault the outage was-they only care that your service didn’t work when they needed it. When your website displays a Cloudflare error page instead of loading properly, your brand takes the reputational hit, even though the technical failure occurred in infrastructure you don’t control.

This is why viewing infrastructure providers as “someone else’s problem” is a strategic mistake. Their reliability directly impacts your customer experience, your revenue, and your competitive positioning. Treating this as purely a technical concern rather than a business risk is like assuming your building’s foundation isn’t your concern because you’re not a structural engineer-until the day it cracks and everything above it fails.

What Should Smart Leaders Do Differently Going Forward?

The November 2025 Cloudflare outage offers several clear lessons for business leaders thinking strategically about infrastructure resilience. Let me translate these into an actionable roadmap.

Understanding the Three Mega-Trends Shaping Infrastructure Risk

Before we dive into specific recommendations, you need to understand three forces that are making infrastructure dependency both more valuable and more dangerous simultaneously:

The “Digital Backup Generator” Framework

Betsy Cooper, Founding Director of the Aspen Policy Academy, introduced a compelling analogy in analyzing this outage: “We need the equivalent of digital backup generators.” Just as hospitals and data centers maintain backup power systems for when the electrical grid fails, businesses need redundant infrastructure capabilities for when primary cloud providers experience disruptions.

What does this mean practically? It doesn’t mean running duplicate infrastructure for everything-that’s prohibitively expensive and complex. It means strategic redundancy for mission-critical services and rapid failover capabilities when primary systems fail.

A Leader’s 90-Day Action Plan

Here’s a concrete roadmap for improving your infrastructure resilience over the next quarter:

1️⃣ Conduct a Dependency Audit (Week 1-2): Map all critical business services and identify which infrastructure providers they depend on, including indirect dependencies through your software vendors. Create a visual “dependency map” showing single points of failure. Ask your technical team: “If Cloudflare/AWS/Azure went offline for six hours today, which of our services would fail?”

2️⃣ Calculate Your Exposure (Week 3-4): Quantify the business impact of infrastructure outages by estimating hourly revenue loss, productivity costs, and SLA penalties for each critical service. This becomes your business case for investing in resilience. Be realistic-assume outages will happen during peak business hours, not conveniently at 3am on a Sunday.

3️⃣ Implement Multi-Vendor Strategy for Critical Services (Week 5-8): For your highest-impact services, implement multi-CDN approaches with DNS-based load balancing and automatic failover. This doesn’t mean abandoning your primary provider-it means having a tested backup that activates automatically when the primary fails. Prioritize based on business impact, not technical complexity.

4️⃣ Establish Independent Monitoring (Week 9-10): Ensure your monitoring infrastructure doesn’t depend on the services being monitored. Use multiple monitoring providers in different data centers to detect outages quickly and differentiate between your issues and infrastructure provider issues.

5️⃣ Test Your Backup Plans (Week 11-12): Actually test your failover procedures under realistic conditions, not just document them. Schedule a “fire drill” where you deliberately switch to backup infrastructure and verify that everything works. Most disaster recovery plans look great on paper but fail their first real test.

6️⃣ Budget for Quality Over Price (Ongoing): The cheapest infrastructure option is rarely the best value when you account for downtime costs. Allocate resources for reliability features, redundancy capabilities, and proven incident response rather than optimizing purely on monthly fees.

The Contrarian Case: Why Cloudflare Stock Actually Looks Attractive

Here’s something that might surprise you: despite this catastrophic outage, I’d argue Cloudflare stock represents a reasonable investment at current levels around $196, down from its pre-outage price of $202. Why? Because the market reaction tells us something important about how investors assess infrastructure risk.

Cloudflare’s stock fell 7.0% at its worst point on November 18, but closed down just 2.8% after the company’s transparent communication and rapid service restoration. This relatively muted reaction-compare it to data breach incidents that can cause 20-30% declines-suggests investors view this as a recoverable operational incident rather than a fundamental company failure.

More importantly, the underlying financials remain strong. Q3 2025 revenue grew 31% year-over-year to $562 million, while net losses decreased dramatically from $15.3 million to just $1.3 million, showing clear movement toward profitability. With a majority of analysts maintaining “Buy” ratings, the market is essentially saying: “They screwed up, they owned it, they’re fixing it, and the long-term growth story remains intact.”

For business leaders, this teaches a valuable lesson about crisis response: transparency, rapid remediation, and concrete prevention measures can contain reputational damage even after spectacular operational failures. CEO Matthew Prince’s decision to personally author a detailed technical postmortem within 12 hours-including the actual code that failed-demonstrated the kind of accountability that rebuilds trust quickly.

As a Customer Service Specialist at InterLIR, I’ve witnessed firsthand how IPv4 address exhaustion impacts organizations worldwide. Every day, we help businesses navigate the complexities of IP address management, and one question increasingly dominates our conversations: how can companies transition to IPv6 while maintaining operational continuity? AWS Lambda’s recent introduction of dual-stack endpoints represents a significant milestone in this journey, offering a practical pathway for organizations to embrace IPv6 without abandoning their existing IPv4 infrastructure.

The serverless computing revolution has transformed how we build and deploy applications, but network connectivity has remained anchored to IPv4 protocols-until now. With AWS Lambda now supporting IPv6 through dual-stack endpoints, organizations have an opportunity to fundamentally reimagine their serverless networking architecture. This comprehensive guide examines the technical, operational, and financial implications of this transition, drawing on real-world implementation experiences and industry best practices.

Understanding the IPv4 Exhaustion Crisis and IPv6 Solution

The IPv4 address space, with its approximately 4.3 billion possible addresses, seemed limitless when first designed in the 1980s. Today, this limitation represents one of the most pressing infrastructure challenges facing the internet. At InterLIR, we’ve observed the IPv4 marketplace evolve dramatically as organizations compete for increasingly scarce address blocks, with prices reflecting this scarcity.

IPv6 fundamentally solves this problem through its 128-bit addressing scheme, providing approximately 340 undecillion unique addresses-a number so vast it’s difficult to comprehend. To put this in perspective, IPv6 offers enough addresses to assign billions of unique IPs to every person on Earth. This abundance eliminates the need for complex Network Address Translation (NAT) workarounds that have become standard practice in IPv4 networking.

For AWS Lambda users, the transition to IPv6 offers several compelling advantages beyond simple address availability:

From my experience supporting customers through infrastructure transitions, I’ve learned that understanding the “why” behind technical changes is just as important as understanding the “how.” The IPv6 transition isn’t merely a technical upgrade-it’s a strategic investment in long-term infrastructure sustainability.

IPv6 network architecture diagram showing Lambda functions bypassing NAT gateways

Architectural Transformation: How IPv6 Changes Lambda Networking

The introduction of IPv6 support fundamentally alters the architectural patterns we use for Lambda functions, particularly those deployed within Virtual Private Clouds. Understanding these changes is essential for making informed decisions about when and how to implement IPv6 in your serverless environment.

VPC Connectivity: The NAT Gateway Paradigm Shift

Traditionally, Lambda functions requiring internet access from within a VPC have relied on NAT Gateways-a necessary but expensive component of IPv4 networking. These gateways translate private IPv4 addresses to public ones, enabling outbound internet connectivity while maintaining security. However, this architecture introduces several challenges:

The financial implications become particularly significant at scale. Consider a Lambda function processing 1TB of outbound traffic monthly through a NAT Gateway. Under IPv4 architecture, this incurs approximately $77.40 in monthly charges ($32.40 base + $45.00 for data processing). With IPv6 using an egress-only internet gateway, these charges disappear entirely. For organizations running multiple high-traffic Lambda functions, annual savings can easily reach tens of thousands of dollars.

Dual-Stack Architecture: Best of Both Worlds

AWS Lambda’s implementation of IPv6 support uses a dual-stack approach, meaning functions can communicate using both IPv4 and IPv6 protocols simultaneously. This design choice is crucial for maintaining compatibility during the transition period. When a Lambda function with dual-stack enabled needs to communicate with an external service, it will:

1. Perform DNS resolution for the target service
2. Receive both A records (IPv4) and AAAA records (IPv6) if available
3. Prefer IPv6 connectivity when available
4. Fall back to IPv4 if IPv6 is unavailable or fails

This intelligent protocol selection ensures maximum compatibility while enabling organizations to benefit from IPv6 advantages wherever possible. In my work at InterLIR, I’ve seen how this approach reduces the risk associated with infrastructure transitions-a critical consideration for production environments.

Lambda Function URLs and Built-in IPv6 Support

One often-overlooked aspect of Lambda’s IPv6 implementation is that Function URLs are inherently dual-stack capable without any configuration changes. This means that if you’re using Lambda Function URLs to expose your functions as HTTP endpoints, IPv6 clients can already access them regardless of your VPC configuration.

This built-in capability operates independently of VPC settings because Function URLs are managed by AWS’s edge infrastructure, which already supports dual-stack networking. For many use cases, this means IPv6 support is already available without any migration effort-a pleasant surprise for organizations concerned about transition complexity.

Implementation Strategy: A Practical Roadmap

Implementing IPv6 support for Lambda functions requires careful planning and systematic execution. Based on successful customer implementations I’ve supported, here’s a comprehensive approach that minimizes risk while maximizing benefits.

Phase 1: VPC Infrastructure Preparation

The foundation of IPv6 support begins with your VPC configuration. This phase involves several critical steps that must be completed before enabling IPv6 on Lambda functions:

Assign IPv6 CIDR Block to VPC – Navigate to your VPC configuration in the AWS Console and add an IPv6 CIDR block. AWS offers three options: Amazon-provided IPv6 CIDR blocks (/56 prefix), blocks allocated through Amazon VPC IP Address Manager (IPAM), or bring-your-own-IPv6 addresses (BYOIP). For most organizations, the Amazon-provided option offers the simplest implementation path.

Configure Subnet IPv6 CIDR Blocks – Unlike IPv4 subnets which may already exist, IPv6 CIDR blocks must be manually assigned to each subnet. AWS automatically divides your VPC’s /56 IPv6 block into /64 subnet blocks. Each subnet receives a unique /64 block, providing 18 quintillion addresses per subnet-more than sufficient for any conceivable Lambda deployment.

Create Egress-Only Internet Gateway – This component replaces the NAT Gateway for IPv6 traffic. Unlike NAT Gateways, egress-only internet gateways are free and don’t process data charges. They provide stateful egress-only access, meaning Lambda functions can initiate outbound connections, but unsolicited inbound connections are blocked-maintaining security while eliminating costs.

Update Route Tables – Add a route for ::/0 (all IPv6 addresses) pointing to your egress-only internet gateway. This route directs all IPv6 internet-bound traffic through the free gateway rather than the paid NAT Gateway. Your route table should now contain routes for both IPv4 (0.0.0.0/0 to NAT Gateway) and IPv6 (::/0 to Egress-Only Internet Gateway).

Phase 2: Security Configuration

Security groups require careful attention during IPv6 implementation. By default, security groups allow all outbound traffic for both IPv4 and IPv6. However, many organizations implement more restrictive policies:

Phase 3: Lambda Function Configuration

With infrastructure prepared, you can now enable IPv6 on Lambda functions. This step requires careful orchestration to avoid service disruptions:

Create New Function Version – Rather than modifying your production function directly, publish a new version with IPv6 dual-stack enabled. This approach provides a clean rollback path if issues arise.

Enable IPv6 Dual-Stack – In the Lambda function configuration, navigate to VPC settings and enable IPv6. AWS will create new Elastic Network Interfaces (ENIs) that support both protocols. This process typically takes 1-2 minutes per function.

Implement Blue/Green Deployment – Use Lambda aliases to gradually shift traffic from the IPv4-only version to the dual-stack version. Start with a small percentage (10-20%) and monitor for issues before completing the transition.

Monitor and Validate – Watch CloudWatch metrics for any anomalies in invocation duration, error rates, or network connectivity. Pay particular attention to functions that communicate with external services.

Cost comparison chart showing NAT Gateway versus IPv6 deployment expenses

Cost-Benefit Analysis: Quantifying IPv6 Advantages

Understanding the financial impact of IPv6 transition helps justify the implementation effort. Let me break down the cost implications based on real-world scenarios I’ve analyzed with InterLIR customers:

NAT Gateway Cost Elimination

NAT Gateway charges consist of two components: hourly charges and data processing fees. For a single NAT Gateway in one availability zone:

For high-availability architectures requiring NAT Gateways in multiple availability zones, these costs multiply accordingly. An organization running NAT Gateways in three availability zones with moderate traffic (1TB/month per gateway) would spend approximately $2,800 annually just on NAT Gateway infrastructure-costs that disappear entirely with IPv6 implementation.

Performance Improvements and Their Business Value

Beyond direct cost savings, IPv6 offers performance improvements that translate to business value:

Use Case Analysis: When IPv6 Delivers Maximum Value

Not all Lambda functions benefit equally from IPv6 implementation. Understanding which use cases gain the most value helps prioritize migration efforts:

High-Value IPv6 Use Cases

Lower-Priority IPv6 Use Cases

Troubleshooting and Common Implementation Challenges

Through supporting numerous IPv6 implementations at InterLIR, I’ve encountered several recurring challenges. Here’s how to address them effectively:

DNS Resolution Issues

Some external services may not properly advertise their IPv6 capabilities through AAAA records, causing connection failures when Lambda prefers IPv6. Solutions include:

Security Group Misconfiguration

Incorrectly configured security groups are the most common cause of connectivity issues after enabling IPv6:

ENI Creation Delays

When enabling IPv6 on Lambda functions, AWS creates new Elastic Network Interfaces. This process can take several minutes and may cause temporary connectivity issues. Mitigation strategies include:

Future-Proofing Your Serverless Architecture

As the internet continues its inevitable transition to IPv6, organizations that proactively adopt dual-stack networking position themselves for long-term success. Based on industry trends and AWS’s strategic direction, I recommend these forward-looking practices:

At InterLIR, we’ve observed that organizations taking a proactive approach to IPv6 adoption experience smoother transitions and better long-term outcomes than those forced to react to immediate pressures. The serverless computing model, with its abstraction of infrastructure management, provides an ideal opportunity to embrace IPv6 with minimal disruption.

The internet has undergone a remarkable transformation over the past half-century, evolving from specialized research networks to the global communications infrastructure that powers our modern world. At InterLIR, we’ve witnessed firsthand how this evolution has fundamentally reshaped not just technology, but the entire landscape of network resource management and digital infrastructure. This article explores the evolutionary journey of the internet, examining how the marriage of computing and communications has fundamentally reshaped our society, economy, and technological landscape-and what this means for businesses navigating today’s complex network environment.

The Revolutionary Marriage of Computing and Communications

The invention of the transistor in December 1947 and the integrated circuit in 1958 set the stage for one of the most transformative technological marriages in human history. Before these innovations, human endeavors were largely constrained by geography. The industrial revolution and the introduction of railways in the mid-19th century had already begun shifting the foundations of wealth and power from agriculture to industrial production, with the telegraph and telephone enabling companies to project their influence across greater distances.

However, when computers entered the communications realm, the pace of change accelerated dramatically. The timeline between major innovations compressed from decades to years, with computing transitioning from esoteric research tools to essential components of everyday life. This acceleration continues today, driving the demand for network resources that we help businesses secure at InterLIR.

Key Technological Foundations

Several foundational technologies emerged during this period that would shape the internet’s architecture for decades to come:

The open distribution model of Unix was particularly significant. Due to antitrust restrictions, Bell Labs was required to license their patents upon request and forbidden from entering businesses outside common carrier communications. As a result, Unix source code was shared widely, allowing universities and organizations to modify and extend it, leading to influential variants like the Berkeley Software Distribution (BSD). This open approach to technology development would become a defining characteristic of internet evolution.

Ethernet network cable connecting distributed edge devices with simple topology diagram

Ethernet: The Triumph of Simplicity and the Smart Edge Philosophy

Ethernet represents one of the most influential networking technologies ever developed, and its design philosophy continues to influence network architecture today. What made it revolutionary was its radical simplicity-it was, essentially, just a wire. Rather than building intelligence into the network itself, Ethernet pushed all networking functions to the edge devices (computers) connected to it.

This “dumb network, smart devices” philosophy transformed network design fundamentally. Ethernet required no internal switch, no packet framing, no controller, and maintained no network state. Instead, connected computers handled all these functions through distributed algorithms. This approach meant that network costs were distributed to the connected devices rather than centralized, creating a more scalable and flexible architecture.

Technical Innovations of Ethernet

The technical elegance of Ethernet’s design included several key innovations:

This design philosophy of pushing intelligence to the edges while keeping the network simple and fast has profound implications for how we think about network resources today. At InterLIR, we see this principle reflected in modern network architectures where flexibility and scalability depend on intelligent endpoint management rather than complex core infrastructure.

Moore’s Law: The Engine of Digital Transformation

The exponential improvements in computing capability driven by Moore’s Law have been the fundamental force behind the internet’s evolution. Gordon Moore’s 1965 observation that the number of transistors on an integrated circuit doubles approximately every two years while fabrication costs increase far less dramatically has held remarkably consistent for decades.

This exponential growth pattern has continuously rendered even recent technologies obsolete. Unlike cars or other technological artifacts that might remain functional for decades, computers from just a few years ago are often considered hopelessly outdated. The VAX 11/780 computer from 1977, once a cutting-edge mainframe capable of executing 1 million instructions per second, now exists primarily in museums. Today’s smartphones possess computing power that would have seemed like science fiction just a generation ago.

The Addressing Challenge and Network Planning

One critical area where Moore’s Law impacted network design was in address space planning-a domain that directly relates to our work at InterLIR. Early network protocols like DECnet Phase 3 used a 16-bit address field, allowing a maximum of 65,535 connected devices. This number seemed more than adequate in an era of room-sized computers costing millions of dollars.

The creators of the Internet Protocol (IP) took a far more visionary approach by implementing a 32-bit addressing architecture, enabling approximately 4.3 billion unique addresses. This decision, seemingly extravagant in the 1970s when there were only thousands of computers worldwide, demonstrated remarkable foresight about computing’s potential growth trajectory.

Yet even this vast address space proved inadequate as Moore’s Law continued to drive the proliferation of connected devices. What seemed like “forever” capacity in the 1980s would be exhausted by the explosive growth of the internet decades later. This exhaustion of IPv4 addresses created the specialized marketplace that InterLIR serves today, where businesses must carefully manage and acquire the IPv4 resources they need to operate.

The Client-Server Revolution and Network Asymmetry

As personal computing emerged in the 1980s, another fundamental shift occurred in how we conceptualized computer networks. Early network designs assumed symmetry-like telephone networks where each endpoint both speaks and listens, computers were expected to both provide and consume services equally.

However, the market evolved differently. Personal computers positioned themselves primarily as clients rather than servers. Users wanted computing equivalents of television sets-devices to access services, not host them. This shift led to a segmentation of the computing environment into dedicated client and server roles, fundamentally changing network architecture and resource requirements.

The Asymmetric Internet Architecture

By the late 1990s, this client-server model became embedded in the internet’s architecture itself. Network design accommodated this asymmetry through several key developments:

This architectural decision aligned with the limitations of existing infrastructure. The dial-up world of the 1990s and the DSL/Cable modem era of the 2000s provided a good fit for client/server networking, allowing rapid expansion by leveraging legacy last-mile infrastructure. However, this asymmetry also created challenges for businesses requiring substantial upload capacity or hosting services, driving demand for dedicated server infrastructure and specialized network resources.

Data center server racks with network infrastructure and cooling systems

Data Centers, Cloud Computing, and the Centralization of Resources

Around the year 2000, specialized data centers began to emerge, consolidating servers into controlled environments with robust power, cooling, and maintenance capabilities. These facilities represented the next evolutionary step in network architecture, providing centralized homes for the growing array of internet services. From our perspective at InterLIR, this centralization created new patterns in how IPv4 addresses were allocated and utilized.

Service specialization accelerated, with dedicated servers for web hosting, email, data storage, and various other functions. Compared to today’s massive AI-scale data centers, these early facilities were relatively modest-typically occupying just a room or two with power requirements in the hundreds of kilowatts rather than megawatts.

The Cloud Computing Revolution

The next major evolutionary phase came with the emergence of cloud computing, which further abstracted computing resources from physical hardware. This shift has fundamentally transformed how businesses think about and interact with computing resources:

Cloud computing represents the culmination of several evolutionary trends: the increasing power of computing hardware driven by Moore’s Law, the client-server model’s maturation, and the continuing abstraction of computing resources from physical infrastructure. However, this centralization also concentrated demand for IPv4 addresses in data center environments, contributing to address scarcity and creating the specialized market we serve.

Addressing Space Challenges: From IPv4 Scarcity to IPv6 Abundance

As predicted by the relentless progress of Moore’s Law, the seemingly vast IPv4 address space with its 4.3 billion addresses eventually proved inadequate. The proliferation of personal computers, mobile devices, and later IoT devices created an address scarcity that threatened to constrain the internet’s continued growth. This scarcity is precisely what drives the IPv4 marketplace that InterLIR facilitates.

The response was IPv6, introduced in 1998 with a 128-bit address space capable of supporting approximately 340 undecillion (3.4×10^38) unique addresses. This expansion represented not just a quantitative improvement but a qualitative rethinking of how addressing should work in a vastly expanded internet environment.

The Transition Challenge

Despite IPv6’s technical superiority and virtually unlimited address space, the transition from IPv4 has been slower than anticipated. Several factors contribute to this gradual adoption:

Legacy Infrastructure – Billions of devices and countless network configurations built around IPv4 cannot be instantly replaced

Network Address Translation (NAT) – This workaround technology extended IPv4’s lifespan by allowing multiple devices to share single public addresses

Dual-Stack Complexity – Running both IPv4 and IPv6 simultaneously adds operational complexity and cost

Business Continuity – Organizations prioritize maintaining existing services over infrastructure upgrades

Economic Factors – The availability of IPv4 addresses through secondary markets reduces urgency for IPv6 adoption

This transition period has created a unique market dynamic. While IPv6 represents the long-term future, IPv4 addresses remain essential for current operations, particularly for businesses requiring compatibility with existing internet infrastructure. At InterLIR, we help organizations navigate this transition by facilitating access to IPv4 resources while they develop their IPv6 strategies.

From Scarcity to Abundance: A Paradigm Shift

The transition from IPv4 to IPv6 exemplifies a broader pattern in computing evolution-the shift from resource scarcity to abundance. Early computing systems were designed with careful attention to efficiency due to limited processing power, memory, and bandwidth. As Moore’s Law drove exponential improvements in these capabilities, design philosophies shifted toward leveraging abundance rather than optimizing for scarcity.

However, this paradigm shift occurs unevenly across different resources. While computing power and storage have become abundant, network addresses experienced a temporary return to scarcity with IPv4 exhaustion. IPv6 promises to restore abundance, but the transition period creates unique challenges and opportunities for businesses managing their network infrastructure.

Current Trends and Future Directions in Internet Evolution

Today’s internet continues to evolve along several key dimensions, each building upon the foundational elements established decades ago. Understanding these trends is crucial for businesses planning their network infrastructure and resource requirements:

The fundamental principles established in earlier eras-open standards, distributed intelligence, and the relentless improvements driven by Moore’s Law-continue to shape how these newer technologies develop and deploy. However, each trend creates specific implications for network resource management and planning.

The Internet of Things and Massive Device Proliferation

Perhaps the most dramatic manifestation of Moore’s Law in the contemporary internet is the explosion of connected devices beyond traditional computers. The Internet of Things represents a natural extension of the trends that have driven internet evolution from the beginning-as computing power becomes smaller, cheaper, and more energy-efficient, it becomes practical to embed it in an ever-widening array of objects.

This proliferation of connected devices creates both opportunities and challenges. The vast IPv6 address space provides the necessary foundation for billions or trillions of connected devices, but questions of security, privacy, standardization, and power efficiency remain to be fully resolved. For businesses deploying IoT solutions, careful planning of network resources becomes critical.

Business Implications of Internet Evolution

For organizations navigating today’s complex network environment, understanding internet evolution provides crucial context for strategic planning:

At InterLIR, we work with businesses to understand how these evolutionary trends impact their specific network resource needs. Whether acquiring IPv4 addresses for immediate operational requirements or planning long-term IPv6 strategies, understanding the historical context and future trajectory of internet evolution enables more informed decision-making.

Bring Your Own IP, or BYOIP, allows a company to use its own public IP address range with a cloud, CDN, hosting, DDoS protection, or network provider instead of relying only on provider-assigned IPs. For businesses that depend on stable IP reputation, firewall allowlists, predictable routing, or multi-cloud flexibility, BYOIP can be an important part of infrastructure planning.

The BYOIP process is also becoming more technical. Traditional onboarding often relied on manual review, Letters of Authorization, and long communication between account teams, engineers, and network operators. Modern BYOIP workflows increasingly use RPKI/ROA, IRR route objects, RDAP or WHOIS data, reverse DNS, TXT records, and provider-specific verification tokens to confirm that a customer is authorized to use and route a prefix.

This is especially relevant for companies that lease IPv4 addresses. A leased IPv4 range can sometimes be prepared for BYOIP, but only when the authorization chain, routing records, registry data, provider policy, and technical setup all support the intended use case. InterLIR’s Bring Your Own IP service helps businesses lease IPv4 ranges and prepare the IP-side configuration required for BYOIP, including route objects, RPKI/ROA support, LOA documentation, WHOIS management, and verification tokens where applicable.

What Is BYOIP?

BYOIP stands for Bring Your Own IP. It means that an organization brings an IP prefix it owns or is authorized to use into a third-party provider’s infrastructure.

Instead of changing to IP addresses assigned by a cloud or hosting provider, the company keeps using a familiar public IP range while moving workloads, applications, traffic delivery, or security services to a new environment.

In practice, BYOIP helps organizations preserve control over their public IP identity. This can be useful during cloud migration, CDN onboarding, hybrid infrastructure deployment, disaster recovery planning, DDoS protection setup, or multi-cloud architecture design.

Why Companies Use BYOIP

Companies usually consider BYOIP when public IP addresses are not just technical resources, but part of their operational identity. A stable IP range may already be trusted by customers, partners, firewalls, payment systems, SaaS platforms, security tools, or email infrastructure.

• Preserving IP reputation during infrastructure changes
• Keeping existing firewall allowlists and partner-side access rules
• Avoiding customer-side IP changes during migration
• Maintaining routing and addressing control
• Reducing dependency on one cloud or hosting provider
• Supporting multi-cloud and hybrid infrastructure
• Separating IPv4 strategy from provider-assigned IP pricing and availability

For many organizations, the main value of BYOIP is continuity. They can modernize infrastructure without changing the public IP addresses that customers, systems, and partners already recognize.

Traditional BYOIP Onboarding vs Self-Serve BYOIP

Historically, BYOIP onboarding was often slow and document-heavy. A customer would submit a request, provide a Letter of Authorization, wait for manual review, and coordinate with provider teams before the prefix could be accepted and announced.

This process made sense from a security perspective, because providers need to avoid unauthorized route announcements. However, it was not always efficient. Technical teams could be ready to deploy infrastructure while still waiting for administrative approval.

Self-serve BYOIP changes this model. Instead of relying only on PDFs and manual checks, providers can validate IP prefix control and routing intent through technical records, cryptographic routing data, APIs, and automated checks. In many cases, documents are still used, but they are increasingly complemented by verifiable routing and registry signals.

A modern BYOIP workflow may use RPKI/ROA to confirm which ASN is authorized to originate a prefix, IRR route objects to support routing policy and filtering, RDAP or WHOIS data to confirm registry-level information, reverse DNS or TXT records for ownership validation, provider-specific verification tokens, and LOA documentation where documents are still required.

This does not remove the need for authorization. It makes the authorization process more technical, more verifiable, and often easier to audit.

Manual BYOIP verification is increasingly complemented by automated validation through RPKI, IRR, rDNS, RDAP, and provider-side checks.

How BYOIP Verification Works

A secure BYOIP process normally needs to answer two questions. First, does the customer have legitimate control over the IP prefix or authorization to use it? Second, is the provider allowed to announce or use that prefix in the intended network?

RPKI and ROA

RPKI, or Resource Public Key Infrastructure, is used to improve routing security. A ROA, or Route Origin Authorization, is a cryptographically signed object that states which Autonomous System is authorized to originate a certain IP prefix.

In a BYOIP setup, the customer or resource holder may need to create or update a ROA so the provider’s ASN is authorized to originate the prefix. If the ROA is missing, wrong, expired, or too restrictive, the route may be rejected by networks that perform Route Origin Validation.

This is one of the most important technical checks in modern BYOIP. A small ROA mistake can cause serious routing problems, especially if the prefix is already being validated by upstream networks.

IRR and Route Objects

IRR route objects are still widely used by network operators to build filters and validate routing policy. Even when RPKI is in place, route objects may still be required by upstreams, peers, cloud providers, CDN networks, or DDoS protection providers.

For BYOIP, route objects help show that a prefix is intended to be routed through a specific ASN or network path. Keeping them accurate reduces the risk of routing filters blocking the prefix.

RDAP, WHOIS and Registry Data

RDAP and WHOIS records help providers review registry-level information about an IP range. Depending on the provider and registry, these records may be used to confirm organization details, contact information, remarks, comments, or authorization chains.

Some providers may also require a verification token, certificate, or other validation record to be placed in RDAP, WHOIS, reverse DNS, TXT records, or another controlled location. This helps connect the IP range to a specific BYOIP request or provider account.

Reverse DNS and TXT Verification

Reverse DNS can be used as a practical proof of operational control when the customer or IP resource holder can publish a required token. TXT-based verification is also common in automated workflows because it gives the provider a simple way to check that the party requesting BYOIP can modify a delegated record.

LOA Documentation

Even with RPKI and automated validation, Letters of Authorization are still used in some BYOIP workflows. Many network operators continue to rely on documents as part of their routing acceptance process.

For leased IPv4 ranges, LOA documentation can be especially important. It helps show that the customer has permission to use the range for the requested BYOIP purpose and that there is a clear authorization chain from the resource holder to the end user.

Using Leased IPv4 Ranges for BYOIP

Not every company that needs BYOIP already owns IPv4 space. Buying IPv4 addresses can require significant capital investment, while provider-assigned cloud IPs may become expensive, limited, or unsuitable for workloads that depend on reputation and long-term continuity.

Leasing IPv4 addresses can be a practical alternative, but BYOIP with leased IPv4 must be handled carefully. A leased range is suitable only when the lease terms, authorization documents, registry data, routing policy, and target provider requirements all allow the intended BYOIP use.

The most important point is that the leased range must support the technical and administrative requirements of the target platform. This may include RPKI/ROA, route objects, LOA documentation, WHOIS or RDAP updates, reverse DNS, verification tokens, and a clear abuse-handling process.

InterLIR’s BYOIP service is designed for this scenario. InterLIR helps with the IP-side preparation of leased IPv4 ranges, while the client completes provider-side onboarding inside AWS, Azure, Google Cloud, Cloudflare, or another provider’s own portal, account, and tools.

BYOIP Requirements by Provider Type

BYOIP is used differently across cloud, CDN, hosting, DDoS protection, and network providers. The general idea is similar: the customer brings an IP prefix, proves authorization, and the provider makes the range usable in its infrastructure.

However, the exact requirements vary. One provider may require a specific minimum prefix size. Another may require a particular ROA, LOA format, verification token, regional onboarding process, account permission, or provisioning timeline.

Because of these differences, businesses should always check the target provider’s current BYOIP requirements before leasing, preparing, or migrating a range.

BYOIP Requirements Checklist

Before starting a BYOIP project, prepare the technical and administrative elements that providers commonly request. Exact requirements vary between platforms, but the following checklist covers the most common areas.

• A suitable IPv4 or IPv6 prefix that meets the target provider’s requirements
• Confirmation that the organization is authorized to use the prefix
• Correct RPKI/ROA configuration for the intended origin ASN
• Valid IRR route objects where required
• Accurate RDAP or WHOIS information
• LOA documentation if the provider, upstream, or peer requires it
• Provider-specific verification tokens or certificates
• Reverse DNS or TXT access where required for validation
• Access to the target cloud, CDN, hosting, or network provider account
• A migration, cutover, and rollback plan
• Monitoring for route visibility, reachability, latency, and reputation

Most BYOIP problems happen because one of these elements is missing, outdated, or configured incorrectly. Preparing them in advance can make onboarding smoother and reduce the risk of routing failures.

Common BYOIP Risks

BYOIP gives companies more control, but it also creates more responsibility. Incorrect routing data or poor migration planning can lead to failed validation, traffic loss, rejected routes, or reputation problems.

• Incorrect ROA origin ASN
• Wrong ROA maximum prefix length
• Missing or outdated IRR route objects
• Incomplete LOA documentation
• Unclear authorization chain for leased IPv4 space
• Outdated RDAP or WHOIS information
• Provider verification token placed in the wrong record
• Prefix advertisement before services are ready
• Overlapping route announcements
• IP reputation, abuse history, or geolocation issues
• Misunderstanding provider-specific limitations

A safe BYOIP deployment should include routing checks, staged migration, reachability testing, service binding validation, and monitoring after cutover.

BYOIP routing should be planned together with service configuration to avoid traffic loss during advertisement or migration.

BYOIP and IP Reputation

One of the main benefits of BYOIP is reputation continuity. If a company already uses an IP range with a clean history and trusted reputation, BYOIP can help preserve that value when infrastructure changes.

However, reputation can also become a risk. If a leased range has previous abuse history, blocklist issues, poor geolocation data, or unclear routing history, those problems may follow the range into the new environment.

Before using any IPv4 range for BYOIP, businesses should check its reputation, abuse history, blocklist status, geolocation expectations, routing history, and suitability for the intended workload.

How InterLIR Helps with BYOIP

InterLIR helps organizations lease IPv4 ranges and prepare them for BYOIP use cases. Depending on the range, provider, registry, and project requirements, InterLIR can support the IP-side setup needed for onboarding.

The cloud-side setup remains the client’s responsibility and is completed inside the provider’s own account, portal, API, and tools. InterLIR supports the IP-side configuration needed to make that onboarding possible.

For companies that want to use leased IPv4 addresses in cloud, CDN, hosting, or network environments, this can reduce friction and help avoid common routing and verification mistakes.

BYOIP FAQ

What does BYOIP mean?

BYOIP means Bring Your Own IP. It allows a company to use its own or authorized public IP address range inside a third-party cloud, CDN, hosting, DDoS protection, or network provider’s infrastructure.

Can leased IPv4 addresses be used for BYOIP?

Yes, leased IPv4 addresses can sometimes be used for BYOIP when the lease arrangement supports the required authorization, routing, registry, and provider verification steps. The range must be checked against the target provider’s current requirements before deployment.

Is RPKI required for BYOIP?

Not always in every workflow, but RPKI/ROA is increasingly important. Many providers and networks use ROA data to validate routing authorization, and an incorrect ROA can cause route validation failures.

What is a ROA?

A ROA, or Route Origin Authorization, is a cryptographically signed object that states which ASN is authorized to originate a specific IP prefix.

What is the difference between BYOIP and provider-assigned IPs?

With provider-assigned IPs, the cloud or hosting provider gives the customer addresses from the provider’s own pool. With BYOIP, the customer brings an IP range it owns or is authorized to use, and the provider makes that range usable inside its infrastructure.

Does BYOIP preserve IP reputation?

BYOIP can help preserve IP reputation because the organization continues using the same public IP range. However, reputation should always be checked before onboarding, especially with leased IPv4 addresses.

Does InterLIR handle the full cloud-side BYOIP setup?

No. InterLIR supports the IP-side configuration, including route objects, RPKI/ROA support, LOA documentation, WHOIS management, and verification tokens where applicable. The client completes provider-side setup inside the cloud, CDN, hosting, or network provider account.

Conclusion

BYOIP is becoming an important part of modern IP management. It helps businesses keep control over their public IP identity while using cloud, CDN, hosting, DDoS protection, or network-provider infrastructure.

Self-serve and automated BYOIP workflows make the process more technical, but they also make preparation more important. RPKI/ROA, IRR route objects, RDAP or WHOIS data, LOA documentation, verification tokens, and migration planning all need to be handled carefully.

For organizations that do not own IPv4 space, leased IPv4 ranges can provide a practical path to BYOIP when the IP-side authorization and routing setup are properly prepared. InterLIR helps businesses lease BYOIP-ready IPv4 ranges and prepare the IP-side configuration needed for cloud and network provider onboarding.

Related Articles You Might Find Useful

As we navigate through 2025, the global Internet routing infrastructure has reached a critical milestone that demands attention from network operators, businesses, and IT professionals worldwide. At InterLIR, where we specialize in IPv4 address marketplace solutions, we’ve been closely monitoring these developments as they directly impact our clients’ network planning and resource allocation strategies. The latest data from the Weekly Global IPv4 Routing Table Report reveals that the BGP routing table has surpassed 1 million entries, marking a significant evolution in Internet backbone complexity.

This comprehensive analysis examines the current state of the IPv4 routing ecosystem, exploring what these numbers mean for businesses operating in an increasingly connected world. As someone who works daily with organizations navigating IPv4 address scarcity and routing challenges, I’ve witnessed firsthand how these technical metrics translate into real-world business decisions and infrastructure investments.

The Million-Prefix Milestone: What It Means for Global Internet Infrastructure

The global IPv4 routing table now contains 1,012,261 prefixes as of November 2025, representing a watershed moment in Internet infrastructure evolution. This figure isn’t just a technical statistic-it reflects the cumulative result of decades of Internet growth, business expansion, and the fundamental challenge of managing a finite resource that has reached its allocation limits.

From our perspective at InterLIR, this milestone carries significant implications for organizations seeking to establish or expand their network presence. The routing table’s growth directly impacts router memory requirements, processing capabilities, and ultimately, the cost of maintaining robust Internet connectivity. When we consult with clients about IPv4 address acquisitions, understanding these routing dynamics helps us provide more strategic guidance about prefix sizing and announcement strategies.

BGP routing table growth visualization showing global prefix distribution and aggregation metrics

The current routing landscape presents several critical metrics that network operators must consider:

The deaggregation factor of 2.58 is particularly noteworthy. This metric indicates that the actual number of routing table entries is more than 2.5 times what would be necessary if all prefixes were maximally aggregated. While deaggregation serves legitimate purposes-traffic engineering, multihoming, and redundancy-it also contributes to routing table bloat that affects every router on the Internet.

Autonomous System Distribution and the Internet’s Operational Structure

The report identifies 77,510 Autonomous Systems present in the global routing table, each representing an independent network operator with its own routing policies and business objectives. This diversity is both a strength and a challenge for the Internet ecosystem. At InterLIR, we work with organizations across this spectrum, from enterprises acquiring their first AS number to established operators expanding their routing footprint.

The distribution of these autonomous systems reveals fascinating insights about Internet operations:

The average AS path length of 4.7 hops indicates that most Internet traffic traverses approximately five different networks between source and destination. However, the maximum observed path length of 57 hops-with ASN 37447 showing an AS path prepend of 53-demonstrates extreme traffic engineering practices that some operators employ to influence routing decisions.

The Transition to 32-Bit ASN Space

The evolution toward 32-bit Autonomous System Numbers continues to progress, addressing the exhaustion of the original 16-bit AS number space. Currently, 47,936 32-bit ASNs have been allocated by Regional Internet Registries, with 39,257 (81.9%) visible in the global routing table. These newer ASNs now originate 215,103 prefixes, representing 21.2% of all announced routes.

For organizations planning network expansions, this transition is largely transparent but represents an important consideration for legacy equipment compatibility. When we assist clients with IPv4 address transfers at InterLIR, we ensure they understand how their routing infrastructure will interact with both 16-bit and 32-bit ASN environments.

Regional Variations: Understanding Global Internet Distribution Patterns

One of the most revealing aspects of the routing table analysis is the significant variation across Regional Internet Registry territories. These differences reflect distinct development trajectories, regulatory environments, and market structures that shape how the Internet operates in different parts of the world.

These regional patterns tell compelling stories about Internet development and resource distribution:

The APNIC region demonstrates high consolidation with an average of 17.59 prefixes per ASN, reflecting the presence of large telecommunications operators serving massive populations. China Mobile alone announces 13,466 prefixes, illustrating the scale of network operations in Asia-Pacific markets. The deaggregation factor of 3.36 suggests moderate route fragmentation, balancing operational flexibility with routing efficiency.

The ARIN region controls the largest address space allocation at 80.2 equivalent /8 blocks, a legacy of early Internet development concentrated in North America. With a relatively low deaggregation factor of 2.23, ARIN networks demonstrate more efficient routing practices. Amazon’s dominance with 14,312 announced prefixes highlights the growing influence of cloud service providers in global Internet infrastructure.

The RIPE region exhibits the most distributed network operator landscape with 29,099 origin ASes and the lowest deaggregation factor of 2.02. This efficiency reflects mature Internet governance practices and well-established routing policies across European networks. The lower prefixes-per-ASN ratio of 9.68 indicates a more fragmented operator landscape with numerous smaller networks.

The LACNIC region shows a higher deaggregation factor of 4.08, suggesting more aggressive route splitting for traffic engineering purposes. Telmex Mexico’s announcement of 12,504 prefixes demonstrates the concentration of Internet infrastructure among major telecommunications providers in Latin America. The region’s smaller address space allocation of 10.2 equivalent /8s reflects later Internet adoption and development.

The AfriNIC region presents the highest deaggregation factor at 5.05 and the highest prefixes-per-ASN ratio of 24.67, indicating both significant route fragmentation and concentration among fewer operators. With only 6.1 equivalent /8s of address space and 1,983 origin ASes, Africa’s Internet infrastructure remains the least developed globally, though it’s experiencing rapid growth.

IPv4 Address Space Exhaustion: The New Reality for Network Planning

The most critical finding from the routing table analysis is the confirmation of complete IPv4 address space exhaustion. The numbers are stark and unambiguous:

At InterLIR, we’ve witnessed this exhaustion transform the IPv4 marketplace from a theoretical concern into a practical reality affecting daily business operations. With 100% of available IPv4 address space now allocated and 99.6% in actual use, organizations can no longer obtain new IPv4 addresses directly from Regional Internet Registries. Instead, they must participate in the secondary market, acquiring addresses through transfers from existing holders.

This reality has several important implications for network planning and business strategy. First, IPv4 addresses have become valuable assets with real market value, requiring careful management and strategic allocation. Second, organizations must balance their immediate IPv4 needs against long-term IPv6 transition planning. Third, the scarcity of IPv4 resources makes efficient address utilization and routing practices more critical than ever.

Route Deaggregation and Its Business Impact

The report identifies 332,336 prefixes smaller than registry allocations, representing significant route deaggregation. While this practice serves legitimate operational purposes-enabling multihoming, traffic engineering, and redundancy-it contributes to routing table growth that affects all Internet participants.

From a business perspective, deaggregation decisions involve trade-offs between operational flexibility and community impact. Organizations announcing more specific prefixes gain finer control over traffic routing but contribute to the global routing table’s growth, increasing memory and processing requirements for routers worldwide. When advising clients at InterLIR, we help them understand these trade-offs and develop routing strategies that balance their operational needs with responsible Internet citizenship.

Major Network Operators and Infrastructure Concentration

The concentration of routing announcements among major providers reveals important trends in global Internet infrastructure. The top five autonomous systems by prefix count demonstrate the scale of modern network operations:

Amazon’s position at the top of this list is particularly significant, representing the growing dominance of cloud service providers in global Internet infrastructure. As businesses increasingly migrate workloads to cloud platforms, these providers’ routing footprints expand correspondingly. This trend has important implications for Internet resilience, as more traffic flows through fewer large networks.

Each region’s leading operator reflects local market dynamics and historical development patterns. China Mobile’s massive presence in APNIC, Telmex’s dominance in LACNIC, and the more distributed landscape in RIPE all tell stories about telecommunications regulation, market competition, and infrastructure investment in their respective regions.

Routing Security and RPKI Adoption Progress

Resource Public Key Infrastructure (RPKI) represents one of the most important developments in routing security, providing cryptographic validation of route origins to prevent BGP hijacking and route leaks. The current adoption statistics show both progress and persistent challenges:

While achieving 57.4% RPKI coverage represents significant progress, the 42.5% of prefixes without ROA protection represents a substantial security gap. These unprotected routes remain vulnerable to hijacking, where malicious actors could announce unauthorized routes and intercept traffic destined for these addresses.

At InterLIR, we strongly advocate for RPKI adoption among our clients. When facilitating IPv4 address transfers, we encourage both sellers and buyers to implement proper ROA configurations, contributing to overall Internet security. The small percentage of invalid ROAs (0.15%) typically results from configuration errors during address transfers or network changes, highlighting the importance of proper RPKI maintenance procedures.

The presence of 416 prefixes from unallocated address space is particularly concerning, representing either administrative errors or deliberate misuse of unassigned resources. These anomalies underscore the ongoing need for vigilant monitoring and enforcement of routing policies by network operators and Internet governance bodies.

Strategic Implications for Businesses and Network Operators

The findings from this comprehensive routing table analysis carry important implications for various stakeholders in the Internet ecosystem. Based on our experience working with diverse organizations at InterLIR, I can offer practical perspectives on how these technical metrics translate into business decisions and operational strategies.

Infrastructure Investment and Planning

With over 1 million prefixes in the global routing table, organizations must ensure their routing infrastructure can handle current and future demands. This requirement affects several aspects of network planning:

IPv4 Resource Strategy

Complete IPv4 exhaustion fundamentally changes how organizations approach address space acquisition and management:

Security Implementation Priorities

The routing security landscape demands proactive measures from responsible network operators:

IPv6 Transition Planning

While IPv4 exhaustion is complete, IPv6 adoption remains uneven and gradual. Organizations must develop dual-stack strategies that maintain IPv4 connectivity while progressively implementing IPv6:

As CEO of InterLIR, a specialized IPv4 address marketplace, I’ve witnessed firsthand the mounting pressures organizations face regarding IP address management and network infrastructure evolution. Amazon’s November 2025 announcement of IPv6 support for S3 Express One Zone represents more than a technical feature addition-it signals a fundamental shift in how enterprises must approach cloud storage connectivity in an era of address exhaustion and infrastructure modernization.

This development arrives at a critical juncture. Since founding InterLIR in 2020, our team has facilitated countless IPv4 address transactions for organizations struggling with address scarcity. The integration of IPv6 into high-performance storage services like S3 Express One Zone provides enterprises with a strategic alternative pathway, though the relationship between IPv4 markets and IPv6 adoption is more nuanced than simple substitution.

The Strategic Context: Why IPv6 Integration Matters Now

Amazon’s implementation of IPv6 for S3 Express One Zone through gateway VPC endpoints addresses several converging pressures that my team at InterLIR observes daily in our interactions with enterprise clients. The timing is particularly significant given the current state of global IP address availability.

IPv4 address exhaustion has transitioned from a theoretical concern to an operational reality. Organizations expanding their cloud footprints increasingly encounter scenarios where private IPv4 address space becomes constrained, particularly in large-scale data center environments or complex hybrid architectures. While InterLIR facilitates IPv4 address acquisitions to address immediate needs, the 128-bit address space of IPv6 (providing approximately 340 undecillion unique addresses) offers a fundamentally different solution to address scarcity.

From my perspective working with organizations across various sectors, the decision to adopt IPv6 isn’t purely technical-it’s strategic. Companies must balance immediate operational requirements against long-term infrastructure sustainability. S3 Express One Zone’s IPv6 support provides a critical component for organizations pursuing this balance, particularly those with latency-sensitive applications.

IPv6 network architecture diagram showing VPC endpoint configuration with cloud storage

Technical Architecture and Implementation Pathways

The implementation approach Amazon has taken with S3 Express One Zone demonstrates sophisticated understanding of enterprise migration challenges. By supporting IPv6 through VPC endpoints rather than requiring public internet connectivity, AWS addresses security and performance concerns that often complicate IPv6 adoption.

VPC Endpoint Configuration Options

Organizations now have three primary deployment models, each serving distinct strategic purposes:

1. IPv6-Only Endpoints – Designed for organizations with fully modernized, IPv6-native infrastructure. This approach eliminates dual-protocol overhead and simplifies network architecture, though it requires comprehensive IPv6 readiness across the application stack.
2. DualStack Endpoints – The pragmatic choice for most enterprises during transition periods. This configuration maintains IPv4 connectivity while enabling IPv6 capabilities, allowing gradual application migration without service disruption.
3. Hybrid Integration – Organizations can add IPv6 support to existing VPC endpoints, facilitating incremental adoption aligned with broader infrastructure modernization initiatives.

Deployment Interfaces and Automation

AWS provides multiple configuration interfaces to accommodate different operational models:

In my experience advising organizations on network infrastructure decisions, the availability of multiple deployment interfaces significantly impacts adoption velocity. Enterprises with mature automation practices can integrate IPv6 support into existing deployment pipelines, while those with more traditional operational models can adopt at their own pace.

Industry-Specific Implications and Use Cases

The intersection of high-performance storage and IPv6 support creates particularly compelling value propositions for specific industry verticals. My work with InterLIR has provided insight into how different sectors approach IP address management, and S3 Express One Zone’s IPv6 capabilities address distinct pain points across these industries.

Financial Services and Trading Platforms

Financial institutions leveraging algorithmic trading or real-time risk analysis systems represent ideal candidates for this technology combination. These organizations typically require:

• Ultra-low latency storage for market data and transaction processing
• Extensive network addressing for distributed processing nodes
• Compliance with regulatory frameworks increasingly mandating IPv6 support
• Simplified network architecture to reduce potential points of failure

The elimination of NAT (Network Address Translation) overhead through native IPv6 connectivity can measurably improve latency profiles-a critical factor when microseconds impact trading outcomes. Additionally, the regulatory landscape in financial services increasingly favors IPv6 adoption, making this capability strategically valuable beyond pure performance considerations.

Healthcare and Research Institutions

Healthcare organizations managing genomic data, medical imaging repositories, or research datasets face unique challenges that S3 Express One Zone’s IPv6 support directly addresses. These institutions often operate extensive device networks-imaging equipment, sequencing machines, research instruments-that benefit from IPv6’s expansive addressing capabilities.

The combination of low-latency storage access and simplified network addressing facilitates more efficient data workflows between research equipment and central repositories. For organizations in this sector, the ability to assign unique IPv6 addresses to each device without complex private network schemes represents significant operational simplification.

Media Production and Content Processing

Media companies with high-performance content production workflows exemplify another compelling use case. Modern media processing architectures often involve hundreds or thousands of processing nodes accessing shared storage resources. IPv6’s address space eliminates constraints on network design, while S3 Express One Zone’s performance characteristics support demanding rendering and transcoding workflows.

IPv6 network architecture diagram showing S3 Express One Zone media workflow infrastructure

Migration Strategy and Risk Management

Based on InterLIR’s experience helping organizations navigate network infrastructure transitions, I recommend a structured approach to IPv6 adoption with S3 Express One Zone that balances innovation with operational stability.

Assessment and Planning Phase

Organizations should begin with comprehensive assessment of their current state:

Phased Implementation Approach

I recommend a five-phase implementation strategy that minimizes risk while accelerating time-to-value:

1. Pilot Environment Establishment – Create isolated test environments with DualStack endpoints to validate application behavior and identify integration challenges without production impact.
2. Security Policy Adaptation – Update network security groups, access control lists, and monitoring systems to accommodate IPv6 address patterns and traffic flows.
3. Application Validation – Systematically test applications against IPv6 endpoints, documenting any compatibility issues and developing remediation plans.
4. Monitoring Enhancement – Extend observability platforms to capture IPv6-specific metrics, ensuring operational visibility throughout the transition.
5. Production Rollout – Deploy IPv6 support in production using DualStack configuration initially, with gradual transition to IPv6-only as confidence and compatibility increase.

Common Pitfalls and Mitigation Strategies

Through InterLIR’s work with diverse organizations, several common challenges emerge during IPv6 adoption:

The Relationship Between IPv4 Markets and IPv6 Adoption

As someone operating in the IPv4 address marketplace, I’m frequently asked whether IPv6 adoption will eliminate demand for IPv4 addresses. The reality is more nuanced and directly relevant to understanding the strategic value of S3 Express One Zone’s IPv6 support.

IPv4 and IPv6 will coexist for the foreseeable future. Organizations still require IPv4 addresses for:

• Public-facing services where IPv4 connectivity remains necessary for universal accessibility
• Legacy systems that cannot be economically upgraded to support IPv6
• Specific regulatory or compliance requirements mandating IPv4 support
• Integration with partner organizations or customers not yet IPv6-capable

However, IPv6 adoption for internal infrastructure-particularly cloud storage connectivity-reduces the rate of IPv4 address consumption. This creates a more sustainable approach where organizations use IPv4 addresses strategically for external connectivity while leveraging IPv6’s expansive address space for internal architecture.

S3 Express One Zone’s IPv6 support enables this hybrid strategy. Organizations can maintain IPv4 addressing for public-facing applications while transitioning internal storage connectivity to IPv6, optimizing their IP address portfolio and reducing long-term address acquisition costs.

Future Trajectory and Strategic Positioning

Looking forward from InterLIR’s vantage point in the network infrastructure market, several trends will shape how organizations leverage IPv6-enabled cloud storage:

Edge Computing Integration

The proliferation of edge computing architectures will increasingly benefit from IPv6’s addressing capabilities. As organizations deploy distributed processing nodes closer to data sources, the ability to assign unique addresses without complex NAT schemes becomes strategically valuable. S3 Express One Zone’s combination of low latency and IPv6 support positions it well for edge-to-cloud data workflows.

Multi-Cloud and Hybrid Architecture Evolution

Organizations pursuing multi-cloud strategies face networking complexity as a primary challenge. Standardized IPv6 implementation across cloud providers facilitates more consistent addressing schemes and simplified connectivity models. As more cloud services adopt IPv6, the strategic value of early adoption increases.

Security Architecture Modernization

IPv6’s native IPsec capabilities provide opportunities for enhanced security models between network endpoints and storage services. Organizations can implement end-to-end encryption more seamlessly with IPv6, potentially simplifying compliance with data protection regulations.

Operational Efficiency Gains

The elimination of NAT and address translation overhead reduces operational complexity and potential troubleshooting challenges. For organizations with large-scale infrastructure, these efficiency gains compound over time, reducing operational costs and improving system reliability.

BGP Zombies and Excessive Path Hunting: How Undead Routes Disrupt Internet Traffic

In the vast, interconnected landscape of the internet, routing protocols play a crucial role in directing traffic efficiently between networks. When these protocols malfunction, they can create unusual phenomena with significant operational impacts. One such phenomenon, appropriately named “BGP zombies,” has been affecting internet routing and causing headaches for network operators worldwide. At InterLIR, where we specialize in IPv4 address management and network resource optimization, understanding these routing anomalies is essential for helping our clients maintain stable, efficient network operations.

As someone who works daily with organizations managing IP resources and network infrastructure, I’ve seen firsthand how routing instabilities can impact business operations. BGP zombies represent one of the more insidious challenges in modern internet routing-routes that refuse to die gracefully, creating cascading effects that can disrupt connectivity and degrade performance across vast portions of the internet.

Understanding BGP and Its Undead Routes

Border Gateway Protocol (BGP) serves as the foundation of internet routing, essentially functioning as the internet’s GPS system. It enables autonomous systems (ASes) to exchange routing information and determine optimal paths for traffic flow. For organizations acquiring IPv4 address blocks through marketplaces like InterLIR, proper BGP configuration and management becomes critical to ensuring those resources function effectively within the global routing infrastructure.

A BGP zombie is a route that persists in the Internet’s Default-Free Zone (DFZ) after it should have been withdrawn. These routes become “undead” when the withdrawal message fails to propagate fully across the network, causing packets to be routed incorrectly or trapped in loops. The consequences range from minor inefficiencies to significant outages affecting user experience across vast portions of the internet. For businesses relying on consistent network availability-a core concern we address at InterLIR-these routing anomalies can translate directly into revenue loss and customer dissatisfaction.

What Causes BGP Zombies?

Understanding the root causes of BGP zombies helps network operators implement preventive measures and respond effectively when issues arise:

From our perspective at InterLIR, helping clients understand these technical factors is part of ensuring they can effectively manage the IPv4 resources they acquire. Network availability problems-which our mission centers on solving-often stem from routing instabilities like BGP zombies rather than simple address exhaustion.

The Path Hunting Process: How Zombies Form

To understand BGP zombies, we must first grasp the concept of path hunting. Path hunting occurs when BGP routers search for the best route to a destination after a previously known route disappears. This process follows specific rules based on longest prefix matching (LPM) and various BGP attributes such as AS path length and local preference.

When a more-specific prefix (for example, a /24 in IPv4 space) is withdrawn, routers must fall back to less-specific routes (such as a /22 or /20) to maintain connectivity. This transition period, during which routers hunt for alternative paths, creates an opportunity for zombies to emerge. For organizations managing multiple IPv4 blocks with varying levels of specificity-a common scenario among our clients-understanding this mechanism becomes particularly important.

Anatomy of a Path Hunting Scenario

Consider this simplified scenario: a network announces two prefixes: 192.0.2.0/22 (less-specific) and 192.0.2.0/24 (more-specific). Initially, all traffic to addresses within the /24 range follows the more-specific route due to longest prefix matching rules. When the network withdraws the /24 announcement, all routers should eventually converge on using the /22 route for that traffic.

However, BGP convergence isn’t instantaneous. Some routers process the withdrawal faster than others, creating a temporary state where:

This inconsistency can lead to routing loops, excessive latency, or even packet loss until all routers converge on the new routing state. In my experience working with clients at InterLIR, these convergence delays often catch network operators by surprise, particularly when they’re implementing changes to their IP address announcements for the first time.

The MRAI Factor: Amplifying Path Hunting Time

The Minimum Route Advertisement Interval (MRAI) significantly contributes to the zombie problem. Specified in RFC4271, MRAI introduces an intentional delay-typically 30 seconds for eBGP updates-between consecutive BGP advertisements from a router. While this prevents excessive BGP message churn and potential route oscillation, it also extends the path hunting duration, potentially allowing zombies to persist longer.

This design trade-off highlights a fundamental challenge in BGP: balancing rapid convergence against routing stability. The 30-second MRAI timer made sense when the internet was smaller and less dynamic, but as networks have grown more complex and interconnected, this delay can feel like an eternity during critical routing changes.

Real-World Zombie Variants Observed in the Wild

Through controlled experiments and real-world observations, researchers at Cloudflare have identified several variants of BGP zombies with distinct characteristics and behaviors. Understanding these variants helps network operators diagnose and address zombie-related issues more effectively.

Variant A: Ghoulish Gateways

This zombie variant manifests between upstream Internet Service Providers (ISPs). When one router in a provider’s network processes withdrawal messages slower than others, routes can become stuck, creating loops between providers. These loops cause packets to bounce back and forth between networks, never reaching their destination.

For example, Cloudflare observed routing loops between two upstream partners after withdrawing a test prefix, with packets bouncing between provider networks for approximately six minutes before convergence-significantly longer than most operators would expect for normal BGP convergence. For businesses dependent on consistent connectivity, six minutes of routing instability can represent substantial service disruption.

This variant particularly affects organizations with multi-homed network architectures-a common configuration among enterprises managing their own IPv4 address space. When working with clients at InterLIR who are establishing their first autonomous system, we emphasize the importance of understanding these inter-provider dynamics.

Variant B: Undead LAN (Local Area Network)

The second variant occurs entirely within a single network. When a route is withdrawn, each device within the network must individually process the withdrawal. If one router lags behind, it can create internal routing loops where packets circulate endlessly between routers within the same organization’s infrastructure.

These internal loops persist until all devices within the network reach a consistent view of the routing table. While typically shorter-lived than inter-provider zombies, internal zombies can be particularly frustrating because they occur within infrastructure that operators directly control and expect to behave predictably.

Zombie Lifespans: IPv4 vs. IPv6

Interestingly, research has revealed that BGP zombies exhibit different behaviors across IP protocols, with significant implications for network planning and operations:

The disparity likely stems from the significantly larger number of IPv4 prefixes in the global routing table compared to IPv6. With more routes to process, BGP speakers may take longer to converge after withdrawals in IPv4 space. This observation has particular relevance for our work at InterLIR, where we focus specifically on IPv4 address markets. The larger IPv4 routing table and longer convergence times mean that organizations managing IPv4 resources face greater exposure to zombie-related disruptions.

Network Interconnection Impact on Zombie Duration

Research has also highlighted how network interconnection levels affect zombie persistence. Highly peered networks with thousands of global connections show longer zombie lifespans when withdrawing routes. Withdrawals from less well-peered networks resulted in faster convergence times-though even these “faster” times (around 20 seconds) can still cause significant operational impacts.

This finding creates an interesting paradox: the more well-connected and resilient your network becomes through extensive peering, the more susceptible you may be to prolonged BGP zombie events. Organizations expanding their network footprint need to balance connectivity benefits against increased convergence complexity.

Mitigating the BGP Zombie Outbreak

Based on research findings that withdrawing more-specific prefixes leads to longer-lived zombies, several practical approaches can reduce their impact. At InterLIR, we work with clients to implement these strategies as part of comprehensive network availability solutions.

Internal Network Improvements

1️⃣ Graceful traffic forwarding – Implementing BGP forwarding improvements that allow more graceful withdrawal of traffic, even when routes are erroneously pointing toward a network. This might include maintaining forwarding state temporarily after route withdrawal to allow stragglers to converge.

2️⃣ Tunneled connectivity – Maintaining ability to deliver traffic over tunneled connections or private network interconnects even when public routing is compromised. GRE tunnels, MPLS, or SD-WAN overlays can provide alternative paths during BGP instability.

3️⃣ BGP community functionality – Utilizing BGP communities like no-export to control route propagation during withdrawal scenarios. Proper community tagging allows more granular control over how routes propagate and withdraw across the internet.

4️⃣ Route monitoring and alerting – Implementing real-time monitoring systems that detect anomalous routing behavior and alert operators to potential zombie situations before they cause widespread impact.

 

Recommended Multi-Step Draining Process

For scenarios where organizations need to drain traffic from on-demand BGP prefixes without introducing route loops or blackhole events, research suggests this approach:

1️⃣ Start with prefix announcement – Organization already announces example prefix (e.g., 198.18.0.0/24) from a provider network or transit connection

2️⃣ Introduce same-length announcement – Organization begins natively announcing the same-length prefix from their own network to destination ISPs, creating redundant path availability

3️⃣ Verification period – Monitor routing tables across multiple vantage points to confirm the new announcement has propagated globally and is being accepted by major transit providers

4️⃣ Withdrawal after stabilization – After sufficient time (typically 5-10 minutes allowing for propagation), signal withdrawal from the original provider network

5️⃣ Post-withdrawal monitoring – Continue monitoring for zombie routes and convergence issues for at least 15-20 minutes after withdrawal

This method prevents excessive path hunting because routers don’t need to aggressively seek a missing more-specific prefix; they can immediately fall back to the same-length announcement that already exists in the routing table. When advising clients at InterLIR on IP address management strategies, we emphasize this type of careful, methodical approach to routing changes.

Industry Implications and Future Directions

BGP zombies represent a significant challenge for the internet’s routing infrastructure, particularly as networks become more interconnected and traffic volumes increase. The research conducted has broader implications for network operators, content delivery networks, and the internet ecosystem as a whole-implications that directly affect how we approach network availability problems at InterLIR.

Recommendations for Network Operators

Based on current research and operational experience, network operators should consider the following practices:

Industry Standardization Efforts

The findings highlight the need for broader industry collaboration on BGP best practices and potential protocol improvements. Some areas for standardization might include:

At InterLIR, we stay engaged with these industry developments because they directly impact how effectively organizations can utilize the IPv4 resources they acquire through our marketplace. Network availability isn’t just about having addresses-it’s about ensuring those addresses function reliably within the global routing infrastructure.

Practical Considerations for IPv4 Resource Management

For organizations acquiring IPv4 address blocks-whether through transfer markets like InterLIR or other means-understanding BGP zombies has practical implications for resource deployment and management:

Prefix Size and Announcement Strategy

The size and specificity of announced prefixes directly affects zombie susceptibility. Organizations should consider:

Provider Selection and Peering Strategy

The research on zombie duration across different network interconnection levels suggests that provider selection matters:

CGNAT Detection: Reducing Collateral Damage in a Shared IP Internet

As Head of Sales at InterLIR, I’ve witnessed firsthand how the global IPv4 address shortage has fundamentally transformed network operations. Since our founding in 2020, we’ve been at the forefront of the IPv4 marketplace, helping organizations navigate the complexities of IP resource management. One of the most significant developments in this landscape has been the widespread adoption of Carrier-Grade Network Address Translation (CGNAT)-a technology that, while solving immediate resource constraints, creates profound challenges for security, user experience, and digital equity.

This article examines the innovative approaches to detecting CGNAT implementations and mitigating their unintended consequences, drawing on recent research and our practical experience in the IP address marketplace. Understanding these dynamics is crucial for any organization making decisions about IP resource allocation, security infrastructure, or global service delivery.

The Evolution of IP Address Sharing

Throughout my career in IP resource management, I’ve observed how the fundamental assumptions about IP addresses have shifted dramatically. Historically, IP addresses served as stable identifiers for both routing and non-routing purposes, including geolocation, security operations, and user identification. Many critical security mechanisms-such as blocklists, rate limiting, and anomaly detection-were built on the assumption that a single IP address represents one coherent entity, typically a single user or device.

However, the Internet’s structure has fundamentally changed. Today, a single IPv4 address may represent hundreds or even thousands of users due to widespread implementation of technologies like Carrier-Grade Network Address Translation (CGNAT), virtual private networks (VPNs), and proxy middleboxes. This transformation has profound implications for how we approach network security, user authentication, and service delivery.

Types of Large-Scale IP Sharing

In our work at InterLIR, we help clients understand the different mechanisms of IP address sharing and their business implications. The distinction between these sharing mechanisms is crucial for developing appropriate security and access policies:

Understanding these distinctions is essential for business decision-making. While VPNs and proxies represent voluntary adoption by users, CGNAT is typically implemented by Internet Service Providers (ISPs) without user knowledge or consent. This makes it an involuntary form of address sharing that disproportionately affects users in developing regions-a critical consideration for companies with global customer bases.

The Socioeconomic Implications of IP Address Scarcity

Working in the IPv4 marketplace since 2020, I’ve gained unique insights into how IP address distribution reflects historical patterns rather than current needs. The distribution of IPv4 addresses globally mirrors the early development of the Internet, with countries in North America and Europe receiving vast allocations during the 1980s and 1990s, while developing regions with later Internet adoption received significantly fewer addresses relative to their populations.

This imbalance creates a striking disparity in the user-to-IP ratio across different regions. In many parts of Africa and South Asia, a single IP address may serve hundreds or thousands of users, while in Australia, Canada, Europe, and the United States, the ratio is much lower. At InterLIR, we see this disparity reflected in market demand-organizations in regions with severe IPv4 scarcity often face difficult choices between expensive IP address acquisitions and implementing CGNAT solutions.

The Unintended Digital Divide

The implications of this disparity extend far beyond technical considerations and directly impact business operations. When security mechanisms, content delivery networks, or online services make decisions based on IP address behavior, they unintentionally create a form of socioeconomic bias that can affect market access and customer experience.

For businesses operating globally, these factors represent both challenges and opportunities. Organizations that understand and adapt to these realities can gain competitive advantages in emerging markets while those that ignore them risk alienating significant user populations.

Understanding CGNAT Implementation

In my role at InterLIR, I regularly advise clients on the technical and business implications of CGNAT deployment. Carrier-Grade NAT represents an enterprise-scale implementation of address translation technology that fundamentally changes how networks operate. To understand CGNAT’s impact, it helps to compare it with the familiar home router network address translation (NAT).

From Home NAT to Carrier-Grade NAT

Most home networks use a simple form of NAT in their broadband router (Customer Premises Equipment or CPE). This first-level NAT translates private addresses within the home (typically in the 192.168.x.x range) to the single public IP address assigned by the ISP. This is a familiar technology that has been in widespread use for decades.

CGNAT introduces a second layer of translation at the ISP level, creating what we call “double NAT” scenarios. When implemented, the ISP assigns a private IP address (often from the 100.64.0.0/10 range defined in RFC 6598) to the customer’s router instead of a public IP. This private address is then translated again at the ISP’s CGNAT device, allowing many subscribers to share a single public IP address.

The Technical Necessity Behind CGNAT

The primary driver for CGNAT deployment is the exhaustion of the IPv4 address space-a reality that defines our business at InterLIR. With only 4.3 billion possible addresses in the IPv4 system and over 5 billion Internet users globally, the mathematical shortfall is obvious. By the early 2010s, all Regional Internet Registries (RIRs) had depleted their pools of unallocated IPv4 addresses, creating the secondary market where we operate.

While IPv6 adoption continues to grow, its deployment remains incomplete. CGNAT serves as a bridge technology, allowing ISPs to maximize the use of their existing IPv4 allocations while the transition to IPv6 proceeds. What was initially conceived as a temporary solution has become, in many networks, a permanent feature. This reality shapes our strategic advice to clients: IPv4 resources remain valuable and necessary for the foreseeable future, even as IPv6 deployment accelerates.

The Challenge of CGNAT Detection

One of the most complex challenges we discuss with clients at InterLIR involves identifying which IP addresses are used for CGNAT. Unlike VPNs or proxies, which can often be identified through published lists or service directories, CGNAT implementations are not publicly disclosed by ISPs. This lack of transparency creates significant challenges for services attempting to differentiate between single-user IPs and those shared among hundreds or thousands of users.

Multi-Faceted Detection Approaches

Leading technology companies have developed sophisticated detection methodologies that combine network measurement techniques, public data mining, and machine learning to identify and classify IP sharing at scale. These approaches build reliable training datasets through several complementary methods:

1️⃣ Distributed traceroutes – Using global probe networks to detect multi-level NAT implementations through hop analysis

2️⃣ WHOIS and PTR record analysis – Mining DNS and registry data for keywords indicating CGNAT usage, such as “cgnat,” “cgn,” or “lsn”

3️⃣ VPN and proxy directories – Compiling reference lists of known non-CGNAT address sharing services for comparison

4️⃣ Feature extraction – Analyzing HTTP request logs to identify distinctive behavior patterns that indicate shared usage

5️⃣ Machine learning classification – Training models to distinguish between different types of shared IPs based on behavioral signatures

Network Measurement Techniques

Traceroute analysis provides powerful insights into NAT deployments that we often discuss with our technical clients. By examining the hop sequence from a client to its own public IP, researchers can detect the presence of shared address space (100.64.0.0/10) or multiple layers of private addressing that strongly indicate CGNAT implementation.

Additionally, many operators encode metadata about their network configurations in DNS reverse lookup (PTR) records. Keywords such as “cgnat,” “cgn,” or “lsn” (Large-Scale NAT) in these records can signal CGNAT deployment. Similarly, WHOIS records and Internet Routing Registry (IRR) entries may contain organizational details or remarks that reveal CGNAT usage. At InterLIR, we leverage these data sources to help clients understand the characteristics of IP address blocks they’re considering for acquisition.

Machine Learning for CGNAT Classification

The most sophisticated approaches to CGNAT detection leverage supervised machine learning to build classifiers that can distinguish between different types of IP addresses: standard single-user IPs, CGNAT-shared IPs, and VPN/proxy IPs. The success of this classification depends heavily on the quality of the training data and the selection of discriminative features.

Feature Selection and Extraction

The key hypothesis underlying effective feature selection is that the aggregated activity from CGNAT IPs shows distinctive patterns of diversity compared to other IP types. This diversity stems from the fundamental nature of CGNAT: hundreds or thousands of independent users sharing a single IP address will naturally generate more varied patterns than a single user or a more homogeneous proxy service.

Importantly, the classification focuses not just on traffic volume but on diversity metrics. While high-volume scanners or bots might generate many requests, they typically show low information diversity. Conversely, CGNAT IPs demonstrate high diversity across multiple dimensions due to the varied user base behind them. This distinction is crucial for avoiding false positives that could impact legitimate high-volume users.

Classification Results and Business Applications

Using datasets of hundreds of thousands of labeled CGNAT IPs, VPN and proxy IPs, and non-shared IPs, advanced classifiers can distinguish between these categories with high accuracy. The resulting models enable more nuanced treatment of traffic based on the likelihood that an IP represents multiple users.

From a business perspective, this classification capability allows organizations to implement more sophisticated security and access policies. For instance, rate limiting might be applied differently to a CGNAT IP representing thousands of legitimate users than to a VPN exit node potentially being used for abuse. This nuanced approach can significantly improve customer experience while maintaining security posture.

Mitigating Collateral Damage

The ultimate goal of CGNAT detection is to reduce the collateral damage caused by security mechanisms that treat all IP addresses equally. In my work at InterLIR, I’ve seen how organizations struggle with this balance-they need robust security but don’t want to alienate legitimate users, particularly in markets where CGNAT is prevalent.

Graduated Response Mechanisms

Traditional security approaches often use binary decisions: an IP is either blocked or allowed. For CGNAT IPs, a more nuanced approach is necessary to avoid punishing hundreds of innocent users for the actions of one bad actor. Modern security architectures should implement:

These approaches help balance security needs with user experience, particularly for users in regions where CGNAT is prevalent due to IP scarcity. For businesses, implementing these strategies can mean the difference between losing customers in emerging markets and successfully serving them.

Industry Implications and Market Opportunities

The problem of CGNAT-related collateral damage extends beyond any single service provider and represents both a challenge and an opportunity for the industry. Security vendors, content delivery networks, and online services all make decisions based on IP reputation that could benefit from greater awareness of large-scale IP sharing.

At InterLIR, we see this creating market opportunities in several areas. Organizations that can effectively serve users behind CGNAT gain competitive advantages in high-growth markets. Additionally, the continued need for public IPv4 addresses-particularly for services that cannot effectively operate behind CGNAT-sustains demand in the IPv4 marketplace where we operate.

The Internet Engineering Task Force (IETF) has long recognized these challenges through standards documents like RFC 6269 and RFC 7021, but practical implementations of CGNAT-aware security remain limited. Organizations that invest in sophisticated IP classification and adaptive security measures position themselves for success in an increasingly CGNAT-prevalent Internet.

Future Directions and Strategic Considerations

While IPv6 adoption continues to grow-a trend we actively support and encourage at InterLIR-CGNAT implementations are likely to persist for the foreseeable future. Several challenges and opportunities remain in this area that organizations should consider in their strategic planning:

The research also points to the need for more standardized approaches to CGNAT implementation and disclosure. Greater transparency from network operators about address sharing practices would benefit the entire ecosystem. At InterLIR, we advocate for industry standards that balance operational needs with transparency, helping all stakeholders make better-informed decisions.

Strategic Recommendations for Organizations

Based on our experience in the IP address marketplace and our understanding of CGNAT dynamics, I recommend organizations consider the following strategic approaches:

Invest in sophisticated IP classification – Don’t rely on simple IP-based security measures; implement or acquire technology that can distinguish between different types of IP sharing

Develop CGNAT-aware policies – Review and update security, rate limiting, and access control policies to account for large-scale IP sharing

Monitor emerging markets – Pay particular attention to user experience in regions where CGNAT is prevalent, as these often represent high-growth opportunities

Plan for dual-stack operations – While maintaining IPv4 capabilities, accelerate IPv6 deployment to reduce long-term dependence on address sharing technologies

Consider IPv4 resource strategy – Evaluate whether acquiring additional IPv4 addresses or implementing CGNAT makes more sense for your specific use case and market position