Private Addresses and NAT: How Home Networks Reach the Internet

Private Addresses and NAT: How Home Networks Reach the Internet

What you'll learn

• Tell the IPv4 exhaustion story: why 4.3 billion addresses ran out and what the Internet did about it
• Recite the three RFC 1918 private ranges with their correct masks — and untangle a mask inconsistency in the textbook
• Walk a PAT translation table row by row and predict where a reply packet lands
• Explain static NAT and why servers need it
• Recognize CGNAT and the 100.64.0.0/10 range on a real ISP connection

This lesson builds on Chapter 6 of Dr. Tahseen Al-Doori's Network Essentials — its public-versus-private addressing section and its catalog of address translation methods. The book taught this material when NAT was becoming universal; we will follow its structure and then extend it to the piece the book could not have known: what ISPs did after the addresses actually ran out.

The day the pool ran dry

IPv4 addresses are 32 bits: about 4.3 billion possibilities. In the 1980s that looked inexhaustible; then the Internet left the laboratory. Every PC, then every laptop, then every phone, camera and thermostat wanted an address — and 4.3 billion stopped looking infinite and started looking like a deadline.

The authority that hands out address space, IANA, allocated its final unassigned blocks to the world's regional registries in February 2011. The regional pools then drained one by one over the following years until, by the end of the decade, effectively nothing was left. This was no surprise crash — engineers had watched the fuel gauge for twenty years and prepared two answers that define addressing to this day:

• The workaround: private address ranges plus NAT — stretch the addresses we have by sharing them. This lesson.
• The fix: a new protocol with a vastly larger address space — IPv6. Next lesson.

The workaround was supposed to be temporary. It worked so well that, decades later, it runs in essentially every home and office on Earth — a "temporary" fix you will support for your whole career.

The private ranges (RFC 1918)

The sharing scheme starts with a reservation. RFC 1918 sets aside three blocks of IPv4 space that are private: anyone may use them, no registration needed, on the strict condition that they never appear on the public Internet. Internet routers drop them on sight — which is exactly what makes them safe to reuse: since they never leave the building, your 192.168.1.0/24 and your neighbor's identical 192.168.1.0/24 can never meet, so they can never conflict.

Two details on this table repay care — both flagged by the book itself, one needing a small correction.

The /12 that surprises everyone. The middle block's mask is 255.240.0.0 — a /12, matching no classful default you might expect. The book rightly insists on precision here: the block runs from 172.16 to 172.31 inclusive, not all of 172.x. An address like 172.20.9.4 is private; 172.40.9.4 is not. Interviewers test this range precisely because the boundaries are unintuitive.

