Skip to main content
LARUS
Plan with IPv4 Continuity
Explore

Technical guide

From /24 to /22: Plan IPv4 Capacity for Business Growth

New customers should move your business forward, not send your team back into another address migration. Plan your next /24, /23 or /22 around real growth, stable APIs and the connections your customers already trust.

Plan with IPv4 Continuity

A business rarely wakes up one morning and suddenly needs 1,024 additional IPv4 addresses.

Capacity pressure usually develops gradually.

A SaaS company launches another production environment. A hosting platform adds more customers. A data centre fills additional racks. A managed-service provider needs more dedicated public addresses. What started as a comfortable /24 slowly becomes a capacity constraint.

At that point, the decision is not simply:

Should we get more IPv4 addresses?

The better question is:

How much IPv4 capacity should we plan for so the business can grow without paying for unnecessary idle space or repeatedly disrupting the network?

That distinction matters in 2026.

Published H1 2026 market data analysed by LARUS recorded 596 completed transactions involving 5,016,064 IPv4 addresses. Within that dataset, /24 blocks appeared in 182 transactions, representing approximately 30.5% of total transaction count.

The data shows that /24 remains a highly active unit in the observed IPv4 market. But market activity does not tell an individual business how much address capacity its infrastructure actually needs.

Market popularity is not the same as infrastructure suitability.

A /24 may be enough for one growing business and unnecessarily small for another. A /22 may give one operator useful growth capacity while leaving another paying for addresses it does not expect to use.

IPv4 capacity planning therefore needs to connect market data with real infrastructure demand.

For the underlying 2026 market analysis, see IPv4 Liquidity in 2026: Which Block Sizes Are Moving Fastest? .

IPv4 Capacity Planning in 2026: Quick Answer

A /24 contains 256 IPv4 addresses, a /23 contains 512, and a /22 contains 1,024.

But the correct choice should not be based on block size alone.

Businesses should evaluate:

  • current IPv4 utilisation;
  • confirmed future demand;
  • forecast growth;
  • customer allocation requirements;
  • network segmentation;
  • operational reserve;
  • routing architecture;
  • IPv6 adoption;
  • expected deployment duration; and
  • the operational cost of having to expand again.

Over-provisioning creates unnecessary cost. Under-provisioning can create repeated operational change.

The goal is not to obtain the largest IPv4 block available.

The goal is to secure enough capacity for a credible planning horizon without creating avoidable financial or operational friction.

/24 vs /23 vs /22: What Is the Difference?

PrefixIPv4 addresses
/24256
/23512
/221,024

A /23 gives you the capacity of two /24s; a /22 gives you four.

  • /24: Serve a contained workload with moderate expected growth.
  • /23: Give growing services, new customers and network segments more room.
  • /22: Plan ahead for substantial, predictable infrastructure expansion.

Use these capacity figures to put your growth forecast into context.

Two businesses using exactly 200 addresses today may require completely different strategies.

One may expect almost no growth for three years.

Another may be onboarding dozens of new customer environments every month.

Capacity planning therefore starts with future demand, not simply current address consumption.

What 2026 IPv4 Market Data Tells Growing Businesses

Market activity can help you understand supply, while your own demand determines the capacity to deploy. Mustafa Akdeniz of IPv4.Center reported 596 transactions covering 5,016,064 addresses in the first half of 2026; 182 transactions involved /24 blocks.

Use those historical observations alongside current IPv4 market data. Then size your next deployment around customer commitments, new services and the effort saved by planning growth in advance.

When Is a /24 Still Enough?

A growing company does not automatically need to move beyond a /24.

For many workloads, 256 IPv4 addresses can remain an efficient operational unit.

Staying with /24-scale capacity may make sense when:

  • current utilisation remains comfortably below capacity;
  • future growth is modest or predictable;
  • customer allocation requirements are limited;
  • the business has a narrow set of public-facing workloads;
  • IPv6 is absorbing a meaningful share of future growth;
  • additional capacity can be introduced later without major disruption; and
  • the business does not need substantial spare capacity for near-term commitments.

The important distinction is between unused addresses and available planning headroom.

A company may still have 60 unused addresses, but if 100 additional customer endpoints are already committed for the next six months, that /24 does not provide much strategic headroom.

