What happens when IPv4 resources are recalled or disputed?

What happens when an IPv4 resource becomes disputed?

The answer is more complicated than saying that a registry simply “takes the addresses back.”

An IPv4 dispute can involve several separate layers: commercial rights, legal claims, registry records, routing authorisation and the running network.

Those layers are connected, but they are not the same.

legal and commercial rights → registry state → routing authorisation → operational use

A dispute affecting one layer does not automatically determine the outcome of every other layer.

For organisations operating production infrastructure, the most important questions are therefore:

• What exactly is being disputed?
• Which organisation has authority to resolve that question?
• What happens to the registry record?
• What happens to routing authorisation?
• Can the running network continue operating safely while the dispute is resolved?

IPv4 Resource Disputes: Quick Answer

An IPv4 resource dispute can affect registry records, transfer eligibility, contractual relationships or administrative authority.

However, there is no single global process under which every disputed IPv4 block is automatically frozen, revoked or reassigned.

The applicable process depends on factors such as:

• the relevant Regional Internet Registry;
• the history of the resource;
• the applicable agreements;
• the nature of the dispute;
• the organisations involved;
• the applicable transfer rules;
• corporate succession or restructuring;
• relevant legal proceedings; and
• the technical state of the running network.

A registry may request documentation, pause a transaction, refuse a transfer that does not meet applicable requirements, or update registry state when the appropriate requirements are satisfied.

Contractual or legal disputes may require resolution by the parties, arbitration, courts or other appropriate mechanisms.

A registry dispute is not automatically a routing outage, and a routing state does not automatically resolve a legal dispute.

What Does “Recalled” Mean for IPv4 Resources?

The word recalled is often used informally when discussing Internet number resources.

It should be used carefully.

There is no single universal Internet-wide process called an “IPv4 recall” that applies identically across all Regional Internet Registries, all resource types and all contractual relationships.

Depending on the situation, people may use the word “recalled” to describe:

• a registry status change;
• termination of a particular contractual right;
• revocation under an applicable agreement or process;
• a disputed transfer;
• correction of inaccurate registration information;
• return of resources under specific circumstances; or
• loss of continued access to addresses supplied by another party.

These are not necessarily the same event.

The exact meaning should therefore be determined from the applicable registry, contract, resource history and legal context.

Four Layers Explain IPv4 Disputes More Clearly

Most confusion around disputed IPv4 resources comes from treating ownership, registry records and routing as though they were one system.

A clearer model separates four layers.

These layers may need to be brought back into alignment, but no single layer should automatically be assumed to answer every question.

A Registry Record Is Not the Same as a Property Judgment

Internet number registries maintain important administrative records.

Those records can help identify:

• registered organisations;
• resource status;
• contact information;
• transfer history where available;
• RPKI-related authority;
• reverse DNS relationships; and
• other resource-management information.

But registry information should not automatically be described as a universal property title.

There is no single ownership model that resolves every IPv4 resource, every agreement and every jurisdiction.

Different resources may have different:

• allocation histories;
• contractual relationships;
• transfer histories;
• legacy status;
• corporate succession histories; and
• applicable legal circumstances.

Registry state is an important coordination record. It should not automatically be treated as the complete legal or operational reality of the resource.

For a deeper explanation, see Who Owns IP Addresses? Understanding Rights, Registry Records and Network Control .

What Can Cause an IPv4 Resource Dispute?

IPv4 disputes can arise for many different reasons.

Common categories include:

1. Corporate Succession

A company may merge, restructure, change legal name, acquire another organisation or cease to exist.

Registry information may then need to be updated to reflect the appropriate successor or new organisational structure.

Problems can arise where documentation is incomplete or different parties make competing claims.

2. Transfer Disputes

A commercial transaction may be agreed between parties while the corresponding registry transfer has not yet been completed.

A disagreement may then arise over:

• whether the transaction was completed;
• whether the transferring party had authority;
• whether payment conditions were satisfied;
• whether the resource was eligible for transfer; or
• whether the applicable registry requirements were met.

Commercial transaction and registry transfer are related, but they should not be treated as the same event.

3. Contractual Disputes

An IPv4 resource may be provided through a lease, service agreement or other contractual relationship.

Disputes may arise over:

• renewal;
• payment;
• termination;
• permitted use;
• abuse obligations;
• routing arrangements; or
• continuity commitments.

