In DHCPv4 pool starvation, why do DHCPDISCOVERs with forged client hardware addresses drain a server's pool, and which switch checks stop it?
answer
- what the server counts as a client
- option 61, else chaddr
- one source MAC, many chaddr values
- rate and binding limits per port
- an empty pool helps a rogue
basics
~20 sA 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.
solid answer
~50 sRFC 2131 makes a server identify a client by its client identifier (option 61) if present, otherwise by `chaddr`. Both are bytes the sender writes, and behind a relay agent the server never sees the Ethernet frame, so each new value is a new client to it. A flood of `DHCPDISCOVER`s with distinct `chaddr` values draws one offer each; offered addresses may be held for an implementation-specific time, and exchanges completed with `DHCPREQUEST` hold addresses for the full lease. When the pool is empty, legitimate clients get no offer — and a rogue server's offer becomes the only one. A per-port MAC limit misses floods that forge only `chaddr`; snooping's `chaddr`-equals-source-MAC check catches those but not a varying option 61, so per-port DHCP rate limits and per-port binding limits close the rest. Option 82 lets a server cap leases per port too.
go deeper
Recall that starvation fills a DHCP pool with fake clients so real hosts get no address, and that it often comes before a rogue server.
Explain why option 61 or chaddr defines a client for the server, and how offers and committed leases each tie up addresses.
Walk through which control catches which variant — MAC limits, the chaddr check, rate limits, binding limits, Option 82 caps — and how you would spot it in lease records.
Balance strict per-port limits against ports that legitimately carry many addresses, and decide which layer owns the cap: switch, server or both.
## What a DHCPv4 server counts as a client RFC 2131 section 4.2 says a server "needs to use some unique identifier to associate a client with its lease". If the client sends option 61, the **client identifier**, the server MUST use it; otherwise it MUST use the `chaddr` field, the client hardware address. Both are bytes inside the DHCP message, written by the sender. Nothing ties them to a physical host, and when a relay agent forwards the request the server never sees the client's Ethernet frame at all. So a new value in either field is, as far as the server can tell, a new client entitled to its own address. ## How a flood becomes an empty pool Seen from the defender's side, starvation unfolds like this: 1. One attachment point emits `DHCPDISCOVER` messages at a high rate, each with a different `chaddr` or client identifier. 2. Each looks like a new client, so the server offers each a fresh address. RFC 2131 lets a server mark offered addresses unavailable and says it SHOULD NOT reuse one before the client responds, releasing it after an implementation-specific timeout — so even unanswered offers tie up addresses for a while. 3. Exchanges completed with a `DHCPREQUEST` commit real leases, which last the full lease time from option 51. 4. Once every address is bound or held, the server has nothing to offer; RFC 2131 says only that it "may choose to report the problem". Legitimate new clients get no offer and, after retransmitting, typically fall back to a 169.254 link-local address. RFC 2131 section 7 anticipated this: "a malicious client could claim all resources for itself, thereby denying resources to legitimate clients". RFC 3046 names the same "IP exhaustion attack" by "fabricated client MAC addresses" among the problems its relay agent information option helps address. ## Why starvation travels with a rogue server An empty pool is a denial of service on its own, but it also removes the competition. A rogue server's offer normally races the legitimate one; once the legitimate server has nothing left, the rogue's offer is the only one clients receive. Treat a pool-exhaustion alarm and a report of a strange gateway on the same VLAN as one incident. ## Controls and what each misses | Control | What it checks | What it misses | Whose rule | |---|---|---|---| | Per-port source-MAC limit (often called port security) | Number of source MACs seen on a port | Floods that forge only `chaddr` inside frames from one source MAC | Switch feature, no RFC | | `chaddr` check in DHCP snooping | `chaddr` equals the frame's source MAC | Floods that keep `chaddr` fixed and vary option 61 | Vendor feature, no RFC | | Per-port DHCP rate limit | DHCP packets per second on an untrusted port | A slow flood under the ceiling, helped by long leases | Vendor feature, no RFC | | Per-port binding limit | Number of bindings one port may hold | Discover-only floods, which create no binding yet still tie up offered addresses | SAVI-DHCP's binding entry limit (RFC 7513 section 11.5); vendor equivalents | | Per-circuit lease limit at the server | Leases per Option 82 circuit ID | Requests that arrive without Option 82 | Server policy built on RFC 3046 | No single row is enough. The `chaddr` check and the rate limit together cover the cheap cases; the binding limit and a per-circuit cap on the server bound what one port can ever hold. Set limits with care: a binding limit of one breaks a port that legitimately feeds a small unmanaged switch or a host running virtual machines. ## Detecting it - Pool utilisation climbing toward 100% with no matching growth in real hosts. - Many new leases whose `chaddr` values carry no plausible manufacturer prefix, or whose client identifiers differ while `chaddr` repeats. - Rate-limit or `chaddr`-mismatch drop counters rising on one access port. - Option 82 circuit IDs in the server's lease records all pointing at one port. Shorter leases make recovery faster once the source is blocked, at the cost of more renewal traffic; they do not prevent the attack.
- Why doesn't port authentication with IEEE 802.1X, on its own, stop DHCP starvation?Port authentication decides who may join; once admitted, a host can still put any `chaddr` or client identifier into its DHCP messages. RFC 9915's security considerations make the same point for DHCPv6: authentication "does not necessarily assure that the connected client will be a good DHCP or network actor". Per-port rate and binding limits are still needed.
- Does the same pool-exhaustion attack work against DHCPv6?A DHCPv6 server identifies clients by the DUID in the Client Identifier option, so forged DUIDs look like new clients, and there is no `chaddr` to compare with the frame. Exhausting addresses in a /64 is impractical, but smaller delegated-prefix pools are a realistic target. RFC 7610's DHCPv6-Shield explicitly does not mitigate attacks against servers; rate limits and RFC 7513 binding limits do.
saying these in an interview costs you the question
- Limiting each port to one MAC address fully prevents DHCP starvation.
- A Discover flood holds no addresses, because servers never set aside offered addresses.
- Starvation needs one physical host for every address it consumes.
- Pool exhaustion is only an outage; it gives an attacker nothing else.
- DHCPv6-Shield also protects a DHCPv6 server from exhaustion floods.