How to Lease an IP Address: Control, Continuity and a Safe Exit
Leasing an IPv4 block is not only a capacity decision. Learn how to verify control, protect continuity and keep a real exit path for your network.
Leasing an IP address is often presented as a simple infrastructure purchase: choose a block, sign an agreement and announce it. That description leaves out the question that matters most once a network depends on the address:
Who can prove control of the resource, keep it usable, and help you leave when the relationship changes?
A public IPv4 block can become part of DNS, customer allowlists, security rules, email reputation, routing policy and investment plans. The address may be leased, but the dependency is real. This guide explains how to evaluate an IP lease as a continuity decision rather than as a list of numbers.
The larger problem: coordination can become power
The Internet depends on shared number and name systems. They help different networks find one another, but a shared record also decides what is recognised, reachable and able to continue. When that record is concentrated in a central administrator, a technical coordination role can quietly become a power centre.
An administrator may maintain a shared number or name record. That technical role alone does not authorise it to speak for network participants across continents or make political decisions on their behalf. Maintaining the address book is not the same as representing everyone whose work appears in it.
This is the larger problem behind an IP lease. If the same institution controls the record, the interpretation of the record and the practical ability to remain connected, users inherit decisions they did not grant. A lease is a small, concrete place to ask whether coordination is serving the network or becoming a command point that no one can replace. Note 2 examines that distinction in full.
The problem in a lease: availability is not control
A provider can show that an address responds today without proving that the whole operating arrangement is sound. The registry record, the organisation using the block, the network announcing it, the party managing RPKI and the party answering abuse reports may all be different.
Those roles can be separated without being confusing. The danger begins when nobody can explain the chain between them, or when one administrator treats a working record as proof that it owns every decision around the resource. A lease that gives you connectivity but no verifiable authority or exit path creates dependence that only becomes visible during a dispute.
That is the same distinction explored in Note 2: a record can coordinate a network without giving its administrator an unlimited mandate over everyone who relies on it.
The solution: a thin coordination layer
The answer is not to pretend that networks need no shared coordination. The answer is to keep the shared layer as thin as possible and limit it to what participants actually need:
- Uniqueness: the same number or name should not be assigned to two participants at once.
- Proof: a participant should be able to show what it controls and what authority it has received.
- Accurate records: the directory should describe reality rather than create an unchallengeable story about it.
- Portability: records, authorisations and operating relationships should be able to move with the work.
- Replaceability: no administrator should become the only possible route to continuity.
In practical terms, a good IP lease tests this design. The provider may coordinate routing, records and support, but you should be able to verify each responsibility, carry the relevant evidence forward and change the relationship without losing the network. The goal is useful coordination without turning the coordinator into a sovereign over the people who depend on it.
Why this is urgent now
The urgency is structural, not a news cycle. Every new dependency pushes more authority into a control plane that users may not be able to inspect or replace. Once an address is embedded in DNS, mail systems, allowlists, routing policy, customer documents and reputation, leaving becomes more expensive.
The practical window is before production dependencies accumulate: verify the control chain and rehearse the exit while the network still works. The institutional window is while Internet coordination can still be made portable and replaceable. If technical administration is allowed to stand in for political representation, users may discover the difference only after their options have narrowed.
What a durable lease must provide
A useful lease should answer five questions in plain language:
- What exactly can we use? Identify the prefix, quantity, intended use and routing model.
- Who is authorized to provide it? Separate the resource holder, the commercial provider, the announcing network and the operational contacts.
- What can we verify before production? Check reputation, geolocation, registration information, routing history, reverse DNS and the relevant authorization records.
- Who can change each layer? Make responsibility for BGP, LOA, RPKI, IRR, reverse DNS, abuse handling and support visible.
- How do we leave? Know how services, DNS, routes, records and customer dependencies will move if the lease ends or the provider fails.
If these answers depend on one person’s memory or on an administrator’s promise, the arrangement is not yet operationally clear.
How to evaluate an IP lease before signing
1. Start with the workload
Define what the addresses will carry. A temporary test environment can be renumbered easily. A customer-facing API, mail system, security platform or ISP network may accumulate dependencies for years. The correct block size and service model follow from that difference.
Consider current use, expected growth, redundancy, locations, customer commitments, email requirements and whether you will announce the prefix from your own ASN.
2. Establish the control chain
Ask where the resource comes from and whether the provider is the holder or an intermediary. Ask who can authorize routing, who can create or change an ROA, who manages reverse DNS, who receives abuse reports and what happens if the commercial relationship changes.
An LOA is useful only when the party issuing it has authority to issue it. BGP can announce reachability, but an accepted route is not by itself proof of ownership or representation. The way data travels across networks makes this separation visible: technical acceptance and institutional authority are different questions.
3. Inspect the block before production
Review the address history before your systems depend on it. Check reputation and blocklists where relevant, expected geolocation, registry information, prior routing, reverse DNS and the status of existing authorization records. Test inbound and outbound connectivity and verify that the intended origin matches the routing and RPKI configuration.
A block can be reachable and still be unsuitable for email, security-sensitive services or a region-specific workload. Finding that out before migration is cheaper than finding it out through customers.
4. Record responsibilities, not just price
The commercial terms should be understandable to the people who will operate the network. Record the prefix, duration, renewal process, notice period, routing responsibilities, RPKI and reverse DNS responsibilities, support path, abuse handling and return process.
Price is one input. The more useful comparison is the complete operational arrangement: what is included, who can act, what evidence is available and how quickly the relationship can be changed.
5. Test continuity before you need it
Before moving critical services, simulate the changes that would matter during a failure. Confirm how a new provider would receive authorization, how routes and ROAs would be updated, how DNS and allowlists would change, and which customers or partners would need notice.
Continuity is not a clause you read after something breaks. It is a capability you test while the network still works.
Why an exit plan is part of the lease
Every lease has a renewal, return or migration moment, even when the contract makes that moment feel distant. During the term, the addresses may become part of application configuration, firewall rules, DNS, customer documentation, partner allowlists, monitoring and reputation systems.
Write the exit sequence before deployment: move services, update DNS, stop announcements, align RPKI and route objects, update reverse DNS, remove old allowlists and verify that legitimate traffic no longer depends on the prefix. A provider that can explain the exit is showing more operational maturity than one that only promises availability.
The deeper lesson: a lease should preserve agency
Leasing can be flexible and commercially sensible. Flexibility disappears when the user cannot verify the resource, cannot transfer the operational relationship and cannot continue when the administrator changes direction.
The stronger design keeps coordination useful while making the gatekeeper replaceable. Control should be provable, records should be portable and the network should remain continuous when a service provider changes. That is why Lu Heng’s work connects infrastructure practice with decentralization: the goal is not to remove coordination, but to prevent a necessary record from becoming an unchallengeable source of power. Note 72 develops the thin coordination layer through uniqueness, portability and continuity.
Questions operators usually ask
Can a business lease public IPv4 addresses?
Yes. A business can receive contractual use of public IPv4 space for a defined period. The important work is to understand the control and routing arrangement around that use.
Do I need an ASN?
Not always. You may need one when you plan to originate the prefix independently through BGP. If the provider routes the addresses through its own network, the operating model may be different. Confirm the model before signing.
Can I lease fewer than 256 addresses?
It depends on how the addresses will be routed. A /24 is commonly used when an organization needs a separately announced IPv4 prefix, while smaller quantities may work inside a provider’s larger aggregate.
Does an IP lease transfer ownership?
Usually it grants defined use for a period rather than permanently transferring the underlying resource relationship. The exact structure depends on the provider, registry records and agreement. Ask who retains each authority and what can be transferred.
What should I do first?
Start by writing down the workload, the control chain and the exit path. Then read Note 2 to see why a functioning record is not the same thing as a legitimate right to command. The technical decision becomes clearer once the authority question is visible.