Most people learn that "192.168 addresses are private" and stop there. Then a device shows up with 169.254.something, or the router's WAN port says 100.72.something, and it's not obvious whether that's fine or a fault. Each of these ranges exists for a specific reason, and knowing which is which turns a confusing address into a useful clue.
RFC 1918 sets aside three blocks of IPv4 space for private networks. Anyone can use them, nobody has to ask permission, and routers on the public internet won't carry traffic addressed to them.
| Range | CIDR | Addresses | Typical use |
|---|---|---|---|
| 10.0.0.0 to 10.255.255.255 | 10.0.0.0/8 | 16,777,216 | Businesses, cloud VPCs, some ISP routers |
| 172.16.0.0 to 172.31.255.255 | 172.16.0.0/12 | 1,048,576 | Businesses, Docker's default networks |
| 192.168.0.0 to 192.168.255.255 | 192.168.0.0/16 | 65,536 | Almost every home router |
The one that trips people up is the middle one. It's 172.16 to 172.31, not all of 172. An address like 172.32.0.1 or 172.100.4.5 is ordinary public space. If you're writing a firewall rule or a regex to spot private addresses, 172.* is wrong.
Because everyone uses the same blocks, your 192.168.1.20 and your neighbour's 192.168.1.20 are completely unrelated machines. That works because of NAT: your router swaps the private address for its one public address on the way out. We explain that step in NAT and port forwarding explained, and the IP lookup shows you the public address the rest of the internet actually sees.
RFC 6598 reserves 100.64.0.0 to 100.127.255.255 as "shared address space". It's meant for ISPs that run carrier-grade NAT (CGNAT), where many customers share one public IPv4 address. The ISP numbers the link between its NAT and your router from this block.
So if your router's WAN or internet address starts with anything from 100.64 to 100.127, you are behind CGNAT. Your router doesn't have a public address of its own. The practical consequences:
The RFC is explicit that this isn't RFC 1918 space and shouldn't be treated as a general private range. Don't number your home LAN from it. The one well-known exception is overlay VPNs: Tailscale, for instance, assigns device addresses from 100.64.0.0/10 precisely because home and office networks rarely use it, so it's unlikely to collide.
RFC 3927 defines 169.254.0.0/16 for link-local addressing. When a device is set to get an address automatically and no DHCP server replies, it picks a random address in this range, checks nobody else has it, and uses it. Windows calls this APIPA. Hosts choose from 169.254.1.0 to 169.254.254.255, because the first and last /24 are reserved.
The RFC also says routers must never forward these packets. A 169.254 address can talk to other devices on the same cable or Wi-Fi, and nothing else.
In practice, seeing one on a laptop almost always means something is wrong:
Start with ipconfig /release then ipconfig /renew on Windows, or sudo dhclient -r && sudo dhclient on Linux systems that use dhclient, and check the router.
There's one legitimate, very common use of this range in servers: 169.254.169.254 is the instance metadata address on the major cloud platforms. It's reachable only from inside the virtual machine, and it's a classic target for server-side request forgery bugs, so web apps that fetch user-supplied URLs should block the whole 169.254.0.0/16 range.
IPv6 has its own local ranges, but they're used differently because there's no shortage of addresses to save.
fe80::/10 is link-local. Every IPv6 interface has one, always, whether or not there's a router. It's the IPv6 counterpart of 169.254, except that its presence is normal, not a symptom. You'll often see it written with a zone suffix like fe80::1%en0, because the same link-local address can exist on several interfaces.
fc00::/7 is unique local addressing (ULA), from RFC 4193. In practice all ULAs start with fd, since the half of the block that would start fc hasn't been defined. The next 40 bits are meant to be generated randomly, which makes it very unlikely that two networks you later merge or connect by VPN will clash. That's a real improvement over everyone picking 192.168.1.0/24.
What IPv6 doesn't usually do is NAT. Your devices get globally routable addresses as well, and the firewall, not address translation, is what keeps unsolicited traffic out. If your device's IPv6 address keeps changing, that's a separate feature, covered in why your IPv6 address keeps changing.
A few more blocks show up in logs and configs often enough to recognise:
::1.2001:db8::/32 for IPv6. That's why examples on this site use them.If you're setting up a network rather than diagnosing one, pick something less common than 192.168.0.0/24 or 192.168.1.0/24. Those are the defaults on so many routers that the first time you connect to a home or office VPN, there's a good chance both ends use the same subnet and routing gets confused.
A random /24 inside 10.0.0.0/8, something like 10.47.19.0/24, avoids nearly all of that. Our subnet calculator shows the usable host range, broadcast address and mask for whatever block you choose, and subnetting and CIDR explained covers how to size it.
Yes, and they constantly do. Private addresses only need to be unique within one network. The trouble only starts when you join two such networks together, for example with a VPN.
It asked for an address by DHCP and got no reply, so it assigned itself a link-local one. Check the connection and the router, then renew the lease.
It's not routable on the public internet, but it isn't RFC 1918 space either. It belongs to ISPs for carrier-grade NAT. Seeing it on your router's WAN side means you're sharing a public address with other customers.
No. The private block is 172.16.0.0/12, which ends at 172.31.255.255. Anything from 172.32 upward is public space.
0 comments
No comments yet. Be the first.