IPv4 Has a Lifecycle: What Registry Data Can and Cannot Show
A plain-language guide to the IPv4 lifecycle: transfers, reuse, routing, RPKI, leasing, history and what registry data cannot show.
IPv4 scarcity is no longer the whole story. The more useful question is what happens to an address block after it has already been allocated.
A block can be transferred, divided, announced by another network, covered by a different routing authorization, leased to another operator, and transferred again. The number may stay the same while the organizations, networks, geography and evidence around it change.
This article gives you a way to read that change. It separates four questions that are often collapsed into one: who is recorded in the registry, who operates the resource, which ASN originates its route, and which evidence explains whether the current state is authorized and continuous.
Begin with four different questions
A registry record answers a registry question: which organization is recognized for this resource under the registry's rules? It does not by itself answer who is using the resource today, where the traffic is routed, or which network is authorized to originate it.
- Registry state: the recorded holder and resource relationship.
- Operational state: the organization, provider or customer actually using the block.
- Routing state: the ASN currently seen originating the prefix in BGP.
- Authorization and history: the ROAs, IRR objects, transfer records and change history that explain the state.
These layers can change together, but they do not have to. Keeping them separate is the first step toward understanding the data.
What the 2026 data shows
The 2026 figures in this article are year-to-date observations from an incomplete year. RIPE NCC's published monthly figures for January through July add up to approximately 16.72 million transferred IPv4 addresses in its service region. A single large month can change the total, so this is evidence of continued movement, not a full-year forecast.
The longer view is just as important. APNIC's analysis of global RIR data recorded 33.4 million IPv4 addresses across 5,619 registered transfer transactions in 2025. It estimated that about 342 million addresses had appeared in RIR transfer logs since 2012. Some addresses appear more than once, which is itself evidence that an address can have more than one registered transition.
The transfer record therefore tells a story of movement after exhaustion. It does not tell the whole story of current use.
Allocation has become reuse
When unused space was easy to obtain, the mental model was simple: a registry allocates a block and a network deploys it. In a mature IPv4 market, an existing block may instead move from one organization to another and acquire a new operational life.
A twenty-year-old prefix may now have a different holder, provider, origin ASN, reverse-DNS arrangement, abuse contact and RPKI configuration from the ones associated with its original allocation. The address number is stable, but the surrounding infrastructure is not.
That is why the current record needs its history. The present holder is important, but it is only one point in the resource's life.
One large block can become several histories
Transfers can also change the unit being managed. A block that began as a /16 may later be represented by smaller resources such as /18, /18, /19 and /20. Each resulting prefix can acquire its own holder, route, ROA, reverse DNS, operational user and later transfer history.
Published transfer logs are useful because they preserve the recorded resource and transition. They should be read as a history of state changes, not as a promise that the original allocation remains the only meaningful operational unit.
Registry geography is not routing geography
An address can move between registry regions without the packets immediately moving to a new country. A registry transfer changes the recognized administrative relationship. BGP describes how reachability is being announced. IP geolocation describes yet another inference.
Those three descriptions may point in different directions without one of them being wrong. Treating a registry country, a company's headquarters, a data-center location and a route origin as interchangeable creates false certainty.
Leasing and delegation add another layer
A lease or operational delegation can let another organization use and announce a block while the registered holder remains unchanged. A transfer log may show no new holder even though the operational user, provider, reverse DNS, contacts and reputation have changed.
This is why transfer data measures recorded registry transitions, not every change in use. A complete investigation needs the registry record, operational authorization and routing evidence together.
RPKI gives the route its own security state
When the intended origin ASN changes, the relevant Route Origin Authorizations should be reviewed. A registry can correctly record a holder while the route still carries an old authorization. Conversely, a valid ROA does not prove that the route is currently being announced.
Read the layers in order: the registry states the recognized relationship, RPKI states an authorization, and BGP shows the route that networks are observing. Each one answers a different question.
What registry data cannot prove
A transfer record does not disclose the transaction price, the commercial reason for the change, every lease, every delegation, or the complete routing history. RIRs also publish data with different definitions and timing.
The careful conclusion is therefore narrower and stronger: registry data is a verified view of important recorded state transitions. BGP, RPKI, IRR records, contracts and operational logs provide other views. Confidence comes from comparing those views, not from forcing one dataset to answer every question.
A practical lifecycle record
For a prefix that matters to a running business, keep a record that can be checked by another operator:
- current registry holder and relevant transfer history;
- current operational user, provider and contacts;
- origin ASN and historical route changes;
- ROAs, IRR objects and reverse-DNS responsibility;
- material changes, approvals and evidence of control; and
- the continuity or exit plan if the relationship changes again.
This is lifecycle management. It is the practical response to an Internet in which old identifiers continue to move through new organizations and networks.
Continue through the three layers
The next article follows the registry layer across RIR boundaries. The third follows a different kind of change: a prefix keeping its number while its BGP origin ASN changes.