How Does an IP Address Get "Registered"? — From IANA to Your Home Router

In the last two articles, we learned how IP addresses are structured (subnet masks, CIDR, public vs. private) and how routing works (routing tables, longest prefix matching, hop-by-hop forwarding). But a question remains: who actually allocates these IP addresses? Why is 8.8.8.8 Google's DNS and 129.211.82.148 someone's cloud server? With billions of devices on the internet, how do we prevent collisions and chaos?

This article starts from the real-world experience of buying a cloud server and traces the complete chain of IP address allocation — from the top-level global authority all the way down to the device in your hand.

• Understand the global IP allocation hierarchy: IANA → RIR → ISP → end user
• Grasp the real meaning of /16 and /24 address blocks — why ISPs take blocks, not individual addresses
• Understand the relationship between BGP route announcements and IP allocation — why a network can only find you after you've both been allocated an address and announced a route
• Know how CG-NAT, the address market, and IPv6 respond to IPv4 exhaustion

• Understand IP addresses, subnet masks, and CIDR basics

• Understand routing fundamentals

You open the Tencent Cloud console and order a lightweight cloud server. A few minutes later, the system tells you: "Public IP: 129.211.82.148."

Where did this IP come from? Why isn't it 8.8.8.8 (that's Google's)? Why doesn't it collide with your neighbor's IP 129.211.82.147? With hundreds of millions of servers worldwide, who coordinates all of this?

The answer lies in a strict top-down allocation chain. Its starting point is an organization you've probably never heard of.

The top authority for global IP address management is IANA (Internet Assigned Numbers Authority). It doesn't hand out addresses directly to individuals or companies. Instead, it divides the entire IPv4 address space (roughly 4.3 billion addresses) into /8 blocks (each containing about 16.77 million IPs) and delegates them to five Regional Internet Registries (RIRs):

Each RIR manages its region's IP pool. APNIC manages the Asia-Pacific region. Tencent Cloud, Alibaba Cloud, China Telecom, and other ISPs all apply for address blocks from APNIC.

IANA's IPv4 address pool was fully allocated in 2011 — all 4.3 billion IPs were handed out. Since then, RIRs can only maintain their inventories through returns and reclamation.

You might think: Tencent Cloud has sold hundreds of thousands of cloud servers. So does it apply to APNIC for hundreds of thousands of individual IP addresses?

No. ISPs get addresses in blocks, with the smallest unit being /24 (256 IPs). For example, Tencent Cloud might apply to APNIC for a /16 block: 129.211.0.0/16, covering all 65,536 IPs from 129.211.0.0 to 129.211.255.255.

Block allocation exists for two reasons:

1. Routing table size is the internet's core constraint

If an ISP announced one route to the world for every single IP it received, the global routing table would explode. In reality, BGP only needs to announce one route: "129.211.0.0/16 belongs to Tencent Cloud." That single entry covers all 65,536 IPs — traffic for any of them converges at Tencent Cloud's border routers, which then distribute it internally.

This is CIDR's real power: one route entry replaces tens of thousands, compressing the global routing table from millions of entries to hundreds of thousands.

2. IP allocation and route announcement are coupled

Acquiring an address block and announcing it via BGP go hand in hand. The ISP announces to the world: "Route all traffic for this block to me." Only after that announcement do other networks know how to reach those IPs. If you get an IP but never announce a route for it, it's unreachable.

After Tencent Cloud receives 129.211.0.0/16, here's what happens:

1. Subnetting: Internal planning divides the 65,536 IPs into /24 subnets (256 IPs each) — 256 subnets total. Each subnet is assigned to a different availability zone or data center. For example, 129.211.82.0/24 goes to a Shanghai data center; 129.211.83.0/24 goes to a Guangzhou data center.

2. Automated assignment: You click "Create Server" in the console and choose the Shanghai data center. Tencent Cloud's backend queries the 129.211.82.0/24 pool for available IPs, finds that .148 is unused, and binds it to your server's virtual network interface.

3. Route distribution: The system updates the relevant switches and routers in that data center to ensure packets destined for 129.211.82.148 are correctly delivered to your server.

So 129.211.82.148 isn't random — it traveled a complete allocation chain: IANA → APNIC → Tencent Cloud → Shanghai data center → your server.

IANA's pool ran dry in 2011. RIR pools followed — APNIC reached its final phase in 2011, and RIPE NCC announced in 2019 that no new addresses remained.

Three parallel approaches are underway:

1. CG-NAT (Carrier-Grade NAT)

This is the most common transitional solution today. Your ISP (e.g., China Telecom) assigns your connection a carrier-grade private IP (like 10.x.x.x or 100.64.x.x), with hundreds of users sharing a single public IP for outbound traffic.

What this means for you: your router doesn't directly own a public IP. You can't do port forwarding. P2P connections become harder. The upside? ISPs conserve public IPs.

If your home PPPoE connection gets an IP starting with 100.x.x.x — you're behind CG-NAT.

2. The IPv4 address market

Unused large blocks can be traded on the open market. MIT once held the entire 18.0.0.0/8 block (16.77 million IPs) and later sold a portion to Amazon Web Services. These transactions cost more than applying to an RIR, but they're worth it for cloud providers that need large pools of public IPs.

3. IPv6

The fundamental solution. The IPv6 address space is 2^128 — roughly 340 undecillion addresses — enough to assign an IP to every grain of sand on Earth. But global deployment has been slow (as of 2025, about 45% of users can access IPv6 websites), primarily due to the cost of replacing legacy network equipment.

1. Log into your cloud server console and check its public IP. Run whois <your-ip> to see which ISP owns it and which address block it belongs to.
2. Use traceroute 8.8.8.8 (Linux/macOS) to trace the path from your machine to Google DNS and observe CIDR aggregation in action — the intermediate routers' IP prefixes should grow progressively shorter.
3. If you have a cloud server in China, use curl ip.sb to check whether you have a truly independent public IP or are sharing an egress.

• IP addresses flow through a five-level hierarchy: IANA → RIR → ISP → subnet → end user
• ISPs receive addresses in blocks like /16 and /24, not individual addresses — this is the foundation of CIDR aggregation and routing table compression
• Acquiring an address block is coupled with BGP route announcement; without a route, the address is unreachable
• IPv4 exhaustion has three parallel responses: CG-NAT (shared public egress), the address trading market, and IPv6 (the fundamental fix)

Three articles down, the network layer (L3) is complete: IP address structure (subnetting/CIDR), routing and forwarding (routing tables/hop-by-hop), and address allocation (IANA → ISP). But IP only provides "best-effort" delivery — it doesn't guarantee arrival, ordering, or uniqueness.

Who handles these problems? The next article enters the transport layer and its core protocol — TCP: how does the three-way handshake establish a reliable connection atop unreliable IP? How do sequence numbers and acknowledgments prevent data loss and reordering? How does the sliding window prevent the receiver from being overwhelmed? And how does congestion control avoid crushing the network?