Skip to content
Article Transfer • •

Common Inter-RIR Transfer Rejections

Each refusal traced to the registry rule behind it, grouped by stage, with the fix per cause and what to check before money changes hands.

An inter-RIR transfer is refused when the deal breaks a rule of either registry. The usual causes are a resource the RIR pair cannot move (LACNIC takes IPv4 only, AFRINIC exchanges nothing, ARIN moves no IPv6), a source still inside a hold period, and a recipient that fails the receiving RIR's needs test. Unpaid registry fees and a failed identity or sanctions check stop transfers too. Every one of these can be checked before any money changes hands.

Why Do Inter-RIR Transfers Get Rejected?

Each registry applies its own rules to its own side. The source RIR checks that the requester is the registered holder, that no dispute is open and that no hold period or lock is running. The receiving RIR checks the recipient: contract or membership, needs plan, presence in its region, identity and sanctions. A deal can pass one side and fail the other.

Types of rejections:

  • Hard rejections: A rule is broken (hold period, incompatible RIR pair, non-transferable resource); only time or a different resource fixes it
  • Soft rejections: Documentation or clarification issues, easily remedied
  • Conditional approvals: Approved for different amount or terms

A rejection has a price of its own. ARIN's $500 transfer request fee is non-refundable (2026 fee schedule), LACNIC keeps the US$200 down payment the receiving organization pays before its analysis (LACNIC inter-regional transfers), and APNIC's transfer fee is 20% of the annual fee for the resources moved. The RIPE NCC charges nothing for transfers. On top comes whatever the purchase agreement says about a failed closing.

For the full sequence of steps, see how inter-RIR transfers work.

Category 1: Hold Period and Eligibility Rejections

The most common hard rejection category involves resources not meeting minimum hold period requirements.

Rejection 1: Hold Period Not Met

Problem: Attempting to transfer resources before the required hold period has elapsed.

Why it happens:

  • Seller miscalculated the hold period
  • Confusion about which date starts the clock
  • Resources were recently transferred to seller
  • Multiple transactions created unclear timeline

Transfer restrictions by RIR:

  • ARIN: the source must not have received IPv4 from ARIN (allocation, assignment or transfer) in the 12 months before approval, unless source and recipient are under common control (NRPM 8.4). Space from the ARIN waitlist cannot be transferred for 60 months (NRPM 4.1.8), reserved-pool space (4.4, 4.10) never. A source that transfers IPv4 out is barred from the waitlist for 36 months.
  • RIPE NCC: IPv4 and 16-bit ASNs cannot be transferred for 24 months after the holder received them, by allocation, transfer, merger or acquisition (ripe-807 section 2.2.1). 32-bit ASNs and IPv6 have no hold period. A resource under a Voluntary Transfer Lock cannot move until the lock ends: locks run 6, 12 or 24 months and cannot be cancelled once applied (ripe-806).
  • APNIC: addresses delegated from the 103/8 pool cannot be transferred for five years after the original delegation (APNIC-127 section 11); APNIC policy sets no other hold period.
  • LACNIC: space allocated by LACNIC cannot be transferred for three years; a received block is locked for one year, and the source cannot obtain IPv4 from LACNIC for one year (LACNIC inter-regional transfers, Policy Manual 2.3.2.18).

Per-region recipient rules are in inter-RIR transfer eligibility.

How to avoid: Before initiating transfer:

# Check ARIN registration date
whois -h whois.arin.net [IP-RANGE] | grep -i "regdate\|updated"

# Check RIPE allocation date
whois -h whois.ripe.net [IP-RANGE] | grep -i "created\|last-modified"

The object's created: date is not the date the holder received the block. The RIPE NCC publishes every transfer with its date (ripe-807 section 4.0); that date, or the allocation date, starts the 24-month clock.

Prevention checklist:

  • Verify exact allocation or transfer date from RIR WHOIS
  • Calculate hold period from the correct date (most recent RIR transaction)
  • Add a buffer: ARIN counts its 12 months to the approval date, not to the filing date
  • Request confirmation from source RIR if dates are unclear
  • Document hold period compliance before making purchase commitment

