What Does Proof of Control Mean for an IP Address?

When someone says they “control” an IP address block, what exactly does that mean?

The answer is more complicated than checking a single WHOIS record.

For Internet number resources, proof of control is evidence that a person or organization is legitimately authorized to perform a particular action involving an IP address resource.

That action might be:

• updating registry information;
• authorizing a BGP announcement;
• creating or changing a Route Origin Authorization (ROA);
• delegating reverse DNS;
• leasing or operationally delegating address space;
• requesting a transfer; or
• representing the resource holder during a dispute.

There is no single piece of evidence that answers every one of these questions.

A registry record can provide important evidence.

RPKI can provide cryptographic evidence about routing authorization.

A contract can document a commercial relationship.

BGP can show who is currently announcing a prefix.

Corporate records can show who is authorized to act for an organization.

These layers may support one another, but they should not be confused.

Proof of control should answer a specific question: who is authorized to do what with this Internet number resource?

What Does “Control” Mean for an IP Address?

An IP address is not controlled in exactly the same way as a physical object.

An IPv4 or IPv6 prefix exists within several overlapping systems.

There is a registry layer, which records Internet number-resource information.

There is a routing layer, where networks announce prefixes using BGP.

There is a security layer, where mechanisms such as RPKI can express route-origin authorization.

There may also be:

• contractual relationships;
• leases;
• operational delegations;
• corporate ownership structures;
• service-provider relationships;
• reverse DNS delegations; and
• applicable legal rights or obligations.

This means control can have different meanings depending on the question being asked.

For example:

Registry control may mean being authorized to update the official resource record.

Routing control may mean being authorized to originate or arrange the routing of the prefix.

Operational control may mean managing the infrastructure currently using the addresses.

Commercial control may involve contractual rights relating to leasing, transfer or delegation.

These should not automatically be treated as identical.

Proof of Control Is Not the Same as IP Ownership

One of the most important distinctions is between control and ownership.

The legal status of Internet number resources can depend on contracts, registry policies, jurisdiction, transaction structure and other circumstances.

There is no reason to assume that one technical record settles every possible legal question.

A registry record can provide strong evidence about recognized registry state.

It does not necessarily determine every contractual, beneficial, operational or legal interest surrounding the resource.

Likewise, controlling the infrastructure announcing a prefix does not automatically prove that the announcing network has the right to transfer the address space.

This is why proof of control should remain a narrower concept.

Instead of asking:

“Who owns this IP address?”

a more useful operational question is often:

“Who has verified authority to perform the action being requested?”

That question can usually be answered more precisely.

Why Proof of Control Matters

Internet number resources must remain globally coordinated.

At the global level, IANA coordinates the Internet’s IP addressing systems and Autonomous System Numbers, while Regional Internet Registries provide regional layers of allocation and registration.

Once resources are in use, changes need to be made carefully.

A registry should not update an address block simply because someone sends an email asking for a change.

A network should not accept a route authorization simply because someone claims to represent the resource holder.

A transfer should not be recorded if the party requesting it cannot demonstrate appropriate authority.

Proof-of-control mechanisms therefore help protect:

• registry accuracy;
• resource holders;
• network operators;
• counterparties;
• routing security;
• transfer integrity; and
• operational continuity.

The objective is not to create unnecessary permission layers.

It is to prevent unauthorized changes while making legitimate changes verifiable.

What Can Be Used as Proof of Control?

There is no universal proof that works for every situation.

A reliable process normally looks at evidence appropriate to the requested action.

Several types of evidence may be relevant.

1. Registry Account and Resource Records

The registry record is an obvious starting point.

It may identify:

• the registered organization;
• resource contacts;
• administrative contacts;
• technical contacts;
• resource status; and
• other registration information.

Access to an authenticated registry account may also demonstrate that a user has been granted certain administrative capabilities within that registry system.

However, registry access should be interpreted carefully.

An employee may have login credentials without having corporate authority to sell or transfer a resource.

A former employee’s credentials may not reflect current authority.

An account can also be compromised.

For higher-impact actions, authentication should therefore be combined with appropriate authorization checks.

Being able to access a system and being authorized to make a particular decision are not always the same thing.

2. Corporate Authorization

When an organization is the recognized resource holder, proof of control may require evidence that the person making a request can legitimately act for that organization.

Depending on the circumstances, evidence might include:

• authorized signatory information;
• corporate documentation;
• director or officer authorization;
• formal letters;
• internal authorization records; or
• another verifiable chain of authority.

The exact documentation required will vary.

The important principle is that control should be traceable from the resource holder to the person requesting the change.

This becomes especially important during:

• mergers;
• acquisitions;
• corporate restructuring;
• insolvency;
• employee departures; or
• disputes between former and current representatives.

3. Routing Authorization

Routing provides another layer of evidence.

If a prefix is being announced through BGP, operators can observe which ASN is originating it.

But a BGP announcement alone is not sufficient proof of legitimate control.

BGP shows routing reality.

It does not, by itself, prove authorization.

A prefix may be:

• legitimately announced by a customer;
• announced by a hosting provider;
• originated by an upstream network;
• temporarily routed during a migration; or
• announced without authorization.

