Step-by-step guide to lease IP addresses safely
From choosing an IPv4 block to testing, operating and leaving a lease: practical steps that connect usable addresses to long-term continuity.
Imagine you are about to launch an online service. You have the servers and the software; now you need public IPv4 addresses so other networks can reach it. A lease gives you agreed use of addresses for a period. Turning that agreement into a dependable service is the work this guide explains.
Start with one question: what needs to be true before customers depend on these addresses? The answer takes you from choosing a block to testing it, operating it and eventually moving on.
1. Describe the service before choosing the block
Write down what the addresses will support, where the service will run and who will operate the network. A “prefix” is a group of addresses described together: a /24 contains 256 address values, while a /23 contains 512. Those counts are not automatically the number of customers or servers you can support; the network design determines that.
For example, a small hosting service might need addresses for customer-facing servers, management and growth. Its network team can turn that service plan into an address requirement. Choosing a /24 merely because it is a familiar size skips that useful conversation.
2. Find out who provides what
A holder, hosting company or specialist provider may offer a lease, sometimes through an intermediary. A Regional Internet Registry maintains number-resource records and related services. Its allocation and transfer processes are different from buying a commercial lease.
Ask the provider to explain the actual operating arrangement. Will traffic reach the addresses through its network, or will your own network announce the prefix? Who can authorise that announcement? Who maintains the registration information, reverse DNS and technical contacts? Reverse DNS is the record that associates an address with a hostname.
A letter of authorisation can document an intended routing arrangement. It is one piece of evidence to check against the parties and records involved; a letter alone does not establish the entire history of a block or prove that your service will work.
3. Check the proposed addresses for your workload
Review the specific block before activation. Check registration details, recent routing history and any reputation information relevant to your service. For email, that includes the blocklists and delivery requirements that matter to your recipients. For a web service, test the destinations and access paths your customers will use.
There is no single “clean” label that establishes suitability for every use. A result from one reputation service is an observation, not a universal verdict. Agree who investigates a problem and how that person can be reached.
4. Test the route before putting customers on it
The network operator should confirm that the intended prefix is announced by the intended network and is reachable from relevant external networks. BGP is the protocol networks use to announce how traffic can reach them. An Autonomous System Number, or ASN, identifies a network in that process.
A Route Origin Authorisation, or ROA, records which ASN is authorised to originate a prefix. RPKI origin validation checks the announced origin against such records. It does not validate the entire path or guarantee that every network will accept a route; the BGP origin-validation specification explains this distinction.
Test the service itself too: DNS, application access, monitoring and any partner allowlists. Start with a controlled deployment and verify results before expanding. A successful payment or a delivered spreadsheet is not the same as working connectivity.
5. Make ongoing responsibility visible
Keep a short operating record: the prefix, the services using it, the relevant registry and routing contacts, the renewal date and the person responsible for each change. Decide how faults and abuse reports reach someone who can act.
If a reputation alert appears, establish what it means and whether it affects the service before deciding how to respond. Automatically withdrawing a live block can turn a limited issue into an outage. The response should follow the actual incident and the people affected.
6. Rehearse how you would leave
Picture the end of the arrangement while you still have time to prepare. Which DNS records, firewall rules, customer allowlists and partner systems depend on these addresses? Which changes need another organisation’s help? Test a replacement path, arrange the necessary overlap and verify customer access before retiring the old route.
A plan to change providers does not automatically mean you can take leased addresses with you. Establish what can remain, what must move and who will perform the work. The useful measure is whether the service can continue through the change.
Why this is also a question of power
Lu Heng’s Note 66 argues that the real test of an IPv4 intermediary comes after the transaction: can it manage the registry relationship and sustain the resource’s use when that relationship comes under pressure?
That shifts attention from paperwork to control. The party maintaining a record can affect a running network, yet the operator may have little ability to replace that administrator. Lu Heng’s proposed direction is accurate, verifiable coordination with continuity, portability and a meaningful way to leave, developed further in Note 72.
The reason to examine this now is simple: dependencies accumulate. Before an address is embedded in customer systems, you have more choices. A careful first deployment makes those choices visible while they are still practical.