InterRIR transfers: 4 registries, dual consent

Four Regional Internet Registries currently enable inter-RIR transfers, while AFRINIC remains excluded due to lacking a policy framework. This mechanism functions as the sole authorized pathway for moving IPv4 blocks and AS Numbers between distinct regulatory jurisdictions like RIPE NCC and ARIN. The process relies entirely on a strict dual-consent architecture where both the sending and receiving registries must approve every request before execution.

Policy frameworks dictate exactly which resources move between regions. You can move only IPv4 transfers between RIPE NCC and LACNIC, whereas full IPv4 and ASN mobility exists with APNIC. Incoming resources face specific status outcomes: LEGACY holdings can retain their classification or convert to ALLOCATED PA based on the recipient's contractual relationship. We outline the precise eligibility criteria for LIRs and non-members initiating these complex cross-border transactions.

Ignoring these procedural nuances risks immediate rejection by the Regional Internet Registry overseeing the destination region. Since internet number resources remain subject to original policies until both registries update their databases, timing and compliance are critical. This guide dissects the operational reality of global IP resource management in 2026, moving beyond theoretical policy to the concrete steps required for successful resource movement.

The Role of Inter-RIR Transfers in Global IP Resource Management

Inter-RIR Transfer Definition and RIR Policy Frameworks

An inter-RIR transfer moves IPv4 blocks between distinct regional registries under dual approval. This mechanism enables global redistribution of scarce IPv4 assets while respecting regional sovereignty. Currently, only RIPE NCC, ARIN, APNIC, and LACNIC maintain active policies facilitating these cross-border transactions. AFRINIC lacks a compatible framework, effectively isolating its resources from the global secondary market. Operational success demands strict adherence to divergent policy frameworks governing each jurisdiction. The source and destination registries must both validate the transaction before updating any records. This dual-consent model prevents regulatory arbitrage but introduces coordination overhead for network operators.

Legacy status preservation varies by receiving policy, often requiring conversion to allocated or assigned states. Organizations ignoring these nuances risk rejected applications and delayed infrastructure deployment. Failure to align with specific regional mandates halts the entire redistribution process. Strategic planning around these constraints ensures efficient capitalization on available IPv4 inventory.

Allocated PA vs Assigned PI Status in RIPE NCC Transfers

Operational flexibility hinges on the distinction between ALLOCATED PA and ASSIGNED PI. The former restricts holding rights to RIPE NCC members for downstream distribution. The latter permits non-member ownership via a sponsoring LIR without further assignment capabilities. Resources flagged as ASSIGNED PI cannot be subdivided or reassigned to third parties, limiting their utility for service providers aiming to lease sub-blocks. Conversely, ALLOCATED PA blocks retain full hierarchical distribution rights but impose stricter membership compliance.

A critical procedural constraint involves the mandatory two-year hold period; IPv4 subnets allocated by RIPE NCC cannot transfer until this timeline elapses since the last allocation. Recipients moving resources into the RIPE region must submit a utilization plan covering at least 50% of the transferred space within five years if originating from needs-based regions.

The inability to re-assign ASSIGNED PI addresses creates a hard ceiling on network expansion strategies for non-member entities. Organizations must evaluate whether their growth model requires the aggregatable nature of PA space or if independent PI space suffices for static infrastructure. Failure to align resource status with business objectives results in inefficient capital deployment and potential regulatory friction during audits.

Inter-RIR vs Intra-RIR Transfer Consent Requirements

Inter-RIR transfers mandate dual regulatory consent from both source and destination registries, unlike single-authority intra-RIR movements. This dual-consent model introduces significant procedural complexity because two distinct policy frameworks must validate the transaction simultaneously. Operators navigating inter-RIR transfers face a bifurcated approval workflow where the source RIR and receiving RIR both hold veto power. Conversely, intra-regional transactions require authorization solely from the destination registry, streamlining the administrative burden.

Specific bidirectional pathways exist for IPv4 blocks and ASNs between RIPE NCC and ARIN, as well as RIPE NCC and APNIC. The corridor between RIPE NCC and LACNIC supports IPv4 mobility but excludes ASN transfers, reflecting divergent regional resource availability. While the market demands fluidity, the requirement for synchronized approval across jurisdictions creates latency that intra-RIR deals avoid. Organizations often underestimate the coordination needed when process initiation protocols differ by region, such as APNIC requiring the recipient to prompt the source.

Failure to secure simultaneous validation halts the resource status conversion, leaving assets in limbo between registries.

Inside the Dual-Consent Architecture of Cross-Registry Resource Movement

Dual-Consent Workflow and iDenfy Verification Steps

