Private Addressing and RFC 1918
Three IPv4 ranges — 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 — are reserved by RFC 1918 for private use and are never routed on the public internet. A packet with one of these addresses as its destination is dropped by any internet router that sees it. Nearly every internal network, home router, and cloud VPC lives inside these blocks, which is exactly why address overlap is a chronic, real-world headache.
Private addressing exists because IPv4's 32 bits — about 4.3 billion addresses — ran out. Rather than give every device a globally unique address, you number your internal hosts from the reserved ranges and share a handful of public addresses through NAT on the way out. The bargain bought IPv4 decades of extra life, at the cost of two engineers each picking 10.0.0.0/16 and discovering they can never connect their networks.
The Three RFC 1918 Blocks
The three blocks differ enormously in size. 10.0.0.0/8 is the largest — 16.7 million addresses, a full class-A-sized space — and is the default for large enterprises and cloud VPCs that want room to subdivide. 172.16.0.0/12 is the middle one, spanning 172.16.0.0 through 172.31.255.255, about a million addresses; it is the least-used and least-remembered, which makes it a good pick precisely because fewer networks collide there. 192.168.0.0/16 is the small one — 65 536 addresses — and the default on virtually every home router.
# the three RFC 1918 ranges, memorize these # 10.0.0.0/8 10.0.0.0 - 10.255.255.255 (16,777,216 addrs) # 172.16.0.0/12 172.16.0.0 - 172.31.255.255 (1,048,576 addrs) # 192.168.0.0/16 192.168.0.0- 192.168.255.255 (65,536 addrs) ip -br addr show # eth0 UP 192.168.1.42/24 <- home/SOHO range # eth1 UP 10.20.4.7/16 <- cloud VPC range
Why Private Space Exists
IPv4 has roughly 4.3 billion addresses, and the internet blew past that count years ago. Private addressing plus NAT was the pragmatic answer: an organization with 10 000 hosts consumes one public address, not 10 000, by numbering everyone internally from RFC 1918 space and translating at the edge. The same private block — 10.0.0.0/8 — is reused by millions of separate networks at once, which is fine precisely because none of them route it publicly.
The catch is the deal NAT makes. Private hosts can reach out, but nothing on the internet can reach in without an explicit forward, because the address is not routable and the host is hidden behind a shared public IP. That breaks the internet's original end-to-end model — every host directly addressable — and is why peer-to-peer, inbound services, and certain protocols need extra machinery to work from behind NAT.
Other Reserved Ranges
Three more ranges are reserved and routinely confused with RFC 1918. 127.0.0.0/8 is loopback — 127.0.0.1 is the host talking to itself, and the whole /8 never leaves the machine. 169.254.0.0/16 is link-local: a host assigns itself one of these automatically when DHCP fails, so a 169.254.x.x address is a symptom, not a configuration — it means the host asked for an address and got no answer.
100.64.0.0/10 is CGNAT space, reserved for carrier-grade NAT — the address an ISP gives your home router when it has run out of public IPv4 and NATs you a second time inside its own network. It is not RFC 1918 and not public; it exists so carriers can run their own private layer without colliding with the customer's 192.168.x.x behind the router.
A private (RFC 1918) address is meaningful only inside one network and is dropped by every public internet router. Many networks reuse the same private block simultaneously, and a private host needs NAT to reach anything outside — nothing on the internet can address it directly. Use private space for every internal host, server, and container that does not need to be reached from the public internet by its own address.
A public address is globally unique and routable — exactly one host on earth holds it, and any internet router knows how to reach it. Public addresses are scarce and allocated by registries, so you spend them deliberately: on internet-facing load balancers, NAT gateways, and the handful of services that must be directly reachable, not on ordinary internal hosts.
- Defaulting every VPC to 10.0.0.0/16. Two such VPCs can never be peered or connected to the same on-prem network, and the only fix is renumbering one side from scratch — plan non-overlapping ranges before the first VPC exists.
- Picking a range that collides with a partner or VPN. The day you connect to a vendor who also uses 192.168.1.0/24, routing becomes ambiguous and the tunnel carries nothing; the overlap, not the tunnel, is the failure.
- Confusing link-local 169.254.x.x with a real address. It signals that DHCP failed and the host self-assigned; treating it as a working address sends you debugging connectivity when the actual problem is no DHCP reply.
- Assuming a private address can reach the internet on its own. Without a NAT gateway or proxy in the path, outbound traffic from RFC 1918 space is dropped at the first public router — the host needs translation to leave at all.
- Carving every network out of 192.168.0.0/16 because it is familiar. Its 65 536 addresses run out fast across multiple sites; reserving 10.0.0.0/8 from the start avoids re-architecting addresses when the second and third sites appear.
- Allocate from 10.0.0.0/8 for any network that will grow, reserving distinct, documented sub-blocks per region and environment so two of your own networks never collide when you later connect them.
- Pick from the under-used 172.16.0.0/12 for VPN and partner-facing segments, since fewer organizations number there, which lowers the odds of an overlap when you peer with an outside network.
- Treat a 169.254.x.x address as a DHCP-failure alarm, not a config — when a host shows one, check the DHCP server and the path to it rather than the host's own settings.
- Maintain a single source-of-truth IPAM record of every allocated private block across all sites and clouds, because overlap is the one addressing error you cannot fix without renumbering an entire network.
- Route private hosts to the internet through a managed NAT gateway and keep them off public IPs entirely, so internal machines are unreachable from outside by default and only deliberate services get public exposure.
Knowledge Check
A host shows an address in 169.254.0.0/16. What does that tell you?
- Its DHCP request got no reply, so it self-assigned a link-local address and has no real connectivity
- It received a perfectly normal private RFC 1918 lease from DHCP and is now ready to route out to the internet
- It is using the loopback range to talk to services on itself
- It sits behind carrier-grade NAT and got a 100.64-style address
Why must a host with an RFC 1918 address use NAT to reach the public internet?
- Private addresses are not routable on the internet, so they must be translated to a public IP to leave the network
- Private addresses use a different packet format that public routers cannot parse
- The internet requires that every outbound packet be encrypted in transit, which is the translation step NAT actually performs
- Private addresses have a shorter TTL and expire before reaching distant servers
Which choice best avoids a future address-overlap problem when sizing private networks?
- Allocate documented, non-overlapping sub-blocks of
10.0.0.0/8per region and environment up front - Number every site from
192.168.1.0/24so the addresses are always familiar - Reuse exactly one identical
/16block across every single VPC so the addressing config stays uniform everywhere - Assign public addresses internally so two networks can never overlap
You got correct