Which RIRs support inter-RIR IPv4 transfers?
ARIN, RIPE NCC, APNIC, and LACNIC have established inter-RIR IPv4 transfer paths with reciprocal counterparts. AFRINIC ratified an inter-RIR transfer policy on February 4, 2026, and reported that reciprocity with the other four RIRs had been confirmed by April, but its implementation is still underway. Confirm AFRINIC's current handling with both registries before treating that route as available.
Both RIRs must approve the exact transfer. A compatible pair does not make every prefix or organization eligible. Source status, recipient need where required, minimum block size, hold periods, disputes, registry agreements, and the direction of the transfer can change the result. Verified September 24, 2026: use each RIR's current policy and transfer team for a live case.
| RIR path | Current status | Decision boundary |
|---|---|---|
| ARIN ↔ RIPE NCC, APNIC, or LACNIC | Established reciprocal paths | ARIN section 8.4 requires reciprocal, compatible needs-based policy. ARIN source and specified-recipient conditions still apply. |
| RIPE NCC ↔ ARIN, APNIC, or LACNIC | Established paths listed by RIPE NCC | Both registries approve the transfer. Resource type, legacy status, and counterpart conditions must match the selected path. |
| APNIC ↔ ARIN, RIPE NCC, or LACNIC | Established where the counterpart permits the transfer | APNIC applies its source or recipient conditions and a /24 IPv4 minimum; the other RIR applies its own conditions. |
| LACNIC ↔ ARIN, RIPE NCC, or APNIC | Established reciprocal paths | LACNIC applies direction-specific need, source, recipient, minimum-size, and timing rules. |
| AFRINIC ↔ another RIR | Policy ratified; rollout and procedure mapping underway | AFRINIC-issued IPv4 cannot simply move out of the region. Eligible resource categories, direction, current system support, and both registries' live procedures need direct confirmation. |
Inter-RIR IPv4 transfer process
- Identify both registry paths. Use RDAP or the source RIR's registry to record the exact CIDR, current rights holder, source RIR, recipient organization, recipient RIR, and whether the resource is legacy, allocated, assigned, or previously transferred.
- Ask both RIRs about the exact direction. Confirm that the pair, resource type, prefix size, and organizations are supported now. Each party normally works with its own RIR while the registries coordinate with each other.
- Prepare recipient eligibility. Complete membership or service agreements, contacts, need justification where required, and preapproval when the recipient RIR offers it. For example, ARIN bases specified-recipient preapproval on projected 24-month need.
- Clear the source. Verify that the source is the recognized holder, the block is not disputed or reserved, applicable holding periods have passed, registration data is current, and the authorized contact can submit the request.
- Make the contract conditional. Identify the exact prefix, parties, price, fees, documents, payment or escrow provider, approval milestones, rejection handling, refund terms, timing, taxes, and operational handover. A private contract does not replace either registry's approval.
- Submit and close against evidence. Follow both RIR workflows, answer registry questions, and release funds only under the agreed verified milestones. Keep both approval records and confirm the final registry entry before treating the transfer as complete.
A qualified purchase or sale request should already contain the CIDR, source and recipient RIRs, registered organization, intended recipient, target date, and routing plan. Use the IPv4 buyer path or IPv4 seller path to prepare those facts; an initial review is not a registry approval or completion promise.
Eligibility and transfer restrictions to check
| Check | Evidence to record | Why a pair-level “yes” is insufficient |
|---|---|---|
| Source authority | Current RDAP or registry record, account status, authorized contact, and documents accepted by the source RIR | A seller, broker, or route origin is not automatically the registry-recognized source. |
| Resource eligibility | Prefix size, allocation or legacy category, prior transfer date, issue date, reserved status, disputes, and applicable agreement | Minimum sizes, hold periods, and eligible resource categories differ by RIR and direction. |
| Recipient eligibility | Recipient RIR account or agreement, organizational validation, approved contacts, need evidence, and preapproval if available | Some paths are needs-based, and preapproval can expire or cover only a stated quantity. |
| Reciprocal route | Written current guidance from both RIRs for the source, recipient, resource type, and transfer direction | Policy adoption, technical implementation, and live case handling can have different dates. |
| Commercial closing | Contract, fees, payment milestones, rejection and refund terms, tax treatment, and dispute process | RIRs update registry rights and records; they do not validate every commercial promise or guarantee a financial outcome. |
ARIN, APNIC, LACNIC, RIPE NCC, and AFRINIC use different policy structures and terminology. Do not transplant a minimum size, hold period, needs test, or legacy-resource rule from one registry into another case. Where a public page and a transfer team's current instruction differ, preserve the dated evidence and resolve it with the two RIRs before proceeding.
A lease is not an RIR transfer. An IPv4 lease grants contract-defined, time-limited use; by itself it does not change the registry-recognized holder, transfer registry control, or move the registration record into the lessee's name. Routing authorization, LOA, RPKI and IRR changes, abuse handling, the term, return, and revocation responsibilities belong in a separate managed leasing path and contract.
Registry approval is not the operational handover
An approved transfer changes the registry record under the applicable RIR processes. It does not automatically create a BGP announcement, authorize an origin ASN, update every routing filter, repair reputation, configure reverse DNS, or make an application ready. Assign owners and acceptance evidence for each operational dependency:
- Registry and authority: final RDAP or registry record, service agreement, authorized contacts, and retained transfer approvals.
- Routing: origin ASN, transit acceptance, prefix filters, maximum-prefix settings, route visibility, and a tested rollback.
- RPKI and IRR: remove or replace old ROAs and route objects in the correct order, then verify Valid, Invalid, or NotFound observations from more than one vantage point.
- DNS and published data: reverse-DNS delegation, PTR workflow, geofeed, abuse contact, routing contact, and any registry-specific objects.
- Reputation and applications: dated evidence from relevant providers, allowlists, mail or security controls, staged traffic tests, monitoring, and escalation ownership.
Plan overlap between the old and new operators where policy and contract allow it. Record the expected state, observation time, and responsible party for every handover item. Registry completion is one acceptance milestone, not proof that every network or third-party database has converged.
Inter-RIR IPv4 transfer FAQs
Which RIRs support inter-RIR IPv4 transfers?
ARIN, RIPE NCC, APNIC, and LACNIC have established paths with reciprocal counterparts. AFRINIC ratified a policy in February 2026 and reported reciprocal confirmation with the other four RIRs, but implementation was still underway in its June 2026 status report. Confirm the exact live path with both RIRs.
What is an inter-RIR IPv4 transfer?
It is a registry-coordinated transfer in which the source and recipient are served by different Regional Internet Registries. Each RIR evaluates the party and conditions within its responsibility, and the registries coordinate the record change.
Does every IPv4 block qualify for an inter-RIR transfer?
No. Prefix size, resource category, registered holder, issue or prior-transfer dates, disputes, reserved status, recipient eligibility, need requirements, and the transfer direction can make a block ineligible.
Can an AFRINIC resource be transferred to another RIR now?
Do not assume so from ratification alone. AFRINIC says its 2026 policy permits inter-RIR transfers for eligible categories where reciprocal policies exist, while AFRINIC-issued IPv4 cannot be transferred out and implementation work was still in progress. Ask AFRINIC and the counterpart RIR about the exact prefix and direction before contracting.
How long does an inter-RIR IPv4 transfer take?
There is no reliable universal duration. Organization validation, preapproval, source eligibility, documents, RIR queues, counterpart coordination, corrections, payment milestones, and operational handover all affect timing. Get current estimates from both registries and avoid a guaranteed date.
Does an approved transfer make the IPv4 block routable?
No. Registry approval does not create BGP transit, an origin authorization, IRR objects, reverse DNS, reputation acceptance, or application readiness. Those changes need separate owners, sequencing, tests, and rollback.
Should payment be released before both RIRs approve?
The contract should define the payment or escrow provider, evidence, milestones, rejection handling, and refunds. A prudent closing ties release to agreed verifiable events and legal advice for the transaction; neither i.lease nor an RIR should be assumed to guarantee the payment outcome.
Primary RIR policy and process sources
- ARIN NRPM section 8.4: inter-RIR transfers
- ARIN transfer quick guide and specified-recipient preapproval
- RIPE NCC inter-RIR transfers
- APNIC Internet Number Resource Policies, section 11.2
- APNIC transfer conditions
- LACNIC IPv4 transfer policy
- LACNIC inter-RIR operating notice
- AFRINIC policy ratification, February 4, 2026
- AFRINIC-37 implementation status