For this reason, a useful proof-of-control model should distinguish:

Who is routing the prefix?

from:

Who authorized that routing?

Those are different questions.

4. RPKI and Route Origin Authorization

RPKI provides one of the clearest examples of cryptographic authorization in the Internet number-resource system.

Under the RPKI architecture, resource certificates attest to holdings of IP address space and AS numbers within the RPKI trust framework, while a Route Origin Authorization allows a resource holder to explicitly authorize an Autonomous System to originate routes for specified prefixes.

That makes RPKI valuable evidence for a specific question:

Is this ASN authorized, within the RPKI system, to originate this prefix?

But even RPKI should not be stretched beyond what it proves.

A valid ROA does not automatically prove:

• legal ownership;
• the terms of a lease;
• who operates the customer application;
• who paid for the resource;
• every contractual interest; or
• that the route is currently being announced.

It is a powerful security assertion.

It is not a universal title document.

5. Letters of Authorization

Network operators frequently use Letters of Authorization, or LOAs, to document permission for routing-related actions.

An LOA may state that a particular network or ASN is authorized to announce a prefix.

This can be useful when:

• setting up BGP;
• moving between providers;
• configuring upstream networks;
• using leased IPv4 space; or
• changing hosting environments.

An LOA provides evidence of authorization, but its reliability depends on whether the party issuing it was itself authorized to do so.

The important issue remains the chain of control.

A document is only as useful as the authority behind it.

6. Contracts and Operational Delegation Records

An IP resource holder may allow another organization to use address space without transferring the underlying registry relationship.

This is common in leasing and other operational arrangements.

A contract may establish:

• which prefix is being used;
• who may route it;
• which ASN may originate it;
• how long the delegation lasts;
• who manages RPKI;
• who controls reverse DNS;
• who handles abuse reports; and
• what happens when the relationship ends.

In this situation, the resource holder and operational user are different parties.

That does not necessarily create a contradiction.

It creates a need for clearer records.

The holder should remain identifiable.

The operational delegation should be understandable.

The routing authorization should match the intended network.

And the end of the delegation should have a clear operational process.

This is one reason The Policy Mirror argues for a registry model capable of recognizing operational delegation while keeping the common coordination layer focused on uniqueness, accuracy and continuity.

7. Reverse DNS Control

The ability to change reverse DNS can demonstrate operational authority over another part of the IP resource environment.

But again, it proves only a specific capability.

If an organization can update PTR records, that does not automatically mean it can:

• transfer the prefix;
• change the registered holder;
• create a ROA; or
• authorize an entirely different network to originate it.

Reverse DNS is one layer.

It should not be mistaken for proof of every other layer.

8. Historical and Audit Records

Proof becomes much easier when resource changes leave an audit trail.

Useful records may show:

• who made a change;
• when it was made;
• what the previous state was;
• what evidence supported the change;
• which organization authorized it; and
• whether related security or routing records changed at the same time.

This becomes particularly important during disputes.

Suppose two parties both claim authority over a prefix.

A system with no meaningful history may contain only the current database entry.

An auditable system can instead reconstruct how the resource moved from one state to another.

That allows the question to become:

Was the transition itself valid?

rather than simply:

“What does the database say today?”

This distinction matters because a good registry should maintain accurate state and make legitimate state changes explainable.

What Proof of Control Does Not Prove

A common mistake is taking one valid piece of evidence and treating it as proof of everything.

That should be avoided.

This is why proof of control is better understood as an evidence framework rather than a single document.

Proof of Control During an IP Address Transfer

Transfers are one of the situations where proof of control becomes most important.

Before a registry record changes from one holder to another, the process should be able to establish at minimum:

1. Which resource is involved?
2. Who is the recognized transferor?
3. Does the person requesting the transfer have authority to act for that party?
4. Is there a conflicting claim, fraud concern or relevant hold?
5. Who is the intended transferee?
6. Can the new registry information be recorded accurately?
7. Can associated operational information transition without unnecessary disruption?

The registry’s role here should be significant but focused.

It should verify the integrity of the registry transition.

That does not necessarily mean deciding every commercial question surrounding the transaction.

This reflects the principle expressed in The Bill of Rights of Uniqueness Coordination: the common layer should protect uniqueness, proof of control, registry accuracy, security assertions, transfer records, auditability and continuity.

Proof of Control During IP Address Leasing

Leasing creates a different situation.

The registered resource holder may remain the same.

Another organization may become the operational user.

A third party may provide the network through which the prefix is announced.

Proof of control should therefore answer several narrower questions:

Who is the holder?

Who is the authorized user?

Who may announce the prefix?

Which ASN should originate it?

Who manages RPKI?

Who controls reverse DNS?

When does the delegation begin and end?

Trying to collapse all these roles into one word—“owner,” “holder,” or “user”—can create more confusion than clarity.

A better system records the relationships that actually matter.

What Happens When Different Proofs Conflict?

The hardest cases occur when different systems tell different stories.

Imagine that:

• the registry identifies Organization A;
• the prefix is announced by Organization B;
• a contract says Organization C is using the addresses;
• an old ROA still authorizes ASN X;
• the current network is using ASN Y; and
• two parties disagree about who may request the next registry update.

