NAT, DHCP, and ARP

These three protocols quietly do most of the work that makes a modern local network usable. Each solves a different, specific problem: DHCP hands out addresses automatically, ARP finds the physical hardware address behind an IP address, and NAT lets many private addresses share one public one. None of them are optional in a typical home or office network — they run constantly, invisibly, underneath everything else in this course.

1DHCP — Dynamic Host Configuration Protocol

Every device on an IP network needs an IP address, a subnet mask, a default gateway, and DNS server addresses (later topics) before it can do anything useful. Manually typing all of that into every laptop, phone, and printer that joins a network would be unworkable at scale. DHCP automates it.

The DHCP handshake: DORA

When a device joins a network, it broadcasts for configuration using a four-step exchange, commonly remembered as DORA:

1. Discover — the new device broadcasts "is there a DHCP server out there? I need an address" (it has no IP yet, so this is a broadcast, not addressed to any specific host).
2. Offer — a DHCP server on the network replies with a proposed IP address and configuration (subnet mask, gateway, DNS, lease time).
3. Request — the device broadcasts back "I accept that offer" (broadcast again, in case multiple DHCP servers made offers — this tells all of them which offer won).
4. Acknowledge — the server confirms, finalizing the lease — the address is now assigned to that device for a defined period of time.

Client                          DHCP Server
  |----- DISCOVER (broadcast) ------>|
  |<---- OFFER (192.168.1.50) -------|
  |----- REQUEST (I'll take it) ---->|
  |<---- ACK (lease confirmed) ------|

Leases

A DHCP-assigned address isn't permanent — it's a lease with an expiration time. Before the lease expires, the client renews it (typically directly with the server, skipping the full DORA cycle); if a device disconnects and never renews, the address eventually becomes available for the server to hand out again. This is why the same laptop can get a different IP address on the same network after being off for a while — nothing guarantees the same address is still free.

2ARP — Address Resolution Protocol

IP addresses get a packet to the right network and host logically, but the actual delivery within a local network segment happens using MAC addresses — the hardware addresses burned into network interfaces, used at the data link layer (see the OSI model topic). Before a host can send a frame to another host on the same local network, it needs to know: "what MAC address corresponds to this IP address?" That's what ARP answers.

How ARP resolution works

1. Host A wants to send a packet to 192.168.1.20, which it knows (from its routing logic) is on its own local network.
2. Host A checks its ARP cache — a local table mapping recently-resolved IP → MAC pairs. If 192.168.1.20 is already there, it uses that MAC immediately, no network traffic needed.
3. If not cached, Host A broadcasts an ARP request to the entire local network: "who has 192.168.1.20? Tell me your MAC address."
4. Only the host that actually owns 192.168.1.20 replies, directly to Host A, with its MAC address.
5. Host A caches the answer and sends the actual frame using that MAC address as the destination.

Host A broadcasts: "Who has 192.168.1.20? Tell 192.168.1.10"
        ↓ (every host on the LAN sees this broadcast)
Host at .20 replies directly: "192.168.1.20 is at aa:bb:cc:dd:ee:ff"

Critically, ARP only works within a single local broadcast domain — a broadcast never crosses a router. If the destination is on a different network, ARP resolves the MAC address of the default gateway (the router) instead, not the final destination — the router itself figures out the next hop from there.

3NAT — Network Address Translation

As covered in the IP/IPv4/IPv6 topic, private IP addresses (like 192.168.1.10) aren't routable on the public internet. NAT, running on your router/gateway, is what lets a device with a private address actually reach the internet — by rewriting its packets to use the router's one public address instead.

What NAT actually rewrites

The specific, common form is NAPT / PAT (Network Address Port Translation, sometimes called "NAT overload") — the kind used by nearly every home router:

1. Host 10.0.0.5 sends a packet from source 10.0.0.5:51000 to some server at 93.184.216.34:443.
2. The router rewrites the packet's source IP and source port to its own public address and a port it picks, say 203.0.113.1:40001, and records this mapping in a translation table.
3. The packet leaves with source 203.0.113.1:40001 — the destination server only ever sees the router's public address, never 10.0.0.5.
4. When the reply comes back addressed to 203.0.113.1:40001, the router looks up its translation table, finds it maps to 10.0.0.5:51000, rewrites the destination back, and forwards it to the correct private host.

This is exactly why many different private hosts behind one router can all reach the internet simultaneously through a single public IP — each gets a distinct translated port, keeping every connection's return traffic routable back to the correct internal host.

arp -a
# ? (192.168.1.1) at aa:bb:cc:dd:ee:ff on en0 ifscope [ethernet]

⚠️ Common Pitfalls

1. Believing NAT is a firewall — NAT blocking unsolicited inbound traffic is an accidental side effect of the translation table, not an enforced security policy; a host with a port forwarded through NAT is exactly as exposed on that port as if it had a public IP directly.
2. Assuming ARP works across the internet — ARP is strictly local-network-only; resolving an address on a different network resolves the gateway's MAC, never the far-end host's MAC directly.
3. Assuming a device's IP address never changes — under DHCP, a lease can expire and be renewed with a different address, especially after being offline; anything that needs a stable address (a server, a printer other systems point to by IP) should use a DHCP reservation or static IP, not assume DHCP will "usually" give the same one back.
4. Not realizing ARP replies are unauthenticated — treating a LAN as inherently trustworthy ignores that any device on it can claim to be any IP via ARP; this is a real, exploitable weakness on shared or untrusted local networks (public Wi-Fi, for example).
5. Confusing DHCP lease renewal with the full DORA process — a renewing client typically talks directly to the server it already has a lease from, without re-broadcasting Discover; only a device with no current lease (or one that's expired) goes through full DORA.
6. Forgetting port forwarding punches a permanent hole — a forwarded port bypasses NAT's "no inbound without an outbound first" protection entirely and permanently for that port, which is exactly why it should be scoped as narrowly as possible.

📋 Quick Reference

DHCP — automatic IP configuration
  DORA: Discover → Offer → Request → Acknowledge
  Leases expire and renew; no guarantee of the same address twice

ARP — IP-to-MAC resolution, LOCAL NETWORK ONLY
  Broadcast request → unicast reply → cached locally (ARP cache)
  Cross-network destination → resolves the GATEWAY's MAC, not the far host's
  No authentication → spoofable (ARP poisoning)

NAT (specifically NAPT/PAT) — many private IPs share one public IP
  Rewrites (src IP, src port) → (public IP, translated port)
  Translation table built OUTBOUND-first
  No matching table row for inbound traffic → dropped (not a firewall decision, just no route back)
  Port forwarding = a manual, permanent table row enabling unsolicited inbound traffic

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: net_nat_dhcp_arp_theory.md · generated by tools/build_lessons.py