How to Lease IP Addresses: A Step-by-Step Guide

Leasing IPv4 addresses typically involves more than selecting a subnet and signing an agreement.

A production-ready IPv4 lease may require reputation checks, routing authorization, an appropriate origin ASN, RPKI and ROA coordination, Internet Routing Registry records, reverse DNS configuration, geolocation updates, and a clear renewal process.

 

For businesses running hosting, cloud infrastructure, VPN services, ISP networks, SaaS platforms, email systems, security services, or other Internet-facing infrastructure, these operational details can determine whether an IPv4 block is actually ready to use.

 

 

This guide explains how to lease IP addresses step by step, from identifying your requirements to deploying and maintaining the leased IPv4 space.

 

If you are still evaluating whether leasing is right for your business, including costs, benefits, risks, and leasing versus purchasing, start with our complete guide to leasing IP addresses.

What is IP Address Leasing?

IPv4 leasing allows an organisation to use IPv4 address space for an agreed period without purchasing the addresses permanently.

 

The resource holder retains control of the IPv4 block, while the lessee receives contractual permission to use the addresses under defined conditions.

 

A lease may be appropriate when an organisation needs additional IPv4 capacity but wants to avoid the higher upfront capital requirement associated with purchasing IPv4 addresses.

However, obtaining contractual access to a prefix is only the beginning.

 

The block must also be suitable for the intended workload, properly authorised for routing, operationally deployable, and supported throughout the lease term.

How to Lease IPv4 Addresses in 11 Steps

Step 1: Determine How Many IPv4 Addresses You Need

Start by estimating the amount of IPv4 space required for the deployment.

Common IPv4 block sizes include:

• /24 — 256 IPv4 addresses
• /23 — 512 IPv4 addresses
• /22 — 1,024 IPv4 addresses
• /21 — 2,048 IPv4 addresses
• /20 — 4,096 IPv4 addresses

Do not base the decision only on immediate requirements.

Consider:

• Current infrastructure requirements
• Expected customer growth
• Additional server or network capacity
• Geographic expansion
• Redundancy requirements
• Future services
• Temporary versus long-term demand

Leasing too little space can force another procurement process shortly after deployment. Leasing substantially more than required can create unnecessary recurring costs.

The objective is to obtain enough capacity for the expected lease period while maintaining reasonable flexibility.

Step 2: Define the Technical Use Case

Before requesting IPv4 space, clearly define what the addresses will be used for.

Common use cases include:

• Web hosting
• Cloud infrastructure
• Internet service providers
• Telecommunications
• VPN infrastructure
• SaaS platforms
• Email infrastructure
• Cybersecurity services
• Data centres
• APIs
• AI infrastructure
• Proxy networks
• Enterprise applications

The intended use matters because different workloads have different operational requirements.

For example, email infrastructure may be particularly sensitive to IP reputation and reverse DNS. Hosting environments may require stable routing and accurate geolocation. ISP deployments may require additional routing and registry coordination.

The provider should understand the intended use before assigning a block.

This also gives both parties an opportunity to confirm that the proposed workload complies with the lease agreement and acceptable-use requirements.

For a broader look at why organisations use leased address space, see the benefits of leasing IP addresses for global businesses.

Step 3: Decide How the IPv4 Block Will Be Routed

The next question is how the IPv4 prefix will reach the global Internet.

Some organisations announce leased IPv4 space using their own Autonomous System Number. Others use routing arrangements provided or coordinated by their upstream network.

If your organisation operates its own ASN, the leased prefix may be announced through Border Gateway Protocol, or BGP.

An ASN identifies an autonomous network participating in Internet routing and helps determine which network originates a particular prefix.

If your team is unfamiliar with this part of the process, read our guide to Autonomous System Numbers and how they relate to IPv4 routing.

Before continuing, confirm:

• Which ASN will originate the prefix?
• Which upstream provider will carry the route?
• Whether the block can be announced from your chosen ASN
• Who is responsible for routing changes
• Whether an LOA is required
• Whether a ROA must be created or changed
• Whether an IRR route object is required

