DHCP — How a Device Gets Its Network Identity

Overview

Every device that communicates over IP needs at minimum two things before it can send or receive a single packet: an IP address and a subnet mask. In most networks, those values are not fixed — they depend on which switch port you plug into, which VLAN you land in, which site you work from. Configuring them manually on every device is not just tedious; in a network with hundreds or thousands of endpoints it is operationally unmanageable.

DHCP — Dynamic Host Configuration Protocol — solves this. When a device connects to a network with no pre-assigned address, it asks, and the network answers. The server hands back a complete network configuration: IP address, subnet mask, default gateway, DNS servers, lease duration, and anything else the administrator has configured it to distribute. The entire process takes milliseconds and requires nothing from the user.

The protocol is defined in RFC 2131, published in 1997. It superseded BOOTP (RFC 951) and inherited its well-known port numbers: the server listens on UDP port 67, and clients send from UDP port 68. Beyond addressing, DHCP can also distribute NTP server addresses, domain names, TFTP server locations for PXE boot, and dozens of other configuration parameters through its extensible options format defined in RFC 2132.

The Bootstrap Problem

There is an obvious chicken-and-egg problem at the heart of DHCP: to send an IP packet you need a source IP address, but the whole point is that you do not have one yet. Before DHCP can hand you an address, you need to ask for it — and asking requires sending a packet.

DHCP sidesteps this with two special addresses defined in the IP specification itself:

• 0.0.0.0 — used as the source address to mean “I have no address.” Routers will not forward packets with this source, which constrains the exchange to the local segment.
• 255.255.255.255 — the limited broadcast address. Every device on the local Layer 2 segment receives it, but routers will not forward it beyond the segment boundary.

This means the initial exchange is entirely local. The client shouts onto the wire, and any DHCP server on the same segment hears it and responds — all without a single packet crossing a router. The server can reply to the client before the client has an IP because it already learned the client’s MAC address from the Ethernet frame header. MAC addresses are enough to deliver a Layer 2 frame; IP is not needed yet.

Topology

The scenario covered in this article is the simplest possible: client and server share the same Layer 2 broadcast domain. No routing is involved.

In real enterprise networks, the client and server are often on different subnets. A relay agent (typically the router or Layer 3 switch at the segment boundary) intercepts the client’s broadcast and forwards it as a unicast packet to the DHCP server on another subnet. That scenario is covered in a separate article.

How to Read the Packet Diagrams

Each section below includes a packet diagram that shows the byte layout of the relevant frame or header as it exists on the wire. Every box represents one field — its width is proportional to the field’s size in bytes, so a wider box means more bytes. The field name is at the top, the byte count in grey below it, and the actual value for this specific packet in cyan. This gives you a visual sense of how much space each field occupies relative to the others before the detailed tables fill in the meaning of each value.

Step 1 — The Client Speaks First

The first thing a device does when it connects with no address is broadcast a DHCP DISCOVER message to the entire local segment. It is essentially shouting into the room: “I am here, I have no address, is there anyone who can help me?”

Because the client has no IP yet, it cannot send a normal unicast packet. Instead, it uses 0.0.0.0 as the source address and 255.255.255.255 as the destination, ensuring every device on the local segment receives it. At Layer 2, the destination MAC is FF:FF:FF:FF:FF:FF — the hardware broadcast address — so the switch floods the frame out every port.

The client also generates a random 32-bit transaction ID (xid) that it will carry through the entire exchange. This is how it matches the server’s responses to its own request, especially important in environments where multiple DHCP servers respond simultaneously.

Layer 2 — Ethernet Frame

The diagram below shows the Ethernet II frame the client puts on the wire. The destination MAC is all FF — the broadcast address — because the client does not know the MAC of any DHCP server yet.

Layer 3 — IP Header

Layer 4 — UDP Header

Layer 7 — DHCP Payload

Step 2 — The Server Responds with an Offer

Every DHCP server on the segment receives the DISCOVER. Each one that has addresses available inspects the request, selects an address from its pool, and sends back a DHCP OFFER.

The OFFER is the server’s proposal. It includes the address the server is willing to assign, the subnet mask, the default gateway, the DNS server addresses, and the proposed lease duration. The server marks this address as tentatively reserved — held for this client, but not yet committed. If the client never responds, the reservation eventually times out and the address returns to the pool.

Something worth noticing here: even though the server now knows the client’s MAC address from the Ethernet header, it still sends the OFFER by broadcast. RFC 2131 specifies that a client must not respond to unicast frames addressed to an IP it has not officially accepted. Broadcasting ensures the OFFER gets through regardless of the client’s state.

Layer 3 — IP Header

The most interesting thing about the OFFER at the IP layer is that the server now has a real source IP — but the destination is still the broadcast address, because the client has no IP to unicast to.

Layer 2 — Ethernet Frame

Layer 7 — DHCP Payload

Step 3 — The Client Selects an Offer

The client may have received OFFER messages from more than one server. It picks one — typically the first that arrived — and must now simultaneously accomplish two things:

1. Tell the server whose offer it accepted: “I want this address.”
2. Tell every other server that sent an OFFER: “I am not taking your address — please release it.”

