IPv4 Transfer Document Checklist: Every File You Need

By Savvas Bout, Founder of Prefixx. Last updated 26 October 2026.

One missing document on an IPv4 transfer can cause the deal to stall at the registry for weeks. To avoid such problems and to keep an IPv4 transfer on schedule, you will need a complete checklist of required documents before starting the transfer process.

It does not matter whether you are transferring a /24 under ARIN or a /16 across registries at RIPE NCC or APNIC. The same core checklist applies whether you are completing a simple intra-registry assignment or navigating the more complex procedural requirements of inter RIR transfers.

The required documents look simple at first. However, Soon you will discover that a legacy block (e.g. pre-1993) needs an additional attestation or that the IRR records of the seller are not inconsistent with the current route origin.

The guide includes a comprehensive set of documents for each category: RIR-specific transfer request forms, proof of organization and authority, LOA requirements. RPKI ROA setup, IRR route object accuracy and a set of pre-transfer checks that reveal problems before they can because any harm.

Inter-RIR transfers are covered in a separate section as the set of required documents grows exponentially with the number of registries a block goes through. Some registries also require documentation related to any autonomous system number that will announce the transferred prefix after the transaction completes.

What an IPv4 transfer document checklist actually covers

The IPv4 transfer document checklist is not a formality that needs to be completed in order to process an IPv4 transfer. The checklist outlines the specific documents that a regional internet registry needs in order to transfer IP address space from one organization to another. If one of the documents is missing, the registry will either reject the transfer request or suspend the processing of the transfer request, sometimes for weeks.

What an IPv4 transfer checklist covers

Each IPv4 transfer needs five document categories:

• Proof of ownership: current WHOIS records, registration service agreements and any other relevant documentation for legacy resources.
• Registry eligibility, this refers to the evidence that demonstrates that the recipient needs the services described in the registry in relation to their needs-assessment or their justified-use criteria.
• Transfer agreement. A signed bilateral agreement between seller and buyer which has been registered with the relevant registry.
• Escrow documentation: Payment instructions and release conditions that are bound by confirmation of the registry.
• Update LOA, RPKI ROA and IRR route objects post-transfer to reflect holder of the routing records has changed.

We check against your current portfolio and your future needs to establish Transfer Eligibility. If there is any shortfall in any of the five areas listed below, the transfer will be held up in the review queue of the relevant registry. Registries apply their own policies when evaluating whether an organization has demonstrated sufficient justification for the requested resources.

Two IPv4 transfer paths this article covers

Note that for intra-RIR transfers (i.e. moving a block of space within one’s own registry), there is no need to gather additional documentation. Inter-RIR transfers (i.e. moving a block of space between registries) add the additional approval process of a second registry, as well as more paperwork between the two registries involved.

Why regional internet registry records matter after the deal closes

Pay escrow and sign the transfer agreement.

This foundation of five categories and two transfer paths will be used as the starting point of our exploration of how a registry checks proof of possession of a block by the source organization.

Regional internet registry records: the foundation of every IP address transfer

The typical IPv4 transfer documentation checklist starts with verification that the original source of the internet number resources (the ‘source’) is the legal entity that still holds those resources and is now transferring them.

Registry records are the single source of truth as to who holds what internet number resources and any discrepancy between what the records state and what the source is able to provide as proof will block the transfer. The registry verification process applies equally to all APNIC account holders who are initiating a transfer as the source entity.

What 'current registered holder' means in practice

RIRs maintain WHOIS databases containing all assigned IP address blocks, linked to an organization ID, registration services agreement, and contact.

Many rebrands, mergers and subsidiary restructuring exercises result in a mismatch between the organization’s trading name and its registered legal entity name. This is often the root cause of transfer delays in the five RIRs.

Legacy and transferred internet number resources eligibility

