Private and Public IP Addresses: How RFC 1918, CGNAT and NAT Work

The difference between a public IP and a private IP

A public IP address is an address that is routable directly over the internet and appears in the global routing tables so it can be reached from anywhere in the world. A private IP address, by contrast, is meaningful only inside a local network; no router on the internet backbone routes these addresses. The same 192.168.1.5 address can be in use on thousands of different home networks at the same time, because it is only valid within its own network.

The reason for this distinction is historical: IPv4 has a total of roughly 4.3 billion addresses, and allocating a permanent public address to every device connected to the internet is not sustainable. Instead, all the devices on a local network take an address from a private range and are combined behind a single public IP with NAT when they go out to the internet.

RFC 1918: the three private IPv4 ranges

RFC 1918 defines three private IPv4 ranges set aside so that they are never routed directly on the internet. Home/office routers and corporate internal networks use these ranges; the addresses are translated to a public IP with NAT on the way out to the internet.

There are other reserved special-purpose ranges beyond these: 127.0.0.0/8 is loopback (a reference to your own machine; 127.0.0.1 = "localhost"), while 169.254.0.0/16 is link-local — the APIPA address the operating system assigns automatically when no DHCP server can be reached. These two ranges are not part of RFC 1918, but they are equally unroutable on the internet.

How NAT translates a private address into a public one

NAT (Network Address Translation) is the mechanism that lets your router map a private address on the internal network to a public address in the outside world. When a device on your home network (192.168.1.10, say) sends a request to a website, the router replaces the source address of that packet with its own public IP and keeps track in a translation table of which internal device belongs to which connection. When the response packet from the server arrives at that public IP, the router consults the table and forwards the packet to the right internal device.

This mechanism works flawlessly for outbound connections, because the translation table is created automatically when the connection is initiated from inside the network. But for inbound connections — a client trying to reach a device on your home network (hosting a game server, a web server or a remote desktop service, for example) — a rule has to be defined manually so the router knows which internal device to send the request to. That is called port forwarding, and it only works if your router itself holds a genuine public IP.

What CGNAT is and why it causes trouble

IPv4 address exhaustion brought ISPs (internet service providers) to the point where they could no longer give every customer a separate public IP. As a solution, many ISPs began deploying CGNAT (Carrier-Grade NAT, RFC 6598): hundreds, even thousands of customers are shared behind a single public IP. The private range reserved for this is 100.64.0.0/10 — a "carrier-grade" private block separate from the three RFC 1918 ranges.

The router of a user behind CGNAT receives not a public IP but an address from this 100.64.0.0/10 range; the real public IP sits on the ISP's own equipment, above a NAT layer shared among several customers. As a result, even if you configure port forwarding on the home user's router, that setting only applies as far as the ISP's CGNAT device — beyond the ISP, no inbound connection can reach your router. This directly affects home server hosting, the direct connection modes of some games, remote access to camera/DVR systems and certain VPN/remote desktop scenarios.

Ways to work around CGNAT

• Requesting a static or genuine public IP from the ISP (usually offered on business packages or as a paid add-on)
• Setting up a reverse tunnel or VPN through a VPS that has a public IP
• Using a VPN such as WireGuard/OpenVPN, making a server with a public IP the entry point and routing traffic to it
• Using cloud-based tunnelling services (services that provide a reverse proxy, for example)

Common mistakes

• Mistaking the 100.64.0.0/10 range for a public IP. Because this range does not "look" like it starts with 192.168 or 10., some users assume it is a public address; in fact it is a private CGNAT block reserved by RFC 6598.
• Assuming an IP that "looks public" is always reachable. Even if the IP you see in your router's interface is a public address, there may be an additional NAT layer, firewall or CGNAT at the ISP level; setting up port forwarding without first confirming that the address really is reachable from outside wastes time.
• Blaming the modem/router when port forwarding does not work. The problem is usually not a router setting but the fact that the ISP is applying CGNAT; in that case no setting on the router side will solve it.
• Assuming ranges such as 127.0.0.0/8 and 169.254.0.0/16 are part of RFC 1918. These are separate blocks reserved for different purposes (loopback and link-local).

Because a tool like this sends no query and performs a purely bit-level range comparison, it is a reliable first step for confirming what the address in your hands actually is before you reconfigure your network. Making this check before you set up port forwarding, configure a VPN or expose a server to the outside world saves you hours lost to CGNAT-related problems.