Order Without Ownership: IP Address Allocation and Routing in a Decentralized Internet

The Internet is a decentralized network by nature. Hundreds of thousands of computer networks, each with their own peculiarities and policies, are interconnected together to form a larger, global network.

There is little to no coordination between these networks. Each network is mainly concerned with its peering neighbors, but it doesn’t need to care about networks further away. A network operator in Japan does not need to ever coordinate with a network operator in Europe to be able to exchange packets with them. They do not need to use the same equipment, vendors, software, or configurations on their networks.

It might seem impossible for such a system to work at a global scale and over a long period of time, and yet, for the most part it does. This is achieved in part thanks to standards organizations like the IETF, which dictates the technical standards that must be used to interconnect networks, but also through the Regional Internet Registries (RIRs), which coordinate the allocation of IP addresses and other shared Internet resources.

In this blog post I will explain what IP addresses and autonomous system numbers are, how they are allocated successfully on the Internet (along with their limitations), and how IPinfo’s actively measured datasets turn static registry data into a verifiable, real-time intelligence layer.

IP Network Challenges

The common point to all networks on the Internet is the use of the aptly named Internet Protocol, or IP protocol. In an IP network, each piece of equipment is assigned an IP address that can be used to send messages to others.

There are two key challenges in IP networks: 

• Finding paths, or routes, between two computers
• Making sure each piece of equipment is assigned a unique address amongst a finite set of possible addresses

To better understand the routing challenge, let’s have a closer look at an IP network. A typical IP network is made up of multiple computers interconnected together through a device called a switch. Each interface of the switch is either connected to a computer, or to another switch.

Two IP networks. Within each network hosts are connected through a switch and can send broadcast messages to all other computers in the same network. Broadcast messages are not allowed past the network boundary. Instead a device called a router is used. A router knows in advance how to reach all other networks.

A switch has two modes of operation when it receives a message from one computer to another. Either it knows, from observing the traffic, to which specific interface the message must be forwarded, or it doesn’t and it sends the message to all interfaces except the interface where the message arrived in a process called flooding. In this setup, there is no need to know the outgoing interface for all destinations in advance since a message can always be broadcast to everyone when the interface is not known.

Networks that support broadcast messages are convenient, but they also suffer from scalability issues. Imagine if every time a computer wanted to send a message to a new destination on the Internet, the message would be sent to all other computers on the Internet in the hope that it would eventually reach its intended destination. Not only would this be a privacy nightmare, this would also clog the network with useless traffic.

From Local Networks to Autonomous Systems

To solve this scalability issue, broadcast messages are not allowed between networks. Instead, another type of device, called a router, is used to interconnect networks. Unlike a switch, a router must know the outgoing interface for each destination in advance:

• One way to populate this routing table is for the network to manually input each route into all routers. However, this process doesn’t scale to large networks and doesn’t allow dynamic reconfiguration when new routers are added or removed, or when links between them become unavailable (e.g. due to a broken cable). 
• Instead, the most common way of populating routing tables is by using a routing protocol. Various kinds of routing protocols exist, but the main idea is for each router to share the list of the network it is connected to with its neighbors and also the networks it learned from its neighbors. After some convergence time, routers should share the same view of the network.

In practice different organizations will use different routing protocols and policies depending on their needs, for example to optimize for throughput or latency. They might also want to filter which routes they accept from other networks to control where their traffic will go. A collection of networks that share a common routing policy is called an autonomous system, or AS. Typically ISPs and large organizations will operate one or more ASes. Within each AS they are free to use the routing protocol of their choice.

The Internet is a collection of autonomous systems, each with their own internal routing protocols and policies, that use the Border Gateway Protocol (BGP) to exchange routes between them.

A proto-Internet with two autonomous systems. Inside an AS the network operator is free to implement any routing policy and use any routing protocol. Between ASes the BGP routing protocol must be used.

One key requirement of the BGP protocol is that each AS has a unique number, called an Autonomous System Number (ASN) assigned to it.

The Need for Unique Resources

For the Internet to work we need two things: unique IP addresses and unique autonomous system numbers. If we let network operators pick these values at random, there is a very high risk of collision, which would result in parts of the network being unreachable, or receiving traffic not meant for them.

The allocation of these resources is coordinated by the Regional Internet Registries (RIR).

RIRs are nonprofit organizations that maintain a registry — or database — of Internet resources. There are five RIRs that cover different parts of the world: AFRINIC for Africa, ARIN for North America, APNIC for Asia and Oceania, LACNIC for South America, and the RIPE NCC for Europe and the Middle East.

The exact types of records and metadata recorded in each database depend on the RIR, but the two most important are IP address ranges and autonomous system numbers.

Resource allocation is hierarchical in nature. The Internet Assigned Numbers Authority (IANA) distributes these resources to RIRs, which in turn distributes them to organizations who need them, which in turn can distribute them to their customers.

IPv4 addresses are by far the scarcest resources, with only 4.2 billion 32-bit addresses to split for every device on the planet. RIRs now have a waiting list in place, as they’ve run out of available IPv4 addresses and have strict quotas (for example the RIPE NCC limits the maximum number of IPv4 addresses allocated to an ISP to 256 addresses).

