Private addressing starts here
The 172.x.x.x space is one of three RFC 1918 private ranges, but most people treat it like a guessing game. It spans from 172.16.0.0 to 172.31.255.255, which gives you exactly 1,048,576 unique addresses split across 16 contiguous /16 blocks. That's more than enough for most organizations, but only if you plan the subnetting before you buy hardware. I've seen teams blast through those 16 blocks in about six months because nobody documented the allocation scheme. The addresses never conflict internally, sure, but once you need VLAN segmentation or a DMZ, the mess becomes impossible to untangle without tearing the network down. I don't recommend starting at 172.16.0.0 on day one. I've watched engineers lose entire weekends troubleshooting DHCP scope collisions that traced back to a previous admin who borrowed a /24 from 172.18.0.0 and forgot to document it. My rule is simple: pick a /12 block, write it down, and never let anyone borrow outside those boundaries without updating the spreadsheet. You'll spend about ten minutes establishing the scheme now instead of six hours chasing ghosts later. The common mistake is assuming 172.16.0.0 is somehow "standard" or that 172.32.0.0 would be a safer starting point. It isn't. 172.32.0.0 and above are public addresses, and if you accidentally configure anything there on a private interface, the device will happily accept it. Your upstream ISP sees traffic from a public IP source and routes it normally. The return path breaks somewhere down the line and you get half-open connections that look like a misconfigured routing table but are actually just a single wrong subnet mask on a single switch port.
Subnet math that actually matters
A /20 gives you 4,096 addresses with 4,094 usable hosts. A /24 gives you 256 with 254 usable. Most people default to /24 everywhere because it's comfortable and familiar. It works until you need to host 600 devices on a single segment, at which point you're either running out of addresses or stacking routers between VLANs unnecessarily. The /20 sits between those two extremes and handles mid-size deployments without the overhead of multiple subnets managing the same broadcast domain. I keep a reference chart on my desk because I can't memorize every mask permutation. Here's the practical part: 172.16.0.0/12 means the first 12 bits are the network portion. That locks 172.16 through 172.31 as your usable block. Everything else is reserved. If you allocate a /16 to a building, you're using all 65,536 addresses there. For a typical office floor with wireless endpoints, camera systems, and workstations, that's overkill. A /20 or /22 fits most floors without eating your allocation budget. The math checks out fast enough that you can do it on a whiteboard during a site survey.
What happens when NAT collides with upstream providers
Here's something most guides skip. When your 172.x.x.x network sits behind CGNAT from your ISP, the double NAT situation creates problems that aren't obvious until you need port forwarding or VPN passthrough. You'll see symptoms like gaming latency spikes, VoIP registration failures, and VPN tunnels that drop after thirty minutes. The fix isn't usually a configuration change on your side. It's requesting a public IPv4 block from the ISP or switching to an IPv6-capable WAN link. I spent three weeks troubleshooting a VPN issue that turned out to be the provider's CGNAT session timeout clearing the tunnel every eighteen minutes. Switched the client to IPv6-only and the problem vanished immediately. Another edge case I deal with regularly: some older medical imaging equipment and industrial controllers hardcode 172.16.0.1 as their default gateway and refuse to accept custom gateway assignments. If you're integrating legacy hardware, you need a dedicated flat subnet with no routing through the main 172.x infrastructure. I allocate a /28 specifically for these devices so they never touch the production VLANs. It's a small price to pay for not having to physically unplug a CT scanner every time someone reboots the core switch.
Get the Full Details
DHCP and DNS considerations
DHCP reservations matter more in the 172 range than most people realize. If you hand out 172.16.5.50 to a print server and then someone provisions a new server at 172.16.5.50 manually, you'll get an IP conflict that shows up as intermittent connectivity loss. The other device doesn't necessarily fail, but ARP cache poisoning makes traffic bounce unpredictably. I use DHCP scopes with generous reservation pools and keep a live inventory sheet updated in real time. When a new device joins, I log it immediately. Ten seconds of logging saves hours of troubleshooting later. Internal DNS for private addresses should resolve to the RFC 1918 space only. I've seen cases where split-horizon DNS leaked 172.x.x.x lookups to public resolvers, which caused internal name resolution to fail when the public zone took precedence. The workaround is straightforward: configure your internal DNS servers with zone files that override any external resolution for the 172.16.0.0/12 range. Test it by querying from inside and outside the network. If both return the same private address, you've done it right.
When the 172 range stops working for you
The 172.x.x.x space runs out of room if you're managing a campus with more than roughly 1,048 private hosts across multiple buildings, especially if you need large host segments. The constraint isn't the total address count. It's the 16 /16 block limit built into RFC 1918. Once you fill those sixteen blocks, you can't extend further without moving to a different private range or renegotiating your allocation with whoever manages the addressing scheme. I've hit this ceiling at a mid-size hospital deployment and ended up consolidating to IPv6 for new equipment while keeping the 172 range for legacy systems. It's not elegant, but it works until the old gear gets replaced. The honest limitation nobody talks about: 172.16.0.0/12 was never designed for modern cloud-native architectures. Containers, microservices, and multi-tenant environments expect larger contiguous blocks and dynamic address allocation. If you're building something that scales beyond a few hundred nodes, the manual subnet planning approach breaks down fast. In those cases, moving to IPv6 or using overlay networks with built-in address management is the cleaner solution. The 172 range is still perfectly viable for traditional enterprise networks, but pretending it fits every scenario just creates technical debt. I stop managing 172.x.x.x allocations manually once I cross two hundred subnets. At that point, I script the entire allocation process with Python and IPy libraries, and I let the automation handle the math. It cuts provisioning time from about forty minutes per new VLAN down to roughly two minutes, and it eliminates the human arithmetic errors that cause most of the conflicts I mentioned earlier.