If rejected:

  • Wait until hold period is satisfied
  • Consider alternative resource sources
  • Negotiate extended closing date with seller

Rejection 2: Source Organization Not Registered Holder

Problem: The organization requesting the transfer is not the registered holder in the RIR database.

Why it happens:

  • Corporate restructuring changed legal entity
  • Resources registered under different subsidiary
  • Parent company vs. subsidiary confusion
  • Merger/acquisition not yet reflected in RIR database
  • A reseller trying to transfer resources registered to another organization

How to avoid:

  • Verify exact legal entity name in RIR WHOIS
  • The selling organization's name must match the registered holder exactly
  • Complete any necessary corporate restructuring with RIR first
  • If recent merger/acquisition, update RIR records before transfer

WHOIS verification:

whois -h whois.arin.net [IP-RANGE] | grep -i "orgname\|organization"

If rejected:

  • Update registration to correct legal entity
  • Complete merger/acquisition process with RIR
  • Establish proper authorization chain

Rejection 3: Outstanding Obligations to Source RIR

Problem: Source organization has unpaid fees, overdue reports, or other outstanding obligations.

Why it happens:

  • Unpaid membership fees
  • Late payment of annual maintenance
  • Outstanding compliance requests
  • Unreturned communications from RIR
  • Account holds or restrictions

At the RIPE NCC, the annual contribution for every LIR account a member holds must be paid before any transfer is processed, and no new or ongoing request is handled once an invoice is 60 days overdue (RIPE NCC Billing Procedure 2026, sections 2.3 and 3.4). ARIN's $500 transfer request fee and LACNIC's US$200 down payment are paid up front; an unpaid fee leaves the request unopened.

How to avoid:

  • Verify account status with source RIR before initiating
  • Pay all outstanding fees
  • Respond to any pending RIR requests
  • Clear any account restrictions or holds

Checking account status:

  • ARIN: Check ARIN Online account dashboard
  • RIPE: Review LIR Portal for outstanding items
  • APNIC: Check MyAPNIC account status
  • LACNIC: Verify member portal compliance status

If rejected:

  • Pay outstanding fees immediately
  • Respond to compliance requests
  • Clear all account holds
  • Request status confirmation from RIR

Category 2: Documentation Rejections

Documentation issues are the most common soft rejections and usually the easiest to remedy.

Rejection 4: Incomplete or Missing Documentation

Problem: Required documents not submitted or incomplete.

Why it happens:

  • Misunderstanding of requirements
  • Checklist not consulted
  • Documents partially uploaded
  • Email attachments failed
  • Portal submission errors

Common missing documents:

  • Company registration papers
  • Authorization letters
  • Officer attestation (ARIN)
  • Notarization (ARIN transfers)
  • Confirmation letter (RIPE)
  • Utilization plans
  • Evidence of an active network element in the region (RIPE NCC)

How to avoid:

Use RIR-specific checklists:

ARIN transfers (source):

  • Signed and notarized Officer Acknowledgement Letter
  • Transfer agreement (if requested)
  • Authorization from Tech or Admin POC
  • Payment confirmation

RIPE transfers (recipient):

  • Recent registration document from the relevant national authority
  • Confirmation letter of the transfer request, signed by a company director legally authorized to act for the party
  • Plan showing 50% use within five years when the space comes from a needs-based RIR (ripe-807 section 3.2)
  • Evidence of an active network element in the RIPE NCC service region
  • Source-side steps for the ARIN direction: RIPE to ARIN transfer step-by-step

APNIC transfers (recipient):

  • Organization registration documents
  • 24-month utilization plan
  • Network infrastructure documentation
  • Authorization letters

Prevention strategies:

  • Create complete document package before submitting
  • Use RIR-provided templates
  • Double-check all attachments uploaded successfully
  • Request confirmation of receipt
  • Keep copies of everything submitted

If rejected:

  • Submit missing documents immediately
  • Check the file format the portal accepts
  • Confirm successful upload
  • Follow up to verify completeness

Rejection 5: Outdated or Invalid Company Registration

