How RIR Policy Differences Shape IPv4 Transactions Across Regions

Two IPv4 blocks can have the same prefix size, similar market value, and equally willing buyers and sellers—yet require different transaction preparation.

The reason is that an IPv4 transaction does not exist only at the commercial layer. The address block is also registered within a Regional Internet Registry framework, and the applicable policies can affect whether the resource is currently transferable, what the recipient must prepare, which records need to be verified, and how an inter-RIR transaction should be sequenced.

For buyers and sellers, the useful question is therefore not:

Which RIR has the easiest transfer rules?

It is:

What does the applicable RIR policy require this specific transaction to have ready before it can move from commercial agreement to registry completion and operational handover?

That distinction turns RIR policy from a background compliance topic into a practical transaction-planning input.

For a region-by-region overview of the individual registry frameworks, see i.LEASE’s guide to RIR transfer rules across regions. This article takes a different approach: it focuses on how those differences change transaction readiness and execution.

RIR policy affects the transaction before paperwork is submitted

A common mistake is to treat registry requirements as something to check after the buyer and seller have agreed on the block and price.

In practice, policy review should happen earlier. Recipient readiness, transfer-path selection, organizational records, and documentation can all affect what happens after the first commercial agreement, as discussed in i.LEASE’s analysis of why IPv4 deals can stall after agreement.

Before a transaction structure is finalized, the parties should already know:

• where the IPv4 block is currently registered;
• what type and status of resource is involved;
• whether the current holder is correctly reflected in registry records;
• whether the resource has recent transfer or delegation history;
• which RIR will serve the receiving organization;
• what recipient requirements may apply;
• and whether the proposed source-to-destination transfer path is currently available.

Different RIR frameworks handle these questions differently.

For example, RIPE NCC’s current transfer policy applies a 24-month transfer restriction to scarce resources such as IPv4 after they are received by a holder, while APNIC applies a five-year restriction to IPv4 addresses originally delegated from its 103/8 free pool.

LACNIC’s current policy requires an organization in its region receiving a transfer to justify the IPv4 resources it intends to receive. ARIN’s transfer framework, meanwhile, defines separate transfer paths for organizational changes, specified-recipient transfers, and qualifying inter-RIR transfers.

These are not reasons to rank one registry against another. They are reasons to perform policy due diligence before designing the transaction.

How policy differences change buyer readiness

A buyer can be financially ready to purchase IPv4 without yet being registry-ready to receive it.

That difference matters.

Depending on the relevant registry and transfer path, buyer preparation can involve:

• creating or maintaining the appropriate RIR account or organizational relationship;
• confirming corporate registration information;
• establishing the correct recipient organization;
• preparing utilization or needs information where required;
• determining the intended resource size;
• identifying the destination RIR;
• and ensuring that the proposed transaction fits an available transfer mechanism.

APNIC’s resource transfer policy, for example, requires participating organizations in applicable transfers to meet its transfer-policy criteria and requires recipients under its unused-resource transfer framework to demonstrate need. LACNIC likewise requires a recipient within its region to justify the IPv4 resources it will receive.

RIPE NCC takes a different approach in its own region, but its inter-RIR policy provides for a utilization plan when the source RIR requires the receiving region to operate a needs-based policy.

The operational lesson is straightforward:

Buyer readiness should be checked against the specific transaction path, not assumed from the buyer’s ability to pay.

This becomes particularly important when a buyer is acquiring IPv4 from another RIR region.

How policy differences change seller readiness

Seller readiness is more than having unused IPv4 space.

Before presenting a block as transaction-ready, the seller should understand whether the registry-side facts support the intended transfer.

That review can include:

• confirming the registered holder;
• checking whether corporate names and registry information still align;
• identifying the exact prefix proposed for transfer;
• reviewing how and when the resource was received;
• confirming whether a policy restriction or voluntary lock applies;
• establishing whether a dispute affects the resource;
• and determining whether the block can follow the intended intra-RIR or inter-RIR path.

Resource history is especially important because a block that looks commercially available may still be subject to a transfer condition.

RIPE NCC’s current policy, for example, prevents scarce resources such as IPv4 from being transferred for 24 months after receipt, subject to stated exceptions. It also provides a voluntary transfer-lock mechanism that prevents a locked resource from being transferred during the agreed period.

APNIC’s rules provide another example: IPv4 originally delegated from its 103/8 free pool cannot be transferred for five years after the original delegation.

These checks are not criticism of registry policy. They are normal asset and transaction due diligence.

A seller who understands the resource history can set more realistic expectations with potential buyers.

Policy differences can change the structure of the deal