When Should a Business Consider /23-Scale Capacity?

A /23 provides 512 addresses.

It may deserve consideration when the business can see that expected demand will exceed its existing /24 during the relevant planning horizon.

Consider a hypothetical SaaS infrastructure provider.

It currently uses 190 addresses from a /24.

The network is still operating normally.

But the company expects:

  • a new production environment;
  • additional customer infrastructure;
  • new dedicated public endpoints; and
  • approximately 120 additional IPv4-dependent resources during the next year.

The immediate issue is not that the /24 is already full.

The issue is that credible future demand is greater than the remaining capacity.

Planning toward /23-scale capacity may allow the expansion to be managed as one infrastructure project rather than repeating procurement and deployment several months later.

When Does Planning for a /22 Make Sense?

A /22 contains 1,024 IPv4 addresses, equivalent in total address count to four /24s.

That may be unnecessary for a company with a few dozen public endpoints.

It can be more relevant for:

  • hosting platforms;
  • data centres;
  • cloud infrastructure;
  • managed-service providers;
  • ISPs;
  • large SaaS platforms;
  • security infrastructure; or
  • businesses with substantial and credible customer growth.

The key word is credible.

A business should not lease or acquire a /22 simply because it hopes to grow.

It should be able to explain where the capacity is likely to be used.

That might include:

  • committed customer deployments;
  • new facilities;
  • separate infrastructure environments;
  • dedicated-address requirements;
  • planned service expansion;
  • reasonable reserve capacity; and
  • a defined planning horizon.

Do Not Use a Single Utilisation Percentage as the Trigger

A simple rule such as:

“When your /24 reaches 80% utilisation, move to a /23.”

may sound convenient, but it is not a universal capacity-planning method.

A company running at 85% utilisation with little expected growth may face less urgency than a company running at 60% while onboarding hundreds of new endpoints.

A more useful planning model considers:

current utilisation + committed demand + forecast growth + operational reserve

and then considers how much future IPv4 consumption could realistically be reduced through:

  • IPv6;
  • address recovery;
  • infrastructure consolidation;
  • network redesign; or
  • more efficient allocation.

A Simple IPv4 Capacity Planning Example

Consider a hypothetical infrastructure company.

It currently uses:

165 IPv4 addresses

Confirmed customer deployments are expected to require:

90 additional addresses

Product forecasts suggest another:

60 addresses

The projected requirement becomes:

165 + 90 + 60 = 315 IPv4 addresses

A /24 provides only 256.

A /23 provides 512.

At a projected requirement of 315, a /23 would leave 197 addresses before any additional reserve or optimisation is considered.

That does not automatically prove that the company should obtain a /23.

It should still assess:

  • whether the growth forecast is credible;
  • whether some workloads can use IPv6;
  • how long the additional capacity will be needed;
  • whether leasing or acquisition is more appropriate; and
  • what operational changes the additional prefix requires.

Now assume the same business expects another 300 addresses of demand within the following expansion phase.

The potential requirement moves beyond /23 capacity.

At that point, /22-scale planning may deserve consideration rather than solving the same capacity problem twice.

The Cost of Under-Planning Is Not Just the Price of More IP Addresses

This is where IPv4 capacity planning becomes an infrastructure decision rather than a subnetting exercise.

Expanding capacity may involve:

  • BGP deployment;
  • RPKI Route Origin Authorisations;
  • IRR route objects;
  • reverse DNS;
  • monitoring;
  • IP reputation review;
  • geolocation updates;
  • firewall changes;
  • customer allowlists;
  • application configuration; and
  • future renewal or migration planning.

A company that repeatedly adds small increments of IPv4 capacity may therefore repeatedly incur operational work that is not visible in the headline cost per address.

The cheapest capacity decision today can become an expensive migration decision later if the business repeatedly outgrows its planning assumptions.


But Bigger Is Not Automatically Better

Capacity planning should not become an argument for leasing or buying the largest available block.

Over-provisioning can create:

  • unnecessary lease expense;
  • unnecessary capital commitment;
  • idle address capacity;
  • larger operational scope; and
  • resources that are not justified by actual demand.

The objective is therefore balance.

Enough capacity to support credible growth, but not so much that the business pays for speculative demand.


IPv4 Capacity Can Become Network Identity

