IP Planning in Telecom: A Guide for Service Providers

For a service provider, IP planning is a different discipline from the enterprise version of the same task. A data center team plans addresses so that devices can be found and documented, but an ISP or telecom operator plans addresses as a revenue product: every block has a procurement history, every subscriber pool has a utilization curve, and every assignment may need to be justified to a registry or reconstructed for a compliance audit. The constraints have also changed permanently. Every regional internet registry has exhausted its free IPv4 pools, new public space now moves through brokers and waiting lists at prices that make each /24 a budget line item, and the natural growth path runs through IPv6, which providers have been slow to embrace even though the address space is effectively free.

The practical stakes are visible in the failures you see across the industry: a routing table bloated by non contiguous allocations from an unplanned acquisition, a subscriber pool exhausted mid launch because nobody tracked utilization, a CGNAT deployment with no logging that cannot identify a subscriber when law enforcement asks, an IPv6 plan that stops at the broadband network gateway and leaves the subscriber segments on IPv4 forever. This guide walks through how service providers should structure their address plans, starting with the registry relationship, moving through hierarchy design and subscriber addressing, and ending with the operational discipline that keeps the plan accurate over years of growth.

At a Glance: Subscriber Addressing Approaches

Start with the Registry Relationship

Every prefix your network announces traces back to a regional internet registry, and that relationship determines what you can plan. If your organization is a Local Internet Registry holding its own allocation, the space is yours to divide: RIPE NCC hands new LIRs a /32 of IPv6 by default and, for IPv4, a place on a waiting list that has grown to hundreds of organizations and more than a year of queue time. If you are not an LIR, your space comes from an upstream provider or from the transfer market, and that distinction shapes your planning in concrete ways, because transferred blocks are rarely contiguous with anything you already hold, and every non contiguous block is a separate aggregate you must carry in your routing table and in your documentation.

The transfer market has become the de facto way providers obtain IPv4, with millions of addresses changing hands every month in some regions. Each transaction carries registration obligations, so the first rule of service provider IP planning is to record the provenance of every block you operate: the registry, the previous holder, the transfer approval, and the contract that governs it. When a registry review or an audit arrives, that provenance is exactly the evidence you will be asked to produce, and it is far easier to capture at acquisition time than to reconstruct years later from email threads.

Your registry relationship also carries a stewardship obligation that should shape how you track space internally. Registries expect utilization evidence when you request a larger IPv6 allocation or a transfer, and they expect your registration records to stay current as space is reassigned or returned. If your internal records match the registry’s records, those requests become a documentation exercise; if they do not, every request turns into a reconciliation project that starts from scratch.

Design the Hierarchy Before You Number Anything

The hierarchy is the plan, and it has to be designed before the first address is assigned. Start from the registry allocation and divide it by region or point of presence, then by function within each location: backbone and transport, loopbacks, interconnect and transit, management, subscriber pools, and a clearly marked block held for growth. The structure you impose now determines whether the network can summarize routes at the core, because aggregation works only when related prefixes live in adjacent ranges, and a provider that lets allocations drift randomly ends up carrying thousands of individual routes where one aggregate would do.

Infrastructure ranges deserve special discipline because their failure modes are silent. Point to point links between routers should be /31s in IPv4 as permitted by RFC 3021, and /127s in IPv6, sized to carry exactly the two endpoints instead of wasting a subscriber sized segment on a single conversation.

Loopbacks are /32s and /128s that never get advertised beyond your own network, and management ranges should be isolated from subscriber traffic entirely, which is where VLAN and subnet management becomes an operational control rather than a documentation nicety. If your team enforces these conventions from day one, an engineer looking at any address can tell from the prefix alone whether it is a backbone link, a management device, or a subscriber, which is worth more than any amount of free text description.

Plan Subscriber Addressing as a Product Decision

Subscriber addressing is the most consequential decision in the whole plan, because each approach is a product tradeoff rather than a purely technical one. Dedicated public IPv4 gives every customer full inbound reachability and the simplest CPE behavior, but it consumes address space at a price that now has to be defended in front of finance. Carrier grade NAT shares a small pool of public addresses across many subscribers using the 100.64.0.0/10 range, which preserves your remaining IPv4 but introduces per subscriber state at the gateway, port exhaustion risks, and logging obligations that some regulators require you to retain. Dual stack gives each subscriber native IPv6 with IPv4 translation only where it is still needed, which is the direction the industry is moving for good economic reasons.

The mechanics of assignment reinforce why the plan has to be explicit. Subscribers terminating on PPPoE or IPoE sessions draw addresses from the pool configured on the broadband network gateway, DHCP pools serve other access types, and business customers often need static assignments that must be reserved rather than drawn dynamically. Each mechanism has to be recorded against the product it serves and the site it terminates in, because the address pool is not a technical detail, it is the point where your revenue, your routing, and your compliance obligations intersect.

The operational details around the pools matter as much as the choice itself. You need to size each pool against the number of subscribers it will serve, the average session count per subscriber, and the peak demand hour, then add headroom for growth, because renumbering a live pool means touching every CPE in the region. Churn has to be handled explicitly: when a subscriber leaves, their address or lease has to be reclaimed and returned to the pool, and when a subscriber is reassigned a different address, any logs that depend on address identity have to keep working. These are exactly the situations where an unrecorded assignment turns into a support ticket, a security inquiry, or a silent capacity leak.

