Three address blocks appear in virtually every network you will ever touch: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. They're defined in RFC 1918, they're the reason IPv4 survived twenty-five years past its predicted exhaustion, and understanding why they need NAT is CCNA objective 1.7. This article covers the blocks, the rules, and a live packet's journey from a private host through PAT to a real machine - captured from our Network Fundamentals lab.
The problem RFC 1918 solved
IPv4 has 4.3 billion addresses; the internet has far more devices. In 1996, RFC 1918 formalized the workaround: reserve blocks that anyone may use internally, on the condition that they are never routed on the public internet. Your 192.168.1.0/24 and a million other households' 192.168.1.0/24 can coexist because none of them exist beyond their own edge router. Uniqueness is only required where the packet travels.
The three blocks
16.7M addresses. The enterprise workhorse - big enough to carve a global addressing plan out of one block.
1M addresses. The one people get wrong: it's /12, so 172.32.x.x is public. Common in labs, Docker, and mid-size shops.
65K addresses. Home and small office default - every consumer router ships with a slice of it.
Exam trap worth drilling: 172.16.0.0/12 runs only through 172.31.255.255. If a question shows 172.33.10.5 and asks whether it's private, it isn't. Also don't confuse RFC 1918 space with 169.254.0.0/16 (APIPA link-local, what a host self-assigns when DHCP fails) or 100.64.0.0/10 (carrier-grade NAT space) - reserved, but not RFC 1918.
Private addresses need a translator
A packet sourced from 10.0.10.11 can leave your network, but no internet router will carry the reply toward a destination in unroutable space. So the edge router rewrites the source: Network Address Translation. With PAT (Port Address Translation, NAT overload), thousands of inside hosts share one public address, distinguished by port numbers - which is how your entire household shares the single IP your ISP assigns.
Watching it happen: real output
In the lab, host H1 (10.0.10.11, private) pings a real Linux machine across the router's outside interface. R1 translates on the way through:
H1:~# ping -c 4 192.168.99.100
PING 192.168.99.100 (192.168.99.100) 56(84) bytes of data.
64 bytes from 192.168.99.100: icmp_seq=1 ttl=63 time=6.20 ms
64 bytes from 192.168.99.100: icmp_seq=2 ttl=63 time=4.18 ms
--- 192.168.99.100 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss
R1# show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 192.168.99.1:1025 10.0.10.11:8 192.168.99.100:8 192.168.99.100:1025Read the columns: inside local is the host's real private address (10.0.10.11); inside global is what the outside world sees (the router's own interface address, port 1025). The destination never learns 10.0.10.11 exists. The four NAT column names are core CCNA vocabulary - learn them from a real entry, not a diagram.
R1# show ip nat statistics
Total active translations: 1 (0 static, 1 dynamic; 1 extended)
Outside interfaces:
Ethernet0/0
Inside interfaces:
Ethernet0/1
Hits: 72 Misses: 0
Dynamic mappings:
-- Inside Source
[Id: 1] access-list NAT-INSIDE interface Ethernet0/0 overloadThe config behind it is three moves: mark the inside interface, mark the outside interface, and one overload rule matching an ACL of the private space. Full walkthroughs in Lab ips-05 - NAT Overload (PAT).
Consequences worth knowing
- Private space is why your addressing plan matters. Two companies merge, both used 10.0.0.0/8 casually, and now someone owns months of readdressing or NAT hairpins. Carve deliberately (our VLSM guide shows how).
- NAT is not a firewall, but it does break inbound-by-default, which is why unsolicited connections need port forwarding or static NAT.
- Leaked RFC 1918 routes are a real failure mode - ISPs filter them, and seeing 10.x routes at an internet edge means someone's redistribution went wrong.
- IPv6 removes the scarcity problem entirely - no NAT required - which is why the pressure valve of RFC 1918 is also the reason IPv6 adoption took decades. See IPv6 Address Types for the parallel concepts (ULA fdxx:: space is IPv6's spiritual successor to RFC 1918).
FAQ
Is 172.32.0.0 a private IP address?
No. The private block is 172.16.0.0/12, which spans 172.16.0.0 through 172.31.255.255. Anything at 172.32 and beyond is public space belonging to someone. This is the most-missed private-addressing question on the CCNA, which is exactly why it keeps appearing.
Is 169.254.x.x a private address?
It's reserved, but it is not RFC 1918. 169.254.0.0/16 is link-local (APIPA) - what a host assigns itself when DHCP fails. Seeing it on a client means "investigate DHCP," not "someone chose this addressing." Same story for 100.64.0.0/10, which is carrier-grade NAT space reserved for ISP internals.
Can I route RFC 1918 addresses between my own sites?
Absolutely - "not routable" means on the public internet. Inside your own network, across VPNs, MPLS L3VPNs, and private WANs, RFC 1918 space routes like any other. Enterprises run global WANs entirely in 10.0.0.0/8. The prohibition is on internet carriage, where providers filter these prefixes (and where you should too, at your edge).
Why do VPNs break when both sides use 192.168.1.0/24?
Because uniqueness is required where packets travel, and a VPN joins two address spaces. If home and office both use 192.168.1.0/24, the client can't tell which side owns a destination. Fixes: renumber one side (best), or NAT the tunnel (ugly, common). It's also why labs and offices deliberately avoid default consumer ranges.
Does IPv6 have private addresses like RFC 1918?
The equivalent is Unique Local Addresses (fc00::/7, in practice fd00::/8), locally generated and not globally routed. The philosophical difference: IPv6's abundance means ULA is a choice for isolation, not a workaround for scarcity - most IPv6 deployments give every host a global address and control reachability with policy instead of NAT. Details in our IPv6 address types guide.
Key takeaways
- 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 - free to use inside, never routed on the internet.
- The /12 boundary: 172.16 through 172.31 only.
- Private addressing works because NAT/PAT rewrites sources at the edge; know all four translation column names.
- APIPA (169.254/16) and CGN (100.64/10) are reserved but are not RFC 1918.
Continue with the Network Fundamentals guide or get hands-on with the IP services lab track.