Resolving these questions before deployment can prevent routing delays after the lease agreement is already active.

Step 4: Check the IPv4 Block’s Reputation

Not every IPv4 address block has the same history.

A prefix may previously have been used for email, hosting, VPN services, proxy infrastructure, automated traffic, or other workloads. Historical misuse can affect how third-party platforms treat the addresses.

Before accepting an IPv4 block, review its reputation.

Check for:

• Active blocklist listings
• Spam history
• Abuse reports
• Malware-related history
• Proxy or VPN classifications
• Previous routing activity
• Reputation problems affecting your intended use

A block can be technically routable while still being commercially unsuitable.

For example, poor reputation may lead to email filtering, repeated CAPTCHA challenges, restricted API access, customer complaints, or delays while reputation records are corrected.

This is why the lowest advertised IPv4 lease price should not be the only selection criterion.

Ask the provider:

• Was the entire prefix checked?
• When was the block last used?
• Are there active reputation issues?
• Who handles pre-existing reputation problems?
• Is replacement space available if a serious issue is discovered?
• Is reputation monitored after deployment?

For production workloads, reputation assessment should happen before traffic is migrated, not after problems appear.

Step 5: Verify the IPv4 Source and Provider

Before signing an agreement, determine who actually controls the resource and who can perform the administrative actions required during the lease.

An IPv4 leasing arrangement may involve a registered resource holder, an asset manager, a marketplace, a broker, a reseller, or several parties.

Multiple parties are not automatically a problem. The risk appears when authority and responsibility are unclear.

Ask who can directly control or coordinate:

• The IPv4 resource
• Registry information
• Routing authorization
• LOA issuance
• RPKI and ROA changes
• IRR route objects
• Reverse DNS
• Abuse complaints
• Renewal
• Replacement space
• Emergency escalation

This matters because the company sending the invoice may not always be the party capable of making an urgent routing or registry change.

For business-critical infrastructure, clear operational accountability is often more important than a small difference in monthly price.

Step 6: Review and Sign the IPv4 Lease Agreement

Once the block and provider have passed technical and commercial checks, review the lease agreement carefully.

The agreement should clearly identify:

• IPv4 prefix or prefixes
• Lease start date
• Lease duration
• Monthly or annual pricing
• Billing schedule
• Permitted use
• Prohibited use
• Abuse-management responsibilities
• Routing responsibilities
• Renewal conditions
• Price changes at renewal
• Termination conditions
• Notice periods
• Replacement conditions
• Liability
• Escalation procedures

Pay particular attention to renewal and termination.

If a production environment becomes dependent on the addresses, an unclear renewal process can create significant migration risk later.

Our detailed guide to key clauses every IPv4 lease contract should include explains the contractual issues in more depth.

Step 7: Obtain the Letter of Authorization

For many routed IPv4 deployments, a Letter of Authorization, or LOA, is used to document permission for a network to announce the prefix.

The LOA typically identifies relevant information such as:

• The IPv4 prefix
• The authorised ASN
• The organisation granting authorization
• The organisation receiving authorization
• The scope of the permission
• Relevant dates or terms

An LOA should come from a party with the authority to grant the routing permission.

Do not treat receiving an LOA as proof that every other routing requirement has automatically been completed.

The LOA is one component of deployment. RPKI, ROAs, IRR objects, upstream filtering, and actual BGP configuration may also need to be addressed.

Step 8: Configure ROA, RPKI and IRR Routing Records

Routing authorization is one of the most important technical stages of IPv4 leasing.

Route Origin Authorization

A Route Origin Authorization, or ROA, specifies which ASN is authorised to originate a particular IP prefix.

ARIN describes a ROA as a cryptographically signed object that identifies the authorised origin ASN and prefix.

Network teams that want the technical definition can review ARIN’s official Route Origin Authorization documentation.

APNIC also provides an overview of RPKI, ROAs and Route Origin Validation.

Before announcing the leased block, confirm:

