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

Plan IPv4 capacity before growth becomes a customer problem

Your next customer, rack, region or API deployment should create revenue, not trigger a rushed renumbering project. The right IPv4 plan gives your network room to expand while the addresses already embedded in customer systems keep working.

That is why capacity planning is bigger than counting today's free addresses. It is about securing the supply, routing and continuity your next deployment needs before the deadline arrives.

Plan the next block around the business you are building, not the addresses you have left.

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 market shows how active /24 capacity remains. Your own customer commitments decide whether /24, /23 or /22 is the right launchpad. For the underlying 2026 market analysis, see IPv4 Liquidity in 2026: Which Block Sizes Are Moving Fastest?

IPv4 capacity planning in 2026: the quick answer

A /24 contains 256 IPv4 addresses, a /23 contains 512, and a /22 contains 1,024. The best choice is the one that gives your next deployments enough room without forcing another procurement and routing project a few months later.

Start with the numbers your team can act on:

• addresses in production today;
• customer and project commitments already in the pipeline;
• the next 12-to-24-month growth forecast;
• reserve for new services and network segments;
• routing and operational work required to deploy the prefix;
• IPv6 growth that can reduce future IPv4 demand; and
• the cost of running out of room at the wrong time.

Under-planning turns growth into repeated operational change. Over-planning ties up budget in idle capacity. The commercial win is a supply plan that keeps customers moving and gives your network room to breathe.

/24 vs /23 vs /22: choose the capacity that keeps growth moving

Prefix	IPv4 addresses
/24	256
/23	512
/22	1,024

• /24: focused workloads and measured growth.
• /23: new customers, services and network segments.
• /22: substantial, predictable infrastructure expansion.

A /23 gives you the capacity of two /24s. A /22 gives you four. Use that simple scale to put your customer pipeline and deployment calendar into context.

Two businesses can each use 200 addresses today and need completely different plans. One may be stable for years. Another may be onboarding new customer environments every month. The second business does not need to wait until its last address is assigned before securing the supply that growth requires.

What the 2026 IPv4 market means for your next deployment

Market activity helps you understand supply. Your own demand determines the capacity you can confidently put into production. The first half of 2026 recorded 596 transactions covering 5,016,064 addresses, including 182 /24 transactions, according to Mustafa Akdeniz of IPv4.Center.

Use those observations with current IPv4 market data, then size the next step around customer commitments, new services and the operational time saved by planning ahead. Fast access to usable capacity matters most when a new customer is waiting for deployment.

When a /24 gives you enough room

A /24 remains an efficient operational unit for a contained workload with measured growth. It can fit when current utilisation is comfortable, customer allocations are limited, IPv6 is taking a meaningful share of expansion, and the next capacity step can be introduced without disrupting production.

Look at headroom, not just unused addresses. A business may have 60 addresses free, but if 100 customer endpoints are already committed for the next six months, that /24 is already a commercial constraint.

When /23-scale capacity protects the next stage of growth

A /23 provides 512 addresses. It gives a growing operator room to add services, customers and dedicated public endpoints without repeating the same procurement and deployment work several months later.

Imagine a SaaS infrastructure provider using 190 addresses from a /24. The network is healthy, but the next year includes a new production environment, additional customer infrastructure, new public endpoints and approximately 120 more IPv4-dependent resources. The pressure is not today's utilisation; it is the confirmed demand already moving toward the network.

Planning /23-scale capacity lets the team treat that expansion as one deliberate infrastructure project. It gives customer deployments a clearer runway and gives the operations team time to prepare routing, reputation and application changes.

When /22-scale capacity makes the business case

A /22 contains 1,024 IPv4 addresses, equivalent in total address count to four /24s. It is a natural planning conversation for hosting platforms, data centres, cloud infrastructure, managed-service providers, ISPs, large SaaS platforms, security infrastructure and businesses with substantial customer growth.

The question is simple: where will the capacity create value? Strong answers include committed customer deployments, new facilities, separate environments, dedicated-address requirements, planned service expansion, reserve for the next deployment wave and a defined planning horizon.

If the answer is several upcoming customer or infrastructure projects, a /22 can keep the network ahead of demand instead of solving the same capacity problem twice.

Do not wait for a percentage to tell you to act

“Move from /24 to /23 at 80% utilisation” sounds easy, but the business case is not a single percentage. A network at 85% with little growth may have more time than a network at 60% that is onboarding hundreds of endpoints.

Use a planning model your sales, network and operations teams can share:

current utilisation + committed demand + forecast growth + operational reserve

Then reduce the forecast where IPv6, address recovery, infrastructure consolidation, network redesign or more efficient allocation can genuinely do the work. The result is a capacity decision tied to customer delivery, not an arbitrary threshold.

A simple IPv4 capacity planning example

Consider an infrastructure company using 165 IPv4 addresses. Confirmed customer deployments need 90 additional addresses, and the product forecast adds another 60.

