Private IP address ranges.

Which private range should you use?

All three RFC 1918 blocks work identically. The choice is about avoiding collisions, and collisions happen when two networks that need to talk to each other picked the same space.

• 10.0.0.0/8 — 16.7 million addresses. Use it for anything that might grow, and give each site its own /16 so the plan stays readable. This is the default choice for corporate and cloud networks.
• 172.16.0.0/12 — 1 million addresses across 172.16 to 172.31. Less commonly used, which makes it a good pick when you expect to VPN into partner networks that are already on 10/8.
• 192.168.0.0/16 — 65,536 addresses. Nearly every consumer router ships with 192.168.0.0/24 or 192.168.1.0/24, so avoid it for anything a remote worker will VPN into from home. That conflict is the single most common cause of a VPN that connects but routes nothing.

The blocks that look private but are not

100.64.0.0/10 — carrier-grade NAT

RFC 6598 set this aside for ISPs to share between subscribers when they ran out of public IPv4. It is not private space you can claim. If your ISP uses CGNAT, your router's WAN address sits in this block — and if you also used it internally, traffic to your own ISP infrastructure would break in ways that are unpleasant to diagnose.

169.254.0.0/16 — link-local

A host assigns itself an address here when DHCP does not answer. Seeing 169.254.x.x is a diagnosis, not a configuration: it means the machine never got a lease. Routers do not forward this traffic, so it never leaves the local segment.

The documentation blocks

192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24 exist so that examples and runbooks can use realistic addresses that are guaranteed never to route anywhere. Use them in documentation instead of inventing an address that belongs to someone.

IPv6: unique local addresses

The IPv6 equivalent of RFC 1918 is fc00::/7, defined by RFC 4193. In practice only the lower half, fd00::/8, is used, and the intent is specific: you generate a random 40-bit global ID and your prefix becomes fd<40 random bits>::/48.

The randomness is the point. It is what makes a later merger with another organisation safe, because the odds of both having picked the same ULA prefix are negligible — which is exactly the problem 10.0.0.0/8 has in IPv4.

There is a second difference worth noting. ULAs were never meant to be the primary addressing scheme with NAT in front, the way RFC 1918 space is. IPv6 hosts normally carry both a global address and a ULA, using the ULA for internal traffic that must keep working when the external prefix changes.

Paste any of these into the IPv6 calculator and it will name the reservation it falls inside.