Problem: Company registration documents are too old or don't match current legal entity.

Why it happens:

  • Using an old registration document
  • Company name changed since documents issued
  • Registration jurisdiction incorrect
  • Documents from wrong legal entity

RIR requirements:

  • RIPE NCC: a recent registration document from the relevant national authority (ripe-863)
  • ARIN: Current company documentation
  • APNIC: Recent registration certificates
  • LACNIC: Current company registration

How to avoid:

  • Obtain fresh company registration documents before starting
  • Verify legal entity name matches exactly
  • The registry named must be the one where the organization is incorporated
  • Check document expiration or age limits

Document sources by region:

  • Europe: National company registries, chambers of commerce
  • US: Secretary of State, articles of incorporation
  • Canada: Corporate registry
  • Asia-Pacific: National business registries
  • Latin America: Registro Mercantil, equivalent registries

If rejected:

  • Obtain current company registration documents
  • The legal name must match the registry record exactly
  • Resubmit with updated documents

Rejection 6: Improper Authorization or Signature

Problem: Authorization letters lack proper signatures, notarization, or authority level.

Why it happens:

  • Signer doesn't have legal authority
  • Missing notarization (ARIN)
  • Unsigned documents submitted
  • Electronic signature not accepted
  • Wrong person signed

Requirements by RIR:

ARIN:

  • Officer Acknowledgement Letter must be signed by corporate officer
  • Notarization required
  • Officer must have authority to bind organization

RIPE:

  • Confirmation letter signed by company director
  • Must be legally authorized to act on behalf of organization

APNIC/LACNIC:

  • Authorization from legal representative
  • Proper designation/title
  • Company documentation

How to avoid:

  • Confirm signer has proper authority (director, officer, authorized representative)
  • Obtain notarization where required
  • Use original signatures
  • Include signer's title and authority
  • Reference corporate documents establishing authority

Notarization tips:

  • Use licensed notary public
  • Bring proper identification
  • Complete the document before notarizing it
  • Check notary seal is clear and complete

If rejected:

  • Obtain signature from properly authorized person
  • Get proper notarization
  • Resubmit with correct authorization
  • May need board resolution establishing authority

Rejection 7: Incorrect or Inconsistent Information

Problem: Information doesn't match across documents or RIR databases.

Why it happens:

  • Legal entity name variations
  • Address mismatches
  • Contact information differences
  • IP range errors
  • Copy-paste mistakes

Common inconsistencies:

  • "Company Inc." vs. "Company Incorporated"
  • Different address formats
  • Old vs. new addresses
  • Technical contact vs. admin contact confusion
  • IP address range typos

How to avoid:

  • Use exact legal entity name from registration everywhere
  • Use consistent address formatting
  • Double-check IP address ranges
  • Verify contact information matches RIR database
  • Review all documents for consistency before submission

Verification steps:

  1. Check exact organization name in source RIR WHOIS
  2. Verify address matches company registration
  3. Confirm contact details are current
  4. Double-check IP ranges against WHOIS
  5. Review all documents for exact matches

If rejected:

  • Correct inconsistencies
  • Update RIR database if needed
  • Match every name and address across all documents
  • Resubmit corrected documentation

Category 3: Needs Assessment Rejections

Needs assessment rejections are particularly challenging as they require substantive changes to justification.

Rejection 8: Insufficient Needs Justification

Problem: Destination RIR determines the recipient doesn't adequately demonstrate need for the requested resources.

Why it happens:

  • Vague or generic utilization plans
  • Unrealistic deployment timelines
  • Insufficient infrastructure documentation
  • Over-requesting relative to demonstrated need
  • Lack of specific use cases

RIR assessment standards:

ARIN (NRPM 8.5):

  • A first /24 needs no needs test for an organization without an IPv4 allocation from ARIN (8.5.4)
  • A larger or an additional block needs documentation showing use of at least 50% of the requested block within 24 months (8.5.5)
  • An organization that already holds ARIN IPv4 must have used at least 50% of its cumulative blocks (8.5.6)

