skip to content

DHCP

4 roadmaps37 questions

DORA hands a host with no address a lease, a gateway and DNS servers, and relays carry it across subnets. It opens every 'from boot to browsing' question and every rogue-server story.

on this pageshow

explore

questions

page 1 of 2

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

A laptop's DHCPv4 offer carries options 1, 3, 6, 15 and 51; what does each give it, and what breaks without 3 or 6?

level: juniorimportance: must knowfreq 55%

basics

~20 s

A DHCPv4 reply carries the address in yiaddr; option 1 is the subnet mask, 3 the routers, 6 the DNS servers, 15 the domain name, 51 the lease in seconds. Without 3 the host stays on its subnet; without 6 names fail.

open as a page

Why can a DHCPv4 client not reach a server on another subnet by itself, and what does a relay agent do about it?

level: juniorimportance: must knowfreq 42%

basics

~20 s

A DHCPv4 client with no address broadcasts to 255.255.255.255, which routers must not forward. A relay agent on the subnet's gateway catches that broadcast, writes its own interface address into giaddr and unicasts the message to the configured DHCP server.

open as a page

In DHCPv4, how does a printer reservation differ from a static address set on the printer, and which should be the source of truth?

level: juniorimportance: must knowfreq 48%

basics

~20 s

A reservation keeps the printer on DHCP: the server always gives its identifier the same address, with current options. A static address lives only on the printer, invisible to the server, so it must stay out of the pool.

open as a page

When a test DHCPv4 server is plugged into a production access switch, what do clients on that VLAN get, and why is it possible?

level: juniorimportance: must knowfreq 45%

basics

~20 s

Clients that accept the test server's offer take its address, default router and DNS servers, and keep renewing with it. DHCPv4 allows this because RFC 2131 gives a client no way to authenticate a server.

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

In DHCPv4, what happens at T1 and at T2, and why does renewing use unicast while rebinding broadcasts?

level: middleimportance: must knowfreq 40%

basics

~20 s

At T1, by default half the lease, a DHCPv4 client unicasts a DHCPREQUEST to the server that granted it; if no DHCPACK arrives by T2, by default 87.5%, it broadcasts the DHCPREQUEST so any server may extend it.

open as a page

A guest Wi-Fi DHCPv4 pool of 500 addresses runs dry by late morning with 24-hour leases; why, and how does a shorter lease fix it?

level: middleimportance: must knowfreq 34%

basics

~20 s

Guests leave without releasing their leases, so each address stays allocated for the visit plus the rest of the lease. With 24-hour leases nothing frees up during the day; a one-hour lease bounds each address to the visit plus an hour.

open as a page

How does DHCP snooping on an access switch stop a rogue DHCPv4 server, and which messages does it drop on untrusted ports?

level: middleimportance: must knowfreq 38%

basics

~10 s

DHCP snooping, a switch vendor feature with no RFC, drops server messages (DHCPOFFER, DHCPACK, DHCPNAK) arriving on untrusted access ports, so only ports marked trusted, toward the real server or relay, can answer clients.

open as a page

What is the difference between stateful and stateless DHCPv6, and which messages and options does each mode use?

level: middleimportance: must knowfreq 40%

basics

~20 s

Stateful DHCPv6 assigns addresses or prefixes through Solicit, Advertise, Request and Reply with IA_NA or IA_PD, and the server keeps a binding. Stateless DHCPv6 sends only Information-request and Reply for settings such as DNS, assigns no address and needs no binding.

open as a page

What is a DHCPv4 lease, and why does a DHCP server grant an address for a limited time rather than permanently?

level: juniorimportance: should knowfreq 45%

basics

~20 s

A DHCPv4 lease is the server's promise not to give an address to anyone else for a stated number of seconds. Leases expire because clients leave without telling the server, and expiry is how the server reclaims those addresses.

open as a page

In DHCPv6, which four messages does a client exchange with a server to obtain an address, and how does Rapid Commit shorten that to two?

level: juniorimportance: should knowfreq 35%

basics

~20 s

A DHCPv6 client multicasts Solicit to ff02::1:2, willing servers answer with Advertise, the client sends Request naming one server, and that server commits the lease in Reply. With Rapid Commit, a server answers the Solicit directly with a committed Reply.

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

A DHCPv4 laptop with default timers leased an address for 8 hours at 09:00, then slept 12:30 to 14:00; what does it do on waking?

level: middleimportance: should knowfreq 22%

basics

~10 s

The laptop's deadlines are T1 13:00, T2 16:00 and expiry 17:00, so at 14:00 it is past T1: it unicasts a renewing DHCPREQUEST to its server, and a DHCPACK restarts the lease from 14:00.

open as a page

For a DHCPv4 network-boot client, where can the boot server and boot file name travel, and what does option 52 overloading change?

level: middleimportance: should knowfreq 20%

basics

~20 s

DHCPv4 inherits BOOTP's siaddr (next server), sname (server name) and file (boot file) header fields; options 66 and 67 carry the same names when option 52 has turned sname or file into extra option space, read after the options field.

open as a page