Approval for inter-RIR transfers begins only after the source registry validates the specific transfer template sent to [email protected]. This dual-consent architecture requires the originating RIR to confirm sender eligibility before the destination registry evaluates recipient need. Identity verification for natural persons introduces a specific friction point requiring a passport copy verified by a third-party called iDenfy. Corporate entities face a distinct constraint demanding a confirmation letter signed by a legally authorized company director within the RIPE NCC service region. Legacy resource holders lacking standard contracts must also submit this director-signed letter to bypass typical contractual prerequisites.

Sequential checks prevent the destination RIR from starting its evaluation until the source registry explicitly notifies it of initial approval. This dependency creates a hard stop in the workflow that blocks parallel processing of due diligence documents. Operators frequently underestimate how divergent document standards between regions stall the confirmation letter acceptance phase. Strict separation of duties ensures no single registry unilaterally alters the global routing table. Misalignment between RIPE Database objects and the receiving registry's timeline results in temporary service gaps for reverse.

Reverse DNS and RPKI Service Disruption During Transfer

Reverse delegation disappears instantly when the source registry deletes DOMAIN objects upon transfer completion. The RIPE NCC confirms immediate removal of all associated objects, leaving IP space without name resolution until the receiving party reconstructs zone files in the new registry environment. This abrupt severance creates a window where mail servers may reject traffic due to failed pointer lookups. Existing RPKI certificates simultaneously shrink or vanish, rendering prior Route Origin Authorizations invalid. Announcements subsequently display an RPKI Unknown status because the cryptographic chain of trust breaks when the original resource certificate is revoked. Operators must generate new certificates under the destination RIR to restore RPKI validity since previous signatures no longer match the transferred block's new registry context. Security services increasingly treat accurate registry data as integral to transfer processing, meaning unresolved validation states can delay final settlement.

Synchronization gaps create hidden operational risks where routing continues while lost cryptographic validation exposes prefixes to potential hijacking until new ROAs are published. This vulnerability persists regardless of the transfer's administrative approval status, a fact Network teams at InterLIR advise coordinating the technical migration of DNS and RPKI assets to occur precisely when registries update, minimizing the exposure window. Failure to align these steps leaves assets reachable but unverified, a state increasingly flagged by modern filtering policies.

Legacy Resource Validation and Contractual Requirements

Legacy IPv4 holders lacking active service agreements must submit a confirmation letter signed by a legally authorized company director to validate ownership. This specific document replaces standard registration papers, satisfying the strict due diligence required for inter-regional mobility. Transfer evaluation cannot proceed without this signed attestation, regardless of the asset's historical status. Operators moving assets into the RIPE region face a binary contractual choice: establish direct membership or apply a sponsoring LIR for ASSIGNED PI status. This exception allows non-members to hold legacy blocks without forcing a full service contract, provided a sponsoring entity manages the registry interface.

Operational overhead conflicts with asset liquidity in this scenario. Choosing the sponsoring LIR path avoids membership fees but permanently restricts downstream assignment capabilities, locking the resource into a static end-user role. Failure to align these contractual states before requesting the transfer causes immediate rejection by the policy team. Precise documentation prevents costly delays in the dual-consent workflow.

Executing a Compliant Inter-RIR Transfer Request step-by-step

Eligibility Rules for Inter-RIR Transfer Requestors

Directional flow and the contractual status of the holding entity dictate eligibility for an inter-RIR transfer request. Operators moving resources from the RIPE NCC region must qualify under one of three specific identities. RIPE NCC members (LIRs) act as primary requestors. Non-members must route applications through their sponsoring LIR. Legacy resource holders lacking the service agreement retain eligibility by submitting a confirmation letter signed by a legally authorized director. This distinction creates a procedural fork where legacy assets bypass standard membership requirements yet still demand rigorous identity attestation.

Verification pathways diverge based on legal structure, introducing a dependency on third-party validation for individuals. Natural persons must submit passport copies verified by iDenfy. Corporate entities provide recent national registration documents.

Operational risk arises when assuming legacy status exempts holders from modern due diligence protocols. Contractual barriers are removed for these assets. The burden of proof shifts entirely to the accuracy of the submitted confirmation letter. Any discrepancy in signatory authority can impede the dual-consent process before the receiving RIR engages.

Executing the Transfer Template and Due Diligence Submission

Submitting the completed inter-RIR transfer template to [email protected] initiates the validation workflow. This email address serves as the assigned contact point for requests originating in the RIPE NCC service region, triggering a sequence of document verification. Operators must attach a recent registration document from national authorities for legal persons or a passport copy verified by iDenfy for natural persons. A signed confirmation letter from an authorized director within the service region serves as the mandatory attestation of ownership.

