The idea
An organisation with hundreds of hosts does not need every one of them to hold a scarce, globally routable address — most never talk to the outside world directly. Lecture 5’s own framing: some networks only need addresses to identify hosts within the organisation, and any network number can be used for that, because nothing outside ever needs to see it. That is a private internet, and RFC 1918 sets aside three blocks specifically so organisations can use them without asking anyone’s permission or coordinating with anyone else.
The catch is the lecture states plainly too: hosts using only a private address cannot reach the outside Internet, because private blocks are never advertised as a route. NAT is the fix — one router holds a small number of real, registered addresses, and every private host shares them by having its outbound packets rewritten on the way past.
Private addressing
How it works
RFC 1918 — three blocks, never routed
| Block | Range | Prefix |
|---|---|---|
| Historically "Class A" private | 10.0.0.0 to 10.255.255.255 | 10/8 |
| Historically "Class B" private | 172.16.0.0 to 172.31.255.255 | 172.16/12 |
| Historically "Class C" private | 192.168.0.0 to 192.168.255.255 | 192.168/16 |
Using private addresses alone saves the cost of a registered block and saves address space generally, but it comes with the one disadvantage the lecture names directly: every host in the organisation is cut off from the outside Internet, because nothing on the public network knows how to route to a private block.
NAT
How it works
One public address, many private hosts
NAT keeps a translation table mapping each outbound (private source IP, private port) pair to (public NAT address, newly assigned port). To stay transparent to both sides, the lecture lists what the router has to do:
- Build an access list of which LAN-side addresses are included in NAT.
- Hold a pool of WAN-side public addresses to translate into.
- Use both the IP address and the port number for the translation, not the address alone — this is what lets many private hosts share one public address at once.
- On every outgoing datagram, replace (source IP, port) with (NAT IP, new port).
- Record that mapping in the translation table.
- On every incoming datagram, replace the (NAT IP, new port) destination with the matching (source IP, port) pulled from the table.
Worked example
The lecture's own NAT transaction
Host
10.0.0.1, port3345, sends a datagram to128.119.40.186, port80. Source and destination are both ordinary IP addresses from the local network’s point of view.The NAT router rewrites the source.
10.0.0.1:3345becomes138.76.29.7:5001— the router’s own registered address, paired with a port it assigns for this flow.The router records the mapping in its translation table: WAN side
138.76.29.7:5001corresponds to LAN side10.0.0.1:3345.The reply arrives addressed to
138.76.29.7:5001. From the outside world’s point of view, that is the only address that ever existed for this conversation.The router looks up
138.76.29.7:5001in its table, finds the matching LAN entry, and rewrites the destination back to10.0.0.1:3345before delivering it internally.
AnswerOutbound: 10.0.0.1:3345 becomes 138.76.29.7:5001. Reply is translated straight back.
Aside
The lecture adds one detail worth keeping: in practice, the NAT pool’s outside address is normally kept separate from the router’s own outside interface address, rather than reusing it for translated traffic.
Try it
Send a few outbound packets from different hosts and watch the table fill in, then try the unsolicited-inbound button — the port on that one is chosen specifically so it matches nothing already in the table.
Where marks get lost
NAT breaks unsolicited inbound, by design
A host behind NAT can start a conversation outward with no trouble — that creates the table entry. What it cannot do is receive a connection nobody inside asked for, because there is nothing in the table to translate against. This is precisely why services run behind NAT (a home web server, for example) need a manually configured port forward: a standing table entry that exists before any outbound packet creates one naturally.
DHCP
How it works
Discover, Offer, Request, ACK
| Step | Message | Source | Destination | Purpose |
|---|---|---|---|---|
| 1 | DHCP Discover | 0.0.0.0 | 255.255.255.255 (broadcast) | Client looks for any DHCP server |
| 2 | DHCP Offer | DHCP server, port 67 | 255.255.255.255 (broadcast) | Server offers an address, lifetime 3600 seconds |
| 3 | DHCP Request | 0.0.0.0, port 68 | 255.255.255.255 (broadcast) | Client asks to use the offered address |
| 4 | DHCP ACK | DHCP server, port 67 | 255.255.255.255 (broadcast) | Server confirms the assignment |
The lecture marks Discover and Offer as skippable, and gives the specific condition rather than leaving it vague: citing RFC 2131 directly, the two steps “can be skipped if a client remembers and wishes to reuse a previously allocated network address.” A brand-new client with no address history always goes through all four steps; a rejoining client that wants its old address back can jump straight to Request.
| Aspect | Static configuration | DHCP |
|---|---|---|
| Who assigns the address | A sysadmin, hard-coded in a config file (e.g. /etc/rc.config) | The network, automatically, when the host joins |
| Address reuse | Held permanently, even while the host is off | Held only while connected — freed when the lease ends |
| Good fit for mobile hosts | No — the address does not follow the host | Yes — designed for hosts that join and leave |
In the exam
- Know the three RFC 1918 blocks by their exact ranges, not just their
prefixes — a question can give you a borderline address like
172.32.0.5specifically to check whether you know where the block actually ends. - NAT translates IP and port, not just IP. That pairing is what allows many private hosts to share one public address simultaneously.
- Trace a NAT example in both directions. Outbound rewrite, table entry, then the reverse rewrite on the reply — a question can ask for any one step given the others.
- The Discover/Offer skip condition is specific, not vague. It is “the client remembers and wants to reuse a previous address,” per RFC 2131 as the lecture cites it — not “sometimes” or “on fast networks.”
- Static vs DHCP is about who assigns and when it changes, not about which is technically superior.