A well-designed IP addressing plan is invisible: the network just works, new sites get addresses without conflicts, and operations staff can identify a device's role and location from its IP. A poorly designed plan is visible in the worst way: address exhaustion at growing sites, routing table entries that exist for no apparent reason, and nobody quite sure what the 10.50.x.x range is used for because the person who allocated it left three years ago.

Most Pakistani ISPs start with an ad-hoc addressing approach that works fine at launch and becomes a significant operational problem by the time the network reaches 20 sites. Rebuilding an addressing scheme on a live network with active subscribers is one of the more painful network operations tasks. Designing it correctly from the start takes a few hours and saves those days.

Separate the Address Spaces

Before allocating a single address, define the separate functional address spaces the network needs. These must not overlap, and each should be large enough for the network's realistic 5-year growth:

Subscriber space is where CGNAT subscriber addresses live. As covered in the CGNAT design article, use RFC 6598 (100.64.0.0/10) for this. Allocate a /16 per PoP or access zone: 65,536 addresses per zone is sufficient for any single-site subscriber population while keeping the allocation clean.

Infrastructure space covers router interfaces, switch management, server management, and point-to-point links. Use a dedicated RFC 1918 range, typically 10.0.0.0/8 with a structured sub-allocation scheme. Never mix infrastructure and subscriber addresses in the same range.

Management space may overlap with infrastructure or be separate depending on whether you implement a dedicated management VLAN. Dedicated management space (a specific /24 or /23 from your infrastructure range) makes firewall rules simpler: allow management protocols from this range and deny from everywhere else.

CGNAT public pool is your public IPv4 space used for NAT translation. This must be publicly routable addresses allocated to you from APNIC or your upstream provider.

Loopback addresses for router identification should come from a dedicated /24 or /23: one /32 per router, used as the router ID in BGP and OSPF, and as the stable management address that remains reachable regardless of which interface is up.

Point-to-point links between routers use /30 or /31 subnets. Allocate a dedicated range for all inter-router links: 10.x.y.0/24 giving 64 /30 subnets is sufficient for most regional ISP topologies.

Structured Allocation Within Each Space

Within each functional space, allocate in a structured hierarchy rather than filling addresses sequentially. For infrastructure:

Region or site level: allocate a /16 or /20 per major site or region. All infrastructure addresses at that site come from its allocation. If Islamabad is 10.1.0.0/16, all devices in Islamabad have addresses in that range.

Function level within each site: further subdivide by function. 10.1.1.0/24 for loopbacks, 10.1.2.0/24 for point-to-point links, 10.1.10.0/24 for server management, 10.1.20.0/24 for network equipment management.

This hierarchy makes the IP address itself informative: 10.1.1.5 is immediately recognisable as a loopback at the Islamabad site, while 10.2.1.5 is the same function at a different site. Operations staff who join after the addressing plan was designed can infer where a device is and what it does from its address.

Address Documentation

An undocumented addressing plan is almost as bad as no plan, because the implicit logic that made sense to the designer is not transferred when they leave. Document the addressing plan in a format that is maintained in parallel with the network: an IP Address Management (IPAM) spreadsheet at minimum, or an IPAM platform like NetBox or phpIPAM for larger networks.

The documentation should capture for each subnet: the prefix, the function, the site, the allocation date, current utilization, and the next available address within the subnet. For individual device addresses, record the hostname, device type, role, physical location, and management interface.

For CTDISR-2025 Section 3 (asset management), a maintained IPAM record is part of the asset inventory evidence: it shows that you know what is on the network, where it is, and what it does. An auditor who asks for your network asset inventory and receives a current IPAM export is in a much better position than one who receives a spreadsheet that hasn't been updated in 18 months.

Planning for Growth

Allocate more than you currently need at every level of the hierarchy. A /24 that fills to 240 addresses in the first year and then cannot grow forces a renumbering exercise. If you have a /16 available for infrastructure, allocating /20s to each site gives 16 sites before you approach the allocation limit, and each /20 gives 16 /24 subnets for functional separation within the site.

The cost of allocating generously is near-zero (unused addresses consume no resources). The cost of running out of addresses in a live network is high. Err toward more space per allocation rather than less.

For operators who need IP address management designed as part of a full network architecture engagement, Network Design & Optimization covers addressing as an integrated component of the topology design. For automation of address management including IPAM integration with provisioning workflows, Automation & Integrations covers the tooling and integration work.