Most home routers hand out addresses starting with 192.168, so that prefix feels like the only private range that matters. It isn't. According to MakeUseOf, RFC 1918 reserves three separate chunks of IPv4 space for private networks, and 192.168.x.x is the smallest of the lot.
The other two blocks have been around since the mid-nineties and behave a little differently. Knowing what each one is good for explains a lot of odd network behaviour, from VPN quirks to the strange addresses Docker keeps inventing on its own.
What happened
- RFC 1918 sets aside three private IPv4 blocks for any network to reuse without coordinating with IANA.
- 192.168.0.0/16 is the most familiar; 10.0.0.0/8 is the largest; 172.16.0.0/12 is the easiest to misread.
- Private addresses only work locally because routers use NAT to share one public IP with many devices.
- The 172.16 to 172.31 stretch hides a trap: anything just past 172.31 is a public address, not a private one.
- Docker and most container networks default to the 172.x block, which is why it shows up unexpectedly on homelab setups.
Why 192.168 hogged the spotlight
Router manufacturers standardized on 192.168.0.1 and 192.168.1.1 as default gateways long ago. Every time someone types that address into a browser, runs ipconfig, or pokes around their router settings, the prefix drills itself deeper into casual memory.
None of that grants it any technical priority. Thousands of unrelated networks can all use the same address at the same time because the address only has meaning inside each local subnet. The collision rule applies inside a single network, not across the internet.
What the other two ranges actually do
10.0.0.0/8 is the spacious one. With a /8 mask, it leaves room for an enormous number of host addresses. Big companies, cloud platforms, VPN providers, and ambitious homelab projects lean on it heavily. Nothing in the spec stops a home router from using it; the convention just never caught on for consumer gear.
The 172.16.0.0/12 block covers 172.16.x.x through 172.31.x.x. That narrow window is where most people slip up. The instant you see an address starting with 172, the reflex is to assume it's private. It might not be. The space just past that ceiling is a public range, and chasing an address there as a LAN problem wastes a lot of time.
Slash notation is worth a brief note here. The number after the slash tells you how many leading bits identify the network; smaller slash numbers mean bigger pools. A /8 block dwarfs a /16 by a wide margin.
Where these ranges keep showing up
Docker is the usual suspect for unexpected 172.x sightings. Container networks routinely carve up addresses inside the 172.16 to 172.31 window, so the moment a developer runs a container on a laptop also sitting on a 192.168 network, routing can get interesting. Virtual machines behave similarly, and several VPN providers hand clients addresses from the 10.x range to keep separation clean across users.
Our analysis
Nothing about the 192.168 dominance is technical. It's learned behaviour. For most home users that bias never causes harm, but anyone running containers, virtual machines, or a VPN can hit surprises when their tooling picks a private range that fights with the rest of the LAN. Treating the three RFC 1918 blocks as interchangeable tools, rather than memorizing one, makes diagnosing those clashes much faster. Watch for routers and mesh systems that let you pick the subnet at setup; choosing the roomier block up front gives you breathing room for future guest networks and IoT segmentation.
A worked example
Say you set up a small homelab server that runs a few Docker containers. Docker's default bridge networks live somewhere inside the 172 block, which is usually fine on a typical home router. Now imagine a friend visits and tries to tether through a corporate VPN that funnels all client traffic into its own 172.x range. The two networks don't collide directly, but route tables can get tangled, and certain services stop responding. Knowing which blocks are in play, and roughly how large each one is, lets you change the Docker bridge subnet, switch the LAN to 10.x, or pick a different VPN profile instead of staring at a broken network for an hour.
What to watch next
Pick one mental model: home gear usually lives at 192.168, pros and Docker love the 172 block, and 10.x is the wildcard. If you buy a new router, check whether it lets you set the subnet on first boot. And remember the 172 trap. Treat any 172 address as private only if it sits inside the window covered by RFC 1918. Anything outside that window is public traffic.
Key takeaways
- RFC 1918 gives you three private blocks; pick the one that fits your scale, not the one your router shipped with.
- The 172 block has a hard ceiling just past 172.31; treat anything above it as public to avoid wasted debugging.
- If you're running Docker, VMs, or a VPN on top of a 192.168 LAN, leave room in your head for 172 and 10.x.
Frequently asked questions
Do I need to change my router away from 192.168?
No. 192.168 works fine for most homes. Switching to the 10.x block gives you more addresses and room for subnets, but it only matters if you're juggling many devices, VLANs, or containers.
Why does Docker show 172.x addresses on my computer?
Docker's default bridge networks use the 172 block. The address is local to your machine and won't interfere with your LAN unless something else on the same network tries to claim the same range.
Is a 172.20.x.x address private or public?
Private. Any address inside the RFC 1918 window for the 172 block qualifies. Just past that window is public.
Can two networks use the same private IP address?
Yes, as long as they're not directly connected. The addresses only need to be unique inside each local subnet, which is why home routers, VPNs, and cloud providers all reuse the same range freely.