Leasing a /22 IPv4 Block: What You Need to Prepare

Leasing a /22 IPv4 block can provide a practical way to add 1,024 IPv4 addresses without purchasing the address space outright.

For hosting providers, ISPs, SaaS platforms, data centres, cloud infrastructure and enterprise networks, a /22 can provide enough capacity to support meaningful growth while remaining operationally manageable.

But receiving a /22 is only the beginning.

Before deploying the block into production, an organisation should understand:

• how the prefix will be routed;
• whether its own ASN will be used;
• whether an LOA is required;
• who can create or update RPKI ROAs;
• how IRR records will be managed;
• whether reverse DNS is available;
• what reputation the addresses already have;
• how abuse reports will be handled;
• how the /22 will be subnetted internally;
• what happens at renewal or termination; and
• how continuity will be protected if infrastructure changes.

A /22 IPv4 lease should be treated as an infrastructure deployment, not simply the delivery of 1,024 addresses.

Leasing a /22 IPv4 Block: Quick Answer

A /22 IPv4 block contains 1,024 IPv4 addresses and can be divided into four /24 networks.

Before leasing one, prepare:

1. your required prefix size and utilisation plan;
2. BGP and upstream routing arrangements;
3. ASN and LOA requirements;
4. RPKI Route Origin Authorisation;
5. IRR route objects;
6. reverse DNS requirements;
7. IP reputation checks;
8. IPAM and subnet allocation;
9. abuse-management procedures;
10. contract, renewal and termination terms; and
11. a continuity and migration plan.

The most important question is not simply:

“Can the provider supply a /22?”

It is:

“Can this /22 be routed, authorised, operated and maintained reliably throughout the period we depend on it?”

What Is a /22 IPv4 Block?

IPv4 address blocks are represented using CIDR notation.

A /22 prefix contains:

• 1,024 total IPv4 addresses;
• four contiguous /24 networks;
• two /23 networks; or
• smaller subnets depending on the internal addressing design.

A /22 can therefore offer useful flexibility.

An operator might use individual /24s for:

• different customer groups;
• different data centres;
• different services;
• regional infrastructure;
• hosting clusters;
• VPN services;
• application infrastructure; or
• separate reputation-sensitive workloads.

Why Lease a /22 Instead of Buying It?

Buying and leasing address space solve different business problems.

Leasing can be attractive when an organisation:

• needs additional IPv4 capacity quickly;
• wants to avoid a large upfront acquisition cost;
• needs the addresses for a defined project or growth period;
• wants operational flexibility;
• is uncertain about long-term IPv4 demand;
• expects future infrastructure changes; or
• wants to preserve capital for other network investments.

Buying may be more suitable when:

• the organisation expects very long-term demand;
• it wants a direct long-term resource relationship;
• capital expenditure is acceptable;
• the block will form part of permanent network infrastructure; or
• the organisation prefers to carry more of the registry and operational responsibility itself.

Neither structure is universally superior.

The decision should depend on cost, expected duration, continuity requirements and the organisation's operational capabilities.

1. Confirm That a /22 Is Actually the Right Size

Before leasing 1,024 addresses, estimate how many addresses the network genuinely needs.

Consider:

• current utilisation;
• expected customer growth;
• server deployment;
• network appliances;
• public-facing services;
• NAT architecture;
• redundancy;
• future products;
• geographic expansion; and
• address reserves.

Leasing substantially more capacity than required can create unnecessary cost.

Leasing too little may require another routing and infrastructure change shortly afterwards.

Select the prefix size based on expected operational demand, not simply because the block is available.

2. Decide How You Will Route the /22

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

Common arrangements include:

• the customer originates the prefix from its own ASN;
• an upstream network originates it on behalf of the customer;
• a hosting or connectivity provider handles routing;
• the block is used through a supported BYOIP model; or
• another agreed routing arrangement is used.

Therefore, leasing a /22 does not always require the lessee to operate its own ASN.

