skip to content

DORA Exchange

4 roadmaps6 questions

Discover, Offer, Request, Acknowledge: four mostly broadcast messages that end in a bound lease. Interviewers ask why the Request is still broadcast and what happens when two servers offer.

on this pageshow

explore

questions

6

In DHCPv4, what are the four messages of the DORA exchange, and who sends each one to which address?

level: juniorimportance: must knowfreq 55%

answer

  1. client asks, servers answer, client picks
  2. the client's two messages are broadcasts
  3. source 0.0.0.0, destination all-ones
  4. UDP ports 67 and 68
  5. only the Ack follows a commit

basics

~20 s

DORA is Discover, Offer, Request, Acknowledge. The client broadcasts a DHCPDISCOVER, each willing server answers with a DHCPOFFER, the client broadcasts a DHCPREQUEST naming the server it chose, and that server commits the lease and sends a DHCPACK.

solid answer

~40 s

A laptop with no address sends a `DHCPDISCOVER` from `0.0.0.0` UDP port 68 to `255.255.255.255` port 67, because it knows neither its own address nor any server's. Every server willing to serve it replies with a `DHCPOFFER` to client port 68, carrying an address in `yiaddr`, a lease time and its server identifier. The client picks one offer and broadcasts a `DHCPREQUEST` that names the chosen server and the offered address, still from `0.0.0.0`. The chosen server commits the binding and replies with a `DHCPACK`; the other servers read the same Request as the client turning them down. Whether an Offer or Ack is unicast or broadcast depends on the BROADCAST flag the client set. After the Ack the client should check that the address is free, and then it is configured.

go deeper

for a junior

Name the four messages in order, say which side sends each, and state that the client's two messages are broadcasts from 0.0.0.0 to 255.255.255.255 on UDP port 67.

for a middle

Explain that the Offer only proposes and the Ack follows the commit, what yiaddr, xid and the server identifier carry, and why replies depend on the BROADCAST flag.

for a senior

Read a capture of the bind: match the xid across all four messages, tell from the Request which server won, and explain an Offer that never turns into an Ack.

for a principal

Weigh what the four-message design costs on a large broadcast domain: each bind floods the VLAN at least twice, and every server on it must return consistent parameters.

## What the DORA exchange does A host that joins a network with no IPv4 address cannot talk to anything by unicast: it has no address of its own and does not know where a **DHCP server** is. The **Dynamic Host Configuration Protocol** (DHCP, RFC 2131) solves that with a four-message exchange, usually remembered as **DORA**: **Discover, Offer, Request, Acknowledge**. At the end the client holds a **lease** — an address it may use for a stated time — plus the other parameters the server handed it. The type of each message travels in an option; this explanation names the types in words. Every DHCP message uses the same fixed header inherited from BOOTP (RFC 951). The fields that matter here: - `op` — BOOTREQUEST from a client, BOOTREPLY from a server. - `xid` — a random 32-bit transaction ID the client picks; replies copy it so the client can match them. - `chaddr` — the client's hardware (MAC) address. - `ciaddr` — the client's current address; zero during this exchange, because it has none. - `yiaddr` — "your" address: the address the server is offering or assigning. - `flags` — its leftmost bit is the **BROADCAST** flag, which asks servers to broadcast their replies. ## The four messages on the wire DHCP runs over UDP: messages to a server go to port **67**, messages to a client go to port **68**. | Message | Sent by | IP source → destination | What it carries | |---|---|---|---| | `DHCPDISCOVER` | client | `0.0.0.0` → `255.255.255.255` | "Is any server there?" — `xid`, `chaddr`, optional hints | | `DHCPOFFER` | each willing server | server → `yiaddr` (frame to `chaddr`) or `255.255.255.255` | offered address in `yiaddr`, lease time, server identifier | | `DHCPREQUEST` | client | `0.0.0.0` → `255.255.255.255` | chosen server's identifier, requested IP address = the offered `yiaddr` | | `DHCPACK` | chosen server | server → `yiaddr` (frame to `chaddr`) or `255.255.255.255` | committed address in `yiaddr`, lease time, parameters | The client's two messages are broadcasts from `0.0.0.0`; RFC 2131 requires a message broadcast before the client has an address to carry source address 0. Whether the server's two replies are unicast or broadcast depends on the BROADCAST flag the client set. ## Walking through one bind Take a laptop with MAC `00-00-5E-00-53-1A` joining an office VLAN, `10.40.8.0/24`, where two servers, `10.40.8.5` and `10.40.8.6`, both serve the subnet. 1. **Discover.** The laptop picks `xid` `0x5A1C93E7` and broadcasts a `DHCPDISCOVER` from `0.0.0.0` port 68 to `255.255.255.255` port 67. Both servers hear it. 2. **Offer.** Each server picks a free address and answers with a `DHCPOFFER`: `10.40.8.5` offers `10.40.8.57`, `10.40.8.6` offers `10.40.8.140`. Both copy the client's `xid`. An offer is a proposal: RFC 2131 does not require a server to reserve it, and nothing is committed yet. 3. **Request.** The laptop chooses one offer — say the first — and broadcasts a `DHCPREQUEST` with the server identifier set to `10.40.8.5` and the requested IP address set to `10.40.8.57`. It still sends from `0.0.0.0`. 4. **Acknowledge.** `10.40.8.5` sees its own identifier, commits the binding to persistent storage and sends a `DHCPACK`. `10.40.8.6` sees a Request naming another server and treats it as the client declining its offer. After the Ack the client SHOULD make a final check that the address is not already in use — typically with ARP — and then it is configured and starts its lease timers. ## Messages that sit around the four DORA is the happy path. RFC 2131 defines eight message types in all (later RFCs add more, such as `DHCPFORCERENEW` in RFC 3203), and the other four serve around the bind: - `DHCPNAK` — server to client: the server cannot grant what the Request asked for, so the client starts again. - `DHCPDECLINE` — client to server: the final check found the address already in use. - `DHCPRELEASE` — client to server: the client gives the address back before the lease ends. - `DHCPINFORM` — client to server: a host with a manually set address asks only for the other parameters. What a bound client does as its lease runs — renewing and rebinding — belongs to the lease lifecycle, not to the bind. A server can receive five of the eight types (Discover, Request, Decline, Release, Inform); a client receives the other three (Offer, Ack, Nak). ## Mistakes that cost points - Saying the **Offer** allocates the address. It only proposes; the **Ack** is sent after the server commits the binding. - Saying the **Request** is unicast to the chosen server. In this exchange it is broadcast, so every server learns the outcome. - Swapping the ports: the client listens on **68**, servers on **67**. - Calling `DHCPDECLINE` a server message. It is the client's; `DHCPNAK` is the server's. - Forgetting that two servers can both answer one Discover: the client gets several offers and must pick exactly one.

  • Why does the DHCPv4 client send its Discover and Request from 0.0.0.0 instead of some guessed address?
    Every IP header needs a source, and the client owns no address yet. `0.0.0.0` means "this host, no address", so it borrows nobody else's. RFC 2131 requires messages a client broadcasts before it has an address to carry source 0. That is also why servers cannot simply reply to the packet's source: they address replies to `yiaddr` with the frame sent to `chaddr`, or broadcast them.
  • Is the DHCPACK the last thing that happens before the laptop uses the address?
    Not quite. RFC 2131 says the client SHOULD perform a final check on the address, for example with ARP. If another host already uses it, the client MUST send a `DHCPDECLINE` and restart configuration; otherwise it is configured, records the lease's expiry and starts its renewal timers.
  • Which DHCPv4 message types does a server receive, and which does a client receive?
    Per RFC 2131, a server receives `DHCPDISCOVER`, `DHCPREQUEST`, `DHCPDECLINE`, `DHCPRELEASE` and `DHCPINFORM`; a client receives `DHCPOFFER`, `DHCPACK` and `DHCPNAK`. So a NAK always comes from a server and a Decline always from a client.

