How to Plan IP Addressing for an ISP

Addressing is the decision that feels trivial in week one and quietly governs your operational life by year three. The blocks you carve up when you have two hundred customers determine whether, at twenty thousand, your routing tables are lean and your troubleshooting is a thirty-second lookup — or whether every new POP forces a renumbering project and every outage starts with “which block is that, again?” Unlike most engineering choices, an addressing plan is extremely expensive to change once customers are live, because the addresses are baked into running configurations, RADIUS, DNS, firewall rules, and customer devices. You essentially get one good chance to do it right.

The good news is that good addressing is not clever — it is disciplined. The principles are well established and boring on purpose: separate address types, allocate hierarchically so routes aggregate, reserve generous headroom, and deploy IPv6 from the start instead of bolting it on later. This guide walks through each, with the failure modes that make operators wish they had read it sooner.

Separate the three kinds of addresses

The first and most important rule is to keep distinct, clearly labeled pools for fundamentally different purposes. Mixing them is how a network becomes impossible to reason about under pressure.

The practical payoff of separation is that you can write firewall and routing policy by block. “Anything from the infrastructure range should never appear as a source on a customer port” becomes a single, auditable rule. When infrastructure, subscriber, and public addresses are interleaved, every policy needs exceptions, and exceptions are where outages hide. Reserve your loopback and link space generously and contiguously from the start — it is small relative to subscriber space and almost never needs to grow, but renumbering loopbacks later is genuinely painful because they anchor your routing and management.

Allocate hierarchically so routes aggregate

Aggregation — also called summarization — is the single highest-leverage idea in addressing. The goal is that a router near the core can represent an entire region, POP, or access node with one route instead of hundreds. You achieve it by allocating address space geographically and topologically: a large block per region, subdivided per POP, subdivided per access node, subdivided per customer segment. Done well, a single summary route advertised from a site covers everything behind it.

The benefits compound. Smaller routing and forwarding tables mean cheaper hardware and faster convergence. Failures stay localized — a flap behind one access node does not ripple a thousand specific routes through the core, because the core only ever saw one summary. And your interior routing protocol stays calm; if you run OSPF or IS-IS, hierarchical addressing is what lets you draw clean area boundaries and summarize between them. The cardinal sin here is first-come-first-served allocation: handing out the next free block to whoever asks, with no relationship between an address and where it physically lives. It works for a while and then it never aggregates, and you cannot retrofit hierarchy onto live customers without renumbering.

Leave real growth headroom

Every level of the hierarchy needs slack. Allocate per region, per POP, and per node with deliberate headroom, because the failure mode of running out of space inside a region is exactly the renumbering you designed the hierarchy to avoid. If a POP's block fills and the only free space is in a different region's range, you have broken aggregation — that POP now needs a second, non-contiguous block advertised separately, and your clean summary is gone.

Headroom is cheap in IPv4 only relative to the cost of renumbering, and IPv4 is genuinely scarce now, which forces a tension: reserve too little and you renumber; reserve too much and you exhaust a finite resource. The standard resolution is to be generous with the structure (leave gaps in your numbering plan so blocks can grow into adjacent space) while being conservative with what you actually assign to customers. You can reserve a large block per site on paper and only light up a fraction of it — the reservation costs nothing until used, but it guarantees that when the site grows, the contiguous space is there.

Deploy IPv6 properly, from the start

IPv6 is not a future project to defer — it is the structural escape from IPv4 scarcity, and the cost of retrofitting it later is a second migration on top of your first. With a registry IPv6 allocation you have, for practical purposes, unlimited space, which changes the planning mindset entirely: you stop conserving and start organizing. Hand each subscriber a consistent prefix (a /56 or /64 per customer are common choices depending on how much you want home networks to subnet), mirror your IPv4 hierarchy so the same site maps to the same place in both plans, and run dual-stack so customers prefer IPv6 where the destination supports it and fall back to (often CGNAT'd) IPv4 only where they must.

The discipline that trips people up is resisting the urge to “save space” in IPv6 — there is so much of it that tight allocation creates more problems than it solves, because non-uniform prefix lengths make automation and reasoning harder. Pick a consistent per-subscriber prefix and stick to it. Because IPv6 directly relieves the IPv4 pressure that drives CGNAT, every customer you move to working IPv6 reduces load on your CGNAT pool — the two strategies are complementary, not alternatives. For the wider IPv6 rollout picture, see IPv6 for ISPs.

Document, automate, and use IPAM

An addressing plan that lives only in a senior engineer's head is a liability that grows with every assignment. The discipline of IP Address Management (IPAM) is simply this: every block has a recorded owner, a purpose, and a status, and no assignment happens outside the system. At small scale a rigorously maintained spreadsheet beats nothing; past a few thousand customers, a real IPAM tool that prevents collisions and tracks utilization earns its keep quickly. The failure mode without it is duplicate assignments — two customers, or a customer and an infrastructure link, handed the same address — which produces intermittent, maddening reachability problems that take hours to trace.

As you scale, the next step is to stop assigning addresses by hand at all. Tie address allocation to your provisioning and billing system so that activating a subscriber pulls the next address from the correct pool automatically, records it, and frees it on disconnect. That closes the loop between addressing and operations: assignments become consistent, auditable, and self-documenting rather than ad hoc. Platforms like ISP Digital integrate subscriber addressing with provisioning so the IPAM record and the live network never drift apart.

Common mistakes

• First-come-first-served allocation — kills aggregation permanently; address always reflects topology.
• Mixing infrastructure and customer space — turns simple policy into a minefield of exceptions.
• No per-site headroom — the fast path to the renumbering you were avoiding.
• Treating IPv6 as “later” — guarantees a second migration and leaves you fighting IPv4 scarcity longer.
• Inconsistent IPv6 prefix lengths — breaks automation; pick one per-subscriber size and hold the line.
• Addressing in someone's head — no IPAM means collisions, and collisions mean intermittent outages no one can explain.

The takeaway

Structure beats cleverness in addressing, every time. A boring, hierarchical, well-documented plan with honest growth headroom and IPv6 deployed from day one will outserve any efficient-but-opaque scheme you could devise — because the whole value of an addressing plan is realized years later, under pressure, when you need a route to aggregate or a block to grow or a fault to localize. The hour you spend designing separation, hierarchy, and headroom now is the weekend you do not spend renumbering live customers later. Start with the registry allocation, mirror your IPv4 and IPv6 plans, reserve generously and assign conservatively, and let your provisioning system, not a spreadsheet you forget to update, be the source of truth.