RFC 1918: Private IP Address Ranges Explained

RFC 1918 is the Internet Engineering Task Force (IETF) standard that carved out three blocks of IPv4 addresses and declared them permanently reserved for private use. Published in February 1996, this document is the reason every home router can assign addresses like 192.168.1.x to your devices without worrying about conflicts with anyone else on the planet. The three ranges defined in RFC 1918 underpin every local area network in existence.

The standard solved a growing problem in the mid-1990s: the internet was expanding rapidly, and public IP addresses were being consumed faster than anticipated. By reserving specific blocks that would never appear on the public internet, RFC 1918 allowed organizations to build internal networks of any size without consuming public address space.

The Three Private Address Ranges

RFC 1918 designates exactly three IPv4 address blocks as private. Each block corresponds to a different scale of network, though any organization can use any of them regardless of size.

10.0.0.0/8 is the largest private block. It spans from 10.0.0.0 to 10.255.255.255, providing 16,777,216 addresses. The /8 prefix means only the first octet is fixed; the remaining three octets are available for subnetting and host addressing. This range aligns with the old Class A designation.

Large enterprises, cloud providers, and data centres favour the 10.x.x.x range because it provides enough space to create thousands of subnets across multiple locations without reusing addresses. AWS, Azure, and GCP all default to 10.x.x.x ranges for their virtual private cloud configurations. Some consumer routers (notably certain Comcast and Xfinity gateways) also use 10.0.0.x for the home LAN.

172.16.0.0/12 is the mid-sized private block. It covers 172.16.0.0 to 172.31.255.255, providing 1,048,576 addresses. The /12 prefix is less intuitive than the others because the boundary falls in the middle of the second octet. The second octet ranges from 16 to 31 (the lower 4 bits are part of the host space).

This range sees less use in consumer networking but appears frequently in container orchestration (Docker uses 172.17.0.0/16 by default), VPN tunnels, and medium-sized business networks. It is a good choice when you want private addressing that will not overlap with the 10.x.x.x or 192.168.x.x ranges already in use elsewhere in your environment.

192.168.0.0/16 is the smallest private block and the one most people encounter daily. It covers 192.168.0.0 to 192.168.255.255, providing 65,536 addresses. Nearly every consumer router ships with a default LAN address in this range, typically 192.168.0.1 or 192.168.1.1.

Home networks overwhelmingly use 192.168.x.x addresses. A typical setup uses 192.168.1.0/24 for the LAN, giving 254 usable host addresses. This is more than enough for residential use, even in smart-home-heavy households.

Why Private Addresses Exist

The concept behind RFC 1918 is address conservation. When the internet was designed, IPv4’s 4.3 billion addresses seemed abundant. By the 1990s, it was clear that every organization, school, government agency, and eventually every household wanting internet access would exhaust the supply.

Not every device needs to be reachable from the public internet. Your printer, your smart thermostat, and your laptop do not need globally unique addresses. They only need to communicate within your local network and reach the internet through a gateway. Private addresses serve this purpose perfectly.

Because private addresses are guaranteed to never appear on the public internet, they can be reused infinitely. Every home in your neighbourhood can use 192.168.1.x internally. Every office building can use 10.x.x.x. There are no conflicts because these addresses never leave their respective networks without being translated first.

The translation mechanism is NAT (Network Address Translation). Your router takes outgoing packets from private addresses, swaps the source to its public IP, and reverses the process for incoming responses. NAT is what allows one public address to serve an entire network of privately addressed devices.

Without RFC 1918 and NAT, every single device on every network worldwide would need its own public IPv4 address. The internet would have run out of addresses years before IPv6 was ready for deployment.

How Routers Use RFC 1918 Addresses

Your router is the device that implements RFC 1918 addressing on your home network. It uses private addresses in three primary ways.

LAN interface address. The router assigns itself a private IP address on the local network side. This address (commonly 192.168.1.1) serves as the default gateway for all devices on the network. When your laptop needs to send traffic outside the LAN, it forwards the packet to this address.

DHCP pool. The router runs a DHCP server that automatically assigns private IP addresses to devices as they connect. The pool is drawn from the same RFC 1918 range as the router’s LAN address. A router at 192.168.1.1 typically hands out addresses from 192.168.1.2 through 192.168.1.254.

NAT translation. When a device with private address 192.168.1.100 sends a packet to the internet, the router replaces the source address with its public IP before forwarding. It maintains a mapping table so it can reverse the translation on incoming responses. The private address never appears on the public internet.

Internet backbone routers enforce the private address boundary. They are configured to drop any packet with an RFC 1918 source or destination address. If a private address somehow leaked onto the public internet, it would be discarded immediately. This enforcement is what makes the reuse guarantee work.

RFC 1918 and VPNs

VPN (Virtual Private Network) configurations interact directly with RFC 1918 addressing. When you connect to a corporate VPN, the VPN server assigns your device a private IP address from its own RFC 1918 range. This lets your device appear as if it is on the corporate network, with access to internal resources.

A common problem arises when your home network and the VPN use the same private range. If your home router uses 192.168.1.0/24 and the corporate VPN also uses 192.168.1.0/24, your device cannot distinguish between local and VPN destinations. Traffic intended for a corporate server at 192.168.1.50 might go to your local network instead.

The solution is to use different RFC 1918 ranges for different purposes. Organisations running VPN services often choose 10.x.x.x or 172.16.x.x to avoid overlap with the 192.168.x.x range that most home networks use. If you control both networks, changing one to a different range eliminates the conflict.

This overlap issue is also relevant for site-to-site VPNs that connect two offices. If both offices use 192.168.1.0/24, the VPN cannot route traffic correctly between them. Planning RFC 1918 usage across all connected sites is a basic requirement for VPN deployments.

RFC 1918 in the IPv6 Era

IPv6 provides enough addresses (340 undecillion) that every device on Earth could have billions of globally unique public addresses. In theory, this eliminates the need for private addressing and NAT entirely. In practice, the concept persists.

IPv6 includes Unique Local Addresses (ULAs), defined in RFC 4193. The ULA range fc00::/7 (practically fd00::/8) serves the same role as RFC 1918 addresses in IPv4: internal communication that should not be routed on the public internet. Organizations use ULAs for services that should remain internal, like printers, file shares, and management interfaces.

However, ULAs are used differently than RFC 1918 addresses. IPv6 devices typically receive both a global unicast address (publicly routable) and a ULA (locally scoped). Unlike IPv4 where NAT is required, IPv6 devices can communicate directly on the internet using their global address while using the ULA for internal traffic.

For home users, RFC 1918 remains the daily reality. IPv4 and its private address ranges will continue operating alongside IPv6 for years. Your router will keep assigning 192.168.x.x addresses via DHCP, running NAT for IPv4 traffic, and handling IPv6 separately. The RFC 1918 framework is not disappearing any time soon.