Legacy space (pre-modern RIR allocation) requires a different treatment. Accordingly, space holder must enter into an LRSA with ARIN (or equivalent with another RIR) as a prerequisite to transfer of such allocated space. Without an LRSA, the registry has no contract basis to grant such transfer. Some organizations choose to acquire space directly from the ARIN waiting list rather than pursue a transfer of legacy resources.

Also note the registration history of a legacy block: any gaps, expired contacts or old org records need to be fixed up before a transfer can be submitted. A contact listed in the registry who no longer exists must be replaced with a current point of contact to satisfy the registry's validation requirements.

IP address records: what to verify before submitting

Before filing a transfer, check these 4 against the current registry information. Verifying that all legal entity details match the registry's records ensures that registration information is accurate and up to date.

• The WHOIS org name for this transfer must match the current registered name of the transferring legal entity.
• A current IP registration agreement is in place and covers required IP address space.
• Org ID is not flagged for any policy violations or outstanding fees.
• Any resources transferred in prior transactions are fully settled in the registry.

Where any of the 4 points fail, they must be fixed prior to transfer.

After ownership of a block has been verified, the block is assigned according to the relevant registry. The assignment process differs depending on whether the block originated from direct allocations or from a transfer market transaction.

Routing and reputation documents: IRR objects, ROAs, reverse DNS and reputation history

Four key technical documents must be updated after an IPv4 address space has been transferred from one holder to another.

IRR objects and routing conflicts

When transferring prefixes between ASes, you must delete the old holder of a prefix from their IRR route objects, too. This is because old stale IRR objects at a source registry cause all sorts of failures to routing security filtering. Remove the old route object from the recipient’s IRR database entry before you add a new route object for that same database entry.

When a transfer agreement signed between parties involves a prefix, the new ROA must be signed under the source's RPKI Certificate Authority (CA) prior to the close of the transfer and re-signed under the recipient's CA immediately after the transfer closes.

Reverse DNS delegation for transferred resources and address blocks

The reverse DNS delegation for each block is held in the registry’s database. After transfer the new holder must update the delegation to point to his own nameservers and then fill in the corresponding PTR records for all used IP addresses. Reverse DNS is checked by carriers and by spam filters. Missing or wrong reverse DNS entries will lead to increased rejection rates.

Reputation history review by recipient organization

Request a Blacklist scan (DNSBL) for major blacklists before the transfer and after the transfer has completed. A previous owner’s poor reputation can cause immediate problems with e-mail delivery and with ad platforms.

We prepare LOA, RPKI ROAs and IRR routing objects for you as part of our white-glove service for our customers with BYOIP. All blocks are checked for reputation by Tixx quality control before they can be bought by customers.

With all routing documents in place, the remaining documents needed to complete transfer of a domain name are the transfer agreement and an escrow arrangement to protect both parties until the domain name is confirmed as added to the registry.

The transfer agreement and escrow: protecting both parties in an IPv4 address space deal

The two key documents for all IPv4 address space transactions are the transfer agreement and the asset purchase agreement. For sales and purchases that are completed immediately (i.e. not sold through an escrow service) these two documents together protect the buyer's and seller's interests from the moment that the two parties have agreed a price until the relevant RIR has confirmed that the inter RIR transfers of the necessary resources have been completed.

These agreements also clarify any registration rights that the recipient will hold once the registry has updated its records.

Preparation: drafting agreements for a specified recipient

1. Draw up the transfer agreement with all parties involved. As the source, indicate the current holder of the block of IP addresses; as the acquirer, indicate the organization to which the IP addresses are to be transferred. Specify the exact prefix, the CIDR notation, and the RIR where the IP block is registered. This must be clearly stated to avoid any delays in the transfer, which could be caused by any ambiguity.
2. Representations with respect to clean title. The source party represents that the IPv4 address block is free of any liens, disputes or other complications with legacy resources. This is a representation that can cause problems for the buyer after the closing if a prior claim surfaces.
3. The transfer fee and payment schedule need to be clearly defined including the amount in currency to be paid and the terms for release from escrow. That release should be confirmed RIR submission (i.e. confirmed submission of relevant information rather than mere submission).

