The team’s articlesRunning a network

Why Buying IPv4 Addresses May Not Give Companies the Control

Buying IPv4 addresses does not do the work of keeping customers connected. Explore Lu Heng’s case for an identity that can continue when providers change.

Contents

An engineer connects a stable blue-marked service point to a different network cabinet while a second route remains visible.
Lu Heng’s proposal separates the identity customers rely on from the network that delivers it. Changing a provider should not force every customer to start again.

A company buys IPv4 addresses so that its services can keep using them. The purchase may solve access to the resource, but a harder question remains: can the company keep serving its customers when it changes a provider?

Imagine moving an important application to a new network. The servers are ready. The application works. But partners have put the old addresses into their firewalls, customers use them in automated jobs and the operations team relies on their established history. A move that looks simple inside the company can become a change project for everyone around it.

This is the difference between acquiring addresses and maintaining continuity. Lu Heng's work starts with the second problem: how can the identity customers already depend on survive changes in the infrastructure delivering it?

What a purchase settles, and what still needs an operator

A commercial agreement identifies what the parties are buying and selling. Registration processes establish the corresponding records. Routing arrangements determine how traffic actually reaches the service. Buying an address block does not make those three layers operate as one.

The company still needs people to maintain contacts, authorisations and routes; providers willing and able to carry the addresses; and a clear way to deal with inconsistent records. Those responsibilities continue after the transaction closes.

In Note 66, Lu Heng explains why a transaction and long-term continuity are different services. The useful question is not simply whether a block can be delivered today. It is who will keep the resulting arrangement workable as circumstances change.

Customers build a history around an address

An address can accumulate practical value through use. A partner's security team recognises it. A supplier has approved access from it. An engineer knows where to find it in a log. These relationships are built by people and systems over time.

Replacing an address can therefore require more than changing a number in a control panel. Someone must identify every dependency, coordinate updates and check that the service still works from the customer's side.

The burden grows as more relationships depend on the same identity. A business should understand that burden before a provider change becomes urgent. Trace one important customer workflow from its first connection to its last external dependency: what would break if the public address changed tomorrow?

Separate identity from the provider delivering it

Note 68 develops Lu Heng's proposal: the identity a customer builds around should be able to continue while the infrastructure provider changes. Local delivery remains valuable, but it should not have to own the customer's entire continuity relationship.

This separation also gives providers a clearer role. They can compete on connectivity, installation, support and the quality of delivery. The customer does not have to rebuild every established relationship merely to choose a different provider.

LARUS One is a practical expression of that approach. LARUS maintains the identity service and renewal relationship; a selected provider supplies local delivery. A provider change still involves checking routing, availability and activation. The aim is an accountable continuity service through that change, not a promise that any address can instantly work on any network.

Bringing your own addresses to a compatible provider can help with portability. It also leaves work to be done: someone must maintain the resource history, manage the route and coordinate the transition. Separating the roles makes that work visible instead of assuming that possession of a block makes it disappear.

The bigger question is who can make continuity conditional

Provider choice is one part of the problem. Records maintained elsewhere may also influence whether an organisation can continue using its resources. A company can invest heavily in a network while remaining dependent on an administrator it cannot readily replace.

Lu Heng challenges the idea that this dependence should grant the administrator authority over the business itself. In Note 72, he argues for coordination that verifies uniqueness and preserves continuity without becoming a permanent permission system.

That proposal is broader than any one commercial service. It asks whether participants can retain verifiable rights and working relationships when their coordinator changes, just as they should be able to retain their identity when their delivery provider changes.

Ask what remains yours through a change

Before treating an IPv4 purchase as the end of the job, follow the next likely transition. Which customers would need to act? Which records would need updating? Who would coordinate the new route? What evidence would the next operator need, and who would remain responsible for continuity?

These questions reveal the work behind control. The ambition is a network identity that serves the customer over time, with providers competing to deliver it. Read Lu Heng's full argument in Note 68 to see why he connects customer continuity with a different economic role for providers.