The 192.168 block — a friendly correction. Our textbook lists the 192.168 range twice, and the two printings disagree: one gives it a /24 mask, the other a /16. Books accumulate these small inconsistencies across editions, and this one is worth resolving cleanly because both numbers are meaningful: RFC 1918 defines the reservation as 192.168.0.0/16 — the full 65,536-address block, exactly as the range column shows (and as the book's own second listing has it). The /24 reading describes something real too: in practice almost nobody uses the block as one flat /16; it is treated as 256 convenient /24 subnets, and your home network — 192.168.1.0/24 or similar — is precisely one such slice. So: the reservation is /16; your deployment of it is usually a /24. Know both readings and the difference, and the inconsistency dissolves.

One more range often mentioned alongside these, because it also begins with "private" in its name: 169.254.0.0/16, APIPA — from lesson 2. It is not an RFC 1918 range; it is link-local self-assignment, a symptom ("I could not find DHCP") rather than a plan. Keep it mentally separate.

Public addresses, by contrast, are globally unique and centrally allocated — today you obtain them from your ISP, which obtained them from a regional registry, which obtained them from IANA. They cost money, they are scarce (see above), and a typical household rents the use of exactly one.

NAT: one address, whole household

Which raises the obvious problem. Your home has a dozen private-addressed devices and one public address. Private addresses cannot cross the Internet. How does anything work?

At the boundary sits the translator: NAT — Network Address Translation — running on your home router (the same box that is your default gateway). As each outbound packet passes through, NAT rewrites the source address: the private address of your laptop is replaced with the router's own public address. To the Internet, every packet from your household appears to come from that one public address; the private addresses never show their faces outside. When replies come back, the router reverses the substitution and delivers inward.

The reversal is the clever part. If five devices all appear as one address, how does the router know which inbound reply belongs to which device? The answer is the form of NAT running in effectively every home: PAT — Port Address Translation (also called NAT overload, or masquerade in Linux documentation). PAT extends the rewrite to the transport layer: it replaces the source port too, assigning a unique translated port per conversation, and records every mapping in a translation table. The port number — Module 2's "which conversation is this?" field — becomes the return address tag for an entire household.

Here is a translation table we authored for a home router whose public address is 203.0.113.20 (all public addresses in this lesson come from the ranges reserved for documentation and examples, a professional habit worth copying):

(The address:port notation is the standard shorthand for "this address, this port.")

Walk it. Rows 1 and 2: the same laptop opened two browser tabs to the same website — two conversations, distinguished only by source port, each given its own translated port. Row 3: a different device, a DNS lookup. Row 4: a third device, another secure web session. Now a reply arrives addressed to 203.0.113.20

. The router looks up 30003, finds row 3, rewrites the destination back to 192.168.10.40, and delivers on the inside. The laptop never knows it was translated; the far server never learns a private address existed. One public address is carrying four conversations here — and could carry tens of thousands.

This is a many-to-one mapping: many private addresses, one public. It is also why, on a home connection, unrequested inbound traffic simply dies at the router: an arriving packet whose destination port matches no table row has no inside destination — there is nowhere to send it. That accidental property acts as a crude shield for households (a real firewall it is not — Module 7 draws that line properly).

The other flavors: static and dynamic NAT

The book catalogs the remaining translation styles, and the taxonomy still maps to modern practice:

Static NAT — a fixed one-to-one mapping: one public address permanently paired with one private address, configured by an administrator. This is how a server lives behind NAT. PAT's table rows are created by outbound conversations, so an inbound-first request (a customer visiting your web server) matches nothing — unless a static mapping guarantees that everything arriving at, say, public 203.0.113.25 forwards to inside 192.168.10.80. The home-router miniature of this idea is port forwarding: "inbound on this port → this inside device, this port" — a static rule scoped to ports instead of a whole address.

Dynamic NAT — one-to-one mappings created on demand from a small reserve of public addresses the organization owns, and released again when idle. It suits organizations holding several public addresses; a home has no such reserve, so you will meet it rarely.

A naming caution the book could not foresee: its era abbreviated Static NAT as "SNAT," but in today's firewall and Linux documentation SNAT means source NAT (rewriting source addresses, the general outbound case) as opposed to DNAT, destination NAT. When you meet "SNAT" in the wild, check which meaning the document intends — modern material almost always means source NAT.

From the textbook to 2026: CGNAT and the range you'll actually see

The book's story ends with NAT at the customer's edge. Exhaustion wrote one more chapter. When new customers outnumber available public addresses, an ISP can no longer hand every household its own public address — so the ISP builds NAT inside its own network. Your router NATs your household to a "public-looking" address... which is itself private to the ISP, translated again at the ISP's border. This is CGNAT — carrier-grade NAT (current), and your traffic crosses two translators before reaching the Internet.

CGNAT needed an address range for that middle layer — one guaranteed to collide neither with the public Internet nor with the RFC 1918 space customers already use. So the IETF reserved a fourth block: 100.64.0.0/10, "shared address space" (RFC 6598) — 100.64.0.0 through 100.127.255.255, for use between ISP and customer. This range is the give-away: if your router's WAN side holds an address between 100.64 and 100.127, you are behind CGNAT. The practical consequences: your household does not control a public address, port forwarding to the outside world cannot work (the table your rule would need lives at the ISP), and some games and video calls take the scenic route. CGNAT is now common on mobile networks and many fiber ISPs worldwide — a range every 2026 network person must recognize on sight, and the natural bridge to the next lesson: the protocol with enough addresses to need none of this.

Watch: NAT Explained — Network Address Translation

Why this video earns its place. PowerCert Animated Videos is one of the most widely recommended visual explainers in networking education, and this is its NAT lesson: the private-to-public rewrite drawn as moving pictures, with addresses visibly swapped as packets cross the router. You have just read the mechanism; watching addresses change on screen makes the table-row bookkeeping feel obvious. It is short, calm and beginner-paced.

As you watch, notice:

• The moment of translation at the router — the source address rewritten on the way out, exactly the substitution our PAT table records.
• The private-versus-public distinction driving the whole story: which addresses may cross the Internet and which never do.
• The return trip: how the router knows where an inbound reply belongs — the lookup you performed by hand on row 3 of our table.
• The framing of NAT as the response to IPv4 scarcity — the exhaustion story you now know with dates.

Caveats folded in. The video dates from 2018, so treat its address-scarcity and IPv6-adoption framing as a snapshot of that year — the current numbers (exhaustion complete; IPv6 at roughly half the Internet) are in this lesson and the next, which carry the up-to-date story. And where the video keeps to the core NAT idea, our sections above go further than it does — the full type taxonomy, translation-table detail, and CGNAT with the 100.64.0.0/10 range are covered in the text you just read, so nothing is missing if a topic does not appear on screen.

The video reinforces visually what you just learned — the lesson is complete without it.

Lab: Find Your NAT Boundary

Objective. Locate the translation boundary on your own connection: identify your private address, your public address, and — the 2026 twist — determine whether a CGNAT layer sits between them.

Setup. Any computer on your normal home (or mobile-hotspot) network, a browser, and access to your router's admin page if you have it (the address is usually your default gateway — you found it last lesson). No settings will be changed; this lab only reads.

Steps.

1. Find your private address: ipconfig on Windows, ip addr on Linux. Note the address and confirm which RFC 1918 block it belongs to.
2. Find your public address: in a browser, search for "what is my IP" and open any of the address-echo services the search returns (or, in a terminal, curl ifconfig.me). The address shown is what the outside world sees — note it.
3. Compare the two. They differ — you have just observed the NAT boundary from both sides. Confirm the public one belongs to no private range.
4. Now hunt for CGNAT. Open your router's admin page and find the WAN (Internet) address it reports. Compare three candidate stories: WAN address equals the address from step 2 (single NAT — your router holds a real public address); WAN address is between 100.64.0.0 and 100.127.255.255 (CGNAT — RFC 6598 shared space, a second translator at your ISP); WAN address is in an RFC 1918 range (double NAT inside your own building — common behind a second router or an ISP modem-router combo).
5. If you cannot reach a router admin page, run the same comparison from your phone on mobile data (most phone dashboards show the connection's address under settings): mobile carriers are heavy CGNAT users, so the shared range is often easiest to spot there.
6. Repeat step 2 from a second device on the same network. Same public address — the whole household shares it, exactly as the translation table predicts.

Expected result. A private address on your machine; a different, public address seen by the world; and a WAN-side verdict — public, shared-space (CGNAT) or private (double NAT).

Verify. You can draw your own connection as boxes and arrows: device (private) → router (translation) → [ISP translator, if step 4 said CGNAT] → Internet (public), with the real addresses labeled on each hop you observed.

Questions.

1. Which of your two addresses could your neighbor's laptop legitimately also be using right now, and why is that not a conflict?
2. If your WAN check found an address beginning 100.7x, what would that tell you — and what household feature would predictably not work?
3. Two devices in your house both loaded the same website. From the server's point of view, how many clients connected, from how many addresses?

(Answers: 1 — the private one: RFC 1918 addresses never cross the Internet, so identical copies in different homes can never meet. 2 — an address inside 100.64.0.0/10 means CGNAT: the ISP translates you a second time; port forwarding for inbound access would not work, since the outermost translation table is the ISP's, not yours. 3 — very likely one apparent client address — the household's shared public one — with the two devices distinguishable only as separate conversations on different ports.)

If it goes wrong.

• Steps 2 and 4 show the same address. Not wrong at all — that is the single-NAT outcome; your router genuinely holds a public address. Record it and move on.
• The address-echo site shows an IPv6 address (long, hexadecimal, colons). Also not an error — your connection is dual-stack and the browser preferred IPv6, where no NAT was needed. A hint of the next lesson; look for the site's IPv4 view, or use a v4-only echo service.
• No router admin access (ISP-locked equipment, dorm or office network). Skip to step 5's phone check, and note the limitation in your lab notes — knowing what you could not verify is part of the craft.
• Public address changes between checks. Normal on many ISPs: household public addresses are commonly dynamic, leased like DHCP addresses. Note both values and the lesson it teaches — "my" public address is rented, not owned.

Reset/cleanup. Nothing was changed anywhere. Keep the sketch from Verify — it reappears when the capstone asks you to document a network's NAT boundary.

Check yourself

1. Classify each as private, shared-space, or public: 172.20.9.4 · 172.40.9.4 · 100.90.1.7 · 192.168.250.6 · 10.0.0.5.
2. A reply packet arrives at the router addressed to the public address with destination port 30004. Using this lesson's translation table, state exactly what the router does next.
3. A small business runs a web shop on an inside server and customers must reach it from the Internet. Explain why everyday PAT cannot deliver those customers, and name the mechanism that can.
4. Your study partner quotes the book: "192.168 private space has a /24 mask." Give the kind, complete correction.
5. A friend on a new fiber ISP cannot make her game server reachable from outside, though she configured port forwarding perfectly. Her router's WAN address is 100.101.55.20. Diagnose.
6. In modern firewall documentation you meet the term SNAT. What does it most likely mean there, and what did the same letters mean in our textbook's era?

Answers

1. 172.20.9.4 — private (inside 172.16.0.0/12, which spans 172.16 through 172.31). 172.40.9.4 — public (past the /12 boundary). 100.90.1.7 — shared space (inside 100.64.0.0/10, the CGNAT range). 192.168.250.6 — private (the reservation is the whole /16, so any 192.168.x.y qualifies). 10.0.0.5 — private (10.0.0.0/8).
2. It looks up port 30004 in the translation table, finds the mapping to inside host 192.168.10.56 with its original port, rewrites the packet's destination to that inside address and port, and delivers it into the private network.
3. PAT's table rows exist only for conversations that began inside; a customer's inbound request matches no row, so the router has nowhere to send it and drops it. The fix is a static mapping — static NAT (or its port-scoped form, a port-forwarding rule) — pairing a public address (or port) permanently with the inside server.
4. Both mask values actually appear in the book, in different places — a printing inconsistency. RFC 1918 defines the reservation as 192.168.0.0/16, the full range up to 192.168.255.255; the /24 describes how people usually deploy a slice of it (one home = one /24 subnet such as 192.168.1.0/24). Reservation /16, typical deployment /24.
5. The WAN address sits inside 100.64.0.0/10 — she is behind carrier-grade NAT. Her port-forwarding rule programs her own router, but the outermost translation happens at the ISP, whose table has no entry for her game server; inbound requests die there. Options: ask the ISP for a real public address, use IPv6 if offered, or use a relay/tunnel service.
6. Today SNAT almost always means source NAT — rewriting source addresses on outbound traffic (the counterpart of DNAT, destination NAT). In the book's era the abbreviation stood for static NAT, the fixed one-to-one mapping. Same letters, different concept — check context.

Key terms

• Public address — a globally unique, registry-allocated address routable on the Internet.
• Private address (RFC 1918) — an address from 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16; freely reusable, never routed publicly.
• NAT (Network Address Translation) — rewriting packet addresses at a network boundary so private hosts can use a public address.
• PAT (Port Address Translation) — many-to-one NAT distinguishing conversations by translated source port; the home default. Also called NAT overload or masquerade.
• Translation table — the router's live record of address-and-port mappings; the lookup that routes replies home.
• Static NAT — a permanent one-to-one public-to-private mapping; how inside servers accept inbound connections.
• Port forwarding — a port-scoped static rule on home routers: inbound on a given port → a chosen inside device.
• Dynamic NAT — on-demand one-to-one mappings drawn from an organization's reserve of public addresses.
• SNAT — in modern usage, source NAT (contrast DNAT); in book-era usage, static NAT — context decides.
• IPv4 exhaustion — the depletion of unallocated IPv4 space; IANA's pool emptied in February 2011, regional pools over the following years.
• CGNAT (carrier-grade NAT) — a second translation layer inside the ISP; traffic is NATted twice.
• Shared address space (100.64.0.0/10, RFC 6598) — the reserved between-ISP-and-customer range; seeing it on a WAN interface means CGNAT.
• APIPA (169.254.0.0/16) — link-local self-assignment; not an RFC 1918 range, despite the similar flavor.

Summary

• IPv4's 4.3 billion addresses ran out on schedule — IANA's pool emptied in 2011 — and the Internet's working answer became private addressing plus NAT, with IPv6 as the true fix.
• RFC 1918 reserves 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16; the 172 block's /12 boundary (through 172.31) and the 192.168 block's /16 reservation are the details exams and interviews probe.
• The book's two 192.168 masks reconcile cleanly: /16 is the reservation, /24 the typical deployed slice.
• PAT lets one public address carry a whole household by translating source ports and keeping a table; replies are routed home by table lookup.
• Servers behind NAT need static mappings (static NAT or port forwarding) because inbound-first traffic matches no PAT row.
• Modern SNAT means source NAT — the book-era reading (static) is a naming shift to know.
• CGNAT adds a second translator inside the ISP using shared space 100.64.0.0/10 (RFC 6598); a WAN address in that range explains broken port forwarding instantly.
• You located your own NAT boundary and rendered a verdict — public, shared-space or double NAT — on your real connection.

Next lesson

NAT is brilliant, and it is a workaround — address scarcity managed, not solved. The module's finale meets the protocol designed to end scarcity outright: IPv6, with addresses so plentiful the arithmetic stops meaning anything, a new notation to read, and one big surprise — there is no broadcast anymore.

Sources and further study

• Al-Doori, T., Network Essentials, Chapter 6 — public/private addressing and the NAT/PAT/static/dynamic taxonomy this lesson retells and updates.
• RFC 1918, "Address Allocation for Private Internets" — https://www.rfc-editor.org/info/rfc1918/ — the private ranges, straight from the source.
• RFC 6598, "IANA-Reserved IPv4 Prefix for Shared Address Space" — https://datatracker.ietf.org/doc/html/rfc6598 — the CGNAT range and why a fourth block was needed.
• Download: OSI and TCP/IP Model Reference (the port numbers PAT rewrites live at the transport layer; keep the map handy).