Why Clear Operational Records Matter in IP Address Leasing

A leased IP prefix can look simple on paper. One organisation holds it, another uses it, a network announces it, and several systems keep it reachable. The difficulty begins when those roles change at different speeds.

A company moves its service to a new provider. The BGP announcement changes, but the old Route Origin Authorization remains. The lease is still valid, but nobody is sure who controls reverse DNS. A security report arrives and reaches the commercial contact instead of the network operator. The network may still be running, yet the record of how it works has become unclear.

This is the question this guide answers: how can an organisation keep a leased network identity understandable when the people, providers and systems around it change?

The problem is not paperwork

Operational records matter because a single IP address or prefix sits inside several relationships at once. The recognised resource holder may be different from the current user. The user may be different from the network that originates the route. The person who manages routing may be different from the person who manages RPKI or reverse DNS.

When those relationships are visible and current, a provider change is a sequence that can be checked. When they are scattered across contracts, email threads, tickets and old configuration, a routine change becomes an investigation.

Good records do not make the arrangement more centralised. They make the actual arrangement easier to see.

Four layers must stay distinct

Start by separating four things that are often collapsed into one word, ownership:

• The resource. The IPv4 or IPv6 prefix, and any ASN associated with the network, give the infrastructure a globally recognisable identity.
• The recognised holder. A registry record identifies the party recorded for the resource and helps the wider Internet avoid conflicting claims.
• The running network. Routers, BGP announcements, upstreams and applications determine where traffic actually goes.
• The operational assertions. RPKI, Route Origin Authorizations, reverse DNS and contact records describe how the resource is meant to function right now.

These layers can belong to different parties without being contradictory. Confusion begins when a record from one layer is treated as proof of everything in the others. A registry record does not prove who currently operates a service. A BGP announcement does not prove who is the recognised holder. A lease contract does not automatically update an ROA.

The purpose of documentation is to keep the relationships aligned enough that an operator can tell which question each record answers.

What a clear record should answer

For every production prefix, an infrastructure team should be able to answer five plain questions:

1. Which resource is this? Record the exact prefix, ASN and relevant registry reference.
2. Who is the recognised holder? Keep the holder identifiable even when another organisation is using the resource.
3. Who uses it now? Name the current operational user, network and provider relationship.
4. Who can change the network? Identify the people or systems authorised to change routing, RPKI, reverse DNS and technical contacts.
5. What happens when the relationship changes? Record the start, material changes, handover and end of the lease or delegation.

This is a map of responsibility. It is not a demand that every detail become public, and it is not a new permission system. Sensitive information can remain in the appropriate private systems while the relevant operators retain a consistent, auditable view.

Routing and RPKI must move together

Consider a prefix moving from one hosting network to another. The new network may announce it correctly, but a stale ROA may still authorise the previous ASN. Networks that perform Route Origin Validation can then see the new route as invalid.

The same change can also affect reverse DNS, abuse contacts, monitoring, customer allowlists and incident response. A route is only one part of the identity that customers have learned to trust.

A useful change record therefore connects the intended route, the authorised origin, the RPKI update, the supporting services and the person responsible for checking the result. The technical details remain with the operators who run the network. The record makes the handover legible.

That is the practical value of RPKI: a narrow, verifiable security assertion about route origin. It should protect the running network without becoming a general authority over unrelated commercial decisions.

Leasing needs a beginning, a middle and an end

Many operational mistakes happen because a lease is documented at activation and then forgotten. A useful lifecycle has three distinct moments.

At the start

Confirm the prefix, recognised holder, operational user, originating ASN, routing authorisation, RPKI responsibility, reverse DNS responsibility, contacts and activation date. Test the route and record what success looks like.

During the lease

Record material changes: a new provider, ASN, data centre, route, ROA, reverse DNS operator, security contact or technical owner. A current record should make the present state clear without forcing a new engineer to reconstruct months of history.

At the end

Plan the withdrawal of the route, the change or removal of the ROA, the treatment of reverse DNS, the return or reassignment of the resource, and the notification of the people who depend on it. Offboarding is part of continuity. A relationship that can start but cannot be unwound cleanly is a hidden dependency.

Why this matters when a provider changes

Provider change is the ordinary test of whether the record describes reality. The address can remain the same while the network, upstream, technical team and security configuration change around it.

With a clear record, the sequence is visible:

current state → authorised change → new route → security and service checks → recorded handover.

Without it, each party may hold one fragment of the truth. One sees the registry entry, another sees the lease, another sees the BGP route, and another sees the stale ROA. No single fragment explains what the network is supposed to do now.

That is why continuity is more than keeping a route alive. It is preserving the ability to understand and change the relationships that keep the route useful.

Accurate records do not require excessive control

There is an important boundary here. A coordination layer needs enough information to preserve uniqueness, accuracy, verifiable security assertions and operational continuity. It does not need to decide the price of a lease, choose a customer, approve an infrastructure design or become the permanent intermediary for every commercial relationship.

Keeping the recognised holder identifiable protects the record. Keeping the administrator replaceable protects the participants. These are compatible goals.

Lu Heng develops this distinction in The Bill of Rights of Uniqueness Coordination and The Policy Mirror: coordination should make shared facts reliable, while authority remains limited to what the shared system actually needs.

The deeper principle: make coordination portable

A record is useful only if it can survive the failure or replacement of the person who currently maintains it. If the facts about a resource live only inside one administrator's account, a provider dispute can become a continuity crisis.

Portability means that the holder, operational user, route, security assertions, contacts and material history can be verified and carried into a new arrangement. It gives the network a way to change its coordinator without pretending that the underlying resource or running service has changed.

This is where operational recordkeeping connects to decentralised Internet governance. The goal is not to eliminate coordination. It is to prevent coordination from becoming an irreplaceable gatekeeper.

The same question appears in The Registry Continuity Fallacy and Running-Code Primacy: protect the ledger and the running network, and keep the institution that coordinates them accountable and replaceable.

A short handover checklist

Before a production prefix changes provider, ask:

• Can we identify the exact resource and recognised holder?
• Can we name the current user, originating ASN and network operator?
• Has the routing authorisation been recorded and tested?
• Will the RPKI assertion change with the route?
• Who owns reverse DNS, abuse response and technical escalation?
• Which customers or systems depend on this address?
• Can another coordinator verify the record if the current one fails?
• Is the end of the lease as clear as its beginning?

If the answers are spread across several systems, that is the first continuity finding. The work is to make the relationship understandable before an incident forces the issue.

What reliable coordination looks like

Clear operational records do not promise that networks will never fail. They reduce the chance that a failure becomes impossible to interpret.

The recognised holder remains visible. The operational user can be identified. The running route can be checked. RPKI and reverse DNS can follow real changes. Contacts can reach the people who can act. The history can explain what happened. The lease can end without leaving behind an unowned route or stale assertion.

That is a modest requirement, but it is foundational. The Internet can remain decentralised only when its participants can coordinate shared facts without surrendering the ability to change their coordinator.

Continue with the original argument

This team guide explains the operational problem in plain language. For the underlying argument about number resources, authority and replaceable coordination, continue to Lu Heng's original Notes, especially the discussion of registry continuity and running code.