Understanding Network Infrastructure · Part 5 · Connecting the enterprise network to branches, clouds, and the Internet
Who allocates public IP addresses worldwide without overlap?
From IANA to the user: registration is not Internet reachability
An organization cannot simply choose public IP addresses for itself. Registration and delegation from IANA through RIRs and ISPs to the end organization must align with the prefix advertisements used in Internet routing. This article explains how to check the registered organization, origin AS, and service operator using separate sources of evidence.
How are unique public IP addresses distributed worldwide by IANA and the RIRs?↑
IANA maintains the global IPv4 and IPv6 address records and AS number records in its Internet number-resource registries. It does not sell addresses directly to ordinary users or companies. Under global policies, it distributes large address pools to regional Internet registries and records special-purpose ranges.
There are five RIRs: AFRINIC, APNIC, ARIN, LACNIC, and RIPE NCC. Each RIR allocates Internet number resources to organizations and maintains registration information under its region's policies. In some countries within the APNIC region, an NIR handles this work. An NIR is not a mandatory step for every country or organization; check regional policy for the actual application and registration process.
This hierarchy organizes responsibility for address use and registration. IANA records broad address-space allocations and special-purpose ranges; an RIR reviews organizational requests under regional policy. An ISP supplying smaller address blocks to customers also follows upstream registration requirements and policies. The records identify who manages the addresses and whom to contact if a problem occurs.
Start an address investigation with the special-purpose registry. Mistaking documentation ranges such as 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 for the public IP addresses of real services leads to incorrect interpretations of registry and route data. For an actual address, use IANA's RDAP bootstrap data to find the responsible RIR, then query that RIR's current registration record. That is why the official registry, not a search site's copy, should be the starting point.
The purpose is to record resources and responsible contacts so the same public address is not used arbitrarily by unrelated parties worldwide. Registry data is not a router's forwarding table, and the registered organization is not necessarily the service operator. Rules protecting personal information and governing reassignment can also affect how much contact information each registry publishes.
Sources for this section IANA Number Resources · IANA Number-related Registries · IETF RFC 7020 · APNIC National Internet Registries
Allocation and assignment distinguish address management from use↑
An upstream registry or ISP can subdivide a large prefix it has received and supply smaller ranges to other organizations. Whether a relationship is called an allocation or an assignment depends on policy and the registry context.
An RDAP or registry lookup helps identify the organization managing a range and its contacts. With cloud services, CDNs, hosting, and reassignment, the registered organization may differ from the service operator. A lookup alone is not proof of service ownership.
Allocation generally means an upstream organization delegates an address block for further distribution; assignment generally designates resources for direct use by a particular end site. Terminology can vary with RIR policy and object type, so read the record's status and parent prefix together. The term alone does not tell you whether the addresses are the customer's own or supplied by its provider.
An RDAP result structures the network range, handle, entities and contact roles, and event times. An abuse contact may handle security reports without being responsible for developing or operating the website. Customers using provider-aggregatable prefixes may need to change addresses when switching ISPs; that readdressing requirement differs from using independent addresses, which still requires suitable policy and routing capabilities. Registration is only one source of evidence when investigating technical reachability and operational ownership.
Address registration does not confer permanent ownership like title to real estate. Policy and contracts grant usage rights and management responsibilities; resources can be returned, transferred, or registered again. For contract review or incident response, compare the current range and change times in WHOIS/RDAP with the upstream provider and internal asset records. That helps avoid mistaking an old record or a larger parent block for the current user.
Sources for this section IANA Number Resources · IETF RFC 7020
What to look for Follow the allocation of address space from IANA to an RIR, then its allocation or assignment to organizations through a regional NIR, LIR, or ISP. Not every region or organization follows the same sequence. The arrows represent address allocation and assignment, not the path packets take.
↔ Scroll horizontally to explore the diagram.
An assigned public IP address can still be unreachable from the Internet↑
Delegation provides the administrative basis for using a prefix. Internet reachability depends on an ISP or organization using BGP to advertise the prefix and other networks accepting the route.
Within a provider aggregate, an ISP may advertise on the customer's behalf. An organization with independent addresses and an AS number may instead advertise directly to several ISPs. Prefix filters, maximum lengths, RPKI origin validation, and provider policies affect whether those advertisements are accepted.
Suppose an organization is assigned 2001:db8:1234::/48 as an example prefix. Surrounding routers must know the prefix's next hop for the packets to arrive. In a real deployment where the organization advertises routes directly, it must configure sessions with its ISP using BGP, and import and export filters must allow the route to propagate. Conversely, an advertised route does not prove valid address-use rights. Registry and routing data are separate, complementary evidence.
In RPKI, a ROA specifies which origin AS may advertise a prefix and the maximum prefix length allowed. It does not create a route automatically; receiving networks must apply origin-validation results through policy. If a prefix is missing, check completed registration, the ISP's export policy, the actual BGP advertisement, and the ROA's origin and maximum length, in that order. Separating registration problems from propagation problems identifies the right organization and place to make a correction.
To investigate reachability, use a route collector or an ISP's observation point to check the prefix, origin AS, AS_PATH, and any more-specific routes. An IRR route object records an operator's intended advertisement; an RPKI ROA authorizes an AS to originate prefixes of permitted lengths. These records alone do not show actual propagation or service responses. Check registration, advertisement authorization, route propagation, and service response separately.
Sources for this section IETF RFC 7020 · IETF RFC 6811 · IETF RFC 4271
IPv4 scarcity brought address transfers, CGNAT, and IPv6 into the picture↑
IANA's free pool for new IPv4 allocations is exhausted, but that does not mean all IPv4 addresses disappeared on one day. Remaining pools, reclaimed addresses, waiting lists, and transfers operate differently across regions under RIR policies.
Organizations can use NAT and address sharing to reduce IPv4 demand, but must account for port and state limits and traceability. IPv6 offers a much larger address space, yet migration also requires preparation for dual stack, DNS, security policy, and operations.
Acquiring addresses through an IPv4 transfer also calls for updating the registry, route filters, ROAs, and reverse DNS, and reviewing reputation history. If the addresses were previously used for spam or attacks, service providers may still restrict the new holder's traffic. A purchase agreement does not immediately provide unrestricted reachability. Before use, check the registry, routing, and security reputation separately.
CGNAT reduces public-address demand by distinguishing subscribers' flows with public addresses and ports. It also complicates inbound connections, consumes port resources, and adds work to tracing users. Deploying IPv6 is not a one-line change to remove NAT: it involves an address plan, router advertisements or DHCPv6, DNS AAAA records, firewall policies, and monitoring. During dual-stack operation, observe IPv4 and IPv6 paths separately to locate problems.
With a much larger IPv6 address space, end-to-end address design faces fewer constraints, but adoption does not immediately remove IPv4 dependencies. Dual stack, NAT64/DNS64, provider support, and security policies may all be part of the transition. Plan the address strategy in stages, considering application IPv6 support, prefix advertisements, observation tools, and operator skills—not just the number of addresses available.
Sources for this section IETF RFC 7020 · IETF RFC 6598 · IETF RFC 8200
To identify who is behind a public IP address, check registry records, BGP routes, and service data separately↑
Scenario: You need to identify who manages the external IP address 203.0.113.20 and investigate its traffic path.
- First, check IANA's special-purpose registry to see whether the address is reserved for documentation, private use, or another purpose.
- For an actual public address, use IANA's RDAP bootstrap data to query the responsible RIR's RDAP service.
- Record the registered prefix, organization, and contacts. Registration data alone cannot identify the owner of the actual service.
- Using BGP route collectors or ISP observations, separately check the advertised prefix, origin AS, and path.
- Compare DNS, certificates, and service-contract information as well to identify the operator.
The address 203.0.113.20 in this article is reserved for documentation; it is not used as an actual operational-address lookup example.
Use three columns to avoid premature conclusions. Under registry, record the parent prefix, managing entity, and contact. Under routing, record the advertised prefix, origin AS, upstream, and RPKI status. Under service, record the DNS name, certificate, HTTP response, and contractual owner. They may point to the same organization, but with CDNs, clouds, or managed services, different organizations in each column can be entirely normal.
For an outage, check several route collectors and external probes to see whether the prefix is visible and whether a more-specific route is selected only in some regions. After a registration change, distinguish the RIR record's timestamp from the ISP's filter-update time. For an abuse report, send relevant evidence to both the service operator and the abuse contact without collecting excessive personal information. Choose records that fit the investigation rather than forcing the question 'Whose IP address is this?' into one oversimplified answer.
Keeping these layers separate lets you describe situations precisely: 'The registered organization is the ISP, but its customer runs the service,' or 'The addresses are registered to us, but the prefix is not yet advertised.' Record lookup times and observation points so the reasoning can be reconstructed even after registrations or routes change.
Sources for this section IANA Number Resources · IETF RFC 6811 · IETF RFC 4271
FAQ↑
Does IANA assign public IP addresses directly to companies?
Does the country in an IP lookup show the user's actual location?
Does having a public IP address mean I need BGP?
Glossary↑
Sources and verification
- IANA Number Resources — Global coordination of IP addresses and AS numbers, and the RIR hierarchy
- IANA Number-related Registries — Lists of IPv4, IPv6, and AS number registries
- IETF RFC 7020 — The Internet Numbers Registry System
- IANA IPv4 Special-Purpose Address Registry — The current authoritative registry of special-purpose IPv4 prefixes
- IETF RFC 6811 — RPKI-based BGP prefix origin validation
- IETF RFC 6598 — Shared Address Space for CGN deployments
- IETF RFC 8200 — The base IPv6 specification and expanded addressing
- IETF RFC 4271 — BGP route advertisements and reachability
Before applying for or transferring addresses, check the relevant RIR's current policies and address availability. Record the time when you look up registration and routing data.