skip to content

When a DHCPv4 server answers a relayed request, how does its reply get back to a client that has no address yet?

level: middleimportance: should knowfreq 28%

answer

  1. the server talks to the relay
  2. giaddr, UDP port 67
  3. the BROADCAST flag shapes the last hop
  4. chaddr instead of ARP
  5. a DHCPNAK is always broadcast

basics

~20 s

A DHCPv4 server unicasts its reply to the relay agent at giaddr on UDP port 67. The relay delivers it on port 68, broadcast if the client set the BROADCAST flag, else unicast to yiaddr at the chaddr hardware address.

solid answer

~50 s

Because `giaddr` is non-zero, RFC 2131 has the server send every `DHCPOFFER` and `DHCPACK` to the relay agent at the `giaddr` address, on the server port 67, never straight to the client. The relay uses `giaddr` to find its interface on the client's subnet (and silently drops a reply whose `giaddr` is not one of its own interfaces), then reads `chaddr`, `yiaddr` and the `BROADCAST` flag. If the client set the flag, the relay sends to `255.255.255.255` and the link-layer broadcast address; if not, it unicasts to `yiaddr` with `chaddr` as the destination MAC, with no ARP, since a client that has not configured the address may not answer ARP for it. The UDP destination is port 68, and the relay changes no DHCP field. A `DHCPNAK` comes back with the flag set, so the relay broadcasts it.

go deeper

for a junior

Remember the two legs: server to relay at giaddr on UDP port 67, then relay to client on UDP port 68.

for a middle

Walk through the relay's delivery choice: a set BROADCAST flag means a limited broadcast, a clear one a unicast to yiaddr at the chaddr MAC with no ARP; then say why a DHCPNAK is broadcast.

for a senior

Use it to diagnose: offers logged at the server but nothing on the client's segment points at the server-to-giaddr leg, meaning routing, filtering of UDP 67, or a relay discarding a giaddr it does not own.

for a principal

Discuss when giaddr's double job breaks, such as unreachable or unnumbered client-side links, and how link selection splits pool choice from the return path at the price of every server supporting it.

