DHCP and ARP: How Your Computer Gets and Uses Its Address

Plug a brand-new laptop into an office network and within a few seconds it has an IP address, a default gateway, and a DNS server — nobody told it any of that, nobody typed anything into a settings panel. A minute later, when you load a webpage, your laptop fires off a packet that goes directly to the right physical device on the local wire even though you never told it which device that was.

Two protocols make that work: DHCP hands out the configuration, and ARP finds the right hardware to deliver each packet to. They’re separate jobs — DHCP gets you logical configuration (an IP, a gateway, a DNS server), ARP turns logical addresses into physical ones — but they happen back to back the first time a host wakes up on a new network, and most of what feels “automatic” on modern networks is one of these two protocols doing its work.

This is lesson 4 of Networking from Scratch. Lesson 2 told you what an address is; lesson 3 showed you how to do the math. This one explains how a host actually gets one of those addresses and uses it to talk to its neighbours.

Part 1: DHCP — the four-packet handshake

DHCP (Dynamic Host Configuration Protocol) is the “automatic IP” mechanism. When a host doesn’t already have an address, it asks the network for one, and a DHCP server replies. The exchange is four packets in a fixed sequence, sometimes called DORA:

1. DISCOVER — client to network: “hi, anyone got a DHCP server?”
2. OFFER — server to client: “here’s a proposal: 192.168.10.142, gateway .1, DNS .53, lease 24h.”
3. REQUEST — client to network: “I’ll take it, formally.”
4. ACK — server to client: “confirmed, it’s yours.”

Let’s walk through what each packet actually contains and why all four are needed.

1. DISCOVER (broadcast)

The client doesn’t have an IP yet, so it can’t address a packet to anyone in particular. It sends a broadcast: source IP 0.0.0.0, destination IP 255.255.255.255, source MAC = its own hardware address, destination MAC = the all-ones broadcast MAC. Every device on the local segment sees the packet; only DHCP servers care.

The DISCOVER includes the client’s MAC address (so the server knows whom to reply to) and a transaction ID — a random number that ties the four packets together. If multiple DHCPs are happening on the same segment at the same time, the transaction ID is what keeps them from getting tangled.

2. OFFER (back to the client)

Any DHCP server that hears the DISCOVER and has an address available picks one out of its pool, fills in the rest of the config, and sends an OFFER. The OFFER includes:

• The proposed IP address.
• The subnet mask.
• The default gateway.
• One or more DNS server addresses.
• The lease time (how long the client gets to keep the address).
• Often a domain suffix (corp.example.com) and an NTP server.

If there are two DHCP servers on the network (which is rare but legal — usually for redundancy), the client may receive two OFFERs. It picks one — typically the first to arrive — and ignores the other.

3. REQUEST (still broadcast)

The client now formally requests the offered address. This is also a broadcast, even though the client knows which server it’s talking to, because:

• The client still doesn’t have an IP — the OFFER hasn’t been accepted yet.
• Any other DHCP server that made an OFFER needs to see the REQUEST so it can put its own offered address back in the pool.

4. ACK

The chosen DHCP server confirms the lease. From this moment on, the client has the address. Most clients log a kernel message like “bound to 192.168.10.142” when this lands.

The whole exchange takes between a few milliseconds (wired LAN) and a couple of seconds (Wi-Fi with retries). On a stable network you barely notice it.

The lease, T1, and T2 — renewal mechanics

A DHCP lease is finite. Default lease times you’ll see in the wild:

The client doesn’t wait until the lease expires to renew. Two timers fire earlier:

• T1 (renewal) = 50% of the lease. Client sends a unicast RENEW directly to the original DHCP server. If the server replies, the lease resets and life goes on.
• T2 (rebinding) = 87.5% of the lease. If renewal failed (the original server is down or unreachable), the client broadcasts a REBIND to any DHCP server. If anyone answers, great.
• Lease expiry — if both timers passed without acknowledgement, the client gives up the address and starts the DORA exchange from scratch.

That’s why a brief DHCP-server outage is usually invisible to clients — they don’t need to talk to the server until 50% of the lease has gone.

DHCP options — what else the server hands out

DHCP doesn’t just deliver an IP. The protocol uses a numbered options system to deliver dozens of other configuration values. The ones you’ll meet most often:

If you ever wondered how a phone shows up at a desk and figures out which call manager to register with, or how a PXE-booting bare-metal box knows where to fetch its boot image from — it’s a vendor-specific DHCP option.

DHCP across subnets — the relay agent

DHCP DISCOVER is a broadcast, and broadcasts don’t cross routers. So how does a single DHCP server hand out addresses to clients in twenty different subnets across an office?

