Leasing IPv4 space can solve an urgent capacity problem quickly. It allows a network to deploy public services, add hosting inventory, support subscribers, or enter a new market without purchasing an address block. Yet the handover of a prefix is only the beginning. If the space has a poor reputation, lacks valid routing authorization, cannot support reverse DNS, or disappears at renewal, the apparent solution can become an operational incident.
That is why a sound procurement process evaluates the service around the addresses as carefully as the addresses themselves. The right checks are neither exotic nor prohibitively slow. They simply need to happen before the prefix reaches production and before customers begin to depend on it.
Start by identifying the leasing model
The term IP leasing covers several arrangements. A dedicated block gives one customer exclusive use during the term, while a shared environment places multiple customers or services behind common public addressing. Separately, the supplier may provide the resource directly or a broker may connect the customer to another resource holder. These dimensions affect control, escalation, and the evidence you should request.
A dedicated block is usually the relevant option when a company needs its own routing, stable allowlists, distinct reputation, or predictable customer-facing identity. Shared addressing may be adequate for workloads that do not need those controls. A broker can help locate inventory, but the customer should still know who can authorize the route, update records, respond to abuse reports, and ensure continued use of the prefix.
The seven checks that prevent most surprises
1. Verify authority over the exact prefix
Ask for evidence connecting the provider to the specific address range, not merely evidence that the provider operates in the market. Review the relevant Regional Internet Registry record and understand who is authorized to approve your use. If several parties are involved, map the resource holder, commercial counterparty, technical operator, and escalation contact. Ambiguity between those roles is a warning sign because incidents rarely respect organizational boundaries.
2. Review routing history and current authorization
A usable prefix must be accepted by the networks that carry your traffic. Confirm how the block will be announced: from your Autonomous System Number, by the provider, or through a hosting or transit partner. When you originate the prefix, align the Letter of Authorization, Route Origin Authorization, Internet Routing Registry objects, and router configuration. A mismatch can lead to route rejection or an RPKI-invalid state even when the commercial agreement is valid.
For additional background, LARUS provides an RPKI and ROA guide, while RFC 9582 defines the current technical profile for ROAs.
Historical routing data can also reveal unexpected origin changes, long periods of inactivity, or patterns worth discussing with the provider. History is not automatically disqualifying, but unexplained history should not be ignored.
3. Test reputation against the intended workload
“Clean” is not a universal status. Different blocklists, fraud systems, content platforms, and security vendors use different data and policies. An address range suitable for a general web service may still face friction in email delivery, payment processing, account creation, or advertising systems. Check the prefix against the services that matter to your application and ask how the provider handles remediation if stale or incorrect reputation data appears.
Run these checks before deployment and keep a dated record. Reputation can change, so build monitoring and abuse-response responsibilities into normal operations rather than treating the initial screening as permanent assurance.
4. Confirm reverse DNS and geolocation support
Many applications rely on PTR records or on the ability to delegate reverse DNS. Email infrastructure is the obvious example, but logging, security controls, customer diagnostics, and network identification may also depend on it. Establish who can create or delegate reverse zones, how changes are requested, and how quickly they are implemented.
IP geolocation is maintained across multiple third-party databases and may lag behind a new deployment. If location affects content, fraud controls, licensing, or customer experience, ask what correction process is available. Do not assume a registry record alone will update every commercial geolocation provider.
5. Match the block size to routing and growth
Address count is not the only sizing question. A /24 contains 256 addresses and is a common unit for independently routed IPv4 capacity, but route acceptance policies, topology, reserve capacity, and subnet design all matter. Estimate near-term utilization, customer growth, infrastructure overhead, and the operational impact of adding another block later. Over-sizing wastes budget; under-sizing can force a second migration sooner than expected.
6. Put operational support in writing
A production prefix will eventually generate a support event: a routing change, an authorization update, a reputation complaint, an abuse report, or a reverse-DNS request. The contract and handover should identify the correct contact for each issue, expected response windows, and escalation paths. “Support included” is too vague when customers are waiting for service restoration.
| Before launch, know exactly who can change the route, who can change the records, and who answers when either is wrong. |
7. Treat renewal as a continuity control
An address becomes more valuable to the user as customers allowlist it, integrations reference it, and operational knowledge accumulates around it. That creates switching cost. Review the initial term, renewal mechanism, pricing process, notice period, provider termination rights, and the assistance available if the relationship ends. Critical workloads need enough lead time to source replacement space, update routing, notify partners, and complete a controlled renumbering project.
Build a pre-production acceptance test
Documents establish intent; testing establishes whether the deployment works. The broader IPv4 leasing process provides context for the handover. Create a repeatable acceptance checklist and require a pass before customer traffic is moved.
- Confirm the assigned prefix and origin ASN match the approved deployment plan.
- Validate route visibility from multiple external networks and check RPKI status.
- Test forward and reverse DNS, including delegation where applicable.
- Check representative addresses in the reputation and security systems relevant to the workload.
- Verify inbound and outbound connectivity, latency, path stability, and application behavior.
- Confirm geolocation results in the markets where location affects the service.
- Exercise the support channel with a low-risk request and record the escalation path.
Keep the results with the contract and technical handover. If a dispute later arises about the initial state of the block, dated acceptance evidence is far more useful than memory.
Red flags worth pausing for
- The seller will not identify who controls or authorizes use of the specific prefix.
- The price is clear, but routing, RPKI, reverse DNS, or support responsibilities are not.
- The provider promises universally “clean” addresses without defining the checks or remediation process.
- The origin ASN or route objects cannot be aligned before the agreed start date.
- Renewal terms are missing even though the workload is expected to be long-lived.
- There is no operational contact beyond the person who closed the sale.
Manage the lease as part of the network
Once deployed, leased space should enter the same control system as other critical infrastructure. Track the prefix, owner or provider, origin ASN, route authorization, DNS delegation, service contacts, contract dates, notice deadline, and the applications that depend on it. Monitor route state and reputation, and review renewal well before the contractual deadline.
This turns leasing from a one-time procurement event into a managed service lifecycle. It also makes future decisions easier: the organization can see which blocks are heavily integrated, which are temporary, and where concentration with one provider creates avoidable risk.
A safer way to add capacity
IPv4 leasing can be a practical route to capacity, but the value lies in dependable use rather than nominal access to a list of addresses. Verify authority, routing, reputation, operational support, and renewal before deployment. Then test the prefix and manage it with the same discipline applied to transit, cloud infrastructure, and customer-facing systems.
A careful process does not slow expansion. It prevents a rushed capacity decision from becoming a routing incident, a reputation problem, or an emergency renumbering project later.