1. Complete the official inter-RIR transfer template with accurate source and destination details.
2. Gather due diligence documents specific to your entity type (corporate registration or individual ID).
3. Secure a signed confirmation letter from a legally authorized company director.
4. Email the complete package to the assigned RIPE NCC coordination address.
5. Await initial eligibility screening before the receiving RIR begins its independent evaluation.

Accuracy of the database registration represents a critical operational consideration. Resources must be properly registered in the source RIR's database to proceed. The procedural bottleneck often shifts from policy compliance to data hygiene, where inconsistent contact records can cause delays. This precision prevents circular delays where the receiving RIR waits for the source to fix data errors that originated in the initial filing.

Verification Checklist for Confirmation Letters and Legacy Status

This document serves as the primary authorization mechanism for legacy holders lacking a direct service agreement, effectively replacing standard contracts during the verification phase. Operators must ensure a legally authorized company director signs this attestation, as the validity of the signature is necessary for the transfer request to proceed.

The decision to convert LEGACY status depends entirely on the receiving party's desire for RPKI signing capabilities versus maintaining historical independence. Legacy assets can retain their original designation. Converting to ALLOCATED PA or ASSIGNED PI enables full cryptographic validation but mandates a new contractual relationship.

Evaluation begins strictly upon receipt of all supporting documents. Submitting incomplete packages wastes the coordinated timing required between registries and delays the final registry update.

Adhering to this checklist ensures the inter-RIR transfer proceeds without administrative friction.

Strategic Best Practices for Mitigating Transfer Delays and Policy Conflicts

Application: Inter-RIR Transfer Policy Frameworks and Jurisdictional Shifts

Regulatory authority over IP blocks shifts instantly from source to destination policies upon registry updates, creating a strict jurisdictional boundary. Internet number resources remain subject to the rules of their current registry until the exact moment both RIRs finalize the transaction, a transition governed by distinct policy frameworks across regions. Notably, AFRINIC lacks an inter-RIR policy entirely, rendering any transfer to or from that region impossible regardless of market demand. Operators must navigate this dual-consent model where the source RIR validates the exit and the recipient RIR approves the entry status.

A sharp tension exists between maintaining LEGACY status and accessing modern security features like RPKI, as legacy holders often lack the contractual relationships required for signing. Legacy resources can technically retain their historical classification or convert to ALLOCATED PA or ASSIGNED PI statuses depending on the recipient's membership posture. Successful transfers require simultaneous adherence to two conflicting regulatory regimes until the final swap occurs.

Strategic Timing Around the RIPE NCC Two-Year Hold Period

IPv4 subnets allocated by the RIPE NCC cannot transfer within two years of their last allocation or transfer event. This mandatory hold period creates a fixed temporal boundary that overrides market urgency or immediate liquidity needs. Operators attempting to move resources before this window closes face automatic rejection, regardless of buyer readiness or price agreement. The constraint applies strictly to the resource block itself, meaning partial transfers do not reset or bypass the clock for the remaining space.

Strategic planning requires calculating exact eligibility dates based on the most recent registry update rather than the original acquisition year. A common error involves misidentifying the start date for blocks with complex histories involving mergers or previous inter-RIR movements. Organizations must verify the specific allocation date in the RIPE Database to avoid wasted due diligence efforts on ineligible assets. Maintaining current utilization efficiency while preparing for future liquidity events presents an operational challenge. Waiting for the hold period to expire may delay necessary network re-architecting or exit strategies. Premature filing guarantees failure and consumes administrative bandwidth improved spent on compliant transactions. Patience remains the only viable strategy when dealing with recently allocated IPv4 subnets.

Application: Pre-Transfer Validation for Contractual Relationships and Legacy Status

Validate contractual status immediately to prevent dual-registry rejection before initiating any inter-RIR transfer workflow.

Operators must distinguish between three distinct entity types requiring unique documentation packages:

1. ALLOCATED PA resources demand active RIPE NCC membership.
2. ASSIGNED PI blocks allow non-member participation through a sponsoring LIR.
3. Legacy holders lacking current service agreements must submit a specific confirmation letter signed by an authorized director.

This document replaces standard contracts but fails validation if the signatory lacks explicit legal standing in national records. Converting LEGACY status enables RPKI deployment but permanently alters the resource's regulatory history.

Preserving legacy independence conflicts directly with gaining modern security tooling access. Choosing to maintain legacy status avoids annual fees but restricts the network to manual routing security measures. InterLIR recommends verifying the company director authorization via national registries before submission to avoid immediate procedural failure. This pre-check eliminates the most frequent cause of evaluation stalls in the IPv4 market.

References

• RIR Policies Comparison: RIPE vs ARIN vs APNIC vs