Ports 67 and 68: DHCP

To speak on a network, you need an address. But to get an address, you need to speak. This is the impossible problem DHCP solves.

DHCP (Dynamic Host Configuration Protocol) is why you can walk into a coffee shop, connect to Wi-Fi, and be online in seconds. No manual configuration. No calling IT. Your device broadcasts a cry for help into the void, and somehow, an identity comes back.

The Bootstrap Problem

Every device on a network needs a unique IP address to communicate. But a new device doesn't have one yet. It can't send a polite request to a server because it has no return address—no way to receive the response.

The solution: use two dedicated ports and broadcast everything.

Port 67 is where DHCP servers listen. They wait for cries from the void.

Port 68 is where clients listen. Even without an IP address, a device can receive packets sent to this port.

A device with no identity (source address 0.0.0.0) broadcasts from port 68 to port 67. The server responds to port 68. This is how devices bootstrap themselves into existence.

The DORA Dance

DHCP assigns addresses through a four-step exchange: Discover, Offer, Request, Acknowledge.

Discover: Your laptop screams into the void. It broadcasts a DHCPDISCOVER message to 255.255.255.255 (every device on the local network) from source address 0.0.0.0. Translation: "I exist but have no identity. Does anyone have one I can use?"

Offer: Every DHCP server that hears this responds with a DHCPOFFER. "Here's an IP address you can have. It's yours for 24 hours. I'll also give you the gateway, DNS servers, and everything else you need." Multiple servers might respond—a blind auction.

Request: Your laptop picks an offer (usually the first one received) and broadcasts a DHCPREQUEST. This broadcast serves two purposes: it tells the winning server "I accept your offer," and it tells losing servers "release the address you offered—I'm not using it."

Acknowledge: The selected server sends a DHCPACK confirming the deal. Your laptop now has an identity. It configures its network interface and joins the conversation.

This entire dance takes milliseconds. Your laptop will renew the lease periodically to keep its address.

Why UDP? Why Broadcast?

TCP requires a handshake. A handshake requires both parties to have addresses. A device without an address can't handshake. So DHCP uses UDP—connectionless, no handshake required.

Broadcasts reach everyone on the local network segment. A device that doesn't know where the DHCP server lives can still reach it by shouting to everyone. The server is out there listening.

But broadcasts don't cross routers. This is where relay agents come in.

DHCP Relay: Crossing Boundaries

Large networks have many subnets separated by routers. Placing a DHCP server on every subnet is wasteful and hard to manage.

DHCP relay agents solve this. A router configured as a relay agent intercepts DHCPDISCOVER broadcasts on its local segment and forwards them as unicast messages to a central DHCP server. The relay includes information about which subnet the request came from, so the server assigns an address from the right pool.

When the server responds, the relay forwards the response back to the original subnet. From the client's perspective, the server might as well be local. One DHCP server can service hundreds of subnets across an entire enterprise.

The Security Problem

DHCP's automatic nature is also its vulnerability. Devices trust whoever answers first.

Rogue DHCP servers are the primary threat. An attacker plugs in an unauthorized DHCP server and races to answer discovery requests before the legitimate server. If they win, they can assign their own DNS servers and gateway—routing all victim traffic through systems they control. Your laptop doesn't know the difference between a legitimate offer and a malicious one.

DHCP snooping is the defense. Enterprise switches designate specific ports as "trusted" for DHCP server traffic. The switch drops DHCP server messages from untrusted ports. No rogue server, no hijacked traffic. Snooping also builds a binding table mapping MAC addresses to IP addresses and switch ports, enabling additional protections like dynamic ARP inspection.

Starvation attacks exhaust the server's address pool. An attacker requests every available address using spoofed MAC addresses, leaving nothing for legitimate devices. Rate limiting and port security help, but the fundamental problem—DHCP has no built-in authentication—remains.

DHCP authentication exists (RFC 3118) but sees almost no real-world deployment. The key management complexity isn't worth it when network access control and 802.1X can authenticate devices before they ever send a DHCP request.