Public IPv4 addresses can become more difficult to replace the longer they remain in production.

An address may become embedded in:

  • customer allowlists;
  • firewalls;
  • API integrations;
  • VPN configurations;
  • banking platforms;
  • payment providers;
  • partner systems;
  • security products;
  • monitoring platforms; and
  • customer network documentation.

Once external systems depend on an address, replacing it may require cooperation from organisations outside the network operator's direct control.

IPv4 can become network identity when external systems begin depending on the address rather than simply the service behind it.

This means capacity planning and continuity planning eventually become connected.

For more detail, read Can Your Business Survive Losing Its IP Addresses? .

One Larger Block vs Multiple Smaller Blocks

A growing organisation may have more than one way to reach the same overall IPv4 capacity.

For example, 1,024 addresses could be represented by one /22 or by multiple smaller prefixes.

Choose the structure that makes your network easier to expand and operate.

Multiple smaller blocks can sometimes provide:

  • deployment flexibility;
  • separation between customers or environments;
  • different routing policies;
  • different locations; and
  • incremental capacity growth.

A larger contiguous block can sometimes reduce:

  • routing fragmentation;
  • the number of separate prefixes to administer;
  • the number of RPKI or IRR objects to maintain;
  • monitoring complexity; and
  • repeated capacity-procurement cycles.

The correct choice depends on network architecture, not merely address count.

IPv4 Capacity Planning Has Four Layers

IPv4 expansion becomes clearer when four different layers are separated:

commercial rights → registry state → routing authorisation → operational use

Layer Capacity Planning Question
Commercial rights Does the business need to lease, acquire or otherwise obtain long-term use of additional capacity?
Registry state What relevant resource and administrative relationships need to be maintained?
Routing authorisation Which ASN will originate the prefix, and what RPKI or IRR changes are required?
Operational use How will applications, infrastructure and customers consume the additional capacity?

These layers need to remain sufficiently aligned, but they are not the same thing.

BGP Should Be Part of the Capacity Decision

Businesses should decide how new IPv4 capacity will be routed before it enters production.

Questions include:

  • Will the company originate the prefix from its own ASN?
  • Will an upstream originate it?
  • Will the network be multihomed?
  • Will multiple prefixes use the same origin ASN?
  • Will capacity be split across data centres?
  • Will customers originate delegated prefixes?
  • Could the prefix need to move between providers later?

Adding capacity without considering route structure can create unnecessary complexity later.

A business does not need to centralise all IPv4 capacity into one prefix.

It should simply understand why its routing structure is becoming more complex before introducing additional prefixes.

RPKI Should Follow the Intended Routing Model

New IPv4 capacity is not production-ready simply because addresses are available.

If the business originates its own routes, Route Origin Authorisations should reflect:

  • the intended prefix;
  • the intended origin ASN; and
  • the permitted prefix lengths.

RPKI provides route-origin authorisation information.

It should not be treated as universal proof of conventional legal ownership.

For more detail, read What Is RPKI? .

IRR Can Also Affect Deployment Readiness

Some networks use Internet Routing Registry information when constructing routing filters.

When additional IPv4 capacity is introduced, the business should determine:

  • whether a route object is required;
  • which origin ASN should appear;
  • who controls the relevant maintainer;
  • which upstreams use IRR filtering; and
  • how future ASN or provider changes will be handled.

Read What Is an IRR Route Object? for a deeper explanation.

Reputation Should Be Checked Before Capacity Becomes Urgent

IPv4 addresses can carry operational history from previous use.

That history may influence:

  • spam filtering;
  • security products;
  • fraud systems;
  • blocklists;
  • VPN or proxy classifications;
  • hosting classifications; and
  • customer acceptance.

The worst time to discover a significant reputation problem is shortly before a customer migration.

Capacity planning should therefore leave enough time to review address history before production depends on the new prefix.

Read Understanding IP Address Reputation .

Reverse DNS and Geolocation May Also Matter

Additional capacity may require more than routing.

Depending on the workload, the business may also need:

  • PTR management;
  • reverse-DNS delegation;
  • geolocation updates;
  • customer-specific naming; and
  • coordination with third-party databases.

This is particularly relevant for:

  • email infrastructure;
  • hosting;
  • managed services;
  • security platforms;
  • location-sensitive applications; and
  • enterprise customer environments.