165 + 90 + 60 = 315 IPv4 addresses

A /24 provides 256. A /23 provides 512, leaving 197 addresses before any additional reserve or optimisation. That /23 gives the company space to deliver the committed work and absorb the next deployment wave without reopening the same capacity project immediately.

If the following expansion phase adds another 300 addresses, the potential requirement moves beyond /23 capacity. Planning at /22 scale can then be the cleaner commercial decision: one stronger runway for growth instead of two rushed expansions.

The cost of under-planning reaches far beyond the address count

Adding capacity touches the running network. Depending on the deployment, your team may coordinate:

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

Repeatedly adding small increments can make the same work recur while customer deadlines get closer. The cheapest capacity decision today can become the most expensive migration decision later when the business keeps outgrowing its assumptions.

More capacity should create freedom, not unnecessary complexity

A larger block is valuable when it creates deployment room. It is wasteful when it sits idle without a customer or infrastructure plan. Match capacity to demand, but give your network enough headroom to act before scarcity becomes an emergency.

One /22 or several smaller prefixes can both reach 1,024 addresses. Multiple smaller blocks can help separate customers, environments, routing policies or locations. A contiguous block can reduce route fragmentation, the number of prefixes to administer, the number of RPKI or IRR objects to maintain and the number of procurement cycles. Choose the structure that makes the next deployment easier to deliver.

Four layers make an IPv4 expansion deployment-ready

A smooth expansion aligns four practical layers:

service relationship → registry records → routing authorisation → production use

Layer	The question your team needs answered
Service relationship	How will the business secure the additional capacity and keep it available for the planned term?
Registry records	Which resource and administrative records need to stay aligned for the deployment?
Routing authorisation	Which ASN will originate the prefix, and what RPKI or IRR changes are needed?
Production use	How will applications, infrastructure and customers consume the capacity?

When those layers are planned together, your operations team can move from capacity decision to customer delivery with fewer surprises. Keep your future options in the plan: customer-origin routing, ASN changes, new transit providers, data-centre moves, RPKI and IRR updates, reverse-DNS control and long-term continuity.

Build the routing plan before customer traffic arrives

Decide how the new capacity will be routed before it enters production. Confirm whether your ASN or an upstream will originate it, whether the network is multihomed, whether multiple prefixes share an origin, whether capacity will be split across data centres and whether customers will originate delegated prefixes.

RPKI should match the intended prefix, origin ASN and permitted prefix lengths. It supplies route-origin authorisation information that helps the network accept the routes you intend to run. See What Is RPKI? for the technical foundation.

If upstreams use IRR filters, prepare the required route objects, maintainer relationships and future ASN or provider changes before a customer is waiting for service. Read What Is an IRR Route Object?

Make the new capacity ready for your customers

Address history can affect spam filters, security and fraud systems, blocklists, VPN or proxy classifications and customer acceptance. Review reputation before migration day, while there is time to resolve an issue. The goal is a smooth customer launch, with fewer surprises once production traffic arrives. Read Understanding IP Address Reputation.

For email, hosting, managed services, security platforms and location-sensitive applications, prepare PTR records, reverse-DNS delegation, customer-specific naming and geolocation updates alongside routing. Coordinate third-party database updates early so the address information your customers encounter supports the service you are delivering.

Protect the address identity your customers already use

Public IPv4 addresses often become part of the service itself. Customers add them to allowlists. APIs, VPNs, banking platforms, payment providers, partner systems, security products, monitoring platforms and network documentation begin to depend on them.

That is why the next capacity decision should include continuity from the beginning. A new block must be routable, usable and ready for the applications and customer connections that make the business valuable. Read Can Your Business Survive Losing Its IP Addresses? for the continuity question.

Lease or buy the next IPv4 block?

Choose the supply model that keeps both your capital and your network working for growth. Leasing keeps cash available for customers, infrastructure and deployment while giving the business an ongoing IPv4 supply. Buying turns capital into a resource your team still has to route, administer and keep aligned with upstream registry requirements.

If public addresses are already embedded in customer APIs, allowlists and production identity, the decision is bigger than a purchase price. It is about how quickly you can secure usable capacity, how easily you can expand again and how confidently you can keep the same network identity in service.

LARUS brings Unlimited IPv4 and IPv4 Continuity together for operators that need room to grow without repeatedly starting over. Bring your current usage, customer pipeline and routing model; we can turn them into the next deployment path.

Lu Heng explains why the running network and its records matter in Protect the Ledger, Not the Gatekeeper.

Compare the full cost of capacity

Price matters, but the useful comparison is not only monthly rate × number of addresses. Include expected duration, capital commitment, routing setup, RPKI and IRR administration, reputation review, reverse DNS, future expansion and the cost of renumbering.

See LARUS Global IPv4 Pricing & Market Statistics for current market context. Market figures change; the business value of a stable, ready-to-deploy supply is decided by your customer commitments.

