IPv4 Address Space Planning Best Practices

Question

A recent question from Craig Constantine pertained to IPv6, but many people are not on the leading edge with IPv6 yet and are still responsible for new or improved IPv4 deployments.

I would like to validate my own enterprise IPv4 address space planning against any public documents or guidance given directly here. Addressing has some unique needs between the DC and Campus that would ideally be considered.

I'm specifically looking to see what best practices exist for planning out private (RFC1918) IP space assignments for regions, cities, campus, buildings, floors, uplinks, WAN links, loopbacks, etc. Wired vs wireless. Internal networks vs. guest networks. *I know this on its own can be a bit of an open-ended question, so I'm looking for specific references or examples to proven and well-thought out plans in a similar way as to the IPv6 answers. Suggested CIDR blocks would be helpful as the space gets allocated.

Aggregation for routing, of course, is desired, and so is the ability to have simplified ACLs. There's a trade-off in ACLs on with the desire to aggregate all employee subnets, for example, whether wired or wireless vs aggregating all wireless users regardless if they are employees, contractors, or guests.

Answer 1

Being in a semi-small company, we broke down our private network somewhat liberally as so:

/24 per Vlan /16 per location

Vlans are spread out, skipping 10 /24s per. Vlan number matches the third octet. Locations are sequential, starting 10 /16s in.

i.e.

• 10.10.1.0/24 - Location A, Management Vlan 1

• 10.10.11.0/24 - Location A, Wireless Vlan 11

• 10.11.11.0/24 - Location B, Wireless Vlan 11

• 10.11.81.0/24 - Location B, SAN Vlan 81

• 10.11.101.0/24 - Location B, Wired Office Vlan 101

Vlan examples:

• 1 - management

• 2 - management for wireless

• 11 - wireless access

• 21 - guests

• 31 - mobile devices

• 41 - factory equipment

• 51 - SAN

• 61 - VoIP

• 71 - Wired access

And so on.

The benefits we saw with this are:

• Easy to refer to an entire location via /16. We use this quite often for VPN ACLs.

• Easy to group device types together for web filtering.

• Any Vlan within the next 10 /24s belongs to the same type as the previous root.

  • So for example, factory equipment... Vlan 31, for certain vendors who have 24/7 remote access, we gave them their own Vlan, 32 or 33 or 34, up to 40. Their VPN access limits them to the equipment that they support without getting granular on IPs/ACEs. If the manufacturing team needs to drop more equipment in, we don't have to update the VPN ACLs. This also includes access ACLs/ACEs between Vlans.

  • Another example: SAN Vlans, we use two of them at minimum for redundancy. So they are always 81 and 82.

  • Last example: Wireless management is broken out to its own Vlan, 2. We do this because we have enough APs to need a WLAN controller but no budget for controllers. This Vlan uses tftp and dhcp options to auto configure and boot the APs from a central config repo and we don't want other equipment that can auto boot to pull the wireless configs.

This setup gives us an easy way to look at an IP and know the location and type of equipment it belongs to. This means less ACLs/ACEs in configuration files for us, especially on limited VPN users. We also have breathing room for expansion in the event we run out of IPs in a Vlan or because we need to further segregate traffic. And since we're a small company, we haven't broken into three digit location numbering yet. Plenty of growth room.

Answer 2

Given that IPv4 has been around for so long there are million different ways that people choose to allocate their IPv4 space.

For us (an ISP) we use the smallest subnet size possible on pure transit links (/30 usually) and then in terms of customers it depends on what their needs are, due to how short everyone is on IPv4 means that instead of using a blanket rule you have to take every customer as their own entity and gather their requirements accordingly.

That is all ofcourse if you were referring to PUBLIC IPv4 space, in terms of the internal RFC1918 stuff then plan your allocations so that you build in room for expansion (e.g. a building only has 50 people in it, dont give them a /26 just because its the next sized subnet but perhaps give them a /24 to allow for expansion.

Another good practice is to allocate to aggregate, that is if you have a building with 10 floors allocate a /20 (or larger) to the building and then allocate the subnets for each floor/department out of that /20, that way you can advertise only the /20 to the rest of your network rather than all the individual subnets for each floor.