IPv4 Transfer Policy Comparison by RIR
An IPv4 transfer must satisfy the source registry’s rules, the recipient registry’s rules and the restrictions attached to the resource. Use the comparison below to screen a proposed ordinary transfer. It does not replace the separate procedures for M&A or historical resources.
Compare ordinary IPv4 transfers
| Registry | Minimum IPv4 transfer | Recipient requirements | Source and resource restrictions |
|---|---|---|---|
| RIPE NCC | No IPv4 minimum in RIPE-807; the other RIR's minimum applies to inter-RIR transfers. | No needs assessment for ordinary intra-region transfers. Inbound transfers from a needs-based region require a plan to use at least 50% within five years. | IPv4 is restricted for 24 months after receipt, including receipt through M&A. Further genuine M&A is excepted; a voluntary transfer lock is a separate restriction. |
| ARIN | /24 for ordinary specified-recipient IPv4 transfers; M&A follows a separate minimum-size rule. | An organization with no IPv4 allocation from ARIN qualifies for an initial /24. Larger or additional requests normally require 50% use within 24 months and 50% utilization of existing ARIN IPv4 holdings; section 8.5.7 offers an alternative route. | The source generally must not have received IPv4 resources from ARIN in the preceding 12 months. M&A and specified exceptions differ; waitlist space has a separate 60-month restriction. |
| APNIC | /24 for ordinary IPv4 transfers within the region and between RIRs. | A detailed 24-month use plan; existing holders also supply past utilization and evidence of compliance with previous delegations. | Addresses delegated from the 103/8 free pool cannot be transferred for five years after original delegation, including through M&A. This is not a blanket five-year lock on all APNIC IPv4 space. |
| LACNIC | /24 under the ordinary IPv4 transfer policy. | Initial or additional allocation/assignment justification under current LACNIC policy; an overseas recipient follows its receiving RIR's rules. | One year before retransferring previously transferred space; three years after a direct LACNIC allocation or assignment. A source cannot receive direct LACNIC IPv4 allocations or assignments for one year after transferring. |
| AFRINIC | CPM 5.7 does not state a universal transfer minimum; the recipient must meet the applicable allocation or assignment criteria. | AFRINIC membership, a Registration Services Agreement and approved initial/additional IPv4 need. | No receipt of an AFRINIC IPv4 transfer, allocation or assignment in the previous 12 months, except M&A; no further direct AFRINIC IPv4 allocations or assignments for 12 months after transfer approval. |
The registry names lead to the relevant policy source and operational detail. Minimum size here means a registry transfer threshold. It does not guarantee that transit providers will accept the resulting prefix.
Check three kinds of restriction
Check the source, the resource and the recipient independently. All applicable conditions feed the registry’s review; passing one does not waive the others or guarantee approval. The connections show a logical requirement, not a filing sequence.
View full diagram
Resource restriction: tied to the block’s history or status. Examples include a RIPE post-receipt period, an APNIC final-pool restriction or an ARIN waitlist restriction. Splitting a prefix does not automatically remove the restriction on its addresses.
Organization restriction: tied to the source’s activity. A rule based on the source receiving resources in the previous year can matter even when the offered block is much older. Ask about the source account’s recent transactions, not just the prefix’s original registration date.
Request-specific condition: tied to the proposed recipient, purpose or route. A recipient may need an operational deployment plan, a service agreement or a different account type. A new legal entity does not inherit another entity’s eligibility merely because they share an owner.
Record which date starts each period and obtain the registry’s eligibility decision when the history is ambiguous.
The transfer route changes the assessment
| Route | Additional question |
|---|---|
| Within one RIR | Are both accounts and this resource type eligible under that registry’s policy? |
| Between RIRs | Do both registries support this direction and resource type, and which needs test applies? |
| Merger or acquisition | Does the evidence establish the corporate event or acquisition of the qualifying business assets? |
| Legacy or historical resources | Is the holder recognized, which services are available, and what status applies after transfer? |
For cross-region cases, use inter-RIR eligibility and handover. A statement that “RIPE has no needs assessment” is insufficient for an inbound transfer from a needs-based region.
Apply the table to a candidate block
- Identify the exact prefix, current RIR, holder and resource status.
- List receipt dates, recent transfers and restrictions on the source account.
- Identify the recipient’s legal entity, account type and supported route.
- Prepare the recipient needs evidence if required.
- Resolve exceptions in the registry ticket before making approval-dependent commitments.
For a corporate event, follow M&A registration changes rather than treating it as an ordinary specified-recipient transfer. A contract calling a transaction an acquisition does not establish the applicable registry procedure.
When preparing an IPv4 block for transfer, provide the account and block history early. It is more useful for eligibility than a general claim that the prefix is “transferable.”