skip to content

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%

answer

  1. the client owns retransmission
  2. randomised exponential back-off
  3. about 4 seconds, then doubling
  4. capped at 64 seconds
  5. a random wait before the first Discover

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.

solid answer

~40 s

DHCP servers never retransmit; the client must, using a randomised exponential back-off. RFC 2131 §4.1's example for a 10 Mb/s Ethernet is a first retransmission after 4 seconds randomised by ±1, then 8 ±1, doubling to at most 64 seconds. Ignoring the jitter, a silent network sees the `DHCPDISCOVER` again about 4, 12, 28 and 60 seconds after the first, and every 64 seconds after that. The randomisation, plus a recommended random wait of one to ten seconds before the very first Discover, stops a building full of machines that power up together from retrying in lockstep. The same algorithm covers an unanswered `DHCPREQUEST`: about four retransmissions, 60 seconds in all, before the client returns to INIT. What a host does when no offer ever comes is outside the four-message exchange.

go deeper

for a junior

Recall that a DHCP client retries on its own when nothing answers, and waits longer before each new try.

for a middle

Compute the schedule — gaps of about 4, 8, 16, 32 and then 64 seconds, each ±1 s — and explain the random one-to-ten-second wait before the first Discover.

for a senior

A client re-sending Discovers on this schedule has received no Offer it could use; check in a capture whether Offers left the server before blaming the client.

for a principal

Plan for recovery after a site-wide power cut: randomised back-off spreads the load, yet a large campus still brings most clients to the servers within minutes, so size them for that burst.

## Who retransmits DHCP runs over UDP, which re-sends nothing, and RFC 2131 puts the whole burden on one side: **DHCP clients are responsible for all message retransmission**. A server answers what it receives and never re-sends an Offer or an Ack on its own. The client MUST use a **randomised exponential back-off** to choose the delay between retransmissions, and the delay SHOULD leave enough time for replies to arrive given the network between client and server. ## The schedule RFC 2131 suggests RFC 2131 §4.1 gives an example for a 10 Mb/s Ethernet: the first retransmission after **4 seconds**, randomised by a uniform value between −1 and +1; the next after **8 seconds**, randomised the same way; then **doubling** on each retransmission up to a **maximum of 64 seconds**. These are SHOULD-level example values for that kind of network; the MUST is the randomised exponential back-off itself. | Retransmission | Nominal gap | Randomised gap | Time since first Discover (nominal) | |---|---|---|---| | 1st | 4 s | 3–5 s | 4 s | | 2nd | 8 s | 7–9 s | 12 s | | 3rd | 16 s | 15–17 s | 28 s | | 4th | 32 s | 31–33 s | 60 s | | 5th | 64 s (cap) | 63–65 s | 124 s | | 6th | 64 s | 63–65 s | 188 s | To compute when each retransmission happens: 1. Add the gaps, not the last gap: the 4th retransmission comes at 4 + 8 + 16 + 32 = **60 s**, not at 32 s. 2. From the 5th onward every gap is the 64-second cap, so the cumulative time grows by 64 s per retransmission: 124 s, 188 s, 252 s. 3. With the ±1 s jitter on every gap, the 4th retransmission can land anywhere from 56 s to 64 s after the first Discover. ## Why randomise - **Desynchronisation at startup.** RFC 2131 says a client SHOULD wait a random time between one and ten seconds before its first `DHCPDISCOVER`, so that machines powered on together — after a power cut, say — do not all broadcast in the same instant. - **Jitter on every retry.** The ±1 s randomisation keeps clients that did start together from retrying in lockstep. - **Backing off.** Doubling the gap means a struggling or absent server faces less and less traffic from each waiting client. Without any randomisation, a few hundred hosts restarted by the same power event would broadcast within the same second and then again at exactly 4, 12 and 28 seconds, each wave reaching the servers as one burst. With it, the waves smear out across a few seconds each, and every retry spreads them further. This randomisation is separate from the random "fuzz" RFC 2131 recommends around a bound client's renewal times; those belong to the lease lifecycle. ## Retransmitting the Request The same algorithm governs a `DHCPREQUEST` that draws neither a `DHCPACK` nor a `DHCPNAK`. RFC 2131's example: a client might retransmit the Request **four times, for a total delay of 60 seconds**, before going back to INIT and starting over with a new Discover, and it SHOULD tell the user that initialisation failed and is restarting. ## What changes between attempts - **`xid`:** keeping it or choosing a new one per retransmission is an implementation decision. Offers are matched against the most recent Discover, so a client that changes `xid` discards late answers to earlier attempts. - **`secs`:** it holds the seconds elapsed since the client began acquiring an address, so it grows with each retry; RFC 1542 says clients SHOULD NOT keep it constant. The Request must repeat the Discover's `secs`, which matters to relay agents. - **`flags`:** the BROADCAST flag stays as the client set it. ## What the schedule does not cover RFC 2131 sets no limit on how long a client keeps re-sending Discovers. What a host does when no offer ever arrives — for example falling back to an IPv4 link-local address under RFC 3927 — is the special-address subject, not the bind's. Nor does RFC 2131 say how long a client should keep collecting Offers once the first one has arrived: the collection period, and how the client then picks an offer, are implementation dependent.

  • Does a DHCPv4 client keep the same xid on each retransmission of its DHCPDISCOVER?
    RFC 2131 leaves it to the implementation: a client may reuse the `xid` or pick a new one per retransmission. Offers are matched against the most recent Discover, so a client that changes `xid` silently discards late Offers that answer an earlier attempt.
  • How does the secs field change across DHCPv4 retransmissions?
    `secs` holds the seconds since the client began acquiring an address, so it grows on each retry; RFC 1542 says clients SHOULD NOT keep it constant. The offer-accepting Request must repeat the Discover's `secs` value, which helps relay agents send it to the same servers.

saying these in an interview costs you the question

  • The DHCP server keeps re-sending its Offer until the client answers.
  • RFC 2131 fixes every retransmission gap at exactly four seconds.
  • Clients retry immediately and as fast as possible to bind sooner.
  • RFC 2131 requires a client to stop after four unanswered Discovers.