Execution: signing and funding escrow

1. Get both organizations to sign off on the transfer agreement. A single organization cannot request transfer to a RIR without the counterparty having signed off on the agreement. We’ll then coordinate the transfer before any monies change hands.
2. Fund the escrow account. The funds will not be released from the escrow account until the domain name has been updated in the appropriate registry to reflect the new holder. This is how Prefixx completes all transactions.

Note: Never wire funds directly to a seller before RIR confirmation. Escrow is the only safe settlement method for internet number resources.

Verification: confirming the IPv4 address transfer

1. Verify that registry records as well as PTR records have been updated. Once the block of IP addresses has been transferred to the new holder, it will appear in the RIR’s WHOIS database and the escrow will be released. Note that verification of correct delegation of PTR records is also required to consider a deal as closed.

Errors in documents can occur even when an agreement was correctly drafted and escrow is in place.

Common document errors that delay an IPv4 transfer request

Most IPv4 transfer request rejections are due to lack of required documentation, rather than an objection to the proposed transfer on policy grounds. Buyers and sellers should verify that all documentation requirements are satisfied well in advance of submitting the transfer request to the registry.

Asset purchase agreement identity and recipient errors

Entity name mismatches are by far the most common cause of delay to transfer.

An expired or missing registry membership agreement (RSA or LRSA) for either party to a transfer prevents the transfer from proceeding.

The needs justification for blocks of /20 and larger is also required by ARIN. Failure to incomplete an addressing plan in full, or failure to accurately document customer space and utilization of allocated but unused resources, will result in a return for revision. The addressing plan must clearly document how allocated space will be used, including any customer assignments that demonstrate efficient utilization of the requested resources.

Routing object errors from direct allocations

Stale IRR records on the source of a block can cause routing failures. These must be withdrawn after a transfer has taken place, otherwise a recipient’s RIR and downsteam networks will see conflicting origin assertions.

The ROA revocation is as important as the initial publication. A source holder that fails to withdraw its ROA for the address blocks involved in an approved transfer will leave the announcements of the new holder in an Invalid state under RPKI and cause them to be dropped by all peers that implement ROA-validating.

DNS and how tixx catches these early

The reverse DNS delegation for the old holder’s name servers is not reversible and thus PTR lookups will cease to function after the transfer. The new holder must update or re-delegate this zone before announcing the IPv4 address space.

For all Tixx by Prefixx blocks we run a set of checks: ownership, transfer eligibility, blacklists and routing. Any errors are fixed prior to the transfer request being sent to the registry rather than after the registry has rejected the transfer and the whole process has to restart again.

Pre-submission quality control is one of the key benefits of dealing with a registered broker over completing paperwork yourself.

Why work with a registered IPv4 broker on your transfer documents

Tracking a detailed checklist of documents required for an IPv4 transfer at the level of the regional internet registries is very complex. A single missing field in a transfer request, an incorrect org ID, or an unresolved IRR route object can be enough to block the entire registry transfer process.

Prefixx deals with all this paperwork as a registered broker with ARIN, RIPE NCC and APNIC (LACNIC facilitated). Understanding the registry process in detail helps brokers anticipate common rejection patterns and prepare documentation that meets each RIR's specific validation requirements.

• Our team prepares LOA, RPKI ROA and IRR objects for all IPv4 transfers (intra-RIR and inter-RIR) end-to-end.
• We Tixx QC every block. Transfer eligibility, owner verification, blacklists, etc. all get verified before a transfer agreement is even signed.
• Escrow-secured transactions. The parties involved in the transfer (source and recipient organizations) are protected throughout the IPv4 address transfer process.
• White glove service is included with all leases. reverse DNS, reputation monitoring and geolocation correction are all included as standard.
• Zero buyer fees. Seller-only commission of 3 to 8%, no hidden charges for the buyer!

If you want a broker who manages the full IPv4 transfer from IP resource agreement through to updated registry records, see how Prefixx works or reach out to our team for a no-obligation conversation.