RIPE NCC (50% within five years, ripe-807 section 3.2):

  • Applies to space coming from a needs-based RIR: the plan must show use of at least 50% within five years
  • Business case must be credible
  • Growth projections should be realistic
  • Recipient rules for this direction: ARIN to RIPE transfer requirements

APNIC (APNIC-127 section 11.1.3):

  • A recipient with no IPv4 yet shows a detailed plan to use the space within 24 months
  • A recipient that already holds IPv4 also shows its past usage rate and compliance with APNIC policy on earlier delegations

LACNIC:

  • Recipients justify need under LACNIC's current allocation rules (Policy Manual 2.3.2.18.2); the received block is locked for one year

How to avoid:

Develop strong justification:

1. Detailed infrastructure documentation:

  • Network topology diagrams
  • Server/equipment deployment plans
  • Geographic deployment areas
  • Service architecture

2. Specific use cases:

  • Customer assignment plans: "50 web hosting customers, 2 IPs each = 100 IPs"
  • Infrastructure needs: "20 servers, 5 routers, 10 network devices = 35 IPs"
  • Service requirements: "VPN gateways: 10 IPs, DNS: 5 IPs, CDN: 50 IPs"
  • Growth projections: "Year 1: 200 IPs, Year 2: 400 IPs" with justification

3. Supporting evidence:

  • Current IP utilization (if applicable)
  • Customer contracts or letters of intent
  • Business plan excerpts
  • Revenue projections
  • Market analysis

4. Realistic timelines:

  • Conservative deployment estimates
  • Achievable customer acquisition rates
  • Reasonable infrastructure buildout schedules
  • Industry-standard utilization rates

Example justification (ARIN 8.5.5, 50% within 24 months):

Current State:
- Existing /24 (256 IPs): 92% utilized (235 IPs in use)
- 180 web hosting customers (average 1.3 IPs each)
- 15 infrastructure IPs
- 40 IPs for internal services

Requested: /22 (1,024 IPs)

Month 0-6:
- 100 new hosting customers x 1.5 IPs = 150 IPs
- Infrastructure expansion = 25 IPs
- Total: 175 IPs

Month 6-12:
- 150 new customers x 1.5 IPs = 225 IPs
- Service diversification (VPS) = 100 IPs
- Total: 325 IPs

Month 12-18:
- 150 customers x 1.5 IPs = 225 IPs
- Infrastructure scaling = 50 IPs
- Total: 275 IPs

Month 18-24:
- 200 customers x 1.5 IPs = 300 IPs
- Geographic expansion = 75 IPs
- Total: 375 IPs

24-Month Total: 1,150 IPs needed
Requested: /22 (1,024 IPs); the 512 addresses that 8.5.5 asks for are in use by month 18

Supporting: Customer contracts for 200 customers attached.
Current utilization: 92% demonstrates efficient usage.

If rejected:

  • Request specific feedback on deficiencies
  • Strengthen documentation with more details
  • Provide additional supporting evidence
  • Consider reducing requested amount
  • Show higher utilization of existing resources if applicable
  • Include customer contracts or commitments
  • Provide market data supporting growth projections
  • Work with consultant to improve justification

Rejection 9: Requested Amount Exceeds Justified Need

Problem: RIR approves transfer but for smaller amount than requested.

Why it happens:

  • Justification supports only portion of request
  • Conservative RIR interpretation
  • Utilization rates don't support full amount
  • Growth projections deemed unrealistic for full amount

Common scenarios:

  • Requested /22 (1,024 IPs), approved for /23 (512 IPs)
  • Requested /20 (4,096 IPs), approved for /21 (2,048 IPs)

How to avoid:

  • Request amount closely aligned with strong justification
  • Add modest buffer (10-20%) rather than excessive
  • The plan must cover the whole requested block
  • Use conservative estimates

If this occurs:

  • Accept approved amount
  • Complete transfer for approved portion
  • Apply again later for additional resources with updated justification
  • Negotiate with seller for partial transfer if possible

Rejection 10: Inadequate Infrastructure Evidence

Problem: RIR questions whether recipient has capability to utilize resources.