However, organisations seeking greater routing independence often use their own ASN and originate the prefix through one or more upstream providers.

Do You Need an ASN to Lease a /22?

Not necessarily.

You need an appropriate routing arrangement, but the ASN used to originate the prefix does not always need to belong directly to the lessee.

The appropriate model depends on:

• your upstream provider;
• network architecture;
• whether you are multihomed;
• whether you require provider independence;
• the leasing provider's technical model; and
• the intended deployment.

If you operate your own BGP network, using your own ASN can provide additional control over:

• upstream selection;
• routing policy;
• traffic engineering;
• multihoming;
• network migration; and
• provider independence.

3. Decide Whether to Announce the /22 or Individual /24s

A /22 can be advertised as one aggregate route, or a network may have operational reasons to advertise individual /24s in addition to or instead of the aggregate, subject to routing policy and upstream support.

For example:

• 203.0.112.0/22as the aggregate;
• 203.0.112.0/24;
• 203.0.113.0/24;
• 203.0.114.0/24; and
• 203.0.115.0/24.

Operators might advertise /24s separately for:

• traffic engineering;
• different locations;
• different upstreams;
• customer segmentation;
• DDoS mitigation; or
• network migration.

But additional announcements increase routing complexity.

Route design should therefore be deliberate rather than automatically deaggregating every /22 into four /24s.

4. Confirm Whether You Need an LOA

An upstream provider may request a Letter of Authorisation, commonly called an LOA, before accepting a leased prefix announcement.

An LOA can help document that the relevant party authorises a network to originate or use the prefix under the agreed arrangement.

Before signing the lease, ask:

• Will an LOA be provided?
• Which ASN will it authorise?
• How quickly can a new LOA be issued?
• What happens if the origin ASN changes?
• Does the upstream require a particular format?
• What happens to the LOA at lease termination?

An LOA is useful operational documentation, but it is not a substitute for RPKI, IRR or the underlying commercial agreement.

5. Prepare RPKI Before Production Deployment

RPKI should be part of the deployment plan whenever the relevant resource framework supports it.

A Route Origin Authorisation, or ROA, specifies which ASN is authorised within the RPKI system to originate routes for a prefix.

If the leased /22 will originate from your ASN, the provider should be able to explain:

• who can create the ROA;
• which ASN will be authorised;
• which prefixes will be covered;
• what maximum prefix length will be configured;
• how quickly the ROA can be changed;
• what happens during an ASN migration; and
• how obsolete authorisation will be removed at the end of the lease.

RPKI for a /22 With /24 Announcements

Prefix length requires particular attention.

If the network intends to advertise only the /22, the ROA can be designed around that routing plan.

If the network legitimately needs to advertise /24 more-specifics, the RPKI configuration must also permit those intended announcements.

Otherwise, a legitimate /24 announcement could become RPKI Invalid.

However, operators should not automatically use an unnecessarily broadmaxLengthsimply for convenience.

RPKI authorization should match the routes the network genuinely intends to originate.

For more detail, read The Role of IP Address Prefixes in RPKI .

RPKI Does Not Prove Ownership of the /22

RPKI terminology should be used carefully.

A ROA provides cryptographically verifiable information relevant to route-origin authorisation.

It should not be described as proof of conventional property ownership.

A useful separation is:

commercial rights → registry state → routing authorisation → operational use

Leasing creates a commercial right to use the addresses under the relevant agreement.

Registry information describes an important administrative state.

RPKI addresses route-origin authorisation.

BGP and the customer's infrastructure determine operational routing.

6. Check IRR Route Objects

Internet Routing Registry records remain important because many networks use IRR information when constructing routing filters.

Before deploying the /22, determine:

• which IRR database will contain the route object;
• which origin ASN will be listed;
• who can create the object;
• who controls the relevant maintainer;
• whether individual /24 route objects are required;
• how quickly changes can be implemented; and
• how stale objects are removed after termination.

The intended BGP, RPKI and IRR states should agree.

