Doing IP Addressing Right

Author
Peter Welcher
Architect, Operations Technical Advisor

In my years of consulting, I’ve run across some interesting IP addressing schemes. “Interesting” as in “yuck” or “hot steaming mess.” You may have too. In fact, you may have inherited one or ended up with one. Hey, nobody said this is easy.

TL;DR: What are some goals for IP addressing, common approaches, and how to “clean up” an addressing scheme.

Note that much of what I have written below uses “IP” generically, i.e., it applies equally to IPv4 and IPv6. Note that even if your IPv4 scheme is fugly, IPv6 gives you a chance to Do It Right.

What Does a Good IP Addressing Scheme Look Like?

What do you consider to be a good IP addressing scheme?

I want several things from any IP addressing scheme:

  • Route summarization. I don’t want /30 or /31 or small prefixes in the routing table. (Anycast might call for some /32s, oh well!)
  • Location indication. As in, I can look at a short printout of IP blocks or something (2nd or 3rd octets) and tell roughly where the address is located.
  • Segment indication. If the network is segmented, it can be very helpful to be able to easily ID which segment a device is in. I’m thinking VRFs here, with logically separated routing per VRF.
  • Good use of IP space. This can be hard to get right since really using IP blocks efficiently is at odds with having, at most, a couple of common subnet sizes. Using IP blocks fully also means you can run out and end up with secondary addresses (yuck) and more wasted IP space. So, this wish list item is a bit squishy. “Not overly wasteful of space”?
  • Plan for the Future. Does the addressing scheme provide some headroom for growth in the number of sites, number of segments, number of endpoints (think IOT), etc.

I personally prefer L3 to the access layer. Yes, L2 is cheap and easier to deploy. But L2 is also a pain when spanning tree etc., messes up. L2 to access layer also hinders tracking down a device’s location. (MAC address tracing = more work!)

Having said that, L3 to the access layer may consume more addresses. I think that’s debatable. If you assume one IP or two IPs per switch port, plus some spares, it should be pretty much a wash. At least, that’s what I’m currently thinking.

For one large site, we created addressing that was roughly 10.13 location bits (building/floor/closet) + (3 segment bits) + host bits (e.g., /24). The annoyance there was that some firewalls and other network devices don’t expect discontiguous bits in wildcard masks. So doing ACLs that matched on segment couldn’t be wildcarded, resulting in “laundry list” ACLs. That might be a case of overthinking things or “being too clever”.

It does lead to a consideration about addressing with segmentation. Do the location bits or the segment bits come first? The latter approach lends itself better to ACLs.

What Does a Bad IP Addressing Scheme Look Like?

Top of the list: failure to use DHCP for all but servers. And yes, there are sites that still hard-code IP addresses into devices. That might be a Worst Practice.  But maybe there was a Security reason? Color me skeptical.

One scheme I’ve seen divided up internal private network 10, a popular sport. Lots of space, but ad hoc subnet sizes, sequentially assigned as subnets at various sites were needed. I think it was something like 9000 different prefixes. Ignoring the really small sub-prefixes, I whittled it down to about 900 larger blocks that were occupied to some degree. And just couldn’t really get my arms around it, in terms of any rhyme or reason for any but the new CSP blocks.

Although staff had started doing location-based assignments more recently, there were a lot of legacy subnets. Basically, random sequential /24s and smaller.

That means no quick location indication, so you’d have to look up the address in the IPAM tool. (Hopefully with good location documentation, or better, location built into DNS name so you don’t have to open the IPAM tool.)

If you have the above problem, you may well have to advertise every small prefix into WAN routing. Which has drawbacks. That’s a good topic for a follow-on routing blog I’m considering writing.

As noted earlier, if you run out of address space, that indicates poor planning. (Is it 5 or 7 Ps: Proper Planning …?).

Use /31s?

Having /31 subnets is *really* efficient use of address space. I’ve done it in places. Only to discover that there are vendors who don’t support /31. That resulted in a mix of /30 and /31 addressing for point-to-point links.

For that reason, I lean towards /30 for all point-to-point link addressing. YMMV.

HSRP/VRRP based adjacencies and forwarding tend to use /29s. I don’t have a better answer.

Tool Up!

One word: IPAM. (And DNS.)