## Why the reply cannot go straight to the client During the initial exchange a DHCPv4 client has no usable IPv4 address. The server is on another subnet, so even a server that knew the offered address (`yiaddr`) could not simply route a packet to it: the packet would reach the client's gateway, which would try to resolve `yiaddr` with ARP, and a client that has not yet configured that address may not answer ARP for it. The relay agent avoids this because it sits on the client's segment and can address the frame to `chaddr` directly. RFC 2131 §4.1 describes a second trap, a deadlock: some client stacks cannot receive unicast IP at all until configured, which the `BROADCAST` flag resolves. ## Leg one: from the server to the relay RFC 2131 §4.1 gives the server a fixed decision order for `DHCPOFFER` and `DHCPACK`: | `giaddr` | `ciaddr` | `BROADCAST` flag | Server sends to | |---|---|---|---| | non-zero | any | any | the relay at `giaddr`, UDP port 67 | | zero | non-zero | any | `ciaddr`, UDP port 68 | | zero | zero | set | `255.255.255.255`, UDP port 68 | | zero | zero | clear | `yiaddr` at the `chaddr` hardware address, UDP port 68 | The first row is the relayed case. The destination port is 67, the **server** port, because the relay agent listens there; port 68 is only ever the client's. The server also has to choose its **server identifier** (option 54), the address the client will later unicast to. RFC 2131 requires an address the client can reach and says that for relayed traffic the server SHOULD pick one from the interface the request arrived on. ## Leg two: from the relay to the client RFC 1542 §4.1.2 describes what the relay does with a reply (a `BOOTREPLY`): 1. **Match `giaddr` to one of its own interfaces.** That tells it which segment the client is on. If `giaddr` is not one of its directly connected interfaces, the reply MUST be silently discarded. 2. **Read the client's link-layer details** from `htype`, `hlen` and `chaddr`, and the assigned address from `yiaddr`. 3. **Apply the `BROADCAST` flag.** Set: send to IP `255.255.255.255` and the link-layer broadcast address. Clear: send an IP unicast to `yiaddr` with `chaddr` as the link-layer destination. If unicasting is not possible, the relay MAY broadcast instead. 4. **Send to UDP port 68**, recomputing the UDP checksum if one is present. 5. **Change no DHCP field.** RFC 1542 forbids modifying any field of the reply. The one thing a relay removes is an echoed Option 82, which it added itself on the way in. ## Why the BROADCAST flag exists Some client stacks cannot receive a unicast IP datagram until an address is configured. RFC 2131 §4.1 says such a client SHOULD set the `BROADCAST` flag in its `DHCPDISCOVER` and `DHCPREQUEST`, and a client that can receive unicast SHOULD leave it clear. The server copies the flag into its reply, and the relay honours it on the last hop. A refusal is a special case. RFC 2131 §4.3.2 says that when a `DHCPNAK` goes through a relay, the server MUST set the `BROADCAST` flag, so the relay broadcasts it. The reason: a client being refused may hold a wrong address or mask and may not answer ARP, so a unicast might never arrive. ## When giaddr cannot also be the return address `giaddr` does two jobs: it names the client's subnet for pool selection and it is the address the server replies to. Usually that is the same address. RFC 3527 describes cases where it cannot be: - a filter on the relay device does not let the server reach the client-facing address; - the client-facing link has no address of its own, for example a point-to-point link with a single host. The **link-selection sub-option** (sub-option 5 of Option 82) splits the jobs. The relay puts a reachable address in `giaddr` and the client's subnet in the sub-option; a server that supports it MUST allocate on that subnet or another subnet on the same link, and sends the reply to the same place it otherwise would. RFC 3011's subnet selection option (code 118) is the client-side counterpart; if both appear, link selection wins. ## What breaks on the reply path - **No route from the server to `giaddr`.** Requests arrive and offers are sent, but they never reach the relay. - **A filter that admits relayed requests but not replies** from the server to UDP port 67 on the relay's address. - **A client that sets `chaddr` to all zeros** and relies on its client identifier. RFC 2131 told servers not to return that option, so a relay could drop such replies; RFC 6842 updates RFC 2131 so a server MUST return the client identifier when the client sent one. - **A client that cannot receive unicast before configuration but leaves the flag clear.** The relay unicasts, and the client never sees the offer.

  • When can giaddr not serve as the DHCPv4 server's return address, and what does the link-selection sub-option change?
    When the server cannot reach the client-facing address, because a filter blocks it or the client link has no address of its own. The relay then puts a reachable address in `giaddr` and adds the RFC 3527 link-selection sub-option (sub-option 5 of Option 82) carrying the client's subnet. A server that supports it MUST allocate on that subnet or its link, and still replies to `giaddr`.
  • Why does a DHCPv4 server pick its server identifier from the interface the relayed request arrived on?
    The client later unicasts renewals to the server-identifier address, so RFC 2131 requires an address the client can reach. For relayed traffic it says the server SHOULD use an address from the interface on which the request arrived, unless it has better information. An address on an isolated management interface would leave clients unable to renew.
  • Why did RFC 6842 change what a DHCPv4 server puts in its replies, and why do relays care?
    RFC 2131 told servers not to return the `client identifier` option, to save space. A client with an all-zero `chaddr`, which some mobile devices send, then got replies with nothing to identify it, and a relay could drop them. RFC 6842 updates RFC 2131: when the client sent a client identifier, the server MUST return it, as DHCPv6 already did.

saying these in an interview costs you the question

  • The server sends the DHCPOFFER straight to the client's new address.
  • The server replies to the relay agent on UDP port 68, the client port.
  • The relay ARPs for yiaddr before it unicasts the offer.
  • The relay agent rewrites yiaddr or other fields before delivering the reply.
  • A set BROADCAST flag makes the server broadcast its reply across the campus.