IPv4 address space is no longer necessarily tied to the Regional Internet Registry where its history began. As IPv4 has become scarcer and secondary transfers have become a normal part of address management, organizations increasingly encounter situations where address space needs to move not only between companies, but also between Regional Internet Registry (RIR) service regions.

These transactions are known as inter-RIR IPv4 transfers. For a network operator, however, an inter-RIR transfer is more than a database update. The IPv4 numbers may remain unchanged, while the registry relationship, routing authorization, operational contacts, reverse DNS, RPKI configuration and supporting records around them may all require review.

Understanding those layers before a transfer can make the transition significantly easier.

What Is an Inter-RIR IPv4 Transfer?

An inter-RIR transfer is a recognized transfer of Internet number resources between organizations associated with different Regional Internet Registries. RIPE NCC explains that inter-RIR transfers must be approved by both participating RIRs before processing, and that once the transfer is completed and both registries update their records, the resource falls under the recipient RIR’s policies. See the RIPE NCC inter-RIR transfer guidance for the current framework.

The numerical IPv4 block itself does not change. A prefix such as 198.51.100.0/24 remains 198.51.100.0/24. What changes is the recognized registry relationship surrounding that resource.

Why Inter-RIR Transfers Matter Now

Cross-registry movement is not a theoretical edge case. IPv4 address space continues to move between RIR regions at meaningful scale. Heng.lu’s data analysis, Inter-RIR IPv4 Transfers in 2026: Where Address Space Is Moving, examines the first-half 2026 flows and explains why the larger story is not simply which region gained or lost addresses, but how portability, registry accuracy and auditability become more important as IPv4 resources move.

1. Confirm the Current Registry State

Before beginning any transfer process, establish the resource’s current authoritative registry state. Identify the exact prefix, the current RIR, the organization presently associated with the resource, relevant administrative contacts and any applicable transfer status. Older IPv4 resources can have complicated histories: previous transfers, subdivision, mergers, legacy registrations or earlier inter-RIR movement. The current transfer should therefore begin with a clear understanding of the current recorded state.

2. Check Whether the RIRs Have Compatible Transfer Mechanisms

Not every RIR pair necessarily supports the same transfer path. Each RIR has its own policy framework, so requirements can differ depending on the source RIR, the recipient RIR, the resource type, legacy status and transfer category. Operators should confirm the current rules of both registries before structuring a transaction.

ARIN’s current transfer guidance states that inter-RIR transfers involving the ARIN region are available only with RIRs that have reciprocal compatible policies. Its current list identifies APNIC, LACNIC and RIPE NCC as approved counterparts. See ARIN – Transferring IP Addresses & ASNs for current requirements.

APNIC likewise states that its inter-RIR transfer process depends on compatible policy and currently identifies ARIN, RIPE NCC and LACNIC as eligible RIR regions. See APNIC’s inter-RIR transfer page.

3. Verify Authority to Transfer the Resource

A current registry entry is important, but transfer due diligence should go further. The party offering the resource should be able to demonstrate that it is authorized to initiate the transfer. Useful evidence may include registry information, corporate authorization, relevant agreements, registry correspondence and previous transfer documentation where applicable.

This matters because the organization registered as the holder may not be the same organization currently routing, using or hosting the resource. Heng.lu’s guide What Does Proof of Control Mean for an IP Address? explains why registry control, routing control, operational use and commercial relationships should be treated as distinct forms of evidence rather than collapsed into one concept.

4. Review the Transfer History

IPv4 resources can have long operational histories. A block may move through initial allocation, corporate restructuring, transfer, subdivision and inter-RIR transfer. Looking only at the current record tells you where the resource is today; transfer history helps explain how it arrived there.

Questions worth asking include:

• Has the prefix been transferred before?
• Was it originally part of a larger allocation?
• Has it crossed an RIR boundary previously?
• Was there a merger or acquisition?
• Does the current holder follow logically from the recorded history?

