APNIC transfer rules: 5-year lockouts explained

Transfers of 103/8 free pool addresses face a mandatory five year lockout period according to APNIC transfer conditions. Readers will dissect the specific scope governing IPv4 and AS number movements, the operational friction inherent in inter-RIR account shifts, and the mandatory financial barriers imposed on new entrants versus established members.

The regulatory environment demands that every recipient account submit a detailed usage plan before APNIC approves any inbound movement from another RIR. Unlike the free movement offered by the RIPE NCC where resource transfers incur no charges, the Asia-Pacific region enforces a paywall where Annual Membership fees or specific transfer fees must be settled before transaction completion. This financial gatekeeping applies universally to historical resources and corporate reorganizations, ensuring that only solvent entities maintain registry presence.

Operational mechanics further complicate these exchanges by instantly deleting associated Whois Database objects upon outbound movement, effectively stripping the source entity of all technical footprint. The policy treats IPv4 transfers resulting from mergers or acquisitions with the same suspicion as commercial sales, requiring proof of continued need or mandating the return of assets. Such friction illustrates a system prioritizing inventory control over fluid market dynamics, forcing organizations to navigate a complex web of fee structures and usage justifications to secure necessary internet infrastructure.

The Scope and Definitions Governing APNIC Resource Transfers

Defining Inbound Inter-RIR Transfers and Eligible Assets

An inbound inter-RIR transfer moves unused or excess IPv4 addresses and/or AS numbers from a member of another registry to an APNIC account. This mechanism reallocates resources rather than relying on depletion-prone free pools. Eligibility extends strictly to members within the RIPE NCC, ARIN, and LACNIC regions. All recipient APNIC accounts will be asked to provide a detailed plan for the use of the transferred resource. Historical resources follow identical validation paths, requiring the recipient of the transfer to be an APNIC Member. The operational constraint lies in the rigorous scrutiny of use cases; operators cannot simply acquire space for future valuation. This policy ensures that transferred blocks re-enter active routing tables quickly, maintaining global table hygiene.

Operational Timelines for APNIC Transfer Requests and Pre-approvals

The 30-day acknowledgment window dictates transfer viability, as unconfirmed requests trigger automatic cancellation. This constraint forces operational discipline, ensuring that only active entities finalize resource acquisition while speculative holds expire.

Pre-authorization mechanisms offer extended flexibility for strategic planning. Approved pre-approvals remain valid for a 24-month duration from the date of issuance. This period allows organizations to align infrastructure deployment with long-term capital cycles without rushing immediate utilization. However, the policy explicitly mandates that resources be "correctly registered to organizations who are using them," prioritizing operational necessity over passive asset holding.

The 103/8 free pool remains restricted for a minimum of five years post-delegation, preventing immediate resale of recently assigned blocks. This specific prohibition narrows the available market inventory, directing demand toward legacy holdings and secondary transfers. Consequently, network architects must verify the origin history of target blocks to avoid rejected applications based on recency rules.

Mandatory Usage Plans and Minimum Size Requirements for IPv4

APNIC mandates a detailed usage plan from all recipient accounts to validate genuine operational need before approving any resource movement. This requirement prevents market speculation by ensuring transferred blocks support immediate infrastructure deployment rather than asset hoarding. Recipients without existing IPv4 resources must demonstrate a detailed plan for resource use within a 24-month horizon. The policy explicitly links this documentation to the prevention of idle inventory accumulation across the regional registry.

Inter-RIR transactions impose additional dimensional constraints alongside administrative checks. The minimum transfer size for these cross-regional movements adheres to thresholds set in Section 3.1 of the governing framework. This floor maintains registry hygiene by discouraging fragmentation of the global routing table through micro-transfers.

Failure to align acquisition strategy with these dimensional and documentary rules results in wasted administrative cycles. Before initiating contact with potential sellers. The cost of non-compliance is total transaction invalidation.

