What should you check before leasing an IPv4 block in 2026?

IPv4 leasing can be faster and less capital-intensive than purchasing address space, but receiving an LOA does not necessarily mean that a prefix is ready for production use.

Before leasing and announcing a block, a network operator should verify several separate areas.

1. Confirm who controls the resource

Check the relevant RIR database and confirm that the lessor is the registered holder or is authorised to act for that holder.

An organisation offering a prefix should also be able to make or coordinate the necessary registry, routing, and RPKI changes.

2. Review the routing history

Check whether the prefix:

• is currently being announced;
• was recently originated by another ASN;
• has conflicting route objects;
• is covered by an existing ROA;
• has shown unexpected origin-AS changes.

A previous announcement is not automatically a problem, but the old configuration should be understood and cleared before activation.

3. Check reputation for the intended use

There is no single authoritative “clean IP” status.

A block may be acceptable for general hosting but unsuitable for email or another reputation-sensitive service. It is worth checking major blocklists, historical abuse data, security classifications, geolocation databases, and previous DNS or routing activity.

Also ask what happens if a serious pre-existing reputation issue is discovered after activation.

4. Verify the LOA

The Letter of Authorization should contain:

• the correct prefix;
• the intended origin ASN;
• the resource holder’s details;
• the authorised party;
• an appropriate validity period;
• a verifiable signature or issuance method.

An LOA alone does not resolve incorrect registry records, conflicting IRR objects, or an invalid ROA.

5. Check the route object and RPKI status

Many networks still use IRR data to create filters, while an incorrect ROA can cause an otherwise legitimate announcement to become RPKI-invalid.

Before announcing the prefix, verify that:

• the route object references the intended origin ASN;
• obsolete route objects have been reviewed;
• the ROA authorises the correct ASN;
• the maximum prefix length is appropriate;
• the route will be RPKI-valid.

6. Confirm reverse DNS and geolocation arrangements

Ask who controls reverse-DNS delegation and how changes are requested.

For geolocation, remember that databases may disagree, particularly after a prefix changes users or routing locations. A geofeed and direct correction requests may help, but updates are not always immediate.

7. Understand abuse responsibilities

The contract should clearly define:

• permitted and prohibited uses;
• who receives abuse reports;
• required response times;
• suspension conditions;
• replacement procedures;
• what happens when the lease ends.

The exit process matters as much as activation. Both parties should know when the route, ROA, reverse DNS, and customer assignments must be removed.

8. Validate the announcement externally

After activation, do not rely only on the local router.

Check external route collectors and confirm that:

• the prefix is visible internationally;
• the origin ASN is correct;
• the route is RPKI-valid;
• no unauthorised ASN is announcing the same space;
• upstream filtering is not limiting propagation.

In practice, leasing IPv4 space is not only a commercial transaction. It is a combination of resource verification, registry administration, routing authorisation, reputation review, and ongoing operational responsibility.

What checks or tools do you consider essential before accepting a leased prefix?

Disclosure: I work with InterLIR Global, an IPv4 marketplace. I prepared a longer step-by-step guide covering block selection, RIPE and ARIN records, LOAs, RPKI, BGP activation, and reputation checks: https://interlir.global/blog/how-to-lease-ipv4-address-blocks-2026/