These issues are primarily contractual questions and should not automatically be treated as questions of registry ownership.

4. Inaccurate Registry Information

Registry data may no longer reflect the relevant organisational reality because of:

• outdated authorised contacts;
• company-name changes;
• mergers;
• acquisitions;
• corporate dissolution;
• administrative errors; or
• incomplete historical records.

Correcting inaccurate information is an important registry function.

5. Alleged Fraud or Unauthorised Changes

In some situations, parties may dispute whether a transfer, account change or request was properly authorised.

These cases may require additional documentation, identity verification or legal review.

They should be handled carefully because an incorrect administrative change can itself create serious continuity problems.

What Can a Registry Do During a Dispute?

The answer depends on the registry and the specific dispute.

There is no single universal procedure.

Depending on applicable rules and circumstances, possible registry actions may include:

• requesting additional documentation;
• declining to process a transfer until requirements are satisfied;
• reviewing corporate succession documentation;
• confirming authorised contacts;
• correcting inaccurate registry information;
• responding to an applicable legal order;
• maintaining the existing registry state while questions are reviewed; or
• taking other action permitted by the applicable agreement and process.

These possibilities should not be converted into a universal claim that registries automatically suspend, confiscate or reallocate every disputed resource.

How ARIN Transfer Rules Illustrate the Difference

ARIN's transfer process provides a useful example of how a dispute can affect an administrative transaction without automatically answering every legal or operational question about the resource.

Under ARIN's published transfer requirements, a source organisation generally must be the current registered holder and must not be involved in a dispute concerning the status of the resources for certain transfer processes.

See: ARIN – Transferring IP Addresses & ASNs .

This means a dispute can prevent or delay a transfer from proceeding.

It does not mean that the transfer process itself automatically resolves every underlying legal dispute.

How RIPE NCC Handles Resource Transfers and Organisational Changes

RIPE NCC also maintains processes for transferring Internet number resources and updating records after changes in business structure.

Its published procedures require relevant organisational information and supporting documentation when resources are transferred or an organisation changes legal structure.

See: RIPE NCC – Transfer of IP Addresses and AS Numbers .

This illustrates the important role of registries in maintaining accurate resource records.

At the same time, maintaining an accurate registry should be distinguished from operating the network that uses those resources.

Who Actually Resolves an IPv4 Dispute?

There is no single answer because different disputes involve different forms of authority.

The key principle is that authority should follow the nature of the question being resolved.

Registry State Does Not Automatically Stop BGP Routing

A change or dispute in a registry system should not be confused with the mechanics of global BGP routing.

BGP is operated by thousands of independently managed networks.

A prefix may continue to appear in the global routing table while an administrative or contractual question is unresolved.

Conversely, a prefix can be accurately registered while experiencing routing problems.

Registry state and routing state influence each other, but they are not identical systems.

RPKI Can Make Registry-Layer Changes Operationally Important

Although registry records do not directly operate BGP, registry-supported routing-security systems can affect operational routing.

RPKI is an important example.

A Route Origin Authorisation can specify which ASN is authorised to originate a prefix.

Networks performing Route Origin Validation may treat announcements differently depending on the resulting validation state.

This means that during a resource dispute, organisations should understand:

• which ROAs currently exist;
• which ASN is authorised;
• who can request legitimate changes;
• whether routing configuration matches the intended state; and
• how changes could affect a production network.

RPKI should support routing security. It should not be treated as a universal property title.

IRR and Reverse DNS Can Also Be Affected

IPv4 disputes may also involve operational dependencies outside the primary registry record.

These can include:

• IRR route objects;
• maintainer access;
• origin-ASN information;
• reverse DNS delegation;
• PTR records; and
• other administrative systems.

An organisation should therefore evaluate the complete operational dependency structure rather than assuming the registration record is the only relevant state.

An Administrative Dispute Should Not Automatically Become a Network Outage

A core resilience principle is to distinguish dispute resolution from unnecessary disruption of running networks.

A legitimate dispute may need to be investigated.

Records may need to be corrected.

Contractual or legal rights may need adjudication.

But where an established network is operating, continuity should also be considered.

Where appropriate, preserving the last verified state while a dispute is resolved can reduce unnecessary disruption without prejudging the final outcome.

This is not an argument for ignoring fraud, valid legal decisions or legitimate registry requirements.

It is an argument for separating the need to resolve a dispute from the assumption that service disruption must always be the first response.

Why Running-Network Continuity Matters

