How to plan an IP address scheme

Most networks don't get planned. They get accreted. Someone sets up 192.168.1.0/24 on day one, devices pile in, a second site appears with the same range, a VPN gets added, and suddenly two subnets collide and nothing routes. Renumbering a live network is one of the most painful jobs in IT, so the cheapest time to plan an addressing scheme is before you need one.

This guide walks through designing a scheme that scales: picking the right RFC 1918 range, sizing subnets with CIDR, aligning subnets to VLANs, and documenting it so the plan survives staff turnover.

Step 1. Count what you have, then triple it

Before picking ranges, inventory what needs an address:

• Workstations and laptops
• Servers and VMs (these multiply fast)
• Printers, phones, cameras, access points
• IoT and smart devices
• Network gear itself (switches, routers, firewalls all need management IPs)
• VPN client pools

Take your honest count per category, then plan for at least 3x. Address space is free; renumbering is not. A subnet that's 80% full on day one is a subnet you'll be splitting within a year.

Step 2. Pick an RFC 1918 range

RFC 1918 reserves three private ranges. They are not interchangeable in practice:

Two practical rules:

Avoid 192.168.0.0/24 and 192.168.1.0/24 entirely. Nearly every consumer router ships with one of these. The moment a remote worker VPNs in from a home network on 192.168.1.0/24, you have an address collision and broken routing. If you must use 192.168.x, pick an obscure third octet like 192.168.73.0/24.

Prefer 10.0.0.0/8 for anything with growth ambitions. Its size lets you encode meaning into the octets, which is where a scheme becomes self-documenting:

10.<site>.<vlan/function>.<host>

10.1.10.0/24  → Site 1, user VLAN
10.1.20.0/24  → Site 1, servers
10.1.30.0/24  → Site 1, VoIP
10.2.10.0/24  → Site 2, user VLAN

With this pattern, anyone reading a log line can identify site and function from the IP alone. That's worth more than it sounds at 2 a.m. during an incident.

Step 3. Size subnets with CIDR, not habit

A /24 (254 usable hosts) is the default reflex, but it isn't always right. Size each subnet to roughly double its forecast device count:

Usable hosts are always 2^(32 − prefix) − 2: the network and broadcast addresses are unusable. Run candidate ranges through the Subnet Calculator to get network address, broadcast, and usable range for each block before you commit. If CIDR arithmetic is rusty, how to calculate a subnet covers it step by step.

One alignment rule that prevents future pain: carve your allocations on clean binary boundaries. If site 1 gets 10.1.0.0/16, site 2 gets 10.2.0.0/16. Don't hand out overlapping or off-boundary blocks; route summarisation depends on it.

Step 4. Map subnets to VLANs

A subnet plan and a VLAN plan should be the same plan. One VLAN, one subnet, and ideally the VLAN ID matches the third octet:

VLAN 10 → 10.1.10.0/24  (users)
VLAN 20 → 10.1.20.0/24  (servers)
VLAN 30 → 10.1.30.0/24  (VoIP)
VLAN 40 → 10.1.40.0/24  (printers/IoT)
VLAN 90 → 10.1.90.0/27  (network management)

Segmenting by function isn't just tidiness; it's the foundation of network security. IoT devices on their own VLAN can't reach your file server when (not if) one of them is compromised. Inter-VLAN traffic passes through your firewall, where you can write rules like "printers accept print traffic from the user VLAN and initiate nothing." If you're auditing what currently talks to what, how to audit network security is the companion exercise.

Step 5. Reserve static ranges inside each subnet

Within each subnet, partition the host range by convention:

.1          default gateway
.2  - .9    network infrastructure (switches, APs)
.10 - .49   static servers, printers, fixed devices
.50 - .239  DHCP pool
.240 - .254 reserved for future static use

The exact split matters less than having one and applying it everywhere. Consistency means the gateway is always .1 on every subnet, and a static device is recognisable by its address alone.

For devices that need fixed addresses but support DHCP (printers, cameras, NAS boxes), prefer DHCP reservations over device-side static configuration. The address is pinned to the MAC address centrally, so changing it later is a DHCP-server edit rather than a tour of web UIs. The MAC Address Lookup tool helps when building the reservation list: paste a MAC from your DHCP lease table and it identifies the manufacturer, so you can tell the thermostat from the door controller.

Step 6. Document it where people will actually look

The plan only works if it's written down and kept current. Minimum viable documentation is a single table (spreadsheet, wiki page, or IPAM tool) with one row per subnet:

Plus a second sheet for individual static assignments and DHCP reservations. Update it as part of the change, not after; documentation written "later" is documentation that's wrong.

If your environment uses internal DNS, give every static device a name and verify forward and reverse records resolve with the DNS Lookup tool. Names in documentation age better than bare IPs.

Step 7. Leave room for IPv6

You don't have to deploy IPv6 today, but don't design a scheme that fights it. Two cheap moves:

• Mirror your IPv4 structure when you do allocate: if site 1 is 10.1.0.0/16, make it 2001:db8:1::/48, with VLAN 10 as 2001:db8:1:10::/64. The parallel structure means one mental model for both stacks.
• Every IPv6 subnet is a /64. Don't try to subnet smaller; SLAAC requires the full 64-bit host portion.

Common addressing mistakes

Using public IP space internally. Squatting on someone else's public range (a classic is 1.1.1.0/24) works until your users need to reach the real owner of those addresses. Stay inside RFC 1918.

One flat /16 for everything. A single broadcast domain with thousands of hosts means broadcast storms, no segmentation, and no security boundaries. Big range, small subnets.

Sizing subnets exactly. A /26 for 55 devices is full the day it ships. Double the forecast, round up to the next CIDR boundary.

Overlapping VPN pools. Remote-access VPN client pools need their own dedicated subnet that exists nowhere else in the organisation, or in common home router defaults.

Undocumented "temporary" statics. Every IP conflict ever investigated traces back to one of these.

TL;DR

1. Inventory devices per category, plan for 3x.
2. Use 10.0.0.0/8 and encode site/function into the octets. Avoid 192.168.0.x and 192.168.1.x.
3. Size each subnet with the Subnet Calculator at double forecast, on clean binary boundaries.
4. One VLAN = one subnet; match VLAN IDs to the third octet.
5. Standardise the in-subnet layout: gateway at .1, statics low, DHCP pool in the middle.
6. Prefer DHCP reservations over device-side statics; document every allocation as part of the change.
7. Structure allocations so IPv6 can mirror them later.

Related

• How to calculate a subnet - the CIDR arithmetic behind step 3
• Subnet Calculator - network, broadcast, and usable ranges for any CIDR block
• MAC Address Lookup - identify devices when building your reservation list