Operational Mechanics of Inter-RIR and Account-Based Movements

Fee Liability and Object Deletion in Outbound Inter-RIR Transfers

The APNIC account holder assumes full financial responsibility for fees during outbound inter-RIR movements involving unused or excess IPv4 addresses and AS numbers. Unlike inbound scenarios where recipients bear costs, this reversal places the monetary burden on the source entity executing the transfer. Operators must budget accordingly before initiating requests to members of other regional registries.

Upon completion of an outbound inter-RIR transfer, all objects associated with the transferred resources, such as sub-assignments, route objects, and domain entries, are deleted from the APNIC Whois Database.

Verifying that the authentic holder matches the source without disputes is a requirement for inter-RIR transfers before submission. The removal of historical routing objects creates a dependency risk if local archives are incomplete.

Executing Outbound Transfers: Fee Payment and Database Cleanup

Initiating an outbound inter-RIR transfer triggers financial liability for the source account holder. The APNIC account holder bears the cost when moving resources to another registry.

Technically, the APNIC Whois Database deletes all associated objects when the transfer is complete. This includes route objects, sub-assignments, and domain entries linked to the transferred block.

Maintaining historical routing stability conflicts with enforcing strict registry accuracy. Deletion of route objects removes traffic engineering constraints associated with the source registry, requiring the new owner to re-publish them. Organizations should coordinate synchronization windows between transfer completion and upstream filtering updates. The source entity retains no rights to the resources once the transaction finalizes.

Critical Failure Mode: Automatic Cancellation After the 30-Day Acknowledgment Window

Missing this window results in immediate cancellation of the request.

Thorough due diligence conflicts with the rigid 30-day acknowledgment clock. Inter-RIR transfers remove all associated route objects from the WHOIS database upon completion, meaning any delay risks leaving the network without valid routing data during the transition. Failure to align these timelines results in lost momentum and repeated administrative fees.

Financial Obligations and Fee Structures for IPv4 Transactions

Annual Membership vs Transfer Fee Liability by Account Status

Fee liability depends strictly on whether the recipient account currently holds IPv4 resources. An initial IPv4 transfer to a new account or an existing empty account triggers an Annual Membership fee obligation. The registry refuses to complete resource registration until this payment clears. Established accounts receiving additional blocks incur a standard transfer fee instead of membership dues.

Operators distinguishing these statuses enable the registry to process transfers without delay. New entities sometimes budget for a transfer fee while missing the Annual Membership fee required for entry. Policy separates joining the registry from expanding an existing footprint. Every transferred block maps to a verified, financially accountable entity within the global routing table.

Executing Fee Payments for Historical and Mergers Transfers

Payment of the Annual Membership fee or transfer fee serves as the absolute gatekeeper for finalizing historical and merger-related resource movements. Identical fee structures govern both historical Internet number resource transfers and transfers due to mergers, acquisitions, and/or reorganization. This uniformity removes ambiguity during complex corporate consolidations. Recipients holding no existing IP blocks must settle membership dues before the registry executes the transaction. Established accounts incur only the standard transfer charge.

Transfer status remains pending until payment clears, potentially delaying integration timelines for merged entities. Transfers involving National Internet Registries demand a specific template completion submitted via email, unlike standard account-to-account movements initiated via the portal. Historical transfers impose an additional constraint: the recipient must strictly be a member. Non-member entities cannot acquire legacy assets directly. Operators verify membership status prior to negotiation to avoid deal failure. The source entity loses all rights to the resources immediately upon completion. Associated WHOIS objects are deleted from the Whois Database in outbound inter-RIR transfers. Misaligned payment timing with legal closing dates creates a window where resources sit in limbo, controlled by neither seller nor buyer.

Transfer Completion Blockers Due to Unpaid Fee Structures