Why it happens:

  • No evidence of existing infrastructure
  • Unbelievable capacity claims
  • Startup with no track record
  • Mismatch between infrastructure and requested amount

How to avoid:

  • Document existing infrastructure thoroughly
  • Provide photos, diagrams, equipment lists
  • Show current IP utilization if applicable
  • Demonstrate technical capability
  • Include staff expertise information
  • Reference data center or hosting facilities

Strong infrastructure evidence:

  • Network topology diagrams with equipment details
  • Data center colocation agreements
  • Server and network equipment lists
  • Screenshots of infrastructure monitoring
  • Current BGP routing table information (if applicable)
  • Upstream provider agreements
  • Technical staff resumes or certifications

If rejected:

  • Provide more detailed infrastructure documentation
  • Include photos of facilities and equipment
  • Add technical staff information
  • Show data center agreements
  • Demonstrate operational capability

Category 4: Regional Presence Rejections

Receiving RIRs register resources only for networks or entities in their own service region, and each defines that differently.

Rejection 11: Insufficient Regional Presence

Problem: Cannot demonstrate adequate operational presence in destination RIR region.

Why it happens:

  • Virtual office only
  • No active network infrastructure in region
  • Registered agent address (not real operations)
  • Business primarily in different region
  • Shell company setup

Regional presence requirements:

  • RIPE NCC: the network using the resources has at least one active element in the RIPE NCC service region (inter-RIR transfers page)
  • ARIN: an active business entity legally formed within the ARIN service region (ARIN request guide)
  • APNIC: operations in the Asia-Pacific region
  • LACNIC: legally established in the LACNIC region

Transferred IPv4 allocations are registered only to RIPE NCC members; PI space can go to a member or to an End User under a sponsoring LIR contract (ripe-807 section 2.0). Inbound legacy space can keep its LEGACY status.

How to avoid:

Establish legitimate presence:

  • Physical office or operational facility (not just registered agent)
  • Active network infrastructure deployed
  • Real business operations in region
  • Local employees or contractors
  • Customer base in region

Strong evidence of presence:

  • Office lease or property ownership documents
  • Business registration in region
  • Local business licenses or permits
  • Employee contracts for regional staff
  • Colocation or transit contracts in the region: for the RIPE NCC this is the evidence that counts, an active network element
  • Customer contracts showing regional service delivery
  • Photos of physical facilities and infrastructure

Weak evidence (insufficient alone):

  • Registered agent address
  • Virtual office
  • Plans to establish presence
  • PO Box
  • Serviced office with no dedicated space

If rejected:

  • Establish real operational presence before applying
  • Provide multiple forms of evidence
  • Include photos and documentation
  • Show active business operations
  • Demonstrate customer base in region

Rejection 12: Due Diligence or Sanctions Check Fails

Problem: The registry cannot verify who is signing, or a signing party appears on a sanctions list.

Why it happens:

  • The registration document is old, or names a different legal entity than the requester
  • The signer is not the authorized representative on record
  • A natural person's ID fails the third-party check
  • A signing party or representative matches an EU or Dutch sanctions list

What the RIPE NCC checks (ripe-863):

  • Natural persons: an identity document (ID card or passport); on inter-RIR requests the check runs through iDenfy
  • Legal persons: a recent registration document from the national authority and approval by an authorized representative; notarization may be requested
  • Sanctions: every signing party and authorized representative is checked against EU and Dutch sanctions lists before registration, and again on later changes

If rejected:

  • Send a current registration document and have the representative named in it sign
  • Redo the identity check with a valid passport or ID card
  • A sanctions match is not fixable on the applicant's side

Category 5: Policy and Compatibility Rejections

Rejection 13: Policy Incompatibility Between RIRs

Problem: Source and destination RIRs have incompatible policies.

Why it happens:

  • One RIR doesn't have inter-RIR transfer policy
  • Policies aren't reciprocal
  • Needs-based requirements incompatible
  • Special resource restrictions