IPv6 addresses do not suffer from this problem thanks to the use of 128-bit addresses, which provides a vastly larger address space. The majority of the IPv6 address space is currently unallocated and reserved for future use.

ASNs used to be defined using 16 bit numbers, meaning a maximum of 65,536 ASNs could be allocated, but were later extended to 32 bits to account for the growing number of ASNs (more than 120k as of 2025).

The current allocation of these resources to RIRs can be seen in the IANA IPv4 Address Space Registry, the IANA IPv6 Global Unicast Address Assignments, and the IANA Autonomous System Numbers List.

The exact resource allocation policy depends on each RIR, but they will typically distinguish two types of allocations: ISPs and end users.

ISP allocations can be further sub-allocated by the ISP to its own customers. We can also say that the ISP acts as a Local Internet Registry (LIR). For these kinds of allocations ISPs usually pay a membership fee that funds the registry operation. 

On the other hand, end-user allocations are usually exempt of membership requirements, but have the restriction that they cannot be sub-allocated.

Let’s have a look at a concrete example, with the 2a01:c910:1:20e::/64 IPv6 range. The allocation hierarchy is as follows:

We clearly see the IANA → RIR → LIR(s) → end user allocation hierarchy.

Who Needs to Own Resources?

One might wonder: why bother obtaining IP addresses from a RIR or LIR when an organization could just use the IP addresses handed out by their ISP?

The main reasons for owning IP addresses are:

• Portability: The ability for an organization to move IP addresses across ISPs without renumbering all of its devices, i.e. having provider-independent address space.
• Multihoming: Announcing IP addresses from multiple ISPs for redundancy.

Additional benefits can be:

• Reputation: By controlling how IP addresses are used, the owner can make sure they are not used for nefarious purposes (e.g. sending spam) and implement its own abuse handling policy by setting point of contact fields in the WHOIS database.
• Reverse DNS delegation: The IANA maintains the root zone for reverse DNS records (in-addr.arpa and ip6.arpa) and delegates the child zones to the RIRs, which in turn can delegate the zones matching the owned resources to the organization's own DNS servers (see RIPE NCC’s documentation for example)

The reason for obtaining an AS number is simpler: it is required to establish public BGP sessions! Thus any network willing to announce IPs on the Internet must have its own ASN.

Note that IP addresses and ASN allocations are independent. An organization might have an ASN, but only route IPs brought by its customer, and similarly an organization can own IPs, but not have the infrastructure to route them and rely on an ISP with an ASN for that.

In practice, most smaller organizations are fine using IP space assigned by their ISP and don’t need their own ASN. Ownership becomes important for companies that run large-scale infrastructure, provide Internet services, or need independence and resilience—such as ISPs, hosting providers, CDNs, and enterprises with complex networks. For these organizations, direct resource ownership offers control, stability, and flexibility that simply leasing addresses from an ISP cannot match.

What WHOIS and RIR Data Reveal

IP address and ASN records in the RIR databases contain information about the owner of these resources, but they can also contain additional metadata like the intended usage of these resources or contact addresses.

Let’s have a look at some resources. To do so we will use the WHOIS protocol with the whois command line utility, but note that there is also a newer HTTP-based protocol called RDAP.

We can query the RIPE database for the 2a01:c910:1:20e::/64 range with the following command:

whois -h whois.ripe.net – 2a01:c910:1:20e::/64

If the WHOIS server is not specified (whois.ripe.net in this case) then the whois command will use the IANA server (whois.iana.org), which will redirect to the appropriate RIR server in most cases. However, it’s good practice to specify the proper WHOIS server to make sure you get the expected record.

inet6num:       2a01:c910:1:20e::/64
netname:        FR-LA-POSTE-DISIT
country:        FR
descr:          SERVICES
admin-c:        DL7113-RIPE
tech-c:         DL7113-RIPE
tech-c:         AA2914-RIPE
status:         ASSIGNED
mnt-by:         PC80199-MNT
created:        2015-05-27T11:38:38Z
last-modified:  2015-05-27T11:38:38Z
source:         RIPE

IPv6 allocation in the RIPE database.

The record tells us multiple things:

• The name of the IP range gives us a hint as to its purpose. In this case it seems allocated to the French post.
• The country tells us that this range is probably used in France, although this attribute is completely free for the user to set and might be unrelated to IP geolocation. See the next section.
• The admin-c and tech-c attribute give us the administrative and technical contacts for this IP range. In this case AA2914-RIPE links to a record containing the addresses of Orange Business Services (the LIR) support center while DL7113-RIPE tells us the address of the French postal service IT services.
• The mnt-by attribute tells us the entity allowed to make changes to the inetnum record itself. Naturally in this case it’s the LIR, Orange Business Services.

The role records linked in the admin-c, tech-c and mnt-by attributes contain postal addresses, phone numbers and email addresses. For example, if we lookup AA2914-RIPE:

role:           Administration Adresses
remarks:        Internet Support Center
address:        Orange Business Services
address:        6 avenue Albert Durand
address:        31700 Blagnac France
phone:          +33969397520
abuse-mailbox:  abuse.orange-business@orange.com
nic-hdl:        AA2914-RIPE
remarks:        http://www.orange-business.com
mnt-by:         RAIN-TRANSPAC
created:        2004-03-12T12:24:14Z
last-modified:  2024-11-26T14:37:29Z
source:         RIPE

Point of contact in the RIPE database.

WHOIS and RIR Limitations

WHOIS ≠ Geolocation

WHOIS records are often used as a proxy for IP geolocation. However, this usage is precarious as there is no guarantee that the addresses in the records are correct or linked to the actual location where the IP addresses are used. For example, the RIPE database documentation has this to say regarding the country attribute:

This identifies a country using the ISO 3166-2 letter country codes. It has never been specified what this country represents. It could be the location of the head office of a multi-national company or where the server centre is based or the home of the End User. Therefore, it cannot be used in any reliable way to map IP addresses to countries.

Furthermore, the granularity of IP address allocation is often too coarse to represent anything below the country level. The proper solution for network operators to share geolocation information are geofeeds.

Route Objects Are Informational Only

Another common source of confusion regarding WHOIS records come from route records. These records tell us which ASNs are expected to announce an IP range. For example, the following record tells us that 90.38.0.0/16 should be announced by AS3215:

route:          90.38.0.0/16
descr:          France Telecom IP2000-ADSL-BAS
origin:         AS3215
mnt-by:         FT-BRX
created:        2012-12-11T10:07:49Z
last-modified:  2012-12-11T10:07:49Z
source:         RIPE

Route record in the RIPE database.

However, these records are purely informational. Some network operators might use them to reject routes where the origin ASN doesn’t match, but some might not use those records at all. Furthermore these records can exist even if an IP range is not actually announced. As such, these records cannot be used to determine which ASN announces an IP range. This information can, however, be obtained from the BGP routing protocol.

The Messiness of Public Registry Data

The RIRs databases are publicly available, which makes them great sources of information about the entities operating on the Internet. However, this data can also be quite messy.

RIRs do not all support the same record types, and even for common records, the attributes supported might be different.

Furthermore, some fields, like the address, are freeform and their validity is not enforced by the RIRs. It is not uncommon to find invalid or mangled addresses in WHOIS records.

How IPinfo Transforms Static Records into Dynamic Intelligence

The Internet’s addressing system was built on a cooperative trust model: registries publish allocations, operators document routing intentions, and the community assumes these records are correct. 

However, this model also allowed some actors to disguise malicious or unwanted traffic. For example, web crawlers can rotate IP addresses and ASNs often to evade detection (see this Cloudflare blog post for a recent example).

IPinfo data sheds light into these issues with our rich data:

IP WHOIS 

Our IP WHOIS data maps IP ranges to their owners in a standardized and enriched format across all regional Internet registries. This data is useful to understand the allocation hierarchy and history of an IP address and, for example, to distinguish stable, ISP-allocated IPs from IPs from IP brokers who might change hands frequently. This data can also be used to discover assets owned by a particular organization, and estimate their attack surface for proactive management. 

IP to Company and IP Ranges

Our IP to Company and IP Ranges dataset are distilled versions of our WHOIS dataset that always return the most specific information for an IP address. They are useful when one cares only about the final owner of an IP address and not the full allocation hierarchy. They allow users to easily obtain all IP ranges belonging to an organization by looking up its name or domain name.

IP to ASN

Our IP to ASN data maps IP addresses to their origin ASN — the organization that routes the IP address on the Internet. This data can be used to know the ISP of a user, but also to filter human traffic from bot traffic often originating from hosting and cloud providers ASNs.

IP Geolocation

Our IP geolocation data, informed by ProbeNet, our internet measurement platform, provides accurate location attribution down to the city level, detecting discrepancies between WHOIS country codes and the IP’s observed geography. 

IP Privacy Detection

Our IP privacy detection data flags IPs using VPNs, proxies, Tor nodes, residential proxies and other anonymizing services, enabling users to filter bot traffic, prioritize investigations, and handle anonymized connections with the appropriate caution.

From Assumptions to Evidence

Traditional registry data is valuable but incomplete. Without validation, it’s easy to misattribute ownership, geography, or routing, leading to costly blind spots.

IPinfo uses publicly available signals, like WHOIS data and geofeeds, standardizes and organizes that information into a consistent format, and builds off that foundation with partner/vendor data as well as our own proprietary intelligence. This approach turns registry data from a static directory into a dynamic, verifiable intelligence layer.

It enables network defenders, researchers, and operators to move from assumption-based analysis to evidence-backed mapping of Internet resources, reducing false positives and uncovering infrastructure that would remain hidden in traditional WHOIS-only workflows.

Ready to see beyond registry records?

Static WHOIS and RIR data only tell part of the story. IPinfo’s datasets combine registry information with real-time measurements, advanced privacy detection, and curated intelligence to give you a complete view of the Internet’s infrastructure.