skip to content

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%

answer

  1. returning clients first
  2. current binding, then previous binding
  3. the Requested IP Address option
  4. offered addresses are held briefly
  5. reuse expired, least recently assigned

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.

solid answer

~50 s

RFC 2131 section 4.3.1 gives the order: the client's **current binding**; else its **previous address** from an expired or released binding, if still free; else the address in the `Requested IP Address` option, if valid and unallocated; else a **new address** from the pool for the client's subnet. Exclusions and reservations are the server's way of shaping that pool: an excluded address is never offered, and a reserved address goes only to its own client. Because servers keep the records of expired and released bindings, a returning laptop usually gets the same address back. The server should not hand an offered address to anyone else until the client answers, and should free it if no `DHCPREQUEST` comes. When no never-used address is left, it reuses expired ones, the least recently assigned being the RFC's example, probing each first.

go deeper

for a junior

Recall that a returning device usually gets its old address back, and that excluded and reserved addresses are not handed to strangers.

for a middle

Walk through RFC 2131's four-step preference and explain how offered, declined and reserved addresses leave the eligible set.

for a senior

Explain the tension between remembering expired bindings and running a tight pool, and why reuse probes are a safety net rather than a design.

for a principal

Weigh address stability for logging and access control against pool headroom when you set pool sizes, lease lengths and retention of old bindings.

## The question the server answers When a **DHCPDISCOVER** arrives, the server has to pick one address to put in the **DHCPOFFER**. That choice is the heart of the server's **pool model**: what it is allowed to give out, and what it prefers to give out. RFC 2131 describes the preference; the *scope*, *exclusion* and *reservation* settings that shape the pool are each server's own vocabulary. ## What is eligible at all Start with the pool for the client's subnet. The server picks that subnet from the interface the message arrived on, or from the relay agent's address when a relay forwarded it. Then remove: - **Excluded addresses**: the gateway, static servers and anything else configured on hosts by hand. - **Reservations for other clients**: an address bound to one identifier by the administrator (RFC 2131's *manual allocation*) is never offered to anyone else. - **Addresses already leased** to another client. - **Addresses just offered** to another client. RFC 2131 says the server SHOULD NOT reuse an offered address before that client responds, and SHOULD mark it available again if no `DHCPREQUEST` arrives. - **Addresses marked unavailable** after a client sent `DHCPDECLINE`, reporting that it found the address in use. ## The order of preference RFC 2131 section 4.3.1 says the new address SHOULD be chosen as follows: 1. **The client's current address**, from its current binding. 2. **The client's previous address**, from an expired or released binding, *if* that address is still in the pool and not allocated. 3. **The address in the `Requested IP Address` option** (option 50), *if* it is valid and not allocated. 4. **A new address** from the pool for the client's subnet. The server identifies "the client" by its `client identifier` option if present, otherwise by `chaddr`. A reservation overrides the list: RFC 2131 lets a server, for administrative reasons, assign an address other than the one requested, so a reserved client gets its reserved address. | Situation | What the server offers | |---|---| | Laptop with a live lease reboots | Its current address | | Laptop back from a week away, old address free | Its previous address | | New phone asks for 10.20.1.15, which is free | 10.20.1.15 | | New phone asks for the excluded 10.20.0.10 | A new address from the pool | | Badge reader with a reservation | Its reserved address | ## Why returning clients keep their address Section 2.2 says the allocation mechanism "attempts to return the same network address each time the client requests an address", and section 4.3.4 says that after a `DHCPRELEASE` the server SHOULD retain the client's record for reuse. A server that remembers expired bindings can give a returning client the same address weeks later, which is what makes logs and access lists easier to read. ## When the pool is tight Remembering old bindings competes with handing out new ones. When no never-used address is left, section 2.2 says the server reuses addresses whose lease has expired, choosing with whatever information it has; **the least recently assigned address** is the RFC's example. Before reusing one, the server SHOULD probe it, an ICMP echo request being the example, and the client SHOULD check it again with ARP. If nothing at all is free, the server sends no offer; the RFC only says it may report the problem to the administrator. ## Exclusions or a narrower range? An **exclusion** and a **narrower range** both keep an address out of the pool; the choice is about readability and change. - **A range that starts above the fixed block** (servers and printers at the bottom, the pool above them) needs no exclusions at all and is the easiest plan to read. - **Exclusions** suit the stragglers: a device someone gave a static address in the middle of the range that cannot be moved yet. - **Either way the server only knows what it is told.** An address configured on a host but neither excluded nor outside the range is, to the server, free. ## The lease time comes from the scope The same section sets the lease length. If the client asked for none, the server returns the remaining time of an existing binding, or else a **locally configured default**, which is where a per-scope lease duration lives. If the client asked for one in option 51, the server may grant it or choose another.

  • A client asks for an address in the Requested IP Address option that its own expired binding does not hold. Which wins?
    The previous binding. RFC 2131 puts the client's previous address, if still free, ahead of the address the client requests; the requested address is only the third choice, and only when it is valid and unallocated. Either way the server may assign something else for administrative reasons, such as a reservation.
  • Why does keeping expired bindings help operations, and when does it stop being possible?
    A returning device gets the same address, so logs, firewall entries and monitoring stay readable across days. It stops when the pool is tight: once no never-used address remains, the server must reuse expired addresses, and the old client's address goes to someone else.

saying these in an interview costs you the question

  • The server always offers the lowest free address in the pool.
  • The Requested IP Address option overrides everything, including the client's previous binding.
  • An offered address is committed as a lease the moment the Offer is sent.
  • Excluded addresses can still be offered when the pool runs dry.
  • A server forgets a client completely once its lease expires or is released.