saying these in an interview costs you the question

  • The DHCPOFFER commits the address; the Request and Ack are just a formality.
  • The client unicasts its DHCPREQUEST to the server whose offer it chose.
  • The client and the server both use UDP port 67 for every DHCP message.
  • The DHCPDISCOVER is sent from the address the client had on its last network.
open as a page

When two DHCP servers both answer a laptop's DHCPDISCOVER, how does the client choose one, and why is its DHCPREQUEST still broadcast?

level: middleimportance: must knowfreq 40%

basics

~20 s

The client may pick any offer, for example the first; RFC 2131 sets no rule. It broadcasts the DHCPREQUEST so every server hears it: the server identifier tells the chosen server to commit and the others that their offers were declined.

open as a page

How does a DHCPv4 server reach a client that has no address yet, and how does the client match the reply to its request?

level: middleimportance: should knowfreq 20%

basics

~20 s

The server unicasts the Offer to the offered address with the frame sent to the client's hardware address, or broadcasts it if the client set the BROADCAST flag. The client accepts only replies whose xid matches its latest request.

open as a page

After a DHCPACK, a laptop's ARP check finds the leased address already in use; what must the DHCP client and server each do next?

level: seniorimportance: should knowfreq 15%

basics

~20 s

The client must broadcast a DHCPDECLINE naming the address and the server, then should wait at least ten seconds before restarting with a new Discover. The server must mark that address not available and should alert its administrator.

open as a page

On a VLAN served by two DHCP servers, a laptop's DHCPREQUEST draws a DHCPNAK instead of a DHCPACK; what happened, and what does the client do next?

level: seniorimportance: should knowfreq 22%

basics

~20 s

The server named in the Request could no longer grant the offered address — RFC 2131's example is that it was allocated meanwhile — so it sent a DHCPNAK. The client discards the offer and restarts with a new DHCPDISCOVER.

open as a page

When no DHCP server answers a client's DHCPDISCOVER, how does RFC 2131 say the client should time its retransmissions, and why randomise them?

level: middleimportance: nice to knowfreq 10%

basics

~20 s

Only the client retransmits, using a randomised exponential back-off. RFC 2131 suggests gaps of about 4 s, then 8 s, doubling to a 64 s cap, each ±1 s, so clients that start together do not retry in lockstep.

open as a page