Pre approval frequently asked questions

Documents needed for inter-rir IPv4 transfers in the ARIN region

Both the seller and buyer must hold a current address space agreement (RSA) or Legacy RSA with ARIN. The seller submits a transfer request through the ARIN Online portal, and the buyer must demonstrate a justified need for the space under ARIN's needs-assessment policy. The recipient organization must complete its needs justification before ARIN will approve the buyer's portion of the transfer request.

Supporting documents for cross region transfers typically include proof of organizational identity, network justification documentation, and any existing LOA if the transferred block is being routed during the transition. Once ARIN approves both sides, the transfer is recorded in the ARIN database and a new WHOIS entry reflects the buyer as the registered holder. Organizations preparing for cross-region transfers should gather all necessary materials early and request resources from their internal compliance teams to avoid delays.

How long do inter RIR transfers take to complete?

An inter-RIR transfer between ARIN, RIPE NCC, and APNIC typically takes four to eight weeks from the point both parties have submitted complete documentation.

What is the minimum transfer size for an ARIN transfer?

ARIN's minimum transferable block size is a /24, which is 256 addresses. Blocks smaller than a /24 cannot be transferred as independent resources under ARIN policy. This minimum applies to both intra-ARIN transfers and inter-RIR transfers where ARIN is the source or destination registry.

Do inter RIR transfers of IPv4 require updating IRR records afterward?

Yes. Once a transfer completes and the recipient organization appears as the new holder in WHOIS, the old route objects become stale and should be deleted by the previous holder or the relevant IRR database.

The new holder must create fresh route objects under their own maintainer to ensure upstream providers can validate routing announcements. Stale IRR records are a common cause of route filtering after a transfer, so updating them promptly is critical. Prompt coordination between the previous and new holder ensures that resources transferred do not experience routing disruptions during the IRR update window.

Inter RIR transfers and why every RIR requires a registration services agreement

A registration contract is the contract between an organization and its RIR that governs the terms under which IP resources are held and used.

Without a current RSA on file, neither a buyer nor a seller, including any recipient organization, can participate in a transfer, because the RIR has no contractual basis to update the registry on their behalf. Legacy holders who have never signed an RSA must execute one before their block is eligible for transfer.

Can I transfer IPv4 address space from RIPE NCC to ARIN?

Yes. RIPE NCC and ARIN have a reciprocal inter-RIR transfer agreement that allows address space to move in either direction. The source organization must be in good standing with RIPE NCC, and the receiving organization must satisfy ARIN's needs-assessment requirements. Both registries review the request independently, and the block must pass each registry's eligibility checks before the transfer is recorded. Prefixx handles inter-RIR transfers across ARIN, RIPE NCC, and APNIC, managing the paperwork on both sides of the transaction.

What happens to ROAs and reverse DNS after IPv4 transferred resources

Existing ROAs created by the previous holder become invalid the moment the block transfers to the specified recipient in the RIR database, because ROA validity is tied to the resource holder's certificate in the RPKI hierarchy. The new holder must create fresh ROAs under their own RPKI certificate to authorize their origin ASN.

Reverse DNS delegations also need to be updated: the previous holder's PTR records and NS delegations remain in place technically, but they point to zones the new holder does not control, which breaks rDNS lookups. Both ROAs and rDNS should be updated as part of the post-transfer checklist before the block is announced.

Every IPv4 transfer fails or stalls at the paperwork stage, not the negotiation stage. The three non-negotiables are clean registry records before you start, a complete needs justification matched to the receiving RIR's current transfer fee and policy requirements, and the right supporting documents assembled in the right order. Get those three right and the transfer moves.

Transfers of IP between RIRs (Inter-RIR transfers) introduce an additional layer of complexity.

If you want a team that prepares the LOA, RPKI ROA, and IRR prefix objects on your behalf and has registered broker status with ARIN, RIPE NCC, and APNIC, review how Prefixx runs a transfer end to end.