How is the DHCPv4 options field encoded after the magic cookie, and how does a parser find option 53 inside it?

level: middleimportance: should knowfreq 30%

basics

~20 s

The DHCPv4 options field opens with the magic cookie 99.130.83.99, then holds code-length-value options until option 255 marks the end. Pad (0) and end (255) are a single octet; option 53 carries the message type, 1 DHCPDISCOVER to 8 DHCPINFORM.

open as a page

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%

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.

open as a page

When a DHCPv4 server answers a Discover from a scope with exclusions and reservations, how does it decide which address to offer?

level: middleimportance: should knowfreq 22%

basics

~20 s

RFC 2131 has the server prefer the client's current binding, then its previous address if free, then the address it requested, then a new pool address; exclusions never enter the pool and reservations go only to their own client.

open as a page

Why does a DHCPv6 server identify clients by DUID rather than MAC address, and why can a reinstalled machine get a new address?

level: middleimportance: should knowfreq 22%

basics

~20 s

DHCPv6 messages carry no hardware-address field; a client identifies itself with a DUID, a stable opaque identifier stored on the device. A reinstall usually wipes the stored DUID-LLT and generates a new one, so the server sees a new client.

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

A phone holding an unexpired DHCPv4 lease rejoins Wi-Fi after two days away; when does its INIT-REBOOT request get a DHCPACK, a DHCPNAK, or silence?

level: seniorimportance: should knowfreq 15%

basics

~20 s

A DHCPv4 client in INIT-REBOOT broadcasts a DHCPREQUEST naming its remembered address. A server ACKs if its record matches, NAKs if the address or subnet is wrong, and stays silent if it has no record of the client.

open as a page

After a DHCPv4 scope adds option 121 with a single route to 10.20.0.0/16, newer clients lose their default route while older ones keep it; why?

level: seniorimportance: should knowfreq 15%

basics

~20 s

RFC 3442 says a DHCPv4 client that supports option 121 must ignore option 3 when both arrive. Newer clients install only the one listed route and no default; older clients ignore 121 and keep option 3. Put 0.0.0.0/0 inside option 121 too.

open as a page

A campus adds a VLAN whose gateway relays DHCPv4 to the central server pair, but its clients get no address; what in the relay path explains it?

level: seniorimportance: should knowfreq 24%

basics

~20 s

Walk the relayed exchange leg by leg: relaying enabled on the new gateway, a pool on both servers for giaddr's subnet, a route and filter letting the servers reach giaddr on UDP 67, and no Option 82 policy refusing new circuits.

open as a page

A DHCPv4 relay agent forwards every client broadcast to two servers; what happens to the duplicate offers, and what must relay and servers do to make it work?

level: seniorimportance: should knowfreq 20%

basics

~20 s

Both servers offer and the relay delivers both; the client takes one and broadcasts a DHCPREQUEST naming it as server identifier. The relay must send that Request to both servers, which must never offer the same addresses.

open as a page

For an office's guest and desk DHCPv4 scopes, should server redundancy come from an 80/20 split scope or a failover pair, and what does each cost?

level: seniorimportance: should knowfreq 22%

basics

~20 s

A split scope gives two unsynchronised servers disjoint parts of one range; it suits long desk leases. A failover pair shares bindings so either can renew any client, which short guest leases need, but its protocol is an expired draft.

open as a page

How does a DHCP snooping switch build and remove its binding-table entries, and why does losing the table in a reboot cut hosts off?

level: seniorimportance: should knowfreq 18%

basics

~20 s

A snooping switch records MAC, IP, lease, VLAN and port from each DHCPACK it forwards to an untrusted port, and deletes the entry on a same-port release or decline, or at expiry. Without the table, hosts are dropped until they redo DHCP.

open as a page

In DHCPv4 pool starvation, why do DHCPDISCOVERs with forged client hardware addresses drain a server's pool, and which switch checks stop it?

level: seniorimportance: should knowfreq 24%

basics

~20 s

A DHCPv4 server identifies clients by option 61 or chaddr, so every forged value looks like a new client and takes an address. Per-port rate limits, a chaddr-to-source-MAC check and per-port binding limits stop one port claiming the pool.

open as a page

On a corporate IPv6 LAN, hosts get addresses from stateful DHCPv6 yet cannot reach anything off-link; what does DHCPv6 leave out, and where must hosts get it instead?

level: seniorimportance: should knowfreq 25%

basics

~20 s

DHCPv6 defines no default-router option and sends no prefix length: an assigned address is treated as a /128. Hosts learn their default router and on-link prefixes from Router Advertisements, so missing or zero-lifetime advertisements leave leased hosts stranded.

open as a page

A home gateway asks its ISP for a /56 with DHCPv6 prefix delegation; how does it obtain the prefix, and how does it use it on its LAN segments?

level: seniorimportance: should knowfreq 18%

basics

~20 s

The gateway solicits with an IA_PD option, often hinting /56, and the ISP's server delegates a prefix with lifetimes. The gateway splits it into 256 /64s, one per LAN, and announces them; the ISP edge must route the /56 to it.

open as a page

showing 1–30 of 37