Windows IP Address Guide: Private Ranges, CGNAT, APIPA, Docker and VPN Conflicts

The useful part isn't the trivia. It's the diagnosis. Once you know the address map, an odd IP tells you where to look: your LAN, a VPN, a container, or your ISP.

The three private ranges from RFC 1918​

RFC 1918, Address Allocation for Private Internets, was published in February 1996. It reserves exactly three IPv4 blocks for private use:

Those totals follow from the prefix lengths. An IPv4 address has 32 bits, so /8, /12 and /16 leave 24, 20 and 16 bits for addresses. The RFC calls them the "24-bit," "20-bit" and "16-bit" blocks. In old classful terms, they are one Class A network, 16 contiguous Class B networks and 256 contiguous Class C networks. These figures count every address in the block, not how many hosts you can use in a given subnet.

According to RFC 1918, an organization can use these ranges without asking IANA or an internet registry. The addresses only have to be unique inside the private network, or inside a group of networks that agree to share the space. That's why your laptop and millions of others can all be 192.168.1.20 without trouble.

The RFC also names the downside. If two separately numbered private networks are later merged, some addresses may clash and parts of a network may need renumbering. Anyone who has connected a VPN from a home LAN that happens to match the office subnet has met this problem in person.

Section summary: 192.168 is everywhere because consumer routers ship with it as the default, not because it's special. The 10.x block is 256 times larger, and nothing stops a home router from using it.

The 172 trap: check the second number​

The 172 block causes the most confusion. Only 172.16.0.0 through 172.31.255.255 is private. The whole 172.x.x.x range is not.

• 172.20.5.8 is private (inside 172.16–172.31).
• 172.32.5.8 is not private. It's ordinary address space.

Seeing "172" at the start of an address isn't enough. You have to check the second number.

Why 172 shows up so often on developer machines​

Docker is one big reason. Broadcom's VMware knowledge base notes that Docker by default uses 172.17.0.0/16 as the default bridge Network, and that it creates a new bridge network that by default uses the next overlapping subnet range (172.18.x.x). These subnets may conflict with customer's Management network. A troubleshooting guide from OneUptime says user-defined networks get subnets from built-in default pools that include more of 172.16.0.0/12 plus 192.168.0.0/16 split into smaller subnets.

This is where VPN pain starts. OneUptime puts it bluntly: VPN subnet conflicts are the most common scenario. Many corporate VPNs use the 172.16.0.0/12 or 10.0.0.0/8 ranges, which overlap with Docker's defaults. The usual fix is to move Docker elsewhere in daemon.json. The bip setting changes the default bridge, while default-address-pools controls the subnets used for new custom bridge networks.

One caveat: Docker settings can be changed, so a 172.x address alone doesn't prove a container is involved. It's a strong hint on a machine running Docker, but it isn't proof.

Section summary: On a dev box, a VPN that suddenly can't reach internal servers may be caused by a container subnet sitting on top of the corporate one. Check your routes before you blame the VPN client.

DHCP and NAT do different jobs​

Two related ideas are easy to mix up with private addressing:

• DHCP hands out configuration. RFC 2131 describes it as a protocol for delivering host-specific settings plus a way to allocate addresses. Your router usually runs it and gives each device an address, gateway and DNS servers. But DHCP is a delivery method, not a private-address standard.
• NAT translates addresses. A typical home IPv4 router rewrites outgoing traffic so websites see your public IP, not 192.168.1.20.

Private addresses don't require NAT, and NAT doesn't require private addresses. They're often used together, which is why people tend to treat them as one thing.

Not every non-public address is "private"​

IANA's IPv4 Special-Purpose Address Registry lists many blocks with special jobs. It records, for each one, whether it is globally reachable, forwardable and so on. RFC 1918 space is only one entry. Three others matter most for troubleshooting:

100.64.0.0/10: your ISP's shared space​

RFC 6598, published in April 2012, created Shared Address Space for service providers. It covers 100.64.0.0 through 100.127.255.255 (4,194,304 addresses) and is meant for use between carrier-grade NAT equipment and customer routers. The IANA registry lists it separately from the RFC 1918 Private-Use blocks.

How to check: open your router's admin page and find the WAN or Internet address. Your PC's LAN address won't tell you. If the WAN address falls in this range, your ISP is probably using CGNAT or similar shared addressing. That matters if port forwarding mysteriously fails or a game console reports strict NAT. It's a strong clue, not proof of your ISP's exact setup.

169.254.0.0/16: link-local (the "DHCP didn't answer" address)​

RFC 3927 defines automatic link-local addressing for when no stable, routable address is available. These addresses only work with devices on the same link, and the RFC says routers must not forward packets to or from this range. Hosts pick addresses at random between 169.254.1.0 and 169.254.254.255. The first and last 256 addresses of the block are reserved.

If a Windows PC shows a 169.254.x.x address, it most likely never got a normal configuration from DHCP. The address doesn't tell you why. It could be a bad cable, Wi-Fi authentication, a dead DHCP server or a driver problem.

127.0.0.0/8: loopback​

127.0.0.1 is how a machine refers to itself. IANA's registry lists loopback as not forwardable and not globally reachable. It isn't another device's LAN address, so if a service is bound only to 127.0.0.1, nothing else on your network can reach it.

IPv6 doesn't just rename 192.168​

RFC 4193 defines IPv6 Unique Local Addresses under fc00::/7. Locally assigned prefixes use fd00::/8, and each site generates a pseudo-random 40-bit Global ID. The goal is to make collisions between separately numbered networks highly unlikely, which RFC 1918 never tried to do. The RFC says ULAs can be routed inside a site but aren't expected on the global internet. It also argues they let sites merge, and let VPNs work, without renumbering.

So treating fd addresses as "IPv6 192.168" misses the point. The format, allocation method and collision behavior are all different. IPv6 link-local addresses (the fe80:: ones you see in ipconfig) are a separate category again.

Quick field guide for Windows users​

Run ipconfig (or ipconfig /all for details) and read the prefix:

1. 192.168.x.x: private and extremely common. Unrelated networks reuse it constantly.
2. 10.x.x.x: private. It could be a home LAN, a corporate network, a VPN adapter or a VM.
3. 172.x.x.x: check the second number. Only 16–31 is private. On a Docker or WSL-heavy machine, look for container or virtual networks.
4. 100.64–100.127.x.x on your router's WAN: likely ISP shared addressing or CGNAT.
5. 169.254.x.x: the adapter didn't get a normal configuration. Start with ipconfig /release and ipconfig /renew, then check the link and the DHCP server.
6. 127.x.x.x: the machine itself, nothing on the LAN.

These are clues, not full diagnoses. The prefix tells you where to look, but it can't tell you which device, misconfiguration or routing rule is the actual cause.

The bottom line​

The MakeUseOf piece gets the basics right. Where it simplifies, the standards fill in the gaps: CGNAT space is a strong hint rather than proof, Docker's 172 range is a configurable default rather than a rule, and link-local addresses come from a specific reserved range. For anyone troubleshooting VPNs, Hyper-V and WSL setups, container stacks or strange ISP behavior, knowing all three private blocks and the main special-purpose ranges saves a lot of time.

Questions for the comments: has a Docker subnet ever broken your work VPN? And did you discover your ISP's CGNAT by checking the router's WAN address, or the hard way through port forwarding?