Every public IP address on the internet has been allocated through a structured hierarchy: from IANA to Regional Internet Registries (RIRs) to Local Internet Registries (LIRs) to end users. This isn’t just bureaucracy — the allocation chain is what makes WHOIS lookups meaningful, what underpins IP geolocation, and what determines who can announce what.

This post walks through the allocation chain, explains who does what, and shows how to read allocation records to learn things about an IP that geolocation alone won’t tell you.

The Allocation Hierarchy

Level 1: IANA

The Internet Assigned Numbers Authority is the top of the chain. IANA allocates large blocks (typically /8 in IPv4 historically; larger in IPv6) to the five RIRs. IANA itself doesn’t allocate to end users directly — they delegate everything to RIRs.

Level 2: Regional Internet Registries (RIRs)

Five regional registries each cover a geographic region:

ARIN — North America (and a few small territories elsewhere).
RIPE NCC — Europe, Middle East, parts of Central Asia.
APNIC — Asia-Pacific.
LACNIC — Latin America and the Caribbean.
AFRINIC — Africa.

Each RIR allocates blocks to LIRs within its region.

Level 3: Local Internet Registries (LIRs)

LIRs are usually ISPs, large hosting companies, or large enterprises. They receive allocations from their RIR and either:

Use them for their own infrastructure.
Sub-allocate to downstream customers.

To become an LIR, you typically pay an annual fee to your RIR and demonstrate need for the allocation.

Level 4: End-user allocations

LIRs assign blocks (often /24 or smaller) to their customers — businesses, smaller ISPs, individual companies. These show up in WHOIS as belonging to the end customer, with the LIR as the parent.

Level 5: End users

Individual users typically get one or a few IPs from their ISP via DHCP. These rarely show up explicitly in WHOIS at the per-IP level; they’re part of the ISP’s pool.

Why the Hierarchy Exists

A few practical reasons:

Distributed governance

No single entity makes all the decisions globally. Each RIR sets policy for its region based on local stakeholder input. ARIN’s policies differ from RIPE’s; that’s intentional.

Routing aggregation

LIRs announce their /20 or /16 to the internet. The individual /24 sub-allocations don’t need separate BGP announcements. This keeps the global routing table manageable.

Need-based assignment

RIR policies (mostly) require demonstrated need before allocating. This was important pre-exhaustion; less so now that the IPv4 free pool is empty.

Accountability

Allocations are tied to organizational identities. If an IP is doing something abusive, you can trace it through WHOIS to a responsible party.

What an Allocation Record Contains

An RIR record for an IP block typically includes:

Prefix / range — Which IPs are in the block.
Holder — The organization to which it’s allocated.
Country — The country code (often the country where the holder is registered, not necessarily where the IPs are used).
Status — Allocated, assigned, available, reserved.
Date allocated — When the block was assigned.
AS number — The ASN authorized to announce it.
Abuse contact — Who to email about abuse from this block.
Sub-allocations — If the block has been further allocated to downstream customers.

For more on querying these records, see WHOIS lookups.

Allocation Trees: An Example

Consider IP 8.8.8.8. The allocation tree:

IANA allocated 8.0.0.0/8 (Class A) to ARIN historically.
ARIN later sub-allocated portions of 8.0.0.0/8 to various organizations.
One of those organizations was Level 3 Communications (later CenturyLink, now Lumen).
Level 3 sold or transferred 8.8.8.0/24 to Google.
Google announces it from AS15169.

You can trace this chain through WHOIS and historical records. Recent allocations are easy; very old allocations sometimes have gaps.

RIR Policy Differences

Each RIR has its own policies. A few notable differences:

ARIN

Most rigid documentation requirements.
Strictest “need justification” before allocation.
Most legal scrutiny for transfers.

RIPE NCC

Open membership; LIR status easier to obtain.
More liquid transfer market.
GDPR-shaped WHOIS data minimization.

APNIC

Most liquid transfer market by volume.
Streamlined IPv6 allocation.
Strong technical engagement.

LACNIC

Smaller membership.
Politically engaged with regional government issues.

AFRINIC

Has had governance disputes and litigation.
IPv4 reserve allocations still being slowly distributed.

For application developers, these policy differences rarely matter directly. They show up indirectly: an IP in RIPE’s region has more sparse WHOIS data; an IP in ARIN’s region has richer abuse contacts.

How LIRs Sub-Allocate

