Loading content...
Every packet that traverses the public Internet carries two critical pieces of information: a source address and a destination address. For global communication to function, these addresses must be globally unique—no two devices anywhere on Earth can legitimately claim the same public IP address at the same time. This seemingly simple requirement has spawned one of the most complex administrative systems in computing: the global IP address allocation hierarchy.
Public addresses are the finite, carefully managed resource that makes the Internet possible. Unlike private addresses that can be reused across millions of independent networks, each public IP address represents a specific, unique point of presence on the global network. The total supply—approximately 3.7 billion usable addresses—must serve an interconnected world of over 8 billion people and tens of billions of devices.
This page provides comprehensive coverage of public IPv4 addressing: how addresses are allocated through the global hierarchy, the role of Regional Internet Registries (RIRs), the distinction between provider-aggregatable and provider-independent addresses, IP acquisition mechanisms, and the economic realities of the post-exhaustion IPv4 market.
The distribution of IPv4 addresses follows a carefully structured hierarchy, designed to ensure fair, documented, and technically sound allocation across the entire Internet. At the apex of this hierarchy sits the Internet Assigned Numbers Authority (IANA), which manages the global pool of unallocated addresses and delegates large blocks to regional authorities.
The three-tier hierarchy:
┌─────────────┐
│ IANA │ (Global Authority)
└──────┬──────┘
│
┌─────────┬─────────┬─┴───┬─────────┬─────────┐
│ │ │ │ │ │
┌───┴───┐ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐
│ ARIN │ │ RIPE │ │ APNIC │ │LACNIC │ │AFRINIC│ (Regional)
└───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘
│ │ │ │ │
┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐
│NIR│ │LIR│ │NIR│ │LIR│ │LIR│ (National/Local)
└─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘
│ │ │ │ │
┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐
│End│ │End│ │End│ │End│ │End│ (End Users)
│Usr│ │Usr│ │Usr│ │Usr│ │Usr│
└───┘ └───┘ └───┘ └───┘ └───┘
This hierarchical structure ensures that address allocation decisions are made by organizations with regional expertise while maintaining global coordination and preventing conflicts.
IANA (Internet Assigned Numbers Authority) operates as a function of ICANN (Internet Corporation for Assigned Names and Numbers), the non-profit organization that coordinates global Internet identifiers. While IANA handles the technical delegation of address blocks, ICANN provides the governance framework and stakeholder coordination.
Regional Internet Registries are the operational heart of address allocation. Each RIR manages IP address resources for a specific geographic region, operating as member-based organizations governed by the Internet community within their service areas. The five RIRs collectively serve the entire world.
| RIR | Full Name | Region | Established | Headquarters |
|---|---|---|---|---|
| ARIN | American Registry for Internet Numbers | North America, parts of Caribbean | 1997 | Chantilly, Virginia, USA |
| RIPE NCC | Réseaux IP Européens Network Coordination Centre | Europe, Middle East, Central Asia | 1992 | Amsterdam, Netherlands |
| APNIC | Asia-Pacific Network Information Centre | Asia-Pacific Region | 1993 | Brisbane, Australia |
| LACNIC | Latin America and Caribbean Network Information Centre | Latin America, Caribbean | 2002 | Montevideo, Uruguay |
| AFRINIC | African Network Information Centre | Africa | 2004 | Ebene, Mauritius |
RIR responsibilities include:
Anyone can look up who holds a specific public IP address using WHOIS services. Each RIR maintains a WHOIS database accessible via command line (whois 8.8.8.8) or web interfaces. The response includes the organization name, address block, and contact information—essential for abuse reporting and network troubleshooting.
The most significant fact about public IPv4 addresses today is their scarcity. IPv4 exhaustion—the depletion of the global pool of unallocated addresses—is not a future concern; it is a present reality that has fundamentally transformed how organizations acquire and manage IP addresses.
The exhaustion timeline:
| Date | Event |
|---|---|
| January 31, 2011 | IANA allocates final /8 blocks to RIRs |
| April 15, 2011 | APNIC reaches final /8 (Asia-Pacific exhausted) |
| September 14, 2012 | RIPE NCC reaches final /8 (Europe exhausted) |
| June 10, 2014 | LACNIC reaches final /8 (Latin America exhausted) |
| September 24, 2015 | ARIN exhausts free pool (North America exhausted) |
| January 2020 | RIPE NCC exhausts remaining reserve |
| July 2020 | LACNIC exhausts remaining reserve |
Post-exhaustion operations:
RIRs continue to operate after exhaustion, but their allocation models have changed dramatically:
IPv4 addresses have become a traded commodity. Prices have risen from approximately $7 per address in 2015 to over $35-50 per address in 2024, with large blocks ($60+ million for a /16) representing significant enterprise IT expenses. This economic reality accelerates IPv6 adoption while creating a robust secondary market.
Address reclamation efforts:
Before complete exhaustion, significant efforts recovered underutilized addresses:
| Organization | Returned | Year | Notes |
|---|---|---|---|
| Stanford University | /8 (16M addresses) | 2000 | Early return of Class A allocation |
| US DoD | Multiple /8s (partial) | 2011 | Returned excess from allocations |
| AT&T | /10 | 2017 | Consolidated legacy holdings |
| GE | /8 | 2017 | Returned historic allocation |
| Various | Ongoing | — | RIR audits identify abandoned resources |
Despite these efforts, exhaustion was inevitable given Internet growth rates. The 4.3 billion address limit cannot accommodate a world where every smartphone, laptop, server, IoT device, and vehicle demands connectivity.
Public addresses fall into two fundamental categories based on their relationship to Internet service providers. Understanding this distinction is crucial for network architects making decisions about address acquisition and multi-homing strategies.
Provider-Aggregatable (PA) addresses:
PA addresses are allocated to end users from their ISP's address block. The addresses 'belong' to the ISP and are merely delegated to the customer for the duration of the service relationship.
Provider-Independent (PI) addresses:
PI addresses are assigned directly to an organization by an RIR, independent of any particular ISP. The organization maintains these addresses regardless of their upstream connectivity.
PA Addressing: PI Addressing:
┌─────────────────┐ ┌─────────────────┐
│ ISP Block │ │ RIR Registry │
│ 203.0.113.0/24 │ │ │
└────────┬────────┘ └────────┬────────┘
│ │
│ Delegation │ Direct Assignment
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ Customer │ │ Organization │
│ 203.0.113.64/26 │ │ 198.51.100.0/24│
└─────────────────┘ └─────────┬───────┘
│ │
ISP Change ISP Change
= Renumber! = Just BGP!
│
┌─────────┼─────────┐
▼ ▼ ▼
ISP A ISP B ISP C
PI addresses are typically justified when: (1) the organization operates critical Internet infrastructure (web hosting, email, DNS), (2) multi-homing is required for redundancy, (3) ISP changes are anticipated, or (4) the organization participates directly in Internet routing via BGP. The overhead of RIR membership and BGP operations must be weighed against these benefits.
| Factor | Provider-Aggregatable (PA) | Provider-Independent (PI) |
|---|---|---|
| Ownership | ISP owns; customer uses | Organization owns directly |
| Acquisition Cost | Free (part of service) | $1,000+ registration + annual fees |
| ISP Portability | Must renumber on change | Portable across any provider |
| Multi-Homing | Limited/complex | Native support |
| BGP Requirements | None | Required (own AS number) |
| Routing Table Impact | Aggregated | Adds prefix to global table |
| Minimum Size | Typically /29 or smaller | /24 (smallest routable) |
Public IPv4 addresses are organized into blocks defined by CIDR notation. Understanding how these blocks are structured, sized, and allocated is fundamental to network planning and Internet routing comprehension.
/8 blocks (legacy Class A):
/8 blocks represent the largest units in IPv4 addressing, containing over 16 million addresses each. Originally assigned to single organizations, these massive allocations were made before anyone anticipated how valuable addresses would become.
Historic /8 allocations include:
| Block | Original Assignment | Current Status |
|---|---|---|
| 0.0.0.0/8 | Local identification | Special use (RFC 791) |
| 9.0.0.0/8 | IBM | IBM (still holds) |
| 12.0.0.0/8 | AT&T Bell Labs | AT&T |
| 15.0.0.0/8 | Hewlett-Packard | HPE |
| 17.0.0.0/8 | Apple Inc. | Apple |
| 18.0.0.0/8 | MIT | MIT |
| 56.0.0.0/8 | US Postal Service | USPS (returned partially) |
| 224.0.0.0/4 | Multicast | Special use |
Modern allocation sizes:
Today's allocations are much smaller, reflecting scarcity and fair distribution policies:
| Block Size | Addresses | Typical Recipient | Common Use |
|---|---|---|---|
| /24 | 256 | SMB, new entrants | Single site, small hosting |
| /23 | 512 | Growing companies | Multi-site small org |
| /22 | 1,024 | Medium ISP | Regional presence |
| /21 | 2,048 | Large enterprise | Multi-national presence |
| /20 | 4,096 | Major carrier | Significant infrastructure |
| /16 | 65,536 | Major ISP/cloud | Large-scale services |
The /24 minimum:
The Internet routing system has practical limits. Most ISPs filter announcements smaller than /24, meaning a /25 (128 addresses) or smaller cannot be independently routed. This creates the effective minimum block size for PI addressing:
/24 = 256 addresses (minimum routable)
/25 = 128 addresses (typically filtered, not routable independently)
/26 = 64 addresses (definitely filtered)
Every announced prefix adds entries to the global routing table, currently exceeding 950,000 entries. Network operators filter small prefixes partly to prevent this table from growing unmanageably. Organizations considering PI addresses must understand this ecosystem constraint.
In the post-exhaustion era, organizations have several pathways to obtain public IPv4 addresses, each with distinct costs, timelines, and considerations.
| Method | Timeline | Cost (/24) | Ownership | Portability |
|---|---|---|---|---|
| ISP Allocation | Days | Free (service) | ISP | None |
| RIR Waiting List | Weeks-Years | ~$500-1000 fees | Organization | Full |
| Transfer Purchase | 1-3 months | $10-20K | Organization | Full |
| Lease/Rental | Days | $500-2000/month | Third party | Contract-based |
| Cloud Provider | Immediate | ~$100-150/month | Cloud provider | None |
When purchasing addresses through the transfer market, verify the block's history: check RIR WHOIS databases for legitimate ownership, review blocklist status (some blocks are tainted by spam/abuse history), and use transfer brokers with escrow services. A block with abuse history may be blocked by major email providers or CDNs.
Not all publicly routable address space is available for general assignment. Certain blocks are reserved for special purposes, and understanding these reservations prevents confusion and configuration errors.
| Block | Purpose | RFC | Notes |
|---|---|---|---|
| 0.0.0.0/8 | This Host | RFC 791 | Used in source field during boot |
| 224.0.0.0/4 | Multicast | RFC 5771 | 224.0.0.0 – 239.255.255.255 |
| 240.0.0.0/4 | Reserved | RFC 1112 | Historically reserved; experimental use |
| 255.255.255.255 | Limited Broadcast | RFC 919 | Local network broadcast |
| 192.88.99.0/24 | 6to4 Relay | RFC 3068 | IPv6 transition mechanism |
| 198.18.0.0/15 | Benchmarking | RFC 2544 | Network device testing |
Well-known public addresses:
Certain public addresses have become widely recognized due to their widespread use in public services:
| Address | Service | Operator | Purpose |
|---|---|---|---|
| 8.8.8.8 | Google Public DNS | Primary DNS resolver | |
| 8.8.4.4 | Google Public DNS | Secondary DNS resolver | |
| 1.1.1.1 | Cloudflare DNS | Cloudflare | Fast, privacy-focused DNS |
| 9.9.9.9 | Quad9 DNS | Quad9 | Security-focused DNS |
| 208.67.222.222 | OpenDNS | Cisco | Family-safe DNS option |
| 4.2.2.1 | Level 3 DNS | Lumen | Legacy public resolver |
These addresses are sometimes hardcoded in applications and network configurations, creating implicit dependencies on their continued operation.
Network security practitioners use 'bogon' to describe addresses that should never appear in Internet routing—including unallocated space, private ranges, and special-use blocks. Bogon filtering blocks traffic from these addresses at network borders, preventing spoofing attacks and misconfigurations from impacting network security.
The ability to determine who operates any given public IP address is fundamental to Internet operations, security incident response, and abuse mitigation. WHOIS databases—and their modern successor RDAP—provide this crucial lookup capability.
Querying WHOIS:
# Command-line WHOIS query
$ whois 8.8.8.8
NetRange: 8.0.0.0 - 8.255.255.255
CIDR: 8.0.0.0/8
NetName: LVLT-ORG-8-8
NetHandle: NET-8-0-0-0-1
Parent: ()
NetType: Direct Allocation
Organization: Google LLC (GOGL)
RegDate: 2023-12-28
Updated: 2023-12-28
Ref: https://rdap.arin.net/registry/ip/8.0.0.0
OrgName: Google LLC
OrgId: GOGL
Address: 1600 Amphitheatre Parkway
City: Mountain View
StateProv: CA
PostalCode: 94043
Country: US
...
RDAP (Registration Data Access Protocol):
RDAP is the modern, structured replacement for WHOIS, offering:
WHOIS data is self-reported and may be outdated, inaccurate, or intentionally obscured. GDPR and privacy regulations have further reduced the personal information available in European (RIPE) records. For authoritative ownership verification, RIR-maintained databases (via RDAP) are more reliable than third-party aggregators.
Public IP addresses are the globally unique identifiers that enable Internet communication. Their scarcity, careful management, and economic value make understanding them essential for any network professional.
What's next:
Having explored both private and public addressing independently, the next page examines address conservation—the strategies and technologies developed to extend IPv4's useful life despite exhaustion. Understanding conservation illuminates why NAT became ubiquitous and why IPv6 adoption remains slow despite pressing need.
You now understand how public IPv4 addresses are structured, allocated, and acquired in the post-exhaustion Internet. This knowledge is essential for network planning, cost estimation, and architectural decisions involving Internet connectivity.