Transferring IPv4 address space from one organization to another involves more than agreeing on a prefix and a price.
Table of Contents
A successful IPv4 transfer may require documentation showing who the parties are, who is authorized to act for them, which IPv4 resources are involved, whether the source is entitled to transfer those resources, and whether the recipient satisfies the requirements of the applicable Regional Internet Registry (RIR).
The exact document list is not identical for every IPv4 transfer.
Requirements can vary depending on:
The source RIR
The recipient RIR
Whether the transfer is intra-RIR or inter-RIR
The status and history of the IPv4 resources
Whether the transaction is a market transfer, merger, acquisition, or corporate restructuring
Whether the recipient must demonstrate need or intended utilization
The contractual relationship each party has with its RIR
The five Regional Internet Registries—ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC—maintain their own policies and operational procedures for Internet number resources. The Number Resource Organization provides an overview of the five-RIR system. Regional Internet Registries – NRO
For buyers and sellers, the practical rule is:
Prepare documentation for the specific transfer path instead of assuming that one universal IPv4 transfer checklist applies everywhere.
This guide explains the documents commonly associated with IPv4 transfers, what buyers and sellers should prepare, and which additional records should be reviewed before the IPv4 block enters production.
Quick Answer: What Documents Are Needed for an IPv4 Transfer?
Depending on the RIR and transaction type, buyers and sellers may need documents or records covering the following areas:
| Document or Record | Buyer | Seller | Purpose |
|---|---|---|---|
| Company registration documents | Often | Often | Verifies the legal entities |
| Authorized signatory evidence | Often | Often | Confirms authority to approve the transaction |
| Government-issued identification | Sometimes | Sometimes | Supports identity verification where requested |
| RIR account / organization record | Usually | Usually | Connects each party to the registry process |
| Exact IPv4 prefix information | Yes | Yes | Defines the resources involved |
| Evidence relating to resource holdership | Review | Often | Supports seller authority and transfer eligibility |
| Needs or utilization documentation | Depends on RIR | Usually no | May support recipient qualification |
| RIR transfer request or form | Yes | Yes | Initiates or confirms registry processing |
| Transfer agreement | Usually | Usually | Documents the transaction between the parties |
| Power of Attorney | If applicable | If applicable | Demonstrates delegated authority |
| RIR service or registration agreement | Sometimes | Sometimes | Establishes the required registry relationship |
| Escrow instructions | Often useful | Often useful | Defines settlement conditions |
| Invoice and settlement records | Usually | Usually | Documents commercial completion |
| LOA / routing authorization | Operational phase | Operational phase | Supports routing handover |
| RPKI / ROA information | Operational phase | Operational phase | Supports route-origin authorization |
| IRR / reverse DNS records | Operational phase | Operational phase | Supports network deployment |
Not every transfer requires every item in this table.
For example, RIPE NCC’s current transfer guidance says parties may need recent company-registration documents, a transfer agreement signed by legally authorized representatives, and evidence demonstrating that the signatories have the authority to act for the organizations.
APNIC uses its own account and transfer workflow, while LACNIC and AFRINIC maintain different procedures and documentation requirements.
The correct starting point is therefore the applicable RIR.
1. Company Registration Documents
One of the first questions in an IPv4 transaction is:
Which legal entity is actually transferring or receiving the IPv4 resources?
This is especially important when the registry record was created many years ago.
Since the original registration, an organization may have:
Changed its legal name
Rebranded
Merged with another company
Created or closed subsidiaries
Been acquired
Changed jurisdiction
Completed an internal restructuring
Recent company-registration records can help connect the legal entity entering the transaction with the organization represented in registry records.
RIPE NCC, for example, currently identifies recent company-registration documents from both parties among the information needed for transfers within its service region.
This should ideally be checked before the commercial closing stage.
If the seller name on the agreement, RIR account, company documents, invoice, and transfer request do not align, there may be a legitimate explanation—but that explanation should be documented.
Accurate registry information is also important beyond the transaction itself. The LARUS Foundation discusses the wider role of accurate Internet resource records in supporting stable network coordination.
Why Accurate Registry Data Supports a Stable Internet – LARUS Foundation
2. Evidence That the Signer Is Authorized
A company may control an IPv4 block, but that does not automatically mean every employee has authority to transfer it.
Buyers, sellers, registries, and transaction advisers may therefore need evidence demonstrating that the person approving or submitting the transaction can legally act for the organization.
Depending on the circumstances, evidence might include corporate registration information identifying directors, officer authorization, a Power of Attorney, registry contact authority, or another appropriate corporate authorization.
RIPE NCC states that transfer agreements must be signed by representatives who are legally authorized to act for their organizations, and supporting documentation may be needed to establish that authority.
ARIN also uses authorized Points of Contact and ARIN Online relationships as part of its resource-management and transfer workflows. Its transfer guidance emphasizes verifying that registration information and organizational relationships are accurate before proceeding.
This is one reason outdated registry contacts can slow a transaction.
If the only authorized contact is a former employee, the organization may need to correct its registry account before the transfer can proceed efficiently.
3. RIR Account and Organization Records
Both parties should check their RIR account readiness early.
Relevant information may include the organization’s legal name, registry account identifier, administrative contact, technical contact, authorized users, billing status, membership or contractual relationship, and current resource records.
APNIC, for example, requires the source account to initiate eligible transfers through MyAPNIC, after which the recipient acknowledges the transfer through its own account.
APNIC also states that organizations participating in transfers generally need an APNIC account, subject to specific exceptions.
AFRINIC’s published transfer guidance similarly describes designated platforms for submitting eligible transfer requests and emphasizes maintaining accurate organization, contact, assignment, routing, and reverse-DNS records.
Do not assume:
“We can sort out the registry account after the commercial agreement is signed.”
Registry readiness should be part of pre-transaction due diligence.
4. Exact IPv4 Prefix Information
Every document relating to the transaction should identify the same IPv4 resources.
For example:
192.0.2.0/24
or:
198.51.100.0/22
Before moving forward, confirm the exact CIDR prefix, prefix length, current RIR, registration status, whether the entire resource or only part of it will move, and whether any applicable transfer restrictions exist.
This becomes especially important when a seller controls a larger allocation but intends to transfer only a smaller portion.
The buyer should also determine whether the resource is:
Legacy or non-legacy
Currently routed
Covered by active ROAs
Associated with existing IRR objects
Delegated for reverse DNS
Subject to a holding or transfer restriction
Commercial agreements, invoices, escrow instructions, and registry submissions should all describe the same resource.
5. Evidence Relating to IPv4 Holdership
A seller should be able to demonstrate a credible relationship with the IPv4 resources being offered.
The authoritative RIR registration is an important starting point.
In more complex cases, supporting evidence may also be relevant, such as previous transfer records, original allocation documentation, corporate name-change records, acquisition documents, merger documentation, corporate succession records, or registry correspondence.
LACNIC states that it may request documentation confirming that an applicant is properly authorized to perform a transfer.
This leads to an important distinction:
A company announcing an IPv4 block through BGP is not, by that fact alone, necessarily demonstrating authority to transfer its registration.
Routing and registry authority are related operational concepts, but they are not identical.
LARUS discusses a related issue in its guide to outdated registration records during IPv4 transfers:
Outdated WHOIS and RDAP Records: A Hidden Risk in IPv4 Transfers – LARUS
6. Buyer Need or Utilization Documentation
Some transfer paths require the recipient to demonstrate need or intended utilization.
Others operate differently.
This is another reason not to apply one generic transfer-document checklist to every transaction.
APNIC currently states that recipients under its unused IPv4 transfer policy must demonstrate their need for the resources being transferred.
ARIN also has transfer paths under which recipient qualification and supporting need documentation may be relevant.
LACNIC’s current intra-regional transfer process requires the receiving organization to satisfy applicable requirements and justify the address space being transferred.
AFRINIC’s currently published operational transfer guidance likewise describes recipient need as part of its policy-based process.
RIPE NCC uses a different policy framework, although inter-RIR transactions can introduce requirements from the counterpart RIR.
Practical supporting information might include current utilization, projected deployment, network architecture, customer assignments, service growth, or an addressing plan.
The key is to establish the recipient’s applicable requirements before setting a closing schedule.
7. The RIR Transfer Request
An IPv4 transfer eventually needs to enter the registry’s official process.
Depending on the RIR, this may happen through an online account, dedicated transfer form, transfer template, or coordinated submission by the source and recipient.
Examples include:
ARIN: transfer requests are handled through ARIN’s registry-services framework and must comply with the applicable ARIN transfer policy.
APNIC: the source initiates an eligible transfer through MyAPNIC, and the recipient then acknowledges it.
LACNIC: the offering organization’s administrative contact completes the relevant transfer form, after which supporting documentation may be requested.
AFRINIC: its current operational guidance identifies designated platforms through which eligible transfer requests are initiated.
RIPE NCC: offering parties submit the required transfer information and supporting documents through the appropriate RIPE NCC process. Inter-RIR transactions use additional coordination between registries.
A broker or marketplace can help coordinate the process, but the relevant RIR remains authoritative for its own registration decisions.
8. IPv4 Transfer Agreement
Most commercial IPv4 transactions also need a written agreement between the parties.
A transfer agreement may document the seller, buyer, exact IPv4 resources, price, payment conditions, applicable RIR process, conditions precedent, representations, responsibilities, settlement mechanism, and what happens if the registry does not approve the proposed transfer.
It is important to distinguish two layers:
The commercial agreement establishes obligations between the parties.
The RIR process determines whether registry records can be changed under the applicable policies and procedures.
One does not automatically replace the other.
RIPE NCC explicitly identifies a Transfer Agreement signed by legally authorized representatives among its documentation requirements for transfers within its service region.
LACNIC’s current process also provides for a transfer agreement and related documentation after the transfer request is approved.
9. Power of Attorney or Delegated Authority
A Power of Attorney is not necessarily required for every transaction.
It becomes relevant where the person acting for the company cannot otherwise demonstrate the authority required for that role.
For example, a network engineer may understand the IPv4 resource but may not have authority to sell it.
A director may be authorized commercially but may not administer the company’s RIR account.
A broker may coordinate the transaction but usually should not be assumed to have authority to bind either party unless that authority has been explicitly granted.
Where authority is delegated, documentation should make clear who granted the authority, who received it, what actions are authorized, and whether there are any limitations.
10. RIR Service or Registration Agreements
Some recipients may need to establish or update a contractual relationship with the receiving RIR.
The details differ significantly by registry, resource status, and transaction type.
For example, LACNIC states that if a receiving organization has not previously received resources from LACNIC, or holds legacy resources in certain circumstances, a service agreement may be required.
RIPE NCC notes that contractual relationships can also be relevant for incoming inter-RIR resources, with different arrangements possible for certain independent or legacy resources.
These requirements should be reviewed before closing rather than treated as last-minute paperwork.
11. Escrow Instructions and Settlement Records
Escrow is generally a commercial risk-management mechanism rather than a universal RIR requirement.
It can help align payment with agreed transaction milestones.
An escrow arrangement may define what happens when the buyer deposits funds, what evidence of registry progress is required, what event triggers release to the seller, and what happens if the transfer is rejected or cannot be completed.
The parties should define the release trigger carefully.
Possible milestones include registry approval, synchronized completion of an inter-RIR transfer, appearance of the recipient in authoritative registry data, or another clearly defined completion event.
The transaction should not rely on vague wording such as:
“Release payment when the transfer is done.”
Instead, the parties should define what “done” means.
For organizations evaluating structured IPv4 transactions, i.lease provides additional guidance on how differences between RIR frameworks can affect transfer preparation:
How RIR Policy Differences Shape IPv4 Transactions Across Regions – i.lease
12. Merger and Acquisition Documentation
Not every IPv4 resource change is a conventional market sale.
Registry updates may also arise from a:
Merger
Acquisition
Corporate reorganization
Business-unit sale
Corporate succession
These cases can require different evidence from an ordinary specified-recipient transfer.
The documentation may need to establish how the legal entity controlling the Internet number resources changed and how the current organization relates to the entity named in historical records.
This can involve corporate-registration documents, merger or acquisition agreements, official filings, name-change evidence, or other records establishing succession.
If the company named in an old registry record no longer exists, this issue should generally be resolved before assuming that the IPv4 block is immediately ready for a normal sale.
13. Inter-RIR Transfer Documents
Inter-RIR transactions require additional planning because two registry frameworks may apply.
The source RIR and destination RIR may need to coordinate before the transfer can be completed.
RIPE NCC’s current guidance, for example, states that inter-RIR transfers must be approved by both RIPE NCC and the counterpart RIR before processing. It also lists additional documentation for parties within the RIPE NCC service region.
APNIC similarly requires a compatible transfer policy on the other side of an inter-RIR transaction and maintains a separate workflow for inbound and outbound transfers.
AFRINIC ratified a broader Number Resources Transfer Policy on February 4, 2026 that includes inter-RIR transfers where reciprocal policies exist; however, organizations should verify the current operational implementation and specific transfer path directly with the registries involved before structuring a transaction.
Before entering an inter-RIR transaction, establish the source RIR, destination RIR, compatibility of the proposed path, source eligibility, recipient qualification, and documentation requirements on both sides.
For additional context:
Which RIRs Support Inter-RIR IPv4 Transfers in 2026? – i.lease
IPv4 Transfer Documents by RIR
The following is a planning summary only. Current official RIR requirements should always be checked for the specific transaction.
| RIR | Examples of Information or Documentation to Prepare |
|---|---|
| ARIN | Accurate Org ID and POC relationships, transfer request, source eligibility information, recipient qualification where applicable, supporting need documentation where required, relevant registration agreements |
| RIPE NCC | Recent company-registration documents, signed Transfer Agreement, evidence of signatory authority, additional agreements or confirmations depending on resource and transfer type |
| APNIC | APNIC account, MyAPNIC transfer submission, recipient acknowledgement, resource details, recipient need/utilization information where required |
| LACNIC | Transfer form, authorization evidence where requested, recipient justification, transfer agreement, order documentation, service agreement where applicable |
| AFRINIC | Applicable transfer request, source and recipient eligibility information, needs justification under relevant operational procedures, appropriate registry/account documentation |
Policies, forms, and procedures can change.
Always verify the current official registry guidance before submitting a transfer.
Documentation Is Only One Part of IPv4 Due Diligence
A complete document pack does not automatically mean that an IPv4 block is operationally ready.
Before closing, buyers should also examine several technical and administrative areas.
Registry data: Check authoritative registration information and confirm the prefix, organization, contacts, and resource status.
NRS.help provides a broader framework for auditing Internet number resources, including registry, routing, RPKI, IRR, reverse DNS, contracts, and historical documentation.
How to Audit Your Company’s Internet Number Resources – NRS.help
RPKI and ROAs: Determine whether the seller currently maintains a Route Origin Authorization, which ASN will originate the prefix after transfer, and when the new authorization should be created.
For background on RPKI:
How Resource Public Key Infrastructure (RPKI) Works – heng.lu
IRR: Review existing route objects and determine whether they need to be updated or recreated for the recipient’s network.
Reverse DNS: Establish who currently controls the reverse zone and how PTR records or delegations will be transitioned.
Reputation: Review significant abuse history, email reputation, security classifications, and relevant blocklists.
Geolocation: Determine whether major third-party databases currently associate the IPv4 block with a location inconsistent with its planned use.
Documentation establishes transaction readiness.
These additional checks help establish deployment readiness.
Buyer Checklist Before an IPv4 Transfer
Before signing and closing, a buyer should be able to confirm the legal identity of the seller, the exact IPv4 resources involved, the seller’s relationship with those resources, transfer eligibility, the buyer’s own registry readiness, any recipient-qualification requirements, the commercial agreement, settlement conditions, and the operational handover plan.
The buyer should also understand the current RPKI status, IRR records, BGP origin, reverse DNS, geolocation, and reputation history of the prefix.
Businesses looking for available address space can explore:
Seller Checklist Before Listing IPv4
A seller should prepare its corporate and registry records before the first serious transaction begins.
That includes confirming the organization’s legal name, authorized signatory, current RIR contacts, exact IPv4 prefixes, relevant transfer history, resource eligibility, current routing state, RPKI information, IRR objects, reverse DNS, and reputation status.
Where an acquisition, name change, or corporate restructuring has occurred, supporting documentation should be organized before the resource is marketed.
A well-prepared resource is easier for buyers, advisers, and registries to evaluate.
IPv4 holders considering monetizing unused resources can review:
Why IPv4 Transfers Can Stall After the Parties Agree
Many delays happen because the commercial agreement is reached before registry readiness is confirmed.
Common issues include the seller’s legal name differing from the registry record, an authorized contact having left the company, incomplete corporate succession records, an unprepared buyer RIR account, missing recipient qualification, an overlooked transfer restriction, or an inter-RIR path that was assumed rather than verified.
Settlement terms can also create problems if they do not match the milestones used by the RIR process.
The safest approach is to resolve identity, authority, registry eligibility, and transfer-path questions before treating the commercial transaction as ready to close.
Why Accurate Documentation Matters After the Transfer
Documentation remains valuable after the transaction is complete.
A well-maintained record creates a clearer relationship between:
the organization → the IPv4 resource → the authorization → the registry → the operational network
That evidence can later help when the organization needs to update registry contacts, establish RPKI, configure reverse DNS, investigate an unexpected change, complete an audit, document a merger, or transfer the resource again.
The broader importance of accurate Internet resource records is discussed by the LARUS Foundation:
Why Accurate Registry Data Supports a Stable Internet – LARUS Foundation
For readers who want to understand the institutions behind Internet number-resource registration, BTW.media provides additional background on Regional Internet Registries:
Regional Internet Registry Overview – BTW.media
LARUS also provides a practical operational perspective on IPv4 transfer preparation and post-transfer considerations:
Best Practices for IP Address Transfers in Business Operations – LARUS
Frequently Asked Questions
What documents are needed to transfer IPv4 addresses?
Common documentation may include company-registration records, evidence of signatory authority, RIR account information, the exact IPv4 prefixes being transferred, registry transfer requests, a transfer agreement, and any recipient-qualification documents required by the relevant RIR. Additional documents may be required depending on the RIR, resource status, transaction type, and corporate history.
Does every RIR require the same IPv4 transfer documents?
No. ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC maintain different policies and operational procedures. Requirements can also differ between intra-RIR transfers, inter-RIR transfers, legacy resources, and merger or acquisition cases.
Does an IPv4 buyer need to prove why the addresses are needed?
It depends on the RIR and transfer path. Certain registry frameworks require recipient qualification or utilization information, while others operate differently. The buyer should establish the applicable requirement before scheduling the transaction.
Is a signed IPv4 purchase agreement enough to complete the transfer?
No. A commercial agreement defines obligations between the buyer and seller, but it does not by itself update authoritative RIR registration. The applicable registry process must still be completed when the resource registration is changing.
What documents should be retained after an IPv4 transfer?
The parties should retain relevant transfer agreements, registry confirmation, invoices, settlement records, corporate authorization evidence, and important correspondence. The recipient should also document the resulting registry information and operational changes involving RPKI, IRR, reverse DNS, BGP, and related network records.
Final Thoughts
There is no single universal document package for every IPv4 transfer.
The correct documentation depends on the organizations involved, the IPv4 resources, their registration history, the source and destination RIRs, resource status, transaction type, and applicable recipient requirements.
The strongest approach is to begin due diligence before the buyer and seller commit to a closing structure.
Verify the parties.
Verify the IPv4 prefix.
Verify authority.
Verify the RIR transfer path.
Prepare the required corporate and registry documentation.
Then align the commercial agreement, settlement process, registry submission, and operational handover around those verified facts.
IPv4 transfer documentation should not be treated as paperwork added at the end of a transaction.
It is part of establishing a clear and reliable chain between the IPv4 resource, the organizations involved, the authoritative registry record, and the network that will ultimately use the addresses.
Organizations looking to acquire IPv4 resources can explore:
IPv4 holders evaluating unused resources can review:
1. Does WHOIS automatically change after an IPv4 transfer?
The relevant RIR updates registration information as part of an approved transfer according to its procedures. Buyers should still verify the resulting WHOIS or RDAP records after completion to confirm that the expected organization and contact information is visible.
2. What happens to a ROA after an IPv4 transfer?
The exact process depends on the RIR. Existing authorization associated with the source may be removed or cease to apply, and the recipient may need to create a new ROA for the IPv4 prefix and intended origin ASN. ARIN, for example, removes transferred resources and their associated ROAs from the source’s RPKI certificate.
3. Do PTR records transfer with an IPv4 block?
Not necessarily. Reverse DNS authority and PTR configuration should be reviewed during the handover. In some inter-RIR transfers, reverse DNS delegation is removed from the source registry and must be recreated through the receiving registry.
4. Does IPv4 geolocation update automatically after a transfer?
No. Geolocation is maintained by multiple third-party providers and platforms. Registry transfer information may be one signal, but operators may need to publish geofeed data or submit corrections to individual providers.
5. Does an IPv4 transfer remove the block's previous reputation?
No. Historical reputation data is maintained independently by third-party systems. Buyers should check the reputation and abuse history of an IPv4 block before acquisition and continue monitoring it after deployment.
