> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # Private IPv4 Addressing (RFC 1918): The Blocks, the Rules, the NAT - URL: https://www.pinglabz.com/private-ipv4-rfc-1918/ - Published: 2026-07-10T18:38:04.000Z - Updated: 2026-08-24T05:13:37.000Z - Description: The three RFC 1918 blocks, the rules that come with them, and why private addresses need NAT. Includes a live packet's journey from a private host through PAT to a real machine, captured in the Network Fundamentals lab. - Author: Jaime - Tags: Fundamentals, CCNA, Networking, #Import 2026-08-01 19:54 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](https://www.pinglabz.com/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 **10.0.0.0/8** 10.0.0.0 - 10.255.255.255 16.7M addresses. The enterprise workhorse - big enough to carve a global addressing plan out of one block. **172.16.0.0/12** 172.16.0.0 - 172.31.255.255 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. **192.168.0.0/16** 192.168.0.0 - 192.168.255.255 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:1025 ``` Read 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 overload ``` The 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)](https://www.pinglabz.com/ccna-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](https://www.pinglabz.com/ipv4-subnetting-vlsm/) 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](https://www.pinglabz.com/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](https://www.pinglabz.com/ipv6-address-types/). ## 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](https://www.pinglabz.com/network-fundamentals/) or get hands-on with the [IP services lab track](https://www.pinglabz.com/ccna-labs-ip-services/).