Known incompatibilities:

  • AFRINIC: no transfers to or from any other RIR. AFRINIC's reconstituted board has ratified a transfer policy with an inter-RIR clause, AFPUB-2020-GEN-006, confirmed in a communiqué of 18 February 2026, but as of September 2026 it is not in its Consolidated Policy Manual, and ARIN and the RIPE NCC still list AFRINIC as incompatible. No start date has been announced.
  • LACNIC: IPv4 only; ASNs move only through a merger, acquisition, reorganization or relocation inside the LACNIC region
  • ARIN: inter-RIR transfers involving ARIN cannot include IPv6

How to avoid:

  • Verify both RIRs support inter-RIR transfers
  • Confirm compatible policies exist
  • Check current RIR policy documentation
  • Understand reciprocity requirements

Compatible RIR pairs (as of September 2026):

Pair IPv4 ASN
RIPE NCC and ARIN yes yes
RIPE NCC and APNIC yes yes
ARIN and APNIC yes yes
RIPE NCC and LACNIC yes no
ARIN and LACNIC yes no
APNIC and LACNIC yes no
AFRINIC and any RIR no no

Sources: RIPE NCC inter-RIR transfers, ARIN transfers. Moving a block between two sponsoring LIRs inside the RIPE region is not an inter-RIR transfer: see change your sponsoring LIR.

If attempting incompatible transfer:

  • Choose resources from compatible RIR
  • No workaround for AFRINIC limitation
  • No date is announced for AFRINIC; check ARIN's and the RIPE NCC's compatibility lists before signing

Rejection 14: One Registry Approves, the Other Refuses

Problem: The source RIR releases the resource but the receiving RIR does not approve the recipient, or the other way round.

Why it happens:

  • The source side checked the holder and the hold period; the receiving side applies its own needs, contract and presence rules (NRPM 8.4: "the conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR")
  • The recipient has no contract yet: the RIPE NCC evaluates only once the receiving party is a member or has a sponsoring LIR contract (PI and ASNs) in place
  • Documents accepted by one registry do not meet the other's due diligence rules

How to avoid:

  • Prepare the recipient's file against the receiving RIR's rules before the source files anything
  • Sign the receiving contract (RSA at ARIN, membership or sponsoring LIR contract in the RIPE region) before the request is evaluated
  • Nobody "certifies" need across registries: each side decides its own part

Category 6: Resource-Specific Rejections

Rejection 15: Special-Use or Reserved Address Space

Problem: Attempting to transfer resources that cannot be transferred.

Why it happens:

  • Special-use designations (RFC defined)
  • Reserved address blocks
  • Multicast ranges
  • Documentation-only ranges
  • Resources with transfer restrictions

Non-transferrable resources:

  • Private address space (RFC 1918)
  • Multicast addresses
  • Reserved ranges
  • Documentation ranges (RFC 5737)
  • Some legacy resources with restrictions

How to avoid:

  • Verify resources are publicly routable
  • Check for special designations in WHOIS
  • Confirm no transfer restrictions
  • Avoid resources with unusual characteristics

Verification:

whois -h whois.arin.net [IP-RANGE] | grep -i "status\|special"

If encountered:

  • Select different resources
  • Confirm no restrictions before purchase commitment

Rejection 16: Resources on Blacklists or With Poor Reputation

Problem: While not typically an RIR rejection reason, resources with poor reputation can be rejected by destination organizations or fail business case.

Issues:

  • Listed on spam blacklists
  • History of abuse
  • Poor sender reputation
  • Associated with malicious activity

How to avoid:

  • Check resources on major blacklists before purchase
  • Review BGP history
  • Check reputation databases
  • Avoid resources with known issues

Checking reputation:

If discovered:

  • May need delisting processes
  • Consider purchasing different resources
  • Factor reputation cleanup into timeline
  • Some blacklistings may be permanent

Impact: Not RIR rejection, but business impact

What to Do If Your Transfer Is Rejected

Immediate Steps

1. Review rejection notice carefully:

  • Understand specific reasons
  • Identify which RIR rejected (source or destination)
  • Note what information is requested
  • Check if partial approval was offered

2. Request detailed feedback:

  • Contact RIR for clarification
  • Ask specific questions about deficiencies
  • Understand what would make resubmission successful
  • Inquire about alternative approaches

