Private and public describe address scope—not whether a device can communicate
A private IPv4 address is intended for use inside private networks and is not globally routed across the public Internet. A public IPv4 address participates in globally unique Internet addressing and can be routed according to Internet routing policy. The important AP Networking skill is not merely labeling an address: it is predicting what must happen to a packet when a private-addressed host communicates beyond its private network.
Private IPv4
Reusable by independent networks. Common on LANs, internal server networks, labs, and enterprise segments. Usually requires translation when ordinary IPv4 Internet access is provided.
Public IPv4
Globally unique within the public routing system. Common on Internet-facing interfaces and services. “Not private” does not automatically mean “normal usable public address,” because special-purpose ranges also exist.
The three RFC 1918 private IPv4 blocks
| Block | Full range | Fast exam recognition | Common trap |
|---|---|---|---|
| 10.0.0.0/8 | 10.0.0.0–10.255.255.255 | Every 10.x.x.x address is inside the block | Thinking only 10.0.0.x is private |
| 172.16.0.0/12 | 172.16.0.0–172.31.255.255 | Second octet must be 16 through 31 | Calling every 172.x.x.x address private |
| 192.168.0.0/16 | 192.168.0.0–192.168.255.255 | First two octets must be 192.168 | Calling all 192.x.x.x private |
Swipe horizontally to inspect the full table.
Can you classify these without guessing?
10.44.8.9
Private. It falls inside 10/8.
172.20.5.8
Private. 20 is between 16 and 31.
172.40.5.8
Not RFC 1918. Second octet 40 is outside 16–31.
192.168.44.7
Private. It falls inside 192.168/16.
Private source → default gateway → NAT → public Internet
*Documentation-style example address used to illustrate the translation concept.
The client can route normally inside the private network. At an IPv4 Internet edge, translation can replace the private source information with public-facing information. On return traffic, the translation state lets the edge map the response back to the correct inside connection.
How many private clients can share one public IPv4 address?
This is commonly described as Port Address Translation (PAT) or NAT overload. The crucial evidence is not merely “the public IP is the same”; the translated flow identifiers allow return traffic to be mapped to the appropriate inside connection.
Separate the forwarding question from the translation question
Route question
Where should the packet be forwarded next?
NAT question
Should address/port information be rewritten for this flow?
Policy question
Is the flow permitted by firewall/ACL rules?
A valid route does not prove NAT is configured, and a NAT rule does not prove the upstream path exists. This distinction is extremely useful in troubleshooting questions.
Read a translation table as evidence
Every private client fails vs. one private client fails
All clients lose Internet access
Shared dependencies become stronger suspects: edge routing, NAT configuration/state, public-facing interface, upstream gateway, or shared policy.
One client fails
A network-wide NAT absence becomes weaker. Check that host's IP/prefix/gateway, local policy, VLAN/access path, DNS behavior, and whether its traffic reaches the edge.
Scope is evidence. It helps you reject fixes that are much broader than the demonstrated failure.
A public address can still be blocked, unrouted, or unavailable
“Public” describes address scope; it is not a promise of successful application access. A public-facing server can still be unreachable because of routing, firewall policy, service state, upstream filtering, or a missing return path.
RFC 1918 addressing is not a security control by itself
Private addressing limits global Internet routing of those addresses, but it does not authenticate users, encrypt traffic, patch systems, or replace firewall policy. A compromised device inside a private network can still communicate with other reachable internal systems if policy permits it.
169.254.0.0/16 is not RFC 1918 private space
An IPv4 address in 169.254/16 is link-local. In common client troubleshooting, seeing such an address can be evidence that the host did not obtain its expected normal configuration from DHCP. Its purpose is different from the reusable RFC 1918 blocks.
“Not RFC 1918” is not identical to “ordinary public host address”
Networking includes address space with special purposes. For AP-style reasoning, use the evidence you are given and avoid the false binary that every IPv4 address must be either RFC 1918 private or an ordinary globally usable host address.
Private addresses can be reused because independent private networks are separate routing domains
Two unrelated homes can both use 192.168.1.10 without conflict because those hosts are not being treated as globally unique Internet endpoints. The trouble begins when those private networks must be interconnected and the same prefixes now need to represent different locations.
Why private address reuse can break VPNs and mergers
This is an address-plan collision. Clean renumbering avoids the ambiguity; some systems can use translation or policy-specific workarounds, but those add operational complexity.
For the full range and route-selection diagnosis, continue with Subnet Overlap Problem.
Local access works, Internet access fails for every client
Strong next branch: preserve the successful local routing checkpoint and inspect the shared Internet edge: default/upstream route, NAT state/rules, public-facing interface, and edge policy. Rechecking the client's Ethernet link is weaker because the client already reaches routed internal destinations.
One client fails while peers behind the same NAT work
A universal NAT failure is contradicted by the working peers. Compare Client C's addressing, gateway, VLAN/path, DNS result, host policy, and whether its packets reach the edge.
A student sees 172.40.10.8 and calls it private
The answer is wrong because the RFC 1918 172 block is only 172.16.0.0 through 172.31.255.255. The second octet 40 falls outside that range.
A NAT entry exists, but the website still does not load
That translation entry is useful evidence, but it does not establish end-to-end application success. The next unresolved dependency may be upstream routing, return traffic, firewall policy, DNS, TCP establishment, TLS, or the application itself.
AP transfer skill: never stretch an artifact beyond the exact checkpoint it proves.
Watch how one fact changes the best diagnosis
| Initial evidence | Changed fact | Reasoning change |
|---|---|---|
| All private clients cannot reach Internet | One peer successfully reaches Internet | Universal edge/NAT outage becomes weaker |
| VPN to corporate 192.168.1.0/24 fails | Home LAN renumbered to 192.168.50.0/24 | Original local/remote prefix collision disappears |
| Client shows 169.254.x.x | Expected network intentionally uses link-local only | Do not automatically infer DHCP failure; context changes |
| Private client has a valid default route | No translation rule matches its source subnet | Routing alone cannot supply required IPv4 translation |
| NAT table shows a translated flow | Remote firewall explicitly denies it | Translation exists; policy becomes the demonstrated failure |
Swipe horizontally to inspect each changed-fact scenario.
Use SCOPE → ADDRESS → ROUTE → TRANSLATE → POLICY → VERIFY
1. Scope
One host, one subnet, or everyone?
2. Address
Private, public-facing, link-local, or misconfigured?
3. Route
Does traffic have the intended next hop/path?
4. Translate
Does the flow match the required NAT/PAT behavior?
5. Policy
Is a firewall/ACL intentionally denying it?
6. Verify
Repeat the original failed test and keep a working control.
Seven statements students should be able to reject
- “Every 172.x.x.x address is private.” Only 172.16/12 is RFC 1918.
- “169.254.x.x is another private block.” It is IPv4 link-local, not RFC 1918.
- “Private addresses cannot communicate.” They can communicate within routed private networks and can reach Internet destinations through appropriate edge routing/translation.
- “NAT and routing are the same thing.” Forwarding and translation are separate decisions.
- “A public IP is automatically reachable.” Routing, policy, and service state still matter.
- “Private addressing makes a network secure.” Address scope is not authentication, encryption, or firewall policy.
- “Private address reuse never causes conflicts.” Interconnecting networks with overlapping prefixes can create route/locality conflicts.
Which conclusion is strongest?
Strong interpretation: the host has passed local and routed-internal checkpoints. Because peers also fail and expected translation state is absent, the shared edge/NAT branch deserves investigation. The artifact does not yet prove whether the root cause is the NAT rule itself, traffic not reaching the edge interface, or another shared edge condition.
24 private vs. public IP reasoning flashcards
Use the filters to practice classification, NAT/PAT, troubleshooting, overlap, and exam traps.