How to Plan IPv4 Capacity Before Leasing Addresses

A practical method for translating workloads, growth, and routing constraints into the right IPv4 block size.

Primary keyword	lease IP addresses
Suggested slug	plan-ipv4-capacity-before-leasing
Meta title	How to Plan Capacity Before Leasing IP Addresses
Meta description	Calculate IPv4 demand, reserve capacity, CIDR size, routing needs, and total cost before leasing an address block for your network.
Target link	Exact anchor lease IP addresses links to the requested i.LEASE guide.

 

Start with the workload

The right IPv4 block is determined by what a network must operate, not by the size that appears most familiar in a provider list. A /24 may be enough for one service and inadequate for another. A larger block may create useful headroom, or it may leave the organization paying for capacity that has no deployment plan. Capacity planning should therefore precede supplier selection and price comparison.

Teams preparing to lease IP addresses should define current endpoints, expected growth, routing boundaries, reserve needs, and the cost of adding another prefix later. This produces a requirement that providers can evaluate and gives procurement a consistent basis for comparing offers.

Count public endpoints

Begin with the systems that need public IPv4 addresses during the proposed lease term. Count production servers, customer instances, network appliances, gateways, load balancers, public application interfaces, and any dedicated addresses required by a product or contract. Remove resources that can remain private behind address translation. The objective is a defensible demand estimate, not a copy of the current inventory.

Separate steady demand from temporary peaks. A hosting pool with predictable monthly growth should be modeled differently from a migration environment that will disappear after six months. Record the expected start date and the month-by-month demand curve when growth is material. This makes it easier to decide whether one larger block or a staged expansion is operationally safer.

Separate nominal and usable capacity

CIDR notation identifies the prefix length and the nominal number of addresses in a block. The CIDR architecture in RFC 4632 explains the classless addressing and aggregation model. A /24 contains 256 address values, a /23 contains 512, and each shorter prefix doubles the count.

Nominal count is not always the same as application capacity. Network design, subnet boundaries, gateway use, platform rules, reserved ranges, anycast plans, and operational policy can reduce the number assigned to workloads. Ask the network team for a usable-capacity figure for the intended architecture rather than assuming every address in the billing count will become a customer endpoint.

Prefix	Nominal addresses	Typical planning use
/24	256	One routed pool or an initial deployment
/23	512	A growing pool with more reserve
/22	1,024	Several services or customer segments
/21	2,048	A larger platform or regional deployment
/20	4,096	Multi-service capacity with longer-term growth

 

The table is a planning shortcut. Route acceptance, provider policy, and topology still determine whether a particular prefix can be announced and used as intended.

Add reserve for known uncertainty

Reserve capacity protects the deployment from ordinary forecast error and small operational changes. It can cover customer growth, maintenance overlap, replacement infrastructure, new zones, or a delayed decommissioning project. Set the reserve from actual volatility and lead time. A fixed percentage applied without context can be too small for a fast-growing platform and unnecessarily large for a stable internal service.

A useful test is to estimate how long the remaining addresses would last under the high-demand scenario. If the pool would be exhausted before another block could be sourced, reviewed, routed, and integrated, the plan needs more headroom or a staged supply agreement. If most of the block remains idle throughout the term, reduce the request or document the operational reason for retaining the reserve.

Plan routing boundaries

Capacity cannot be planned independently of routing. Confirm whether the organization will announce the prefix from its own Autonomous System Number, use a provider announcement, or place the block behind a hosting or transit partner. Decide whether one aggregate can serve the workload or whether separate prefixes are needed for regions, upstreams, customers, security zones, or failure domains.

When the customer originates a leased prefix, the parties should coordinate the origin ASN, Letter of Authorization where required, route objects, and the Route Origin Authorization. The required prefix and maximum length must align with the actual announcement plan. Capacity that cannot be authorized or accepted by upstream networks is not deployable capacity.

Match the term to the demand curve

The lease period should cover the useful life of the requirement plus realistic deployment and migration windows. A short commitment can fit a temporary project, but frequent renewal may create price and continuity exposure for a stable service. A longer commitment can provide planning certainty, yet it may leave the organization paying for surplus capacity if the workload changes.

Use an IPv4 cost calculator with sourced assumptions to compare the same capacity and time horizon. Include setup, routing, support, monitoring, renewal, and exit work rather than comparing only a rate per address.

Check supply after the requirement is clear

A capacity plan should identify the required prefix size, acceptable alternatives, target region, intended use, routing model, start date, and term. Only then should the team review current supply. Availability changes, and a visible listing does not prove that a block fits the application or can be reserved on the required schedule.

A managed IPv4 leasing review can coordinate inventory, authority, routing, and commercial checks against the defined requirement. The team should still inspect the exact prefix and approve the technical and contractual evidence before activation.

Use a capacity approval checklist

1. Record current public endpoint demand and the expected peak during the lease term.
2. Remove workloads that can use private addressing or shared egress.
3. Calculate usable capacity after subnet, platform, and operational reserves.
4. Select the smallest CIDR plan that covers demand and justified headroom.
5. Confirm topology, origin ASN, upstream policy, and required route authorizations.
6. Compare one aggregate with multiple prefixes for resilience and operational control.
7. Model the complete cost over the same term used in the demand forecast.
8. Document the trigger and lead time for adding capacity or beginning renumbering.

Approve capacity before choosing a block

The IANA IPv4 Address Space registry documents the 32-bit IPv4 allocation space, but a successful lease decision depends on the specific workload and route. Define usable demand, reserve, topology, term, and expansion triggers before comparing inventory. That sequence reduces wasted capacity and lowers the chance that a growing service will require an avoidable emergency migration.