3. Assess the situation:

  • Determine if rejection is soft (fixable) or hard (fundamental issue)
  • Estimate time needed to address issues
  • Consider impact on agreement with seller
  • Evaluate alternative options

Registries publish no figure for how long a corrected request takes. The RIPE NCC completes most transfers inside its own region "within one or two business days" and says transfers between RIRs take longer, because both registries must synchronize (RIPE NCC transfers); ARIN says the time "can vary". Stage-by-stage expectations are in inter-RIR transfer timeline.

Remediation Strategies

For documentation issues (soft rejections):

  • Gather missing or corrected documents
  • Check signatures and file formats
  • Address every reason listed in the notice, not the first one
  • Add new evidence; an identical resubmission gets the same answer
  • Resubmit promptly

For needs justification issues:

  • Strengthen justification with more details
  • Add supporting evidence and documentation
  • Consider reducing requested amount
  • Provide customer contracts or business data
  • Ask for the registry's specific objection before rewriting the plan

For regional presence issues:

  • Establish legitimate presence if missing
  • Provide contracts, not statements
  • May require substantial time and investment
  • Deploy equipment in the region first: the RIPE NCC registers inbound space only for a network with an active element in its service region

For hold period issues:

  • Wait until hold period is satisfied
  • Consider alternative resources
  • Renegotiate timeline with seller
  • No quick fix available

For policy incompatibility:

  • Transfer may not be possible
  • Select resources from compatible RIR
  • No workaround available

Prevention: Best Practices to Avoid Rejection

Pre-Transfer Verification Checklist

Before initiating transfer:

Eligibility verification:

  • Hold period requirements met (with buffer)
  • Source organization is registered holder
  • No outstanding obligations to source RIR
  • Resources are transferrable (not special-use)
  • Both RIRs have compatible inter-RIR policies

Documentation preparation:

  • Recent registration document obtained
  • Authorization letters with proper signatures
  • Notarization obtained where required (ARIN)
  • All information consistent across documents
  • Contact information current in RIR databases

Needs justification:

  • Detailed utilization plan developed
  • Infrastructure documentation prepared
  • Supporting business evidence gathered
  • Realistic timelines and projections
  • Specific use cases documented

Regional presence:

  • Legitimate operational presence established
  • Multiple forms of proof available
  • Active network infrastructure in region
  • Business operations documented

Professional review:

  • Documentation reviewed by expert
  • Legal review completed if needed
  • RIR requirements verified
  • Compliance confirmed

When to Seek Professional Help

Consider professional assistance for:

  • First inter-RIR transfer
  • Large transfers (a /16 or larger)
  • Complex justifications
  • Previous rejections
  • Tight timelines
  • Legacy resources
  • Multiple-party transactions
  • Unfamiliar RIRs
  • A closing date that cannot slip

Professional services available:

  • Transfer brokers and facilitators
  • Sponsoring LIRs
  • RIR consultants
  • Legal advisors specializing in IP transfers
  • Documentation preparation services

Checking a Transfer Before You File

We verify the eligibility requirements of both the source and the destination RIR before anything is filed: hold periods and locks, the resource type the pair accepts, the recipient's contract and needs plan, and the documents each side asks for. We then prepare the forms, justifications and supporting documents, handle the communication with both registries and report progress until the registration has moved. Transfers are quoted per case on the inter-RIR transfer service page. When an ASN or a PI block arrives in the RIPE region as an independent resource, we can act as its sponsoring LIR afterwards.

Reference: Current Inter-RIR Policy Documents

Summary

Check the pair first: LACNIC moves IPv4 only, AFRINIC moves nothing, and ARIN moves no IPv6. Then check the clock on the source (RIPE NCC 24 months for IPv4 and 16-bit ASNs, ARIN 12 months since the source last received IPv4 from ARIN, APNIC five years for 103/8 space, LACNIC three years for its own allocations) and the recipient's plan against the receiving RIR's test. Paid fees, a recent registration document and a clean sanctions check close most of the remaining gaps before a registry ever sees the file.