Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

Objective 1.7 — Describe private IPv4 addressing

Private IPv4 space lets organizations number internal networks without requesting globally unique public addresses for every host. It solves an allocation problem; it does not provide encryption, authentication, or automatic Internet access.

The three RFC 1918 ranges

The private ranges are:

Only 172.16–31 is private inside the broader 172.0.0.0/8; addresses such as 172.40.1.1 are not RFC 1918. Likewise, not every 192.x.x.x address is private. Use the actual prefix boundary.

Reachability and translation

Ordinary Internet routing does not carry RFC 1918 destinations as globally reachable space. An internal host commonly uses NAT or PAT at an edge to have its source represented by a public address. NAT is a separate configured service. A private address can communicate across private routed links or VPNs without translation if both sides have nonoverlapping routes.

Private addressing is not a firewall. If routing and policy permit a path, private hosts can reach one another. Security still requires explicit controls.

Planning for overlap

Because many organizations reuse the same ranges, mergers, partner links, remote access, and multicloud connections can expose overlap. Two sites both using 10.0.0.0/8 cannot distinguish remote and local destinations by that prefix alone. Smaller deliberate allocations, documentation, and coordination reduce future collision risk. Translation can sometimes bridge overlap but adds operational complexity.

Worked scenario

A designer proposes 172.35.8.0/24 as private because it begins with 172. Reject that reasoning: the private /12 stops after the range whose second octet is 31. For an internal branch, choose a nonoverlapping subnet from an approved RFC 1918 plan. If the branch needs Internet access, separately design edge translation, routing, DNS, and security policy.

Verification approach

Confirm an address against the actual three prefixes, then inspect the local routing plan. For external access, verify the translation rule, inside and outside roles, active translations, return routing, and security policy. Do not infer translation from the address being private.

Common traps

• Calling the entire 172/8 range private.
• Treating APIPA or documentation ranges as RFC 1918.
• Calling private addressing a security control.
• Assuming NAT automatically exists.
• Ignoring overlap before connecting two private networks.

Readiness checklist

• I can recognize all three private prefixes precisely.
• I can separate addressing, routing, translation, and policy.
• I can explain why overlap matters.
• I can choose a private subnet from a coordinated plan.