RIR policy can influence more than whether a transfer is possible. It can also affect how the commercial transaction should be structured.

Consider a transaction involving:

• a purchase agreement;
• buyer and seller documentation;
• escrow;
• registry submission;
• registry review;
• registry-record completion;
• settlement;
• and operational handover.

Those events should not be treated as unrelated tasks.

The commercial agreement should define milestones that make sense for the applicable transfer process.

For example, the parties may need to determine:

• what must be verified before funds enter escrow;
• which registry conditions are prerequisites to closing;
• what constitutes successful registry completion;
• whether payment releases immediately after registry update or after another agreed condition;
• what happens if additional documentation is requested;
• and when operational responsibilities pass from seller to buyer.

The i.LEASE IPv4 buying workflow reflects this type of sequencing: inventory selection is followed by escrow, preparation for applicable RIR policy requirements, registry transfer, and then operational handover.

The principle is more important than any single workflow:

Registry requirements and commercial milestones should be designed to fit together.

A transaction becomes harder to manage when the contract assumes one sequence while the actual registry process requires another.

Three IPv4 deals can look identical and still require different preparation

The effect becomes clearer when comparing three hypothetical transactions.

Scenario 1: Buyer and seller are in the same RIR environment

A hosting company wants to acquire a /20 from another organization operating within the same RIR framework.

Commercially, the transaction may be relatively straightforward:

• confirm seller authority;
• confirm buyer eligibility;
• verify resource status;
• prepare required documentation;
• align settlement with the transfer process;
• complete registry and operational handover.

Only one RIR framework is directly involved in the source-to-recipient transfer.

That does not eliminate due diligence, but it reduces the number of policy interfaces involved.

Scenario 2: Buyer and seller are in different RIR regions

Now assume the same /20 is being acquired by an organization in another RIR region.

The prefix size and price may be unchanged.

The transaction architecture is not.

The parties now need to consider:

• requirements on the source side;
• requirements on the receiving side;
• whether an inter-RIR pathway exists between the two;
• what information each registry expects;
• how responsibility moves between the registries;
• and how the transaction timeline should accommodate both processes.

APNIC explicitly states that inter-RIR transfers depend on the counterpart RIR having an appropriate inter-RIR transfer policy, with source and recipient conditions determined by the applicable RIRs.

ARIN similarly recognizes inter-RIR transfers where the recipient qualifies under the recipient RIR’s policy.

The deal may still be fully executable. It simply requires two-sided preparation.

Scenario 3: The block has recent transfer history

Now assume the buyer and seller are in a compatible registry environment, but the /20 recently changed hands.

Commercially, it may look no different from another /20.

Policy review may produce a different answer.

If the resource is subject to a current transfer restriction, voluntary lock, or other condition, the timing of the proposed transaction may need to change.

This is why an IPv4 marketplace listing should not be assessed from prefix size, reputation, and price alone.

Resource history is part of transaction readiness.

Inter-RIR compatibility should be checked before closing assumptions are made

An inter-RIR transaction involves two registry environments, so a statement such as “this RIR supports inter-RIR transfers” is not enough by itself.

The relevant question is whether the specific source-destination combination and resource category can follow a supported path at the time of the transaction.

Policies can also evolve.

AFRINIC, for example, ratified a new Number Resources Transfer Policy in February 2026 covering intra-regional transfers, certain legacy-resource transfers, and inter-RIR transfers where reciprocal arrangements exist. The ratified framework also distinguishes resource categories when determining transfer eligibility.

That is why inter-RIR planning should verify the current official position of the registries involved instead of relying on an old transaction, article, or assumption.

For buyers and sellers, the practical sequence is:

1. identify the source RIR;

2. identify the destination RIR;

3. classify the resource;

4. verify source-side eligibility;

5. verify recipient-side readiness;

6. confirm that the current inter-RIR path supports the proposed transaction;

7. then align commercial and settlement milestones.

This approach treats policy verification as part of transaction design rather than as a final compliance check.

Policy differences can affect timing without creating a fixed timeline

It is tempting to ask:

How long does an IPv4 transfer take?

A single universal answer is not very useful.

Transaction timing can depend on:

• whether one or two RIRs are involved;
• whether buyer documentation is already complete;
• whether organizational records match;
• whether resource history requires additional review;
• whether the recipient must provide supporting information;
• how quickly both parties respond to requests;
• and how the commercial settlement process is structured.

APNIC’s operational transfer guide, for example, notes that the recipient must acknowledge an initiated transfer within 30 days and that APNIC evaluates the request after recipient acknowledgement.