BGP + RPKI + IRR should describe the same intended routing relationship.

For more detail, read What Is an IRR Route Object? .

7. Verify the IPv4 Block's Reputation Before Leasing

A /22 provides substantial address capacity, but it can also carry operational history from previous use.

Before signing the lease, check whether the addresses have been associated with:

• spam;
• malware;
• phishing;
• open proxies;
• botnet activity;
• hosting abuse;
• fraud;
• email blocklists;
• proxy or VPN classifications; or
• other negative security signals.

Reputation is not one universal score.

Different providers maintain different datasets and update them independently.

Therefore, avoid relying solely on a provider's claim that the range is a “clean /22.”

A clean IPv4 block should mean that relevant reputation signals have been reviewed for the intended use, not that every third-party system is guaranteed to treat every address positively forever.

Check Reputation at the /24 Level, Not Only the /22

Reputation inside a /22 may not be uniform.

One /24 may have different historical use from another /24 within the same aggregate.

A useful review therefore considers:

• the complete /22;
• each individual /24;
• selected individual IP addresses where relevant;
• historical BGP origins;
• reverse DNS history;
• blocklist exposure; and
• geolocation classifications.

This is especially important when different /24s will serve different customer groups or workloads.

For a complete due-diligence framework, read How to Check IP Reputation Before You Buy IPv4 Addresses .

8. Determine Whether Reverse DNS Is Required

Reverse DNS is important for many workloads, but its importance depends on how the addresses will be used.

It is particularly important for:

• email infrastructure;
• some security systems;
• network diagnostics;
• logging;
• customer requirements; and
• services that expect meaningful PTR records.

Before leasing the /22, ask:

• Is reverse DNS delegation available?
• Can we manage PTR records directly?
• Does the provider make changes on request?
• What is the expected update time?
• Can separate /24s be delegated appropriately?
• What happens to PTR records when the lease ends?

A hosting platform running web servers may have different rDNS requirements from an email provider.

Therefore, reverse DNS should be matched to the workload rather than treated as an identical requirement for every deployment.

9. Plan the /22 in Your IPAM System

A /22 is large enough that informal spreadsheets quickly become difficult to manage.

An IP Address Management system can help track:

• allocated addresses;
• available addresses;
• customers;
• servers;
• subnets;
• locations;
• DNS records;
• services;
• assignment dates;
• reputation-sensitive workloads; and
• future capacity.

A simple /22 plan might look like:

The actual structure should follow your own network requirements.

10. Understand the Registry Relationship

Regional Internet Registries maintain important Internet number-resource registration information.

But it is inaccurate to describe those databases simply as universal property registers showing the legal owner of every IP address.

When leasing a /22, determine:

• which registry maintains the relevant resource record;
• which organisation carries the underlying resource relationship;
• who carries registry-facing responsibility;
• how RPKI is administered;
• how reverse DNS is administered;
• whether operational contacts can be represented where appropriate; and
• what happens if the provider's resource relationship changes.

Registry state matters, but registry state, commercial rights and network operation remain distinct layers.

11. Understand What Rights the Lease Actually Provides

Avoid reducing the relationship to:

“The provider owns the IP addresses and the customer has no control.”

That framing is too simplistic.

A better analysis asks:

• What contractual right to use the /22 does the customer receive?
• Who carries the underlying resource relationship?
• Who controls BGP?
• Can the customer use its own ASN?
• Who controls RPKI changes?
• Who manages IRR?
• Who manages reverse DNS?
• Can the prefix move between upstream providers?
• What happens at renewal?
• What happens at termination?

These questions tell the customer much more about practical control and continuity than an ownership label alone.

12. Confirm That Your Routing Is Provider-Neutral Enough for Your Needs

A production /22 may eventually become deeply embedded in the organisation's infrastructure.

Before that happens, determine whether use of the addresses is tied unnecessarily to:

• one data centre;
• one hosting provider;
• one transit provider;
• one cloud platform; or
• one routing architecture.