IPv4 resources can become deeply embedded in business infrastructure.

A production prefix may appear in:

• customer allowlists;
• firewall configurations;
• APIs;
• banking systems;
• payment platforms;
• VPN configurations;
• security services;
• DNS;
• partner systems;
• SaaS integrations; and
• compliance documentation.

Losing access to the same prefix can therefore create consequences far beyond obtaining a replacement address block.

Renumbering may require coordination across systems and organisations that the network operator does not directly control.

Registry continuity and running-network continuity are related, but the stability of the registry institution is not by itself the same thing as continuity of the customer's service.

What Does “Preserve the Last Verified State” Mean?

Where appropriate, one resilience approach is to avoid unnecessary changes to a known operational or administrative state until the relevant dispute has been resolved.

This principle does not mean that existing records can never be changed.

It means changes with potentially significant operational consequences should be:

• supported by appropriate authority;
• documented;
• auditable;
• proportionate;
• technically understood; and
• implemented with continuity consequences in mind.

This can reduce the risk that an unresolved administrative conflict creates an avoidable outage before the underlying facts have been determined.

Due Process Matters More When Registry Actions Can Affect Operations

Registries need processes for maintaining accurate records and responding to legitimate requests.

Where an administrative decision can materially affect production networks, stronger procedural safeguards become more important.

Useful safeguards can include:

• clear published rules;
• documented authority;
• transparent procedures;
• reasonable opportunities to respond;
• auditable decision-making;
• proportionate action; and
• continuity planning where technically appropriate.

Registry coordination is most useful when it remains focused on accurate resource coordination and interoperability without unnecessarily expanding into operational control.

What Happens If an IPv4 Transfer Is Disputed?

A transfer dispute does not necessarily mean the addresses disappear from the Internet.

Depending on the circumstances, a disputed transfer may:

• be delayed;
• require additional documentation;
• fail to meet registry eligibility requirements;
• require clarification of corporate authority;
• require contractual resolution between the parties;
• be affected by litigation or another legal process; or
• remain unresolved until the relevant authority is established.

The routing status of the prefix may be a separate operational issue.

What Happens If a Leased IPv4 Block Is Disputed?

Leasing creates another important distinction.

The organisation using the prefix may not be the organisation carrying the upstream registry-facing relationship.

A customer should therefore understand:

• who is the contractual provider;
• who carries the underlying resource relationship;
• who manages RPKI;
• who manages IRR;
• who controls reverse DNS;
• who communicates with the customer during a dispute;
• what continuity commitments exist; and
• what happens if the same prefix eventually becomes unavailable.

Multiple parties are not inherently a problem.

The risk comes from dependencies whose ownership, responsibility or continuity path is unclear.

First-Party IPv4 Service and Dispute Risk

A first-party service model can simplify some of these questions by making the provider's upstream responsibilities clearer.

A useful separation is:

Customer

→ operates the network, applications and routing policy

IPv4 service provider

→ carries defined commercial and registry-facing responsibilities associated with providing the service

Registry layer

→ supports uniqueness, registration and related coordination functions

The benefit does not come from centralising control over every layer.

It comes from making accountability easier to identify when something changes.

Clear responsibility is more useful than concentrated control.

Can an IPv4 Resource Be Revoked?

In some circumstances, the registry status or contractual status of an Internet number resource may be affected by applicable agreements, policy processes, legal decisions, fraud findings or other valid authority.

But it is inaccurate to describe every IPv4 resource as being continuously subject to a universal recall power exercised in the same way across all RIRs.

The answer depends on:

• the resource;
• the relevant registry;
• the applicable agreement;
• resource history;
• the nature of the claimed breach or dispute;
• applicable policy; and
• any relevant legal process.

What Enterprises Should Do Before an IPv4 Dispute Happens

The best time to prepare for an IPv4 dispute is before one exists.

Enterprises should understand:

• their contractual rights;
• the current registry state;
• the underlying resource relationship;
• their provider's continuity responsibilities;
• who can update RPKI;
• who can update IRR;
• who controls reverse DNS;
• which ASN is authorised to originate the prefix;
• how much infrastructure depends on the same addresses;
• how long renumbering would take;
• what notice would be available before a migration; and
• what escalation process applies if a dispute occurs.

IPv4 Dispute and Continuity Checklist

Portability Can Reduce Dispute-Related Operational Risk

Once an IPv4 prefix becomes part of an organisation's long-term network identity, portability can become an important continuity consideration.

An enterprise may eventually change:

• data centre;
• cloud provider;
• hosting provider;
• transit provider;
• routing architecture; or
• other infrastructure components.

Where technically and contractually possible, those changes should not automatically force renumbering simply because an unrelated infrastructure dependency has changed.

This is especially important where the same IPv4 identity has become embedded across customers and third-party systems.

How LARUS Approaches IPv4 Continuity

LARUS approaches IPv4 leasing as an ongoing infrastructure service, not only as access to address inventory.

The objective is to make important responsibilities clearer across:

• commercial relationships;
• registry-facing administration;
• routing-related support;
• renewal planning;
• operational deployment; and
• continuity.

The customer should continue to control its own network operation.

The provider's role is to carry clearly defined service and upstream responsibilities, not to centralise control over the customer's network.

Organisations where stable IP identity is operationally important can learn more about LARUS IPv4 Leasing Continuity Assurance .

Frequently Asked Questions

What happens when an IPv4 resource is disputed?

The outcome depends on the nature of the dispute. A registry may request documentation, delay or refuse a transfer, review administrative information or take another action permitted by its applicable processes. Contractual or legal questions may require separate resolution.

Can a registry take back an IPv4 block?

Some applicable agreements, policies, legal decisions or other valid processes can affect the registry or contractual status of a resource. However, there is no single universal recall process that applies identically to every IPv4 resource and every RIR.

Does an RIR decide who legally owns an IPv4 block?

A registry can make decisions about its records and applicable registry processes. Broader legal rights may depend on contracts, resource history, applicable law and appropriate legal proceedings.

Can a disputed IPv4 block continue routing?

It may. Registry state and BGP routing are separate layers. The actual routing outcome depends on network announcements, filtering, RPKI, upstream policy and other operational factors.

Does a registry dispute automatically invalidate BGP announcements?

No. There is no automatic one-to-one relationship between a registry dispute and global BGP withdrawal. Routing and registry administration are separate systems, although mechanisms such as RPKI can create important operational relationships between them.

Who resolves an IPv4 ownership dispute?

It depends on what is being disputed. Registry-process questions may be handled by the relevant registry. Contract disputes may be resolved by the parties, arbitration or courts. Legal entitlement questions may require appropriate legal proceedings.

Can an IPv4 transfer proceed while the resource is disputed?

Not always. Applicable transfer rules may prevent a transfer from proceeding while the status or authority surrounding the resource is unresolved. The exact requirements depend on the relevant registry and transfer path.

Does RPKI prove ownership of a disputed IPv4 block?

No. RPKI provides cryptographically verifiable information relevant to routing authorisation. It should not be treated as universal proof of legal property ownership.

What happens if leased IPv4 becomes disputed?

The customer should identify which party carries the underlying resource relationship, who is responsible for registry-facing administration, who manages routing-related authorisation and what continuity obligations apply. The result depends on the specific service and dispute.

Should a registry dispute immediately stop a running network?

Not necessarily. Legitimate administrative and legal processes still matter, but where a production network is operating, the continuity consequences of administrative changes should also be considered.

How can businesses reduce IPv4 dispute risk?

Maintain accurate documentation, understand the registry state, clarify contractual rights, know who controls RPKI and IRR, document corporate succession and build a continuity plan before the resource becomes deeply embedded in production.

Conclusion

IPv4 resource disputes are not simply ownership disputes and they are not purely registry problems.

They can involve several separate but connected layers:

legal and commercial rights + registry state + routing authorisation + operational use

A registry performs important coordination functions and may need to review documentation, process transfers, correct records or respond to applicable authority.

But registry state should not automatically be confused with complete legal ownership or direct operation of the running network.

Likewise, an active BGP route does not resolve every legal or contractual question surrounding a resource.

The strongest approach is to keep these layers aligned while respecting the different roles they perform.

Resolve disputes accurately. Preserve due process. Maintain auditable records. And where legitimate networks are already running, avoid turning unresolved administration into unnecessary operational disruption.

For a broader explanation of registry-layer dependency, read Registry-Layer Risk: Why IPv4 Continuity Depends on More Than Ownership .

For more on IP address ownership and control, read Who Owns IP Addresses? .

For organisations where stable IPv4 identity has become part of production infrastructure, explore LARUS IPv4 Leasing Continuity Assurance .