Make Room for IPv6 Early

Every regional registry has exhausted its free IPv4 pool, so the only growth path that does not cost you money per subscriber is IPv6. A /32 LIR allocation holds roughly 65,536 site sized /48 prefixes, which is effectively unlimited capacity for a provider of almost any scale, and requests up to /29 are granted with a documented plan. The convention that works is simple: one /48 per site, one /64 per subscriber segment so that SLAAC functions as designed, and a /56 or /48 delegated to residential CPE through DHCPv6 prefix delegation so that home networks can subdivide their own space without colliding with the provider’s plan.

The rollout order matters. Enable IPv6 on your backbone, interconnect, and management ranges first, while the only traffic on the new stack is your own, then bring subscriber segments up one region at a time with a dual stack configuration that keeps IPv4 working in parallel. The mistake that wastes years is treating IPv6 as an infrastructure project that ends at the broadband network gateway, leaving subscriber segments on IPv4 only, which is precisely where the address pressure lives. Each segment you convert removes a slice of demand from your IPv4 pool and from whatever you pay for it on the transfer market, and a unified IP planning workflow is what keeps the two families in step as you roll out.

Plan for Business and Provider Independent Space

Business services complicate the plan because they bring addresses you do not fully control. Customers with provider independent space announce their own prefixes through their own BGP sessions, which means your network carries their routes and your documentation has to track which customers terminate at which edge, with which autonomous system numbers, and under which agreements. Customers without PI space take provider aggregatable addresses from your ranges, and the discipline that protects you is a clear rule about how those ranges are carved, because a business block reassigned every few years will fragment your aggregate if it was not planned for that.

The planning question for business services is therefore where the boundary sits between your address space and the customer’s. If you provide dedicated internet access with your own addresses, you retain control over the block and the responsibility to track its utilization. If the customer brings PI space, you are a transit path, and your records need to capture the customer ASN, the prefixes they announce, and the port they terminate on, so that an abuse report, a peering dispute, or a maintenance window can be resolved from your source of truth rather than from a router that nobody has touched in two years.

Track Utilization Like a Financial Ledger

Address space is inventory with a cost basis and a utilization obligation, and it has to be managed like one. Your registry expects utilization evidence when you justify a new allocation, your budget expects to know what each subscriber pool costs, and your planning process needs to see which pools are approaching exhaustion before a launch deadline forces the question. The discipline is continuous rather than quarterly: utilization changes with every subscriber, every churned account, and every decommissioned service, so a snapshot from three months ago is not a plan, it is a guess.

The tools you need are the ones that make the ledger automatic. Utilization should be visible at every level of the hierarchy, from the /32 allocation down to a single /24 subscriber pool, so that exhaustion dates can be projected from real trends instead of discovered during a provisioning emergency. Stale assignments are a cost center that most providers underestimate: addresses held by services that were decommissioned, pools reserved for products that never launched, and ranges that were allocated on paper but never used. A reclamation pass that returns those to the pool is often the cheapest way to buy capacity, and it only works when the records are structured enough to identify what is stale in the first place.

Document the Assignments or Lose Them

The plan survives only if the assignments are recorded with enough structure to answer the questions that come up years later. A CGNAT logging requirement asks which subscriber held which translated address at which moment, which is unanswerable unless your assignment history is complete and timestamped. A registry review asks how a block is utilized, which is unanswerable unless every subnet and address in it is accounted for. A troubleshooting session asks which device, VLAN, and site an address belongs to, which is unanswerable if the record is a row in a spreadsheet that three people edit independently.

That is why service provider IP planning depends on a source of truth that connects addresses to the rest of the network. When a subscriber pool is linked to its network topology, its gateway device, and its site, an engineer can trace a reported address back to the physical path in minutes instead of reconstructing it from memory. When every change carries an audit trail with the responsible user and the time, compliance questions become routine lookups. And when the same system tracks your IP address management alongside device inventory and circuits, the documentation does not drift into a parallel universe that nobody trusts, it stays current because it lives where the work happens.

Structuring Service Provider Address Space with Obelinf

Obelinf is built to model a service provider’s address plan as structured, connected records rather than a flat list: your registry sized allocation becomes a subnet, each region and subscriber segment gets its own subnet and address pool, and CIDR validation plus duplicate detection catch miskeyed ranges before they reach production. Subnets link to the VLANs and VRFs that carry subscriber traffic, addresses link to the devices that terminate them, and utilization is visible on every subnet and pool so you can see one approaching its limits before it runs dry. Every allocation, reclamation, and change is recorded in an automatic changelog with user identity, giving you the audit trail that CGNAT logging, registry reviews, and internal compliance all demand without any extra effort.

Because the address plan shares one data model with your sites, devices, circuits, and network topology, the questions that used to require three tools now have a single answer: which subscribers ride this pool, which gateway terminates it, and when the assignment changed. The same relationships that keep your routing table aggregatable keep your documentation accurate, because both are maintained from the same source of truth rather than from parallel records that drift apart. For a provider planning its next region, its next subscriber product, or its next IPv6 rollout, that is the difference between an address plan that documents the network and one that actually operates it.