Where supported, the ability to use the same prefix with your own ASN and move between upstream networks can improve operational flexibility.

Provider-neutral continuity becomes more valuable as the cost of renumbering increases.

13. Evaluate Abuse-Management Responsibilities

A /22 can support hundreds or thousands of systems, making abuse management an important operational responsibility.

Potential incidents include:

• spam;
• malware;
• phishing;
• botnets;
• open proxies;
• credential attacks;
• copyright complaints;
• scanning;
• fraud; and
• other prohibited activity.

Before deployment, determine:

• who receives abuse reports;
• how quickly complaints must be handled;
• who communicates with external reporters;
• what evidence is required;
• what activity violates the lease;
• when individual IPs may be suspended;
• when the entire service could be terminated; and
• how false or disputed complaints are handled.

The lessee should also operate appropriate monitoring and incident-response procedures.

14. Review the Lease Contract Carefully

The contract determines much of the commercial relationship.

Important terms include:

• exact prefix or capacity;
• lease term;
• price;
• billing cycle;
• renewal process;
• notice periods;
• permitted use;
• prohibited use;
• BGP responsibility;
• ASN changes;
• LOA support;
• RPKI support;
• IRR support;
• reverse DNS;
• abuse management;
• reputation issues;
• termination conditions;
• migration period;
• service interruption procedures; and
• dispute resolution.

A low monthly price does not compensate for unclear operational responsibility.

15. Understand Renewal Risk Without Overstating It

Renewal matters, particularly when a /22 has become part of long-running production infrastructure.

But renewal is not the only continuity risk.

Other risks include:

• upstream provider changes;
• routing errors;
• RPKI misconfiguration;
• IRR problems;
• reputation deterioration;
• contractual disputes;
• infrastructure migration;
• provider failure; and
• unexpected operational dependencies.

A good lease therefore asks not only:

“Can we renew?”

but:

“What could interrupt continued use of this /22, and who is responsible for each dependency?”

16. Prepare for Lease Termination Before Deployment

Every lease will eventually renew, change or end.

The termination plan should be understood before applications and customers become dependent on the addresses.

Plan for:

• BGP withdrawal;
• ROA changes;
• IRR cleanup;
• reverse DNS removal;
• customer migration;
• DNS changes;
• firewall changes;
• allowlist updates;
• geolocation changes;
• reputation review; and
• final confirmation that traffic has moved away.

17. Consider Whether the /22 Could Become Part of Your Network Identity

A leased /22 may initially feel replaceable.

Over time, however, its addresses can appear in:

• customer allowlists;
• banking systems;
• payment platforms;
• APIs;
• VPN peers;
• firewalls;
• security platforms;
• partner networks;
• monitoring systems; and
• compliance documentation.

At that point, replacing the block may require much more than updating BGP.

An IPv4 prefix can become part of business network identity when third parties begin depending on it.

For production workloads, continuity should therefore be evaluated before the addresses become difficult to replace.

Read: Can Your Business Survive Losing Its IP Addresses? .

18. Compare the Total Cost of Leasing With Buying

Leasing usually reduces the initial capital requirement, but the total economic comparison depends on time.

Consider:

• monthly or annual lease rate;
• expected lease duration;
• setup fees;
• support fees;
• routing requirements;
• internal operating costs;
• reputation remediation;
• future market pricing;
• the cost of acquiring IPv4; and
• the strategic value of direct long-term control.

There is no fixed number of years after which buying automatically becomes cheaper.

Market pricing, lease rates and capital costs all change over time.

For current pricing information, see Global IPv4 Pricing & Market Statistics .

19. Use IPv6 Alongside IPv4 Planning

Leasing IPv4 should not prevent an organisation from deploying IPv6.

IPv6 provides a vastly larger address space and is the long-term architectural response to IPv4 scarcity.

However, many businesses continue to require IPv4 compatibility because customers, applications and external services do not operate in an IPv6-only environment.