This illustrates why timing should be managed as a workflow rather than reduced to one advertised number.

A well-prepared transaction can still involve registry processing. A poorly prepared transaction can add avoidable back-and-forth before that process can move forward.

The goal should therefore be readiness, not a promise of a universal closing time.

Where RIR policy ends and transaction execution begins

Understanding the applicable RIR policy tells the parties what conditions and processes apply.

Execution is the work of making sure the transaction is actually prepared around those requirements.

That can include:

• buyer and seller verification;
• transaction documentation;
• resource-history review;
• registry preparation;
• escrow coordination;
• transfer submission;
• settlement;
• registry-record updates;
• routing authorization;
• RPKI and ROA preparation;
• reverse DNS;
• and operational handover.

For a deeper discussion of why registry, routing, documentation, and lifecycle dependencies remain relevant beyond simple marketplace matching, see Understanding Operational Risk in IPv4 Address Markets.

This distinction is central to the current i.LEASE operating model.

i.LEASE describes itself as an IPv4 secondary-market platform supporting buying, selling, leasing-in, and leasing-out, while using authorization-based workflows to connect transactions with registry and lifecycle operations.

That does not replace the relevant RIR.

It means the transaction is organized around the applicable RIR process instead of leaving registry and operational requirements as disconnected follow-up tasks.

The difference can be expressed simply:

Policy defines the applicable requirements. Execution aligns the parties, documents, settlement, registry process, and operational handover with those requirements.

A transaction-readiness matrix

Instead of comparing RIRs as “easy” or “difficult,” buyers and sellers can evaluate whether each side of a specific transaction is ready.

Transaction question	Buyer	Seller	Why it matters
Source RIR identified	✓	✓	Establishes the starting registry framework
Destination RIR identified	✓	✓	Defines the receiving-side process
Resource holder verified		✓	Confirms source authority
Resource history reviewed	✓	✓	Can reveal transfer restrictions or status issues
Recipient eligibility prepared	✓		Determines receiving-side readiness
Corporate records aligned	✓	✓	Reduces identity and authorization questions
Inter-RIR compatibility confirmed	✓	✓	Establishes whether the intended cross-region path is available
Required documentation prepared	✓	✓	Supports efficient submission
Escrow milestones aligned	✓	✓	Keeps settlement synchronized with execution
Registry completion condition defined	✓	✓	Clarifies when the transfer milestone has been reached
Operational handover planned	✓	✓	Prepares the resource for actual deployment

The matrix changes the question from:

“Which RIR is easier?”

to:

“What needs to be ready for this transaction?”

That is a more useful way to plan an IPv4 acquisition or sale.

What buyers should confirm before signing

A buyer considering IPv4 across multiple regions should know:

• the exact prefix being purchased;
• the current RIR;
• the intended destination RIR;
• current resource status;
• recent transfer history;
• recipient requirements;
• whether an inter-RIR path is currently supported;
• the evidence required before settlement;
• and what operational handover is included after registry completion.

The buyer should also distinguish registry completion from production readiness.

A successfully updated registry record does not automatically configure the network that will use the new block.

Depending on the deployment, post-transfer work can still include RPKI, rDNS, routing, IRR, geolocation, reputation, security, and internal IPAM changes.

What sellers should confirm before listing

A seller can improve transaction readiness by verifying:

• the precise resources available;
• correct organization and registry records;
• resource history;
• current transfer eligibility;
• any applicable lock or restriction;
• corporate authority;
• expected buyer documentation;
• inter-RIR options where relevant;
• and the handover responsibilities that follow completion.

This preparation helps prevent a block from being marketed using assumptions that later need to be revised during execution.

It also gives buyers a clearer basis for evaluating the opportunity.

The practical takeaway

RIR policy differences matter because IPv4 transactions cross both a commercial layer and a registry layer.

Those differences can change:

• what a buyer must prepare;
• what a seller must verify;
• whether a specific transaction path is currently available;
• how settlement conditions should be structured;
• how much documentation is required;
• and how the registry process fits into operational handover.

They do not require buyers to decide that one RIR is better or worse than another.

Each transaction should instead be evaluated against the policies that actually apply to its source resource and receiving organization.

When policy review happens early, it becomes a planning tool rather than a late-stage surprise.

For organizations sourcing IPv4 across different registry regions, i.LEASE combines secondary-market access with authorized transaction and lifecycle workflows designed to coordinate the commercial, registry, and operational stages around the applicable requirements.

Explore IPv4 buying opportunities through i.LEASE when your transaction requires coordinated marketplace, registry, and operational execution.

 

Frequent Asked Questions