skip to content

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%

answer

  1. chicken and egg before configuration
  2. a flag the client sets
  3. packet to yiaddr, frame to chaddr
  4. a random 32-bit number
  5. NAKs are always broadcast locally

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.

solid answer

~50 s

With `giaddr` and `ciaddr` both zero, RFC 2131 gives the server two ways to reach an unconfigured client. If the client set the BROADCAST bit in `flags`, the `DHCPOFFER` or `DHCPACK` goes to `255.255.255.255` and the link-layer broadcast address. If the bit is clear, it goes as IP unicast to `yiaddr` with the frame addressed to `chaddr` — the server cannot ARP for `yiaddr`, because nobody owns it yet. A client that cannot accept unicast before it has an address sets the bit; one that can should clear it. A `DHCPNAK` on the local subnet is always broadcast. The client matches replies by `xid`, a random 32-bit value it chose: an Offer whose `xid` differs from its latest `DHCPDISCOVER` is silently discarded, and the Request reuses the chosen Offer's `xid` so the Ack can be matched too.

go deeper

for a junior

Recall that a client without an address can still receive replies, that it picks a random transaction ID, and that DHCP replies go to UDP port 68.

for a middle

Walk through the server's delivery choice: broadcast if the client set the BROADCAST flag, otherwise unicast to yiaddr with the frame sent to chaddr, and NAKs always broadcast.

for a senior

When clients keep re-sending Discovers without binding, use a capture to check whether Offers left the server, how they were addressed and whether their xid matched.

for a principal

Weigh the cost of clients that demand broadcast replies: every Offer and Ack then floods the VLAN, which adds up on large or dense wireless segments.

## The chicken-and-egg problem A DHCPv4 client in the middle of its first bind has no IP address. Yet the server must deliver a `DHCPOFFER` and later a `DHCPACK` to it, and the client must be sure that what arrives answers its own `DHCPDISCOVER` and not a neighbour's. RFC 2131 handles the first half with addressing rules and the **BROADCAST flag**, and the second half with the **transaction ID**, `xid`. RFC 2131 itself calls the delivery problem a potential deadlock: some client implementations cannot receive a unicast IP datagram until they are configured, so an address could not be delivered until the client already had one. ## How the server addresses its reply For a client on the server's own subnet (`giaddr` is zero), RFC 2131 gives these rules: | Condition in the client's message | Where the `DHCPOFFER` / `DHCPACK` goes | |---|---| | `ciaddr` non-zero | unicast to `ciaddr` (a client that already has an address — not the case during a first bind) | | `ciaddr` zero, BROADCAST bit set | IP broadcast `255.255.255.255`, link-layer broadcast | | `ciaddr` zero, BROADCAST bit clear | IP unicast to `yiaddr`, frame sent to `chaddr` | | any `DHCPNAK` | always IP broadcast `255.255.255.255` | The third row is the subtle one. The server cannot resolve `yiaddr` with ARP, because nobody owns that address yet and the client will not answer for it. So the server builds the frame itself, putting the client's hardware address from `chaddr` in the link-layer destination. If unicasting that way is not possible on the server's platform, the server MAY fall back to a broadcast. When `giaddr` is non-zero, the reply goes to the relay agent instead — the relay's subject. All replies go to UDP port **68**. RFC 951 explains why the client port is reserved rather than random: a reply may be broadcast, and a broadcast to a random port could land on some unrelated listener on another host. ## The BROADCAST flag - It is the **leftmost bit of the 16-bit `flags` field**; the other 15 bits MUST be zero. - The **client** sets it. RFC 2131: a client that cannot receive unicast IP datagrams until its protocol software is configured SHOULD set it in every `DHCPDISCOVER` and `DHCPREQUEST`; a client that can receive them SHOULD clear it. - The **server** copies the client's `flags` into its reply and uses the bit to choose broadcast or unicast. A relay agent delivering to the client looks at the same bit. - RFC 1542 introduced the flag as a workaround for old implementations and hoped clients would be fixed so it was not needed; where clients still set it, every Offer and Ack floods the whole VLAN. ## Matching replies with xid 1. In INIT the client generates a **random 32-bit `xid`** and puts it in the `DHCPDISCOVER`. 2. Each server copies that `xid` into its `DHCPOFFER`. An Offer whose `xid` does not match the **most recent** Discover must be silently discarded, and any `DHCPACK` arriving while the client is still selecting is discarded too. 3. The `DHCPREQUEST` carries the **same `xid` as the chosen Offer**. 4. The server copies the Request's `xid` into its `DHCPACK` or `DHCPNAK`, so the client can match the outcome. Whether a client keeps the same `xid` on a retransmission or picks a new one is an implementation decision; a client that changes it will discard late Offers to its earlier attempts. `xid` is a matching aid, not a guarantee. RFC 6842 points out that `xid` values generated by different clients on one subnet need not be unique, so the client hardware address in `chaddr`, or the client identifier that RFC 6842 now requires servers to echo when the client sent one, is what ties a reply to one particular client. Nor is `xid` a defence: the Discover is broadcast, so any host on the link sees it. Protecting clients against forged replies is a rogue-server defence, not part of the bind. ## What this looks like when it breaks - A client that needs broadcast replies but clears the flag may never see its Offers and keeps re-sending Discovers on its back-off schedule. - A capture showing Offers addressed to `yiaddr` that never get a Request back often means the client could not receive them. - Offers carrying an `xid` the client did not send are for another client and are ignored, however good the address.

  • Why is a DHCPv4 DHCPNAK on the local subnet broadcast even when the client left the BROADCAST flag clear?
    RFC 2131 says that whenever `giaddr` is zero the server broadcasts any `DHCPNAK` to `255.255.255.255`, because the client may not have a correct address or mask and may not be answering ARP. A NAK also carries `yiaddr` zero, so there is no address to unicast to.
  • Does the DHCPv4 xid protect a client against forged replies?
    No. RFC 2131 asks clients to choose `xid` values that rarely collide, which serves matching, not authentication; the Discover is broadcast, so every host on the link sees its `xid`. Defending clients against replies from an unauthorised server is the job of rogue-server defences at the switch, not of the bind itself.

saying these in an interview costs you the question

  • The server ARPs for the offered address to deliver the DHCPOFFER.
  • The server sets the BROADCAST flag whenever it decides to broadcast.
  • Every DHCP reply is broadcast because the client has no address yet.
  • The client accepts the first DHCPOFFER that arrives, whatever its xid.
  • The xid authenticates the server's reply against forgery.