A practical strategy may therefore involve:

• dual-stack deployment;
• continued IPv4 capacity for compatibility;
• IPv6-first deployment where practical;
• reducing unnecessary IPv4 consumption; and
• periodically reviewing future IPv4 requirements.

A /22 lease can therefore serve as one component of a broader transition strategy, rather than an alternative to IPv6.

20. Test Everything Before Moving Production Traffic

Before putting customers or critical workloads onto the /22, perform a deployment validation.

Check:

• BGP visibility;
• expected origin ASN;
• RPKI validation state;
• IRR objects;
• upstream route acceptance;
• reverse DNS;
• forward DNS where relevant;
• geolocation;
• major reputation systems;
• incoming connectivity;
• outgoing connectivity;
• latency and path quality; and
• monitoring and alerting.

Do not make the first production packet your first test of the leased prefix.

/22 IPv4 Lease Deployment Checklist

Red Flags Before Leasing a /22 IPv4 Block

Consider additional due diligence if:

• the provider cannot explain the underlying resource relationship;
• RPKI support is unclear;
• the provider cannot produce an LOA when your upstream requires one;
• IRR responsibility is unknown;
• reverse DNS requirements cannot be supported;
• the /22 has significant unexplained current abuse;
• different /24s have serious reputation problems;
• renewal terms are unclear;
• termination can occur without a realistic migration period;
• the provider cannot explain how ASN changes are handled;
• there are unidentified upstream intermediaries; or
• no party is clearly responsible when an operational issue occurs.

None of these points automatically proves that a provider is unsuitable.

They are reasons to understand the dependency before moving production workloads onto the prefix.

What to Ask an IPv4 Leasing Provider

Before leasing a /22, ask the provider:

1. Is the /22 dedicated to our organisation during the lease?
2. Can we announce it from our own ASN?
3. Can we change upstream providers?
4. Will you provide an LOA?
5. Who creates and updates the ROA?
6. Can the ROA support the /24 announcements we need?
7. Who manages IRR route objects?
8. Can we control reverse DNS?
9. Has the reputation of all four /24s been reviewed?
10. How are abuse reports handled?
11. What is the renewal process?
12. How much notice is provided before termination?
13. What happens if we change ASN?
14. What happens if your upstream resource relationship changes?
15. What support is available during a routing incident?

Brokered vs First-Party /22 Leasing

A /22 may be sourced through a broker, marketplace, reseller or first-party provider.

None of these models is automatically unsafe.

The important distinction is responsibility.

Multiple parties do not automatically create risk.

Risk increases when dependencies are invisible and responsibility is unclear.

For a deeper comparison, read IPv4 Broker vs First-Party IP Leasing Provider: What's the Difference? .

How LARUS Approaches /22 IPv4 Leasing

LARUS approaches IPv4 leasing as an infrastructure service, not simply access to a block of addresses.

For production deployments, the relevant requirements can include:

• dedicated IPv4 capacity;
• clear commercial responsibility;
• support for customer routing;
• LOA processes where required;
• RPKI support;
• IRR support;
• reverse DNS;
• reputation awareness;
• abuse management;
• renewal planning; and
• continuity planning.

The objective is not to centralise control of the customer's network.

The customer should continue to control:

• its BGP policy;
• network architecture;
• applications;
• security configuration;
• traffic engineering; and
• infrastructure decisions.

The value of the service is clearer responsibility for the upstream functions associated with delivering stable IPv4 capacity.

Clear accountability should support customer independence, not replace it.

For organisations where a leased /22 may become part of long-term production infrastructure, see LARUS IPv4 Leasing Continuity Assurance .

Frequently Asked Questions

How many IP addresses are in a /22?

An IPv4 /22 contains 1,024 total IPv4 addresses and can be divided into four /24 blocks.

Can a /22 be split into four /24s?

Yes. A /22 contains four contiguous /24 networks. Whether they should be announced individually depends on the network's routing design and upstream policies.

