Ask a network architect how many addresses a fifty-site estate needs and you’ll get a question back: fifty of what? A site is a location or an isolated segment, not one device. Each one eats a block of address space, not a single address. And planning conversations tend to smear three separate pools together: private internal space behind the perimeter, public routable space the internet can see, and whatever WAN addressing the carrier hands you per circuit. So the real question is how much space to reserve. Addressing goes load-bearing the second routing protocols, firewall objects and DHCP scopes start depending on it. Get the reservation wrong and you fail in one of two directions. Too small, and you’re running a renumbering project that touches every system holding an address. Wildly too big, and your prefixes scatter and your routing tables fill with entries that summarise badly.
Building the Per-Site Address Baseline
Before you pick a single subnet mask, go inventory what actually burns an address at a typical branch. The list is longer than most spreadsheets admit, and it keeps growing quietly as buildings pick up sensors, displays and badge readers.
- Infrastructure: router interfaces, firewall interfaces, switch management addresses, wireless controllers and access points, uninterruptible power supplies.
- Wired endpoints: desktops, VoIP handsets, printers, multifunction devices, conference room systems.
- Wireless endpoints: laptops, tablets, handheld scanners, staff mobiles enrolled on the corporate SSID.
- Guest and IoT: visitor devices, cameras, door controllers, HVAC and building management gear, digital signage.
- Management and out-of-band: console servers, remote hands interfaces, monitoring probes.
Infrastructure addresses are static and permanent. Endpoint counts move around with headcount, shift patterns and how many visitors walk in. Here’s the bit people miss: DHCP scope sizing follows peak concurrent devices, not employee count. One person can easily show up with a laptop, a mobile running a softphone and a headset that registers on its own. The count matters less than how far subnets need to sit from each other.
Tip: size the scope on the busiest hour of the busiest day, then add a lease-overlap allowance so devices cycling through short leases cannot exhaust the pool.
Private Address Space and the Arithmetic of Subnetting
RFC 1918 gives you three ranges for internal use, and the room they offer is nowhere near equal. 10.0.0.0/8 is the biggest canvas and the cleanest hierarchy for a multi-site estate. 172.16.0.0/12 sits in the middle. 192.168.0.0/16 is the cramped one, and it’s also the range every piece of consumer kit on earth defaults to. Not ideal. The host arithmetic is simple and completely unforgiving: a /24 gives you 254 usable addresses once network and broadcast are carved out, and every extra bit of prefix halves what’s left. A /25 gives 126. A /26 gives 62.
A uniform block per site makes operations easier even when your branches vary wildly in size. Predictable boundaries summarise cleanly, routing tables stay short, firewall rules stay readable. Then segmentation multiplies everything: voice, guest, physical security and management all want their own subnet, so one location can end up holding five or six separate networks instead of one flat range.
Tip: allocate on VLAN boundaries first and let host counts follow, instead of sizing a flat subnet and retrofitting segmentation later. Assigning contiguous blocks per region then permits one aggregate route where dozens of specific entries would otherwise appear.
Where Public IPv4 Is Still Genuinely Required
Internal totals and public totals are two different sums. Most branch traffic leaves through NAT and never needs a routable address of its own, which is why the public number for a fifty-site estate usually comes out as a sliver of the internal one. The genuine requirements cluster around a short list:
- Internet-facing services hosted on premises rather than in a data centre or cloud region.
- Site-to-site VPN endpoints where the remote peer insists on a fixed address.
- Mail infrastructure whose sending reputation is bound to a specific address.
- Remote access gateways and any appliance that must accept inbound connections.
Carriers are increasingly handing branch circuits dynamic addressing, or dropping them behind carrier-grade NAT. That quietly kills inbound reachability and breaks anything that expected a stable peer address. Scarcity makes it worse: transfer market prices and monthly lease charges turn public IPv4 into a budget line rather than something free.
Tip: audit which locations truly need inbound reachability before ordering static addressing everywhere, because the majority do not.
Overlap, Acquisitions and the Cost of Renumbering
The classic collision shows up with a merger or a partner connection. Two organisations, or two managed service vendors, both defaulted to the same popular private subnet, and now routing between them simply isn’t possible without someone intervening. NAT between overlapping internal networks is a workaround, not a fix. It hides true source addresses in your logs, makes troubleshooting miserable, and confuses any application that embeds addresses in its payloads or referrals.
Renumbering effort gets underestimated constantly, because so much of it moves in lockstep. DHCP scopes, DNS records, firewall objects, access control lists, monitoring targets, backup jobs, hardcoded application references, plus every diagram and runbook - all of it shifts together, usually inside a change window nobody wants to own.
Tip: steer core sites away from the most commonly used default private ranges, leaving a clear path for future partner and acquisition connections.
Reserving address space costs you almost nothing at design time. Clawing it back later costs project budget, weekend hours and operational risk. That’s the justification for allocations that look generous on paper.
IPv6 and Dual-Stack Sizing for a Multi-Site Estate
IPv6 changes the whole exercise. The constraint moves from host counts to subnet counts, because a /64 goes on every segment whether three devices or three hundred sit on it. Planning turns into hierarchy work: take the provider or registry allocation, cut it by region, then by site, then by segment, keeping every level aligned and consistent.
Dual-stack is where the actual cost lands. Two address plans, two sets of firewall rules, two DNS record types and two monitoring views running side by side for the entire transition. A gap in one stack is a hole in your security posture even when the other one is watertight.
Tip: design IPv6 allocations on nibble boundaries, so prefixes remain readable at a glance and reverse DNS delegation stays straightforward.
One more thing worth flagging: IPv6 removes the pressure to undersize subnets. And undersizing is exactly the habit that produces IPv4 renumbering projects a few years after deployment.
Growth Headroom, Documentation and Address Governance
Plan against a horizon, not against today’s occupancy. Sites grow, wireless and IoT density climbs year over year, and projects or events throw temporary surges at you that a tightly fitted scope can’t swallow. Governance is what stops that headroom from quietly evaporating:
- Maintain a single authoritative address register that everyone trusts.
- Allocate from a documented scheme rather than ad hoc, per engineer.
- Record purpose and owner for every block issued.
- Reclaim space formally when a site closes or a segment retires.
- Review utilisation on a fixed cycle instead of during incidents.
Spreadsheets fall apart at this scale. They can’t detect conflicts, can’t verify reality, can’t track history. An IP address management platform gives you conflict detection, DHCP and DNS integration, audit trails and delegated allocation rights.
Tip: treat unallocated space as reserved capacity with a documented release process, not as free territory anyone may claim.
Tip: record the growth assumption beside each allocation, so the next engineer understands why a block looks oversized rather than reclaiming it.
Putting the Numbers Together
What you’re producing here is a method, not one number. Count the segments each site needs. Size every segment on peak concurrent devices, with headroom you chose on purpose. Multiply across all fifty locations, then add infrastructure addressing, point-to-point transit links and router loopbacks. The public IPv4 requirement falls out on its own and should be justified service by service, since it usually amounts to a small share of the internal total. Sizing decisions come back later, when moving a network to new IPs is on the table.
Four design priorities carry the plan: predictable per-site blocks, regional aggregates that summarise cleanly, deliberate avoidance of the overlap-prone default ranges, and a parallel IPv6 scheme built from day one. Address planning behaves far more like a governance discipline than a technical calculation, and it pays for itself during mergers, audits and expansion. Get it wrong and the cost isn’t measured in addresses. It’s measured in renumbering projects. That renumbering risk starts on day one, since even the reputation attached to reused address space can follow a brand new site into production.