Should a Growing Business Lease or Buy Its Next IPv4 Block?

Choose the supply model that keeps your capital and your network working for the business. Leasing supports both long-running production services and new expansion: you can put capital into customers, infrastructure and growth while drawing on an ongoing IPv4 supply.

Buying commits capital up front and leaves your team managing the resource’s registry relationship. That purchase does not remove upstream registry dependence. Compare the full operating commitment, including routing, administration, renewal and continuity, rather than treating a purchase price as the end of the decision.

LARUS offers first-party Unlimited IPv4 and Continuity for operators whose public addresses become part of customer APIs, allowlists and production identity. Plan the /24, /23 or /22 you need now with the continuity of that identity in view.

Lu Heng explains why the records and the running network matter more than preserving a registry institution in Protect the Ledger, Not the Gatekeeper.

What About the Cost of IPv4 Capacity?

Price matters, but the correct comparison is not simply:

monthly rate × number of IP addresses.

A business should consider:

  • capacity cost;
  • expected duration;
  • capital commitment;
  • routing setup;
  • RPKI and IRR administration;
  • reputation review;
  • reverse DNS;
  • future expansion;
  • renumbering risk; and
  • migration cost.

For current market information and capacity context, see LARUS Global IPv4 Pricing & Market Statistics .

IPv6 Should Be Part of the Forecast

Planning additional IPv4 does not mean abandoning IPv6.

IPv6 is the long-term architectural response to IPv4 scarcity.

A useful 2026 capacity plan should therefore ask:

Which future workloads genuinely need public IPv4, and which growth can move to IPv6?

Every workload that can move away from unnecessary IPv4 dependence changes the capacity calculation.

But businesses should also avoid assuming that IPv6 immediately eliminates IPv4 requirements.

Customers, APIs, enterprise networks, external services and legacy applications may still require IPv4 connectivity.

/24, /23 or /22? A B2B Decision Framework

Business Condition Capacity Question
Current deployment remains comfortably below 256 addresses Is the existing /24 still sufficient for the next planning horizon?
Current /24 has limited headroom and confirmed growth is approaching capacity Would /23-scale capacity reduce the chance of another near-term expansion?
Multiple services, customers or sites are expanding simultaneously Would /22-scale planning simplify growth compared with repeated incremental additions?
Growth is real but uncertain Would leasing additional capacity preserve more flexibility?
Public addresses are embedded in customer systems How can expansion reduce future renumbering risk?
Network is changing ASN, transit provider or data centre Can additional capacity be introduced without unnecessary routing disruption?
IPv6 adoption is increasing How much forecast IPv4 demand can realistically be reduced?

Questions to Answer Before Expanding IPv4 Capacity

  1. How many IPv4 addresses are actively used today?
  2. How many are already committed to upcoming customers or projects?
  3. What is the realistic 12-to-24-month growth forecast?
  4. How much operational reserve does the workload need?
  5. Can IPv6 reduce part of the forecast requirement?
  6. Will the new prefix use the same origin ASN?
  7. What RPKI changes will be required?
  8. Will new or updated IRR route objects be required?
  9. Is reverse DNS important for the workload?
  10. Has the reputation of the new address space been reviewed?
  11. Will customers need to change allowlists or security policies?
  12. What happens if the business outgrows this capacity again?
  13. Is leasing, acquisition or a hybrid model more appropriate?
  14. Can the capacity remain usable through future infrastructure changes?

You do not need every answer before speaking with us. Bring your current usage and growth plans; LARUS can help turn them into the next deployment.

Do Not Wait Until the Existing /24 Is Full

Capacity planning works best before scarcity becomes an emergency.

Waiting until the final usable addresses have already been allocated can compress the time available for:

  • commercial evaluation;
  • reputation checks;
  • BGP preparation;
  • RPKI changes;
  • IRR configuration;
  • reverse DNS;
  • customer migration;
  • allowlist changes; and
  • production testing.

A better approach is to review capacity periodically using both:

current utilisation + forward demand

rather than waiting for a single percentage threshold.

Capacity Planning Should Preserve Operator Flexibility

Businesses should avoid designing IPv4 growth around unnecessary dependence on one unrelated infrastructure component.