Keep IPv6 in the forecast

IPv6 is the long-term answer to IPv4 scarcity, and every workload that can move to IPv6 changes the capacity calculation. It does not remove today's IPv4 requirement for customers, APIs, enterprise networks, external services and legacy applications.

Use IPv6 to reduce unnecessary dependence while securing the IPv4 capacity that your customers and production systems still need.

/24, /23 or /22? A practical decision framework

Business condition	Commercial planning question
Below 256 addresses with measured growth	Can /24 carry the next deployment without putting a customer deadline at risk?
Confirmed growth is approaching /24 capacity	Would /23 give the team room to deliver once instead of expanding again soon?
Several services, customers or sites are expanding	Would /22 simplify the next growth phase and protect deployment speed?
Growth is real but timing is uncertain	Would leasing preserve cash and keep the supply flexible?
Addresses are embedded in customer systems	How will expansion protect the identity those systems already trust?
ASN, transit provider or data centre is changing	Can the new capacity move through the routing change without unnecessary disruption?
IPv6 adoption is increasing	Which future workloads can move to IPv6, and which customers still require IPv4?

Questions to answer before the next customer deployment

• How many addresses are active today?
• How many are committed to customers or projects already in the pipeline?
• What will the next 12-to-24 months require?
• How much reserve keeps sales and operations from waiting on the next block?
• Which workloads can move to IPv6?
• Which ASN, RPKI and IRR changes will the new prefix need?
• Will reverse DNS, geolocation or reputation affect the workload?
• Will customers need allowlist or security-policy updates?
• What happens when the business outgrows this capacity again?

You do not need a perfect spreadsheet before you act. Bring your current usage, customer pipeline and routing needs; LARUS can help turn them into the next deployment.

Do not wait until the /24 is full

The best time to plan is before scarcity becomes an emergency. Waiting for the last usable addresses compresses the time available for reputation checks, BGP preparation, RPKI, IRR, reverse DNS, customer migration, allowlists and production testing.

current utilisation + forward demand = the right time to plan

Secure the next capacity while your team still has room to make the right technical and commercial choice.

How LARUS supports IPv4 capacity planning

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

Align the prefix and origin ASN with BGP, RPKI and IRR; prepare reverse DNS, geolocation and reputation checks before customer traffic arrives. Your team keeps control of its infrastructure while LARUS helps keep address supply and deployment moving.

For APIs, allowlists and services that depend on the same public addresses over time, IPv4 Continuity keeps network identity at the centre of the growth 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 when current utilisation, customer commitments and the next planning horizon fit inside 256 addresses. If committed growth is already approaching the limit, plan the next capacity before the deadline does it for you.

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

Move the conversation to /23 when customer demand, new environments or public endpoints will push beyond /24 during the planning horizon, or when repeating the same capacity project would slow delivery.

When does planning for a /22 make sense?

A /22 makes sense when several services, customers or facilities are expanding and 1,024 addresses create a useful runway for the next phase.

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

No. Use the structure that makes your routing, segmentation, locations and customer delivery easier to run.

Should I wait until my /24 is nearly full?

No. Review current utilisation together with committed demand and forward growth. Waiting until the block is nearly exhausted leaves less time for routing, reputation, allowlists and production testing.

What utilisation percentage should trigger expansion?

There is no single percentage. A lower-utilisation network with a large customer pipeline can need capacity sooner than a high-utilisation network with little growth. Use demand and timing together.

Should a growing business lease or buy IPv4?

Leasing is a strong long-term option when the business wants to keep capital available and build on an ongoing supply. Buying requires up-front capital and leaves the team operating the resource through its routing and registry relationships. Compare the complete growth path, not only the monthly rate.

Does a larger IPv4 block create network stability?

Capacity creates room; stability comes from putting it into a sound routing, monitoring, RPKI, IRR and operational plan. LARUS Continuity keeps the address identity and the growth plan connected.

Does RPKI prove ownership of the additional IPv4 block?

No. RPKI identifies which ASN is authorised to originate a prefix; it does not establish property ownership. Align the ROA with your routing plan, and plan address continuity separately so the network identity your customers rely on stays central to the deployment.

Does IPv6 remove the need for IPv4 planning?

Not immediately. IPv6 can reduce future demand, while customers, applications and external networks may still require IPv4 connectivity today.

What is the biggest capacity-planning mistake?

Planning only for today's address count. The stronger plan connects current demand, customer growth, routing readiness, operational headroom, migration effort and continuity.

Give the next deployment room to succeed

Start with the customers you want to serve and the network you want to run. Match current usage, committed deployments, forecast growth and operational headroom to the prefix that gives the business room to deliver.

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

LARUS Unlimited IPv4 gives growth a dependable supply strategy. IPv4 Continuity keeps network identity in the plan, so expansion can move the business forward without repeatedly starting over.