Network Address Translation (NAT)

Network Address Translation would be meaningless without a clear boundary between "private" and "public" address spaces. How does a NAT device know which addresses to translate? How can millions of independent organizations use the same IP addresses without causing global routing chaos?

The answer lies in RFC 1918, published in 1996, which formally defined three blocks of IPv4 addresses reserved exclusively for private networks. These addresses—never routed on the public Internet—form the foundation upon which NAT operates. Every home network, every corporate LAN, every data center private subnet uses these addresses.

This page provides comprehensive coverage of private address spaces: their definition, design rationale, proper usage, and the critical relationship between private addressing and NAT.

Before RFC 1918, organizations had only two choices for IP addressing:

1. Request globally unique public addresses from their Regional Internet Registry (RIR)
2. Invent their own private addressing scheme and hope it didn't conflict with anything

Both approaches had serious problems:

The public address problem:

• Limited IPv4 space meant addresses were increasingly scarce and expensive
• Organizations received allocations based on demonstrated need, not future growth
• Every device, even internal-only systems, consumed globally unique addresses
• Address changes when switching ISPs disrupted internal networks

The ad-hoc private address problem:

• Without coordination, different organizations might choose the same addresses
• If these organizations later merged or interconnected, massive conflicts arose
• No routers knew to filter these addresses, leading to "address leakage"
• Troubleshooting became nearly impossible when random addresses appeared

RFC 1918's solution:

Reserve specific address blocks that:

• Will never be assigned to any organization as public addresses
• Will never be routed on the public Internet
• Can be used by any organization internally, without registration
• Provide different-sized blocks for different organizational needs

RFC 1918 designates three address blocks for private use, each from a different classful network class. This design accommodates organizations of vastly different sizes—from home networks to massive enterprises.

Understanding each range:

10.0.0.0/8 — The Enterprise Block

This single Class A network provides over 16 million addresses. It's the largest private address block and the most flexible for large-scale private networks.

• Best for: Large enterprises, cloud providers, data centers, carrier networks
• Subnet flexibility: Can be divided into 256 /16 networks, 65,536 /24 networks, or any CIDR combination
• Common usage: AWS VPCs often use 10.x.x.x; Kubernetes default pod networks use 10.x.x.x
• Address examples: 10.0.0.1, 10.100.50.25, 10.255.255.254

172.16.0.0/12 — The Mid-Size Block

This range spans 16 contiguous Class B networks (172.16.x.x through 172.31.x.x), providing about 1 million addresses.

• Best for: Medium-sized organizations, corporate networks, isolated segments
• Common confusion: Only 172.16-31 are private; 172.0-15 and 172.32-255 are public
• Subnet flexibility: 16 natural /16 boundaries for departmental allocation
• Address examples: 172.16.0.1, 172.20.100.50, 172.31.255.254

192.168.0.0/16 — The Small Network Block

This range has become synonymous with home and small office networks, providing about 65,000 addresses.

• Best for: Home networks, small offices, lab environments, embedded systems
• Default usage: Most consumer routers default to 192.168.0.x or 192.168.1.x
• Subnet flexibility: 256 natural /24 subnets (192.168.0.x through 192.168.255.x)
• Address examples: 192.168.1.1, 192.168.0.100, 192.168.100.50

Let's examine each range in greater depth, including how to calculate subnets, determine usable addresses, and understand the binary structure.

Selecting the appropriate private address range requires considering current needs, future growth, potential conflicts, and organizational structure. This is an architectural decision with long-term implications.

The VPN Conflict Problem:

When organizations establish VPN connections—whether site-to-site or remote access—overlapping address spaces create routing nightmares. Consider this scenario:

Scenario: Company A (192.168.1.0/24) needs VPN access to Company B (also 192.168.1.0/24)

Problem: When a host in Company A (192.168.1.50) tries to reach a host in Company B (192.168.1.100), the local routing table sends traffic to the local subnet, not through the VPN tunnel. Both networks claim the same address space!

Solutions:

1. NAT at VPN endpoint: Translate remote network to different addresses (complex, breaks some applications)
2. Renumber one network: Painful but permanent solution
3. Use unique private ranges originally: The best solution, but requires foresight

While RFC 1918 defines the primary private address ranges, several other special-purpose address blocks exist that network engineers must understand. These serve specific functions and should never be used for general private networking.

Key ranges to understand:

127.0.0.0/8 — Loopback

Traffic destined for any address in this range never leaves the host. It's used for local testing and inter-process communication. While the entire /8 is reserved, 127.0.0.1 ("localhost") is the conventional address.

169.254.0.0/16 — Link-Local (APIPA)

When a device cannot obtain an IP address via DHCP, it may self-assign an address from this range (Automatic Private IP Addressing). These addresses are only valid on the local link and are never routed.

100.64.0.0/10 — Carrier-Grade NAT (CGNAT)

Added in RFC 6598 (2012) for ISPs implementing NAT between customers and the Internet. This allows ISPs to share scarce public IPv4 addresses among multiple customers. This range exists specifically to avoid conflicts with customer private networks that might use RFC 1918 addresses.

Documentation Ranges (TEST-NETs)

These three ranges are reserved exclusively for use in documentation, examples, and educational materials. Using these addresses in actual networks won't cause Internet conflicts since they're never routed publicly.

Private addresses and NAT form an inseparable partnership. Understanding their relationship clarifies why both technologies must work together.

Why private addresses REQUIRE NAT:

Private addresses are, by design, non-routable on the public Internet. ISPs and Internet backbone routers are configured to drop packets with private source or destination addresses. This means:

1. A host with address 192.168.1.100 cannot directly communicate with 8.8.8.8 (Google DNS)
2. Packets from 10.0.0.50 sent toward the Internet are discarded at the first public router
3. External servers cannot route responses back to private addresses

NAT bridges this gap by translating private addresses to public addresses at the network boundary.

The RFC 1918 filtering requirement:

RFC 1918 explicitly states that routers at network boundaries should filter these address ranges:

"Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links." — RFC 1918, Section 5

This means:

• ISPs SHOULD drop inbound/outbound packets with RFC 1918 addresses (ingress/egress filtering)
• Enterprise border routers SHOULD filter private addresses from external routing updates
• Internet backbone routers SHOULD reject routes to private address ranges

In practice: Most responsible ISPs implement this filtering, though enforcement varies. Private addresses occasionally "leak" due to misconfiguration, but cannot establish bidirectional communication.

The NAT dependency matrix:

Effective private address management prevents conflicts, simplifies troubleshooting, and scales with organizational growth. These best practices reflect industry experience from thousands of network deployments.

We've thoroughly covered the RFC 1918 private address spaces that form the foundation for NAT deployments worldwide. Let's consolidate the essential knowledge.

What's Next:

With private addresses understood, we'll explore the first NAT type in detail: Static NAT. Static NAT creates a permanent, one-to-one mapping between an internal host and a public IP address—essential for servers that must be consistently reachable from the Internet. We'll examine its configuration, use cases, and trade-offs compared to other NAT types.