• The correct origin ASN
• The correct IPv4 prefix
• The appropriate maximum prefix length
• Who controls the RPKI certificate
• Who can modify the ROA
• How quickly an incorrect ROA can be corrected

An incorrect ROA can cause an otherwise legitimate announcement to become RPKI-invalid.

Networks that perform Route Origin Validation may reject or treat invalid routes differently, which can lead to partial reachability.

IRR Route Objects

An Internet Routing Registry route object associates a prefix with the ASN expected to originate it.

Some network operators use IRR data when building routing filters.

RIPE NCC documents route and route6 objects as part of its Internet Routing Registry database. Technical teams can refer to the RIPE Database documentation for routing objects.

Before deployment, the routing information across the lease documentation, ROA, IRR records, and BGP announcement should be consistent.

Step 9: Announce and Test the IPv4 Block

Once authorization is ready, the network team can begin announcing the prefix.

Do not immediately migrate critical production traffic.

First verify:

• BGP announcement visibility
• Origin ASN
• Route propagation
• RPKI status
• Upstream acceptance
• Global reachability
• Firewall configuration
• Access control lists
• Monitoring systems
• Partner allowlists

Test reachability from multiple networks and geographic locations where possible.

A prefix appearing in your local routing table does not necessarily mean that every part of the Internet can reach it correctly.

For important infrastructure, a staged deployment is safer than moving every workload at once.

Step 10: Configure Reverse DNS and Geolocation

Once the IPv4 block is routing correctly, configure the supporting operational records.

Reverse DNS

Reverse DNS maps an IP address back to a hostname through a PTR record.

This can be important for:

• Email infrastructure
• Hosting
• Network diagnostics
• Logging
• Security investigations
• Customer environments

Before leasing, establish whether reverse DNS will be delegated to you or managed by the provider.

Our guide to reverse DNS and PTR records for leased IPv4 explains the subject in more detail.

Geolocation

Newly deployed leased IPv4 space may initially appear in the wrong city, region, or country in third-party databases.

If location matters to the workload, verify:

• Existing geolocation
• Geofeed availability
• Registry information
• Who manages geolocation updates
• Whether major geolocation providers need to be contacted

Different databases update at different speeds, so geolocation changes may not appear everywhere at the same time.

Step 11: Monitor the Block and Plan for Renewal

IPv4 leasing does not end when deployment is complete.

Once the addresses support live infrastructure, monitor:

• IP reputation
• Routing visibility
• RPKI validity
• Abuse reports
• Reverse DNS
• Geolocation
• Provider communications
• Lease expiry
• Renewal deadlines

The longer a business uses an IPv4 block, the more operational dependencies may become attached to it.

These can include:

• DNS records
• Customer allowlists
• Firewall policies
• APIs
• Mail systems
• VPN configurations
• Monitoring tools
• Security rules
• Partner integrations
• Application configurations

That makes renewal planning important.

Do not wait until the final weeks of the lease to ask whether the addresses will remain available.

Confirm the renewal process early and identify a migration or replacement strategy in case circumstances change.

Our analysis of IPv4 renewal risk and continuity explains why reliable access over time can become more important than initial delivery.

How Long Does It Take to Lease IPv4 Addresses?

The commercial agreement may be completed relatively quickly, but production readiness depends on several factors.

Deployment time can be affected by:

• Provider due diligence
• Contract review
• Payment
• LOA issuance
• Origin ASN confirmation
• ROA creation or modification
• IRR updates
• Upstream routing policies
• Reverse DNS delegation
• Geolocation requirements
• Security configuration
• Internal change-control processes

Simple deployments may move quickly when routing and authorization are already prepared.

More complex environments can take longer, especially when several organisations must coordinate registry, routing, security, or application changes.

For that reason, businesses should distinguish between:

“The IPv4 lease has been signed”

and

“The IPv4 block is production-ready.”

They are not always the same milestone.

IPv4 Leasing Checklist

Before moving production traffic to a leased IPv4 block, confirm the following:

 

FAQs