Inter-RIR IPv4 Transfers: What Moving Between Regions Actually Means
A reader-friendly analysis of 2026 inter-RIR IPv4 transfers, regional movement, portability, registry state and operator checks.
An inter-RIR transfer moves a recorded IPv4 resource relationship from one Regional Internet Registry region to another. The address numbers do not change. The registry relationship does.
That sounds administrative, but it affects how operators investigate history, verify continuity and understand what a current record does and does not mean. The safest way to read the 2026 data is to follow the movement without pretending that registry geography is the same as network geography.
What moved in the H1 2026 snapshot
The source snapshot for this article covers the first half of 2026 and excludes mergers and acquisitions. It associates approximately 8.8 million IPv4 addresses with about 293 recorded inter-RIR transfers.
The largest flows were approximately:
- ARIN to RIPE NCC: 4.20 million addresses;
- ARIN to APNIC: 2.28 million;
- RIPE NCC to ARIN: 942,000; and
- RIPE NCC to APNIC: 580,000.
These figures describe recorded registry movement. They are not a direct measurement of traffic, price, regional economic growth or the physical location of the networks using the addresses.
Why two registries are involved
An inter-RIR transfer is a coordinated state change. The source and recipient registries both need to process the event, after which the resource is governed under the recipient region's applicable policies.
RIPE NCC's inter-RIR transfer guidance explains the process from the recipient side. Its public statistics provide a useful way to inspect the recorded events rather than relying on a headline about a single large flow.
The useful mental model is not “an address travelled from one country to another.” It is “the recognized registry relationship moved from one coordination system to another, with a record that should remain explainable.”
ARIN outflow is not automatically North American loss
ARIN was the largest source in this snapshot, with approximately 6.55 million addresses moving toward other RIR regions. Most of that volume went toward RIPE NCC and APNIC.
An outflow does not automatically mean that North American infrastructure lost that capacity. A resource can be registered in one region and still be announced through infrastructure elsewhere. The administrative region, the organization's legal location, the route origin and the physical network location should be checked separately.
RIPE NCC and APNIC show the receiving side
RIPE NCC received approximately 4.55 million addresses in the snapshot, mostly from ARIN. APNIC also received meaningful inbound movement. Looking at recipients is useful because it shows where registry relationships are being re-established, but it still does not identify every operational user or every route.
A transfer should therefore be understood as a transition between recorded states:
- source holder and source RIR;
- verified transfer event;
- recipient holder and recipient RIR; and
- the routing, RPKI, reverse-DNS and operational records that need to remain coherent.
Transfer count and address volume tell different stories
A small number of very large transfers can dominate the address total, while many smaller transfers can dominate the event count. Those are two different signals.
For that reason, a responsible reading reports both how many transfers were recorded and how many addresses were involved. It also states the period, the included registries and the exclusions. Without that context, a large number can sound like a change in Internet use when it may simply reflect one large registry event.
A registry move is not a route map
Inter-RIR transfer and BGP rehoming can happen together, but neither implies the other. A resource can change registry relationship while continuing to be originated by the same ASN. A network can change its origin ASN while the registered holder remains unchanged.
Leasing makes the distinction even clearer. The registered holder, operational customer, hosting provider and originating ASN may all be different organizations. A transfer log will not describe that entire arrangement.
What should follow the transfer
After a transfer, an operator should check more than the new registry record:
- Registry: holder, resource size, transfer date and history.
- Routing: expected origin ASN, propagation and old announcements.
- RPKI: ROAs that authorize the intended origin and prefix length.
- Reverse DNS: delegation and records that customers or security systems depend on.
- IRR: route objects and filters used by providers.
- Contacts: technical and abuse contacts that remain reachable.
- History: evidence that lets a later operator reconstruct the transition.
- Continuity: DNS, allowlists, VPNs, reputation and other business dependencies.
APNIC's transfer log format is a useful reminder that a transfer record is cumulative history. It is one part of an operational record, not a replacement for the rest.
What the data does not prove
The H1 2026 figures do not prove where a prefix was routed, who paid for it, whether it was leased, or whether every operational record was updated at the same time. They also should not be extended into a full-year global conclusion.
The stronger conclusion is about portability: IPv4 resources can move between coordination regions, and the surrounding systems need to preserve uniqueness, verified state, security and continuity when they do.
From regional allocation to global mobility
IPv4 was allocated through regional systems, but its operational life is increasingly mobile. The coordination question is no longer only who receives a new block. It is how an existing block can move through legitimate states while leaving a record that another operator can understand and verify.
That is why inter-RIR statistics belong beside transfer history, routing evidence and proof of control. The number is portable only when the evidence around the number remains portable too.