How to Transfer IP Addresses Between RIR Regions
What to check before an inter-RIR IPv4 transfer, how to preserve network continuity, and why Lu Heng separates authentication from investment approval.
An inter-RIR transfer moves the registration of Internet number resources between regional Internet registries. For an IPv4 buyer, it can be a way to obtain an existing address block held in another registry’s region. It requires coordination between the parties and the registries involved.
It does not physically move a server. Nor does it automatically reduce latency, relocate stored data or make a network reachable. Registration and network operation are connected, but they are separate pieces of work.
Before committing to a transfer
Identify the exact block, the registered holder, the intended recipient and both registries. Check that this resource is eligible for transfer between that particular pair. A process available for IPv4 must not be assumed to apply to IPv6 or to autonomous system numbers.
Use the current official rules: ARIN’s transfer policy, APNIC’s transfer information, or the RIPE NCC transfer guide, as appropriate. Both ends matter. Check eligibility, required evidence, any holding restrictions and the order in which the registries expect the parties to act.
Confirm who is authorised to act for each organisation and whether the resource has disputed claims or operational dependencies. A price agreement alone does not establish that the seller can complete the registration change.
Keep the administrative and engineering work together
- Prepare both sides. The source and recipient should agree on the exact resources and provide the records their registries require. Where a recipient needs a usage assessment or prior approval, establish that before relying on a completion date.
- Follow the applicable inter-RIR procedure. Coordinate the requests and confirmations through the source and destination registries. Do not substitute an internal transfer form or assume that one registry’s approval completes the other’s work.
- Plan operational continuity. Assign responsibility for registration contacts, routing-registry entries, reverse DNS and routing-security authorisations. A Route Origin Authorisation, or ROA, states which network may originate a route. Changes to its certificate or issuer need to be coordinated so valid announcements do not become invalid during the handover.
- Verify completion. Check the resulting holder records, security authorisations and actual routing from relevant networks. Confirm service behaviour as well as the administrative receipt. Keep a clear record of who will maintain each item afterwards.
A registry can confirm a transfer without guaranteeing that every network will accept the resulting route. Your engineering plan still has to account for upstream providers, routing filters and the services using those addresses.
The deeper issue: what should the registry approve?
These practical checks reveal an important distinction. Establishing that a seller is authorised and a transfer is genuine protects the integrity of the register. Judging whether the buyer’s business plan deserves approval gives the administrator a different kind of power.
Lu Heng explores this in Note 74. If the parties, addresses and authentic documents stay the same, changing a deployment forecast does not create an address conflict. He argues that the operator bearing the investment risk should make the investment decision.
Why transferability is not the same as freedom to leave
An approved transfer under today’s rules is not an unconditional right to change coordination providers. Lu Heng’s wider proposal is for operators to keep their resources, verifiable history and service continuity when changing providers.
That requires secure succession of records and routing authorisations, not simply another copy of a database. The reason to work on it now is practical: dependence is hardest to fix when a dispute has already put a network’s future in doubt.