What Does Proof of Control Mean for an IP Address?

When someone says, “We control this IP address block,” the first question should be: control it for which action?

An IP prefix can appear in a registry, be announced through BGP, be protected by an RPKI authorization, be used under a lease, and support a running business at the same time. These facts are connected, but they are not the same fact. Treating one of them as proof of everything is how a technical record becomes a source of operational confusion and institutional power.

Proof of control is evidence that a person or organization is authorized to perform a specific action involving an Internet number resource.

That action might be updating a registry record, authorizing a route, changing a ROA, delegating reverse DNS, using address space under a contract, requesting a transfer, or representing a resource holder during a dispute. Each action needs the evidence that actually answers its question.

Begin with the action, not the word “ownership”

“Who owns this IP?” sounds simple, but it combines several different questions:

• Who may update the recognized registry record?
• Who may authorize an Autonomous System to announce the prefix?
• Who operates the network using the address space?
• Who may change reverse DNS or security settings?
• Who may lease, transfer or commercially delegate the resource?

A useful proof-of-control process names the action first, then asks who is authorized to perform it and what evidence supports that authority. This keeps an operational investigation precise without pretending that one database field resolves every contractual, organizational or legal relationship.

Four layers that are often confused

1. Registry control

A registry record describes recognized state: the organization associated with a resource, contacts, status and other information the coordination system maintains. Access to a registry account may show that a person can perform some actions in that system.

It does not automatically show that the account holder can sell the resource, transfer it, or speak for the organization in every situation. Credentials can be outdated, shared or compromised. System access and authority to make a particular decision are different things.

2. Routing control

BGP shows how a network is currently announcing a prefix. It is evidence about routing reality. It does not, by itself, prove that the announcing network was authorized by the resource holder.

A prefix may be announced by a customer, a hosting provider, an upstream network, a new provider during a transition, or an unauthorized party. The two questions are therefore separate:

Who is announcing the prefix?

Who authorized that announcement?

3. Security control

RPKI and a Route Origin Authorization provide cryptographically verifiable evidence for a narrower question: which Autonomous System is authorized, within the RPKI system, to originate a specified prefix?

That is valuable protection for routing. A valid ROA is not a universal title document. It does not automatically prove the terms of a lease, who operates the application, who paid for the resource, every commercial interest, or whether the route is currently being announced.

4. Operational and commercial control

A company may run servers, firewalls, VPNs, DNS, email or customer services on address space that it does not hold in the registry. A lessee may be authorized to use and route a prefix while another organization remains the registered holder. A provider may announce it on behalf of the operator.

This is not necessarily a contradiction. It is a set of relationships that must be recorded clearly: who holds the resource, who may use it, who may announce it, who manages RPKI and reverse DNS, and what happens when the arrangement ends.

What each piece of evidence can and cannot show

The point is not to create paperwork for its own sake. The point is to prevent a valid piece of evidence from being stretched beyond what it proves.

Why this matters when a network is changing

Proof of control matters most when something important is about to change: a company is moving providers, a prefix is being leased, an organization is restructuring, a route is being rehomed, or two parties disagree about who may act.

Before changing a running network, a careful process should identify:

1. the exact IPv4 or IPv6 prefix involved;
2. the last verified registry state;
3. the person or organization requesting the action;
4. the authority that connects that person to the resource holder;
5. the ASN that currently originates the prefix and the ASN intended to originate it;
6. the relevant RPKI, reverse DNS, routing and delegation records;
7. the evidence supporting the transition; and
8. the steps required to preserve service while the state changes.

A change can be administratively correct and still cause an outage if its routing, DNS, security and partner dependencies are ignored. Conversely, an active BGP announcement can keep traffic moving while the underlying authority is disputed. A sound process records both facts instead of allowing one to erase the other.

The hardest case is a disagreement between layers