Unpaid Annual Membership or transfer fee invoices halt IPv4 registration immediately, regardless of technical readiness. This financial gate prevents database updates until the ledger clears. A hard dependency forms between accounting and network operations. Accounts receiving their first block must settle membership dues. Established entities pay the specific transfer charge. Confusing these categories causes delays because operators often misidentify their liability status before initiating the move. Policy mandates that resources remain unregistered until the correct fee type is identified and paid.

Failure to distinguish these obligations results in the transaction not being completed. Recipients must acknowledge a transfer request within 30 days after initiation by the source account, or the request will be automatically cancelled. Operators verify their account standing against the transfer guide criteria before expecting completion. Pre-validating fee classification avoids suspension of IPv4 deployment timelines.

Executing Post-Transfer Registration and Resource Finalization

Defining Post-Transfer Rights and Policy Compliance

Completion of the transaction instantly terminates all source entity rights to the transferred IPv4 addresses and AS numbers. These resources immediately become subject to current APNIC policies, specifically Section 11.3 regarding historical internet resources. The recipient assumes full legal liability, while the previous holder loses any claim to the block.

Operators must execute the following steps to finalize registration status:

1. Confirm deletion of all legacy route and domain objects from the APNIC Whois Database.
2. Submit a detailed utilization plan if the transfer involves addresses from the 103/8 free pool, which carry a mandatory five-year lock-up period.
3. Settle the required Annual Membership fee or transfer fee to activate the new registry entry.

A critical operational tension exists between immediate network deployment and policy compliance. While engineering teams often seek to announce routes instantly upon handover, InterLIR advises that announcing blocks before fee settlement risks route filtering by upstream providers who validate registry status. The legal transfer of title precedes technical viability; without cleared financial obligations, the resource remains in a limbo state where it is legally owned but operationally unusable.

Executing Resource Registration and Route Object Updates

Finalize the IPv4 transfer by registering resources to your account only after the source objects are deleted.

1. Verify that all legacy route and domain objects associated with the block are removed from the APNIC Whois Database.
2. Submit a detailed utilization plan if the transfer involves addresses from the 103/8 free pool or constitutes a first-time allocation.
3. Settle the required Annual Membership fee or transfer fee before APNIC completes the registration.

NIR transfers require a specific text-based template containing registration information, which must be emailed rather than processed via the standard portal interface. Once the financial and administrative gates clear, the system registers the resources to the recipient entity immediately.

Operators must recreate these route objects manually, as the transfer process does not migrate routing policies automatically. This manual recreation introduces a brief window where the AS path lacks valid origin authentication until the new object propagates globally. While speed is desirable, rushing the object creation before fee clearance triggers an automatic rejection of the update request. Failure to align these steps results in a state where the IP block is legally owned but technically unroutable via standard BGP announcements.

Troubleshooting Missing Registrations and Deleted Database Objects.

All route objects and sub-assignments linked to transferred blocks vanish from the APNIC Whois Database instantly upon transaction initiation. This automatic deletion creates an immediate routing blackhole if the recipient fails to manually recreate every object before the cutover window closes. Operators often mistake this clean slate for a system error, yet the policy explicitly mandates removal to prevent conflicting registry data during ownership handover.

The operational risk intensifies because no automated backup restores these definitions for the new owner. You must reconstruct the entire hierarchy, including domain pointers and assignment details, using fresh credentials. Neglecting even a single route object leaves the associated prefix unreachable via BGP, as upstream peers will filter the unregistered announcement.

Execute this verification sequence to restore service availability:

1. Confirm the complete absence of legacy objects in the publicWHOIS search tool.
2. Recreate inetnum and route objects with updated maintainer references matching your account.
3. Validate that no lingering filters block traffic due to missing RPKI validation chains.

InterLIR recommends auditing the database state one hour post-transfer to catch missing entries before users report outages. The cost of this manual labor is negligible compared to the revenue loss from an unannounced prefix.

References

• RIPE IPv4 Transfer Process: How to Buy, Sell, and