It achieves both with a single DHCP REQUEST, broadcast to the entire segment. The REQUEST includes Option 54 (Server Identifier), which names the winning server by IP address. Every server on the segment sees this message. Servers that find their own IP in Option 54 know the client chose them. Servers that find a different IP know they were not selected and immediately de-reserve the address they were holding.

Why is it still a broadcast?

The client still uses 0.0.0.0 as its source IP and broadcasts to 255.255.255.255. There are two reasons: the client still has no confirmed IP it can use as a source address, and the message must reach all DHCP servers on the segment so that those whose offers were rejected can release their reserved addresses. Unicasting only to the winning server would leave every other server sitting on a reserved but now unwanted address indefinitely.

Layer 7 — DHCP Key Options

The most important fields in the REQUEST are the two options that identify what the client is accepting and from whom.

Step 4 — The Lease is Confirmed

The selected server receives the REQUEST, verifies the address is still available, and sends back a DHCP ACK. This is the final message in the initial exchange and the one that makes the lease official.

The ACK confirms every parameter from the OFFER: address, subnet mask, gateway, DNS, and lease duration. Receiving the ACK is what starts the lease timer. Once the client receives this message, it knows the address is its to use.

But the client still does not immediately configure its interface. It first performs an ARP probe — a broadcast ARP asking “does anyone else have 192.168.1.100?” — to verify no other device is already using the address. If another device responds, the client sends a DHCP DECLINE back to the server and restarts the process from scratch. If nobody responds to the ARP probe, the address is clear and the interface is configured.

Layer 7 — DHCP Payload

The ACK looks nearly identical to the OFFER. The key difference is Option 53, which now reads 5 (ACK) instead of 2 (OFFER), and yiaddr — the confirmed IP address — is now officially the client’s.

The Full Exchange — DORA

Now that you have seen each step in detail, the complete exchange has a name: DORA — Discover, Offer, Request, Acknowledge. It is the standard shorthand for the four-message sequence that takes a device from a blank slate to a fully configured IP host.

Notice that all four messages use 255.255.255.255 as the destination. The server cannot switch to unicast until after the ACK because the client has no confirmed IP to receive unicast traffic on.

Lease Mechanics

The address a DHCP server assigns is not permanent. It is a lease — valid for a defined period — and managing that lease is what keeps address pools healthy over time. Without lease expiry, a client that disconnects permanently would hold its address forever, eventually exhausting the pool.

RFC 2131 defines three timers that govern the lease lifecycle:

At T1, the situation is fundamentally different from the initial exchange: the client now has a valid, confirmed IP address. It sends the renewal REQUEST directly to the server that issued the lease as a unicast packet — a targeted one-to-one conversation that does not disturb the rest of the network. If the server responds with an ACK, the lease timer resets to zero and the countdown begins again.

If the server is unreachable by T2 — perhaps it crashed or the client moved to a different segment — the client falls into rebinding mode. It broadcasts a REQUEST to find any available DHCP server willing to extend the lease. A different server can respond and take over the lease, though the client may receive a different address depending on that server’s pool.

If the lease reaches full expiry with no renewal and no rebind, the client must discard its IP address entirely and restart from Step 1 — a full DISCOVER broadcast as if it had just connected for the first time. In Windows this results in a brief APIPA address (169.254.x.x) while retrying; on Linux the interface is left unconfigured until a server responds.

Key Concepts

The transaction ID is the glue

The xid field is a random 32-bit number generated at the start of the DISCOVER and echoed unchanged through the OFFER, REQUEST, and ACK. On a segment where dozens of clients may be running simultaneous DHCP exchanges, the xid is the only mechanism a client has to know which incoming messages belong to its own conversation. Without it, a client could accidentally configure itself with an address offered to a different device.

Broadcast is a design choice, not a limitation

It is tempting to read “broadcast” as a workaround for the client not having an address yet. The use of broadcast in Step 3 (REQUEST) goes beyond that — at that point, the client could have unicasted directly to the chosen server. It broadcasts instead because it needs all other DHCP servers on the segment to see the message and release their reserved addresses. Broadcast is the architecturally correct tool for that problem.

DHCP is connectionless — reliability is the client’s responsibility

DHCP runs over UDP. There are no TCP-style acknowledgements and no automatic retransmission at the transport layer. If a DISCOVER goes unanswered, the client is expected to retry — RFC 2131 recommends an exponential backoff starting at around four seconds. A client that exhausts its retries will report that no DHCP server is available. In Windows this shows up as an APIPA address; in Linux, the interface is left unconfigured.

Lease duration is an operational policy decision

A short lease is appropriate in environments with frequent turnover, like a conference room or café Wi-Fi. A long lease suits a corporate LAN where devices are stable. Getting this wrong causes real problems: leases that are too short generate renewal storms during busy periods; leases that are too long exhaust the address pool when many devices leave without releasing their addresses gracefully.

References

• RFC 2131 — Dynamic Host Configuration Protocol
• RFC 2132 — DHCP Options and BOOTP Vendor Extensions
• RFC 951 — Bootstrap Protocol (BOOTP)