The purpose is not to treat every historical change as suspicious. The objective is to establish a traceable and understandable resource history.

5. Do Not Confuse Registry Transfer With BGP Routing

One of the most common mistakes in IPv4 due diligence is assuming that registry and routing information should always show the same organization. They answer different questions. A registry record may help identify the recognized holder of a resource; BGP shows which ASN is currently originating the prefix.

The two can differ for legitimate reasons. A holder may authorize a hosting provider, customer or managed network provider to originate a prefix. Likewise, an inter-RIR transfer can be completed without an immediate BGP origin change if the recipient continues using the same network provider.

6. Review RPKI Before the Routing Change

If the transfer will also involve a new origin ASN, RPKI should be part of the migration plan. A Route Origin Authorization (ROA) can authorize an ASN to originate specified IP prefixes. If the planned origin changes, relevant ROAs should be reviewed so that the new routing state does not conflict with route-origin validation.

For the technical standard, see RFC 9582 – A Profile for Route Origin Authorizations (ROAs).

7. Check Reverse DNS

Reverse DNS is another dependency that can be overlooked during a resource transfer. Mail systems, logging, troubleshooting, security analysis, hosting environments and application identification may all depend on PTR records or reverse-delegation continuity. Before completing a transfer, determine who controls reverse DNS, whether delegation will change and whether the receiving organization has a continuity plan.

8. Review IRR and Routing Records

Internet Routing Registry information may also need attention. If the transfer changes the origin ASN, routing policy, upstream provider or operational network, associated route objects may need updating. Registry state, routing state, RPKI state and IRR state should be viewed as related but distinct layers.

9. Check Reputation and Geolocation Separately

An inter-RIR transfer changes registry state. It does not automatically reset third-party reputation or geolocation databases. A prefix may retain historical observations in spam, fraud, security or geolocation systems even after a legitimate transfer and redeployment. Recipients should therefore review registry history and operational reputation history separately.

10. Preserve Evidence of the Transition

Once the transfer is completed, retain evidence of both the old and new state. Useful records may include registry output before the transfer, transfer confirmation, new registry data, relevant RPKI information, routing state, authorization documents, reverse-DNS information and internal change records.

Heng.lu’s concept of Registry-State Export for Internet Number Resources develops the same continuity idea further: important registry state should be capable of being preserved in an authenticated, portable and auditable form so future operators can reconstruct legitimate state changes.

11. Plan for Operational Continuity

The most important transfer test is not simply whether the database update succeeds. It is whether the running network can transition safely. Operators should know whether routing will change, when RPKI will be updated, whether reverse DNS will continue, whether upstream providers need documentation, whether allowlists are tied to the resource, and what rollback or recovery options exist.

This operational emphasis aligns with Heng.lu’s Running-Code Primacy framework, which argues that coordination systems should ultimately support interoperable running networks and operational continuity.

Inter-RIR Transfer Is Portability in Practice

An IPv4 block can begin its history in one registry environment and later move into another while remaining the same globally unique resource. That makes inter-RIR transfer a practical example of portability.

What needs to survive the transition is not the original regional context. What needs to survive is uniqueness, accurate registration, verifiable control, historical traceability, routing security and operational continuity.

A Practical Pre-Transfer Checklist

Conclusion

Inter-RIR IPv4 transfers are becoming an established part of the modern IPv4 lifecycle, but the transfer itself is only one layer of the process. A well-managed transition requires operators to distinguish registry state, routing state, routing authorization and operational use.

The IPv4 prefix may remain numerically unchanged while each of those surrounding layers evolves. Good transfer practice therefore depends on more than moving a record from one RIR to another. It depends on preserving an understandable chain of control, keeping supporting records accurate, aligning routing and security information where necessary, and protecting the continuity of the running network.

IPv4 portability works best when movement is not merely possible. It should also be verifiable, auditable and operationally predictable.