How much headroom should an address plan reserve?

Enough for each block to double at least once. Sparse allocation achieves this automatically, and it costs nothing in private space. In public space, size the reservation against a realistic growth forecast instead.

What is sparse allocation?

Placing each new allocation at the midpoint of the remaining free space rather than immediately after the previous one. Every allocated block ends up with contiguous free space after it, so it can grow in place instead of being renumbered.

Should the address plan encode site or function first?

Whatever you summarise on. If routes are aggregated per site, site comes first. If policy and filtering are the dominant concern and sites share a routing domain, function first can be better. Choosing wrongly is recoverable only by renumbering.

What utilization should trigger acquiring more space?

Plan to act at around 80% of an aggregate. Acquiring and routing address space takes weeks, and the last 20% disappears faster than expected once growth is non-linear.

Can I fix a bad address plan without renumbering?

Rarely. You can add disjoint space and route it separately, but that permanently increases the number of prefixes you announce and the length of every filter. Renumbering is usually the cheaper long-term option.

Designing an IPv4 Address Plan

Reviewed by Marek Dvořák, Network engineer

An address plan is a design decision that is expensive to reverse. The goal is a hierarchy where every level summarises into the level above, and every block has room to grow without moving.

Assumed: you know which blocks you hold and roughly how many sites, roles, and segments you need to address. If not, start with what is IPAM.

Establish the hierarchy before allocating

Decide which dimensions the plan encodes and in what order. The usual candidates are region, site, role, and environment. The order matters more than the choice, because the outermost dimension is the one you can summarise on.

A workable default for a multi-site network:

aggregate  →  region  →  site  →  role  →  segment
10.0.0.0/8    /12        /16      /20      /24

Pick the order by asking where routes are aggregated. If each site announces its own summary, site must sit above role. If sites share a routing domain and your dominant concern is firewall policy, role above site can be the better trade.

Write this down before assigning anything. A hierarchy discovered retroactively from existing assignments is not a hierarchy.

Size each level on power-of-two boundaries

Every level rounds up to a prefix boundary. A site needing 12 /24s gets a /20, not “12 consecutive /24s” — because a /20 is one route and 12 consecutive /24s are twelve.

Aligning matters as much as sizing. A /20 must start at a multiple of 4,096 addresses. A block that is the right size but starts in the wrong place cannot be expressed as a single prefix, which defeats the point. The subnet calculator will show you the realignment if you get it wrong.

Round generously at the top and tightly at the bottom. Aggregates are cheap to oversize and expensive to change; segments are the reverse.

Allocate sparsely rather than sequentially

This is the step that separates plans that survive from plans that get rebuilt.

Sequential allocation fills from the bottom: site A takes the first /16, site B the next, site C the next. When site A needs to double, the space after it belongs to site B, so site A gets a second disjoint block and now announces two routes forever.

Sparse allocation places each new block at the midpoint of the remaining free space:

First site     10.0.0.0/16    (start of 10.0.0.0/8)
Second site    10.128.0.0/16  (midpoint of the remainder)
Third site     10.64.0.0/16   (midpoint of the first half)
Fourth site    10.192.0.0/16  (midpoint of the second half)

Every allocation has free space immediately after it, so growth extends the existing prefix rather than adding a new one. In private space this costs nothing — you have 16.7 million addresses and no reason to pack them.

In public space the calculation changes, because the space is expensive. There, apply sparse allocation within what you hold and accept tighter packing, but still leave each block room for one doubling.

Reserve headroom explicitly

Record growth space as reserved in your IPAM, with a note saying what it is reserved for. Do not leave it blank.

Blank space reads as available. Someone under time pressure during an incident will assign it, and the reservation that existed only in the designer’s head disappears silently. This is the most common way a good plan degrades.

Group by role so filters stay short

Keep management, customer-facing, infrastructure, and point-to-point space in separate aggregates rather than interleaved.

The payoff is in every downstream system. “Management space is 10.255.0.0/16” is one ACL line, one monitoring scope, one firewall object. Interleaved management addresses scattered across per-site ranges become a rule per site, in every device, maintained forever.

Point-to-point links deserve their own aggregate for the same reason, and should use /31 rather than /30 — RFC 3021 makes both addresses usable, halving the space and removing the mental arithmetic.

Document and validate the plan

Load the design into your IPAM before deployment, not after — see the NetBox or phpIPAM quickstarts.

Then check three things:

Every level summarises. Each site’s assignments fit inside one prefix; each region’s sites fit inside one prefix.
Every block can double. For each allocation, the space immediately following it is free or reserved.
Roles are separable. You can express “all management space” and “all customer space” as one prefix each.

If any of the three fails, fix it now. Every one of them costs a renumbering project later.

Mistakes that force a redesign

Starting at 10.0.0.0/24 and 192.168.1.0/24. Every default configuration uses these. The first VPN, partner connection, or acquisition collides. See private IP ranges.

Encoding something that changes. Department names, project codes, and vendor names all change; addresses do not follow. Encode topology and function, which are stable.

Planning to exactly current requirements. A plan sized to today’s device count has no headroom by definition, and the first growth event breaks it.

Treating public and private space with the same method. Private space should be allocated generously and sparsely. Public space is scarce and expensive, and its plan is driven by what aggregates into a single announcement.

Deferring documentation. A plan that exists only as deployed configuration is not a plan. It is an archaeology exercise for whoever comes next.

When the plan says you need more space

Track utilization per aggregate and act at around 80%. Acquiring routable address space takes weeks between agreement, registry transfer, and routing — see transfer timelines for the registry side, and IPv4 services for acquiring space.

IPAM best practices — keeping the plan accurate once it is deployed
Subnet calculator — check alignment and split blocks
CIDR chart — prefix sizes and boundaries
Utilization and RIR audits — what registries expect the plan to look like

Last updated on August 29, 2026

What is IPAM Best practices