The router (or a Layer-3 switch) on each subnet runs a DHCP relay agent, sometimes called ip helper-address in Cisco-flavoured config. When the relay sees a DHCP broadcast on its local segment, it wraps the packet in a unicast and forwards it to the configured DHCP server’s IP, on the other side of the router. The server replies, the relay unwraps the response, and the client sees a normal DHCP exchange even though the actual server is a layer-3 hop away.

The relay also tells the server which subnet the request came from (via the giaddr field), so the server can hand out an address from the right pool. That’s how one DHCP server can serve 10.10.1.0/24, 10.10.2.0/24, and 10.10.3.0/24 simultaneously without any of them being on the server’s own segment.

Static reservations vs static IPs vs dynamic

For most networks, reservations beat static-on-the-host: you get the same stable IP without scattering hard-coded values across dozens of devices.

Part 2: ARP — finding the hardware on the other end

Now your laptop has an IP, a gateway, and a DNS server. The first thing it tries to do is reach the gateway — the router on the way out. It knows the gateway’s IP (DHCP handed that over). What it doesn’t know is the gateway’s MAC address, which is what the Ethernet/Wi-Fi layer actually uses to deliver a frame.

That’s the job of ARP (Address Resolution Protocol). It’s a tiny, ancient protocol — literally one request and one reply — and it runs on every IPv4 packet you’ve ever sent.

The ARP exchange

Client (broadcast):  "Who has 192.168.10.1? Tell 192.168.10.142."
Gateway (unicast):   "192.168.10.1 is at e8:cc:18:11:22:33."

Two packets. The request is a broadcast on the local segment so every device sees it; only the device whose IP matches replies. The reply is unicast, sent directly to the asking machine’s MAC address.

The asking machine then caches the result in its ARP table for some minutes (Linux defaults around 60 seconds, Windows around 2 minutes), so it doesn’t have to ask again for every packet.

Inspect the ARP cache yourself

# Windows
arp -a

# macOS / Linux
arp -an
# or, modern Linux:
ip neigh show

You’ll see one line per known neighbour, with their IP, MAC, and the interface the entry was learned on. On a typical home laptop, your ARP cache usually contains the gateway, maybe a printer, and any device you’ve recently connected to on the same LAN. Anything you’ve only reached via the internet doesn’t appear — the gateway handles those, and from your laptop’s perspective, the gateway’s MAC is the only one that matters for off-LAN traffic.

Gratuitous ARP

Sometimes a host sends an ARP request for its own IP. That’s called a gratuitous ARP and it’s a way of announcing “hi, I just came up with this IP” to the segment. Two real uses:

• Conflict detection. If a reply comes back from someone else, the IP is already in use and the host should not take it. DHCP clients usually do this right after the ACK.
• Cache update. Other hosts on the segment learn the new IP-to-MAC mapping immediately, instead of waiting for their cached entry to expire. This is what makes failovers fast — when a virtual IP moves from one node to another, the new owner sends a gratuitous ARP and every device on the LAN updates its cache within milliseconds.

What can go wrong with each — and how to recognise it

The 169.254.x.x case is the one beginners most often see in the wild. That range is APIPA / link-local; the OS auto-assigns one of these addresses when DHCP doesn’t come back. It’s a strong signal that DHCP, not the host, is the broken thing.

A note on IPv6 (preview)

IPv6 has a different model. Hosts can configure themselves without a DHCP server using SLAAC (StateLess Address AutoConfiguration) — the router on the segment advertises the network prefix, and each host generates its own host portion of the address. There’s also DHCPv6 for the cases where you do want central control (DNS servers, options the router doesn’t advertise, etc.). And ARP doesn’t exist on IPv6 — its job is done by Neighbor Discovery (ND), which lives in ICMPv6 and is functionally similar but better engineered.

We’ll cover all of that in the IPv6 article later in the pathway. For now, just know: the concepts are the same — how do I get configured, how do I find the hardware on the other end — the protocols are different.

What you can now answer

• How does a brand-new device get an IP address? — DHCP DORA: DISCOVER, OFFER, REQUEST, ACK.
• What else does DHCP hand out? — Subnet mask, gateway, DNS, lease time, domain suffix, vendor-specific bits.
• How does DHCP work across subnets? — A relay agent on each router forwards broadcasts as unicasts to a central DHCP server.
• How does my computer find the MAC address for a given IP? — ARP request to the broadcast MAC, ARP reply back from the owner of that IP.
• What does 169.254.x.x mean? — DHCP failed; the host fell back to APIPA / link-local.

What’s next

You now know how a host gets configured and how it talks to its immediate neighbours. The next article zooms out one level: routing vs switching — the one-paragraph mental model that finally makes the difference between a switch’s MAC table and a router’s routing table click. Once that’s in place, the rest of the infrastructure-side articles in this pathway (cabling, Wi-Fi, WAN design) all become much more concrete.