Spreadsheets are not a great IPAM solution.

About Planning for the Future

Eventually, the future arrives, and your plan goes from ugly to sort of broken. Then more broken. Which raises the subject of re-addressing.

A good thought I came across: when doing IPv6, plan for a lot more devices, due to IOT. Which to me may also lead to many more segments. Since IOT devices may have security challenges, isolating them by vendor and/or specific device type may become necessary. See above re segments.

Cleaning Bad Addressing Up

Feeling masochistic?

Re-addressing can be time-consuming but is useful in terms of good hygiene. If end systems are on DHCP, re-addressing coupled with device replacement (and L3 to the closet) can work out well. (And shift the workload to whoever gets contracted to deploy the new stuff.)

FWIW, I read somewhere that Chrysler used to re-address every 3 years.

You’ll need space and time.

Space: you’ll need adequate address space for transition, roughly 2x as much addressing space. That could be tough to obtain! Ditto a new IP block.

Time: re-addressing is painful cleanup and can take quite a while. So re-addressing cannot be your top priority.

Management support: you will probably break things, despite best efforts. Try to do so in a controlled easily-resolved way.

Data centers generally require lots of time. You can do clean addressing for new servers or VMs or container groups. But old servers can take 10 or more years to go away. And some apps hard-coded addresses, making those even harder to change. Such things can fall into the “life is too short” category.

Access Lists

Good addressing can help with security access lists.

For instance, having a common subnet mask for campus or for data center subnets (/24?) reduces the likelihood of getting the subnet mask wrong in a security rule. Or maybe two or three: “small”, “medium”, and “large” subnets as needed per location.

For one site with some large buildings and many smaller ones, having one subnet size for the large (heavy Layer 2) buildings and another size for the small buildings enabled efficient use of IP space.

As hinted earlier, if you need ACL rules for different VLANs or other segments, then having segment bits before location bits in addressing might be helpful. Another way to describe this is to assign IP blocks by segments, then within those, divide up similarly by location.

Some Other Thoughts

“IP addressing” encompasses both IPv4 and IPv6. The same principles apply. If you haven’t implemented IPv6 yet, you have a chance to “re-do” things the right way! Don’t miss the opportunity!

And IPv6 has *lots* of space. So plan for *lots* of growth, and don’t be shy about it!

Also note that if you or your predecessors did not plan for growth, you may be about to run out of IPv4 addresses. The world has run out of IPv4 addresses – see the address exhaustion links below. You can implement IPv6, or you can do IPv4 NAT. While NAT works, it adds complexity and could be considered “digging the hole you’re in deeper. NAT at every site is a nightmare.

Admittedly, security teams sometimes have a problem with IPv6 global routability. What, no NAT? See the link below concerning that.

Links re Addressing Best Practices

Some Google searches led rapidly to the following and more! However, most of what I found deals with very specific situations, rather than the big picture. E.g., reserving the first say 16 (not 10, please) addresses in a /24 for the routers, printers, etc. FWIW, I do NOT like having router addresses at the end of the address block, I like them to be .1 for HSRP/VRRP (if in use), .2, .3 for the HA pair, etc.

And this blog is more about the overall big picture.

https://www.networkcomputing.com/networking/ipv4-subnetting-best-practices

https://climbtheladder.com/10-ip-addressing-scheme-best-practices/

(I disagree with that one re NAT. I would not want lots of sites, each doing NAT to each other and the outside world.)

I came across the following, which you might find interesting reading:

Cisco on Cisco Best Practices Cisco IP Addressing Policy (pdf)

Links: Other Related Topics

https://en.wikipedia.org/wiki/IPv4_address_exhaustion

https://www.internetsociety.org/deploy360/ipv6/faq/

https://www.ccexpert.us/network-design/planning-the-ip-addressing-hierarchy.html

https://afrinic.net/support/general-queries/how-to-develop-ipv4-addressing-plan

https://www.internetsociety.org/blog/2015/01/ipv6-security-myth-3-no-ipv6-nat-means-less-security/

Conclusion

This topic is a broad topic, and I’m also sure there are strong and varied opinions. I’ve tried to touch on the main things I’ve noticed over the years, rather than getting too bogged down in smaller details.

Disclosure statement