A typical ISP receives a /20 (4096 addresses) from their RIR. They might:

Use part for their own infrastructure (NOC, web servers, customer-facing services).
Allocate /24s (256 each) to business customers.
Pool /29s (8 each) for small business customers.
Pool individual addresses for residential customers (one per home behind NAT).

The sub-allocations show up in WHOIS:

inetnum:    203.0.113.0 - 203.0.113.255
netname:    ACME-CORP-NET
descr:      Acme Corp, Boston, MA
country:    US
status:     ASSIGNED PA  (provider-assigned)
parent:     203.0.113.0/22  (assigned to upstream ISP)

The “parent” tells you which LIR owns the larger block. Both the customer and the LIR are visible.

Geographic Mapping

The country in an allocation record is sometimes misleading. A US-incorporated company might use IPs in many countries. The record says “US”; the actual usage doesn’t.

For geolocation, commercial databases triangulate:

The registered country from the RIR.
BGP announcements and their geographic distribution.
DNS hints (server names, reverse DNS).
ISP customer information.
User-submitted feedback at scale.

The result is usually more accurate than “the country in the allocation record.” For an anycast IP, the allocation record’s country is essentially meaningless — the IP is used everywhere.

IPv4 vs IPv6 Allocation

The hierarchies are the same, but the allocation sizes differ:

IPv4

IANA-to-RIR: historically /8 chunks. Pool exhausted.
RIR-to-LIR: /22 or smaller in most regions today.
LIR-to-customer: often /24 or smaller.

IPv6

IANA-to-RIR: /12 chunks of the /3 reserved for global unicast.
RIR-to-LIR: typically /29 or /32 (huge in IPv6 terms; trillions of addresses).
LIR-to-customer: typically /48 to /56.

The IPv6 allocations are much larger because addresses are essentially infinite. The point is structure, not conservation.

Transfer Markets

Since IPv4 ran out, allocations can be transferred between organizations. The transfer must be registered with the relevant RIR(s). Each RIR has its own transfer policies:

Within an RIR — Common, usually straightforward.
Between RIRs — Coordinated, more administrative effort.
Cross-policy — Some transfers from “needs-based” RIR (ARIN) to “open market” RIR (RIPE) require additional documentation.

A liquid IPv4 marketplace has emerged. See IPv4 exhaustion and the marketplace for details.

What This Means for Application Developers

For most application developers, allocation hierarchy is invisible. You query an IP geolocation API and get country/ASN. The allocation chain is what makes the API’s data accurate, but you don’t interact with it directly.

Where it surfaces:

Investigation

When researching abuse, fraud, or unusual traffic, the WHOIS chain (allocated-to → parent → RIR) helps you understand who’s responsible.

Geolocation accuracy

A “newly allocated” IP often has stale or wrong geolocation for a few weeks until databases catch up. Recent transfers are a common cause of geolocation inaccuracy.

ASN reliability

The ASN in an allocation record is the authorized origin AS. The actual announcing AS (from BGP) is what matters for routing. They should match — when they don’t, that’s potentially a BGP hijack or simply stale records.

Country claims

Don’t trust the registered country alone. Cross-reference with a real geolocation service.

Tools

A few tools for exploring allocation records:

whois CLI — Universal command-line tool.
RIPEstat (stat.ripe.net) — Rich UI for RIPE region data.
ARIN’s RDAP (rdap.arin.net) — Modern JSON interface.
bgp.tools, bgp.he.net — Combine allocation, BGP, and geolocation views.
Ip2Geo API — Returns the LIR-level organization and ASN inline with geolocation.

TL;DR

IP allocation flows IANA → RIR → LIR → end user.
Five RIRs divide the world geographically.
LIRs are usually ISPs or large enterprises that receive blocks from their RIR.
Allocation records show holder, country, dates, ASN, abuse contacts.
The registered country may not match where the IPs are used.
IPv6 allocations are much larger by design.
Transfers between organizations happen via RIR-registered processes.
For most application developers, this is plumbing — but understanding it helps with investigation, geolocation accuracy, and ASN reasoning.

The IP allocation hierarchy is one of those quietly-essential pieces of internet governance. It’s the reason WHOIS lookups return meaningful data and the foundation for everything in IP intelligence. For querying these records, see WHOIS lookups; for the marketplace that’s evolved around scarcity, IPv4 exhaustion and the marketplace.

How IP Addresses Are Allocated: IANA, RIRs, and LIRs