How ISPs Manage IP Allocation on a Large Scale

A new customer connects, another moves premises and a third needs a stable address for a hosted service. At ISP scale, these changes happen continuously. Address management has to connect each customer request to capacity, routing and a record the next operator can understand.

The useful starting point is the running network: which services must remain reachable, how addresses reach customers and which changes can be made without disrupting existing connections.

Separate obtaining space from using it

An ISP's address inventory may contain long-held resources, registered transfers, leased space and space supplied through another provider. The applicable arrangements differ. Once a resource is available to the operator, it still needs an internal plan, working routes and customer provisioning.

A registry record and a route announcement do different jobs. Registration records coordination information; routers forward traffic according to their configuration and the routes they accept. Keeping those layers consistent is operationally important. Treating the administrative layer as the owner of every network beneath it is a further political claim, which Lu Heng challenges in Note 67.

Divide space around the service

Allocate pools to access regions, customer classes or infrastructure roles, leaving deliberate room for growth and recovery. CIDR describes blocks using a prefix length: an IPv4 /24 contains 256 address values. That arithmetic alone does not tell you how many customers a design can serve.

Some customers need an individual address; others need a routed prefix containing many addresses. Network, broadcast and provider reservations depend on the design. Avoid using a city's population or the label “national ISP” as a shortcut for choosing a block size.

CIDR's routing and aggregation model also explains why a coherent address plan can reduce the number of separately advertised routes. Aggregation must still match the actual paths: a tidy inventory cannot make an unreachable destination reachable.

Make each assignment traceable

Record the customer or service, prefix or address, access node, routing context, assignment method and relevant start and end times. Dynamic sessions and static assignments have different lifecycles. DHCP leases, access-session systems and provisioning APIs need to feed the record that operators use.

Before expanding a pool, compare planned assignments with observed demand at busy times. A large total allocation can hide an exhausted local pool. Conversely, an empty-looking range may be reserved for failover rather than forgotten.

Choose sharing and protocol support deliberately

With address-and-port translation, often called NAPT and commonly included under “NAT”, several customers or devices can share public IPv4 space. Carrier-grade NAT adds operating requirements, including capacity planning, application compatibility and time-specific mapping records. A public address alone may then identify several users.

IPv6 offers a much larger address space and supports different customer prefix plans. It does not automatically deliver access to an IPv4-only destination. Evaluate native IPv4, dual stack and translation designs against the services customers actually use, along with support effort and recovery behaviour. None of these choices should be reduced to a slogan.

Protect continuity through ordinary changes

A customer departure is a small change with several dependencies. Confirm the assignment has ended, remove or update the relevant routing and name records, check remaining service references and only then return the resource to a suitable pool. Keep the earlier assignment history instead of overwriting it.

Routing monitoring, source-address filtering and DNS security address different failure modes. DNSSEC authenticates DNS data; it does not validate an IP assignment or stop every routing attack. A useful operations view shows these separate signals without claiming one control solves all of them.

Let coordination support the people running the network

Regional teams can manage their pools while maintaining a shared, inspectable record. The organisation needs a way to correct mistakes, export meaningful data and replace a failed management supplier. A hierarchy used to organise numbers is not, by itself, a mandate to exercise political power over everyone using them.

For Lu Heng's proposed boundary between necessary coordination and institutional control, read Note 72. For practical checks inside an organisation, continue with common IP resource management mistakes.