Do I need an ASN to lease a /22?

Not necessarily. The prefix needs an appropriate routing arrangement, but an upstream or service provider may originate it on your behalf. Organisations operating their own BGP infrastructure commonly use their own ASN.

Can I announce a leased /22 from my own ASN?

Yes, if the leasing arrangement, upstream routing and necessary authorisations support it. Confirm LOA, RPKI and IRR requirements before deployment.

Do I need a ROA for a leased /22?

Where RPKI is supported, creating appropriate route-origin authorisation is an important routing-security practice. The ROA should match the intended origin ASN and required prefix lengths.

Does RPKI prove that I own the leased /22?

No. RPKI provides cryptographically verifiable information relevant to route-origin authorisation. It should not be treated as proof of conventional legal ownership.

Can I announce four /24s from a leased /22?

Technically this may be possible when the routing arrangement and upstream policy support it. Ensure the RPKI and IRR configuration also reflects the intended /24 announcements.

Do I need IRR route objects?

They may be important because some upstreams and peers use IRR data to construct routing filters. Ask your providers what they require.

Is reverse DNS required?

It depends on the workload. Reverse DNS is particularly important for email and can also be useful for security, logging and service identification.

How do I know whether a /22 has good reputation?

Review the complete block and its individual /24s across relevant spam, security, abuse, geolocation and routing-history sources. No single reputation database provides a complete answer.

Does a provider “own” the leased /22?

Ownership terminology can oversimplify Internet number-resource relationships. A better approach is to identify the underlying resource relationship, registry state, commercial rights, routing authorisation and operational responsibilities.

Can I change upstream providers while keeping the leased /22?

This depends on the lease and routing model. If provider-neutral use is important, confirm this before the addresses become embedded in production systems.

What happens if I change ASN?

The BGP configuration, RPKI ROA and relevant IRR objects may need to be updated as part of the migration. Plan the sequence carefully so legitimate routes do not become Invalid or unexpectedly filtered.

What happens when the /22 lease ends?

The parties should coordinate BGP withdrawal, RPKI changes, IRR cleanup, reverse DNS changes, application migration and any customer or partner updates.

Is leasing a /22 cheaper than buying?

Leasing generally requires less upfront capital, but long-term economics depend on current lease rates, acquisition prices, duration and operational costs. There is no universal break-even period.

Is a /22 suitable for a hosting provider?

It can be. A /22 provides 1,024 addresses and allows subdivision into four /24s, which can provide useful capacity for hosting environments. The correct size still depends on actual utilisation and growth.

Is IPv4 leasing still relevant if we deploy IPv6?

Yes. IPv6 should be part of long-term network planning, but many applications, customers and external systems continue to require IPv4 compatibility. Dual-stack strategies can therefore remain practical.

Conclusion

Leasing a /22 IPv4 block can provide 1,024 addresses without requiring an outright IPv4 acquisition.

But successful deployment requires more than selecting the block and signing a lease.

A production-ready /22 requires alignment between:

commercial rights + registry state + BGP + RPKI + IRR + reverse DNS + reputation + operational responsibility + continuity

The customer should understand who carries the underlying resource relationship without confusing that relationship with ownership of the customer's network.

RPKI should express the intended route-origin authorisation, not be treated as property proof.

IRR and reverse DNS should support the intended deployment.

Reputation should be checked before production use.

Renewal and termination should be planned before the same addresses become embedded in customers, APIs, firewalls and external systems.

The goal is not simply to lease 1,024 IPv4 addresses. The goal is to deploy a /22 that remains routable, supportable and operationally predictable for as long as the business depends on it.

For a step-by-step overview of the leasing process, read How to Lease IPv4 Addresses in 8 Steps .

To compare different IPv4 leasing structures, read IP Leasing: How IPv4 Leasing Works, Models, Costs & Benefits .

For organisations where stable leased IPv4 identity is important to long-term infrastructure, explore LARUS IPv4 Leasing Continuity Assurance .