Imagine a registry that identifies Organization A, a prefix announced by Organization B, a contract that lets Organization C use the address space, an old ROA authorizing ASN X, and a current network operating through ASN Y. Two people then ask the registry to accept different changes.

Choosing one system and ignoring the rest does not resolve the conflict. The investigation should ask:

• What was the last state that was verified, and by what evidence?
• What changed after that state?
• Who authorized each change?
• Which claims describe registry state, routing state, security state or operational use?
• Which parts of the network are currently serving customers?
• Can the requested update be made without unnecessarily disrupting a legitimate running network?

Historical records are essential here. A reliable coordination system should make it possible to reconstruct how a resource moved from one verified state to another, rather than showing only whichever record happens to be current. The question is not only “What does the database say today?” It is also “Was the transition itself valid and explainable?”

What a practical proof process looks like

For a high-impact change, use a layered check:

Confirm the resource

Identify the exact prefix and its relationship to the service, customer or network. Do not begin with a general claim about “the IPs.”

Confirm the requested action

State whether the request concerns a registry update, route authorization, RPKI, reverse DNS, leasing, transfer or operational use. Different actions require different authority.

Confirm the people and organizations

Identify the recognized holder, the person making the request, any provider, any lessee and any organization that will operate the network. Trace the authority from the holder to the requested action.

Compare the live and recorded states

Check the registry record, current BGP origin, RPKI authorization, reverse DNS, contracts and operational records together. Mark contradictions instead of silently choosing a favorite source.

Preserve the transition

Record the previous state, the evidence for the new state, the people who approved it, and the changes needed in routing, DNS, security and monitoring. Test the handover before closing the old arrangement.

This turns “proof of control” into a decision trail that another operator can inspect. It also makes disputes easier to resolve because the system can show what was known at each step.

Why proof should remain portable

If all evidence exists only inside one institution's private database, a resource holder's ability to demonstrate control becomes dependent on continued access to that institution. Staff changes, provider failures, account lockout and institutional disputes can then turn a technical fact into a permission crisis.

A more resilient coordination model should make the important parts of proof independently verifiable, auditable, transferable where appropriate, understandable to counterparties and recoverable during institutional failure. Credentials should not be exposed simply to make evidence portable. The principle is narrower: validity should not depend unnecessarily on institutional lock-in.

This is also why a registry's useful function should be separated from the idea that its administrator must be permanent or politically entitled to decide every question around a resource. Networks need uniqueness, accurate records, security assertions and traceable changes. They do not need one institution to become the owner of every commercial or operational decision that follows.

Thin coordination requires strong proof

Making coordination thinner does not mean making it careless. It means concentrating the common layer on the functions that networks must be able to verify:

• uniqueness of the resource;
• identity and evidence of control;
• accurate registry state;
• security assertions;
• transfer and audit records;
• conflict status; and
• operational continuity.

Pricing, customer geography, ordinary business models and the choice of infrastructure provider do not automatically belong in that same layer. Strong proof should protect the integrity of coordination without becoming a vague justification for controlling every decision made with an Internet number resource.

That is the boundary behind Lu Heng's larger argument. In The Bill of Rights of Uniqueness Coordination, the common layer is asked to protect uniqueness, verifiable control, accuracy, security and continuity. In Running-Code Primacy, the direction is toward technical rules that participating networks can verify and adopt, rather than permanent institutional permission deciding which future arrangements are legitimate.

The answer in one sentence

Proof of control is not one document, one login, one BGP announcement or one registry field.

It is a precise chain of evidence showing who is authorized to perform this specific action, what supports that authority, what state will change, and whether the resulting network can continue to operate.

A strong coordination system makes 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 it verifiable. The proof should serve the network, rather than becoming a substitute for it.

Continue with:

• Note 9: On APNIC governance and the need for a clean break
• Note 72: The Bill of Rights of Uniqueness Coordination
• Note 65: Running-Code Primacy
• Why Clear Operational Records Matter in IP Address Leasing