Plan your next deployment around the flexibility you need. Consider how additional capacity should be evaluated for:

  • customer-origin routing;
  • ASN flexibility;
  • transit-provider changes;
  • data-centre migration;
  • RPKI update capability;
  • IRR update capability;
  • reverse-DNS control; and
  • long-term continuity.

A good IPv4 capacity model should support the running network without unnecessarily controlling how that network must evolve.


How LARUS Supports Business IPv4 Capacity Planning

Tell us where your network is growing, how many customers are coming next and which connections must stay stable. LARUS brings Unlimited IPv4 and practical support for the deployment around it.

Align your prefix and origin ASN with BGP, RPKI and IRR; plan reverse DNS, geolocation and reputation checks before customer traffic arrives. Your team keeps control of its infrastructure while LARUS supports the address supply and upstream coordination.

For APIs, allowlists and services that depend on the same public addresses over time, IPv4 Continuity puts that stability at the centre of the plan.

Frequently Asked Questions

How many IPv4 addresses are in a /24?

A /24 contains 256 IPv4 addresses.

How many IPv4 addresses are in a /23?

A /23 contains 512 IPv4 addresses, equivalent in total address count to two /24 blocks.

How many IPv4 addresses are in a /22?

A /22 contains 1,024 IPv4 addresses, equivalent in total address count to four /24 blocks.

Is a /24 enough for a growing business?

It can be. The answer depends on current utilisation, expected growth, customer requirements, segmentation and the relevant planning horizon.

A business should not move to a larger block simply because another company of similar size uses one.

When should a business move from a /24 to /23-scale capacity?

A /23 may deserve consideration when credible demand is expected to exceed /24 capacity within the business's planning horizon and another near-term capacity expansion would create unnecessary operational work.

When should a business consider a /22?

A /22 can be relevant when a credible infrastructure forecast points toward more than /23-scale demand or when multiple services, customers or facilities make 1,024-address capacity operationally useful.

Is one /22 always better than four /24s?

No. The best structure depends on: routing design, availability, network segmentation, market conditions, geography, operational requirements and the organisation's existing infrastructure.

Should I wait until my /24 is nearly full before expanding?

Not necessarily. Capacity should be reviewed using both current utilisation and credible forward demand.

Waiting until addresses are nearly exhausted can reduce the time available for routing preparation, reputation checks and migration planning.

What percentage of IPv4 utilisation should trigger expansion?

There is no universal percentage.

A network at high utilisation with little expected growth may have less urgency than a network with lower current utilisation but significant committed future demand.

Should a growing business lease or buy IPv4?

For a business that wants to keep capital available and build on an ongoing supply, leasing is a strong long-term option. Buying adds an up-front investment and direct responsibility for the registry relationship. Compare the whole operating model and address continuity, not just the monthly rate against a purchase price.

Does a larger IPv4 block provide better network stability?

Not automatically.

Network stability also depends on: BGP, upstream connectivity, RPKI, IRR, configuration, monitoring and operational responsibility.

Does RPKI prove ownership of the additional IPv4 block?

No. RPKI provides route-origin authorisation information. It should not be treated as universal proof of legal property ownership.

Does IPv6 eliminate the need for IPv4 capacity planning?

Not immediately.

IPv6 can reduce future IPv4 dependence, but customers, applications and external networks may continue to require IPv4 compatibility.

What is the biggest mistake in IPv4 capacity planning?

One common mistake is optimising only for today's address count.

A better plan considers:

current demand + future growth + routing + operational readiness + migration cost + continuity

Conclusion

Start with your customers and the network you want to run. Combine current usage, committed deployments, forecast growth and operational headroom; then choose the prefixes and routing model that support them.

A /24 contains 256 addresses, a /23 contains 512 and a /22 contains 1,024. The right plan gives you room to launch services while protecting established APIs, allowlists and customer connections.

LARUS Unlimited IPv4 gives that growth a supply strategy. IPv4 Continuity keeps the long-term address identity in view, so expansion can move your business forward without repeatedly starting over.

Room for your next customer

Grow your network without starting over.

Bring your current usage, growth plan and routing needs. LARUS brings Unlimited IPv4 and Continuity to support the addresses your business depends on.

Plan with IPv4 Continuity