Simply choosing one database and ignoring the rest may not resolve the underlying issue.

A better investigation asks:

• What was the last verified registry state?
• What changed after that?
• Who authorized the change?
• What evidence supports each claim?
• Which parts of the network are currently operational?
• Is there evidence of fraud or an unauthorized state transition?
• Which information can be updated without unnecessarily disrupting legitimate network operation?

A disputed state should be treated as a problem to investigate, not as an excuse to pretend that operational reality does not exist.

Why “Last Verified State” Matters

When control is uncertain, maintaining an auditable last verified state can help prevent uncertainty from becoming arbitrary change.

The idea is straightforward.

Before changing a disputed record, the system should know:

• what the last verified state was;
• which evidence supported it;
• what new evidence has appeared;
• whether the proposed transition is valid; and
• whether a dispute remains unresolved.

This does not mean preserving an incorrect record forever.

It means making changes traceable.

A registry should be able to say not only:

“This is the current state.”

but also:

“This is how the resource moved from the previous verified state to the current state.”

That is what auditability adds to proof of control.

Proof of Control Should Be Portable

There is another important design question.

What happens if proof of control exists only inside one institution’s private database?

Then the resource holder’s ability to demonstrate control can become dependent on continued access to that institution.

A more resilient coordination model should make important evidence:

• verifiable;
• auditable;
• transferable where appropriate;
• understandable by counterparties; and
• recoverable during institutional failure.

This does not mean every credential should be publicly exposed.

It means that validity should not depend unnecessarily on institutional lock-in.

A resource holder should be able to demonstrate a legitimate chain of control even when providers, employees, infrastructure or administrative systems change.

A Practical Proof-of-Control Checklist

Before making a significant change involving an IP resource, ask:

Resource identity

• Which exact IPv4 or IPv6 prefix is involved?
• Is the resource uniquely identified?

Registry state

• Which organization is currently recorded?
• Are the relevant records current?
• Is there an active dispute or conflict?

Organizational authority

• Who is requesting the change?
• Can that person legitimately act for the organization?

Routing

• Which ASN currently originates the prefix?
• Which ASN is intended to originate it after the change?
• Who authorized that arrangement?

RPKI

• Is there a relevant ROA?
• Does it match the intended routing state?
• Who can make necessary RPKI changes?

Operational delegation

• Is another organization currently using the resource?
• Is that delegation documented?
• When does it begin or end?

Reverse DNS

• Who controls the reverse DNS delegation?
• Does that responsibility need to change?

Auditability

• What evidence supports the requested state transition?
• Will the previous state remain traceable?

Continuity

• Can the change be completed without unnecessarily disrupting a running network?

This is a much more useful test than asking whether someone can produce one document labelled “proof of control.”

Thin Coordination Requires Strong Proof, Not Broad Control

A thin registry does not mean a registry with weak security.

In many ways, the opposite is true.

If a coordination layer is focused on a smaller set of essential functions, those functions need to be done well.

That means strong mechanisms for:

• uniqueness;
• identity;
• proof of control;
• registry accuracy;
• fraud prevention;
• security assertions;
• transfer records;
• auditability;
• conflict status; and
• operational continuity.

What does not necessarily belong in the same common layer are broader decisions about:

• pricing;
• customer geography;
• ordinary commercial models;
• business strategy; or
• which legitimate infrastructure provider an operator chooses.

Proof of control should protect the integrity of the registry.

It should not become a vague justification for controlling every decision involving an Internet number resource.

Proof of Control and Running Networks

Ultimately, proof of control matters because IP addresses are used by running networks.

Once a prefix is deployed, it may support:

• servers;
• websites;
• APIs;
• cloud environments;
• customer services;
• firewalls;
• VPNs;
• DNS;
• email systems;
• security policies; and
• network access controls.

An unauthorized change can therefore have consequences far beyond a registry database.

At the same time, an unresolved administrative question should not automatically be allowed to create unnecessary disruption for a valid running network.

This balance is central to Running-Code Primacy.

The registry needs strong evidence.

The security layer needs valid authorization.

The record needs to remain accurate.

But these mechanisms exist to support interoperable networks.

They should not lose sight of that purpose.

Conclusion

Proof of control for an IP address should not be reduced to one database field, one BGP announcement or one document.

Internet number resources exist across several layers.

The registry records one part of reality.

BGP describes routing.

RPKI describes route-origin authorization.

Contracts may describe commercial or operational delegation.

Corporate records can establish authority to act.

Audit history shows how the resource moved between states.

Each layer answers a different question.

The goal is not to make proof more complicated than necessary.

It is to make it precise.

Who controls the resource?

is often too broad.

A better question is:

Who is authorized to perform this specific action, what evidence supports that authority, and can the resulting state be independently understood and verified?

That is what proof of control should provide.

A strong registry system should make legitimate control easy to demonstrate, unauthorized changes difficult to perform, disputes easier to audit and running networks easier to protect.

The registry should record control accurately.

The evidence should make control verifiable.

And the proof should serve the network—not become a substitute for it.