Skip to content

DHCPOFFER

A Discover reaches every DHCP server on the segment, since it's broadcast — and every one of them is free to answer. DHCPOFFER is that answer: a server proposing a specific address and a specific set of configuration parameters, without committing anything yet. Nothing is reserved permanently at this point, and the client hasn't agreed to anything either; an Offer is a proposal, not a lease.

What the server fills in

An Offer is a BOOTREPLY, and most of what makes it distinct from the Discover that triggered it comes down to which of the shared header fields the server gets to set that the client couldn't:

  • op is 2.
  • xid is copied straight from the Discover — this is the field that ties an Offer back to a specific attempt, especially useful once retries are in play and more than one Discover with different xid values might be outstanding.
  • yiaddr, "your IP address," carries the address being proposed. This is the field actually worth pausing on: it's the server proposing an address to the client, not the server's own address, and it's easy to misread on a first pass through a packet capture as the sender's address rather than the offer itself.
  • siaddr is filled in only if this server (or another one named here) also serves as a boot server for this client — not something an ordinary laptop or phone lease touches.
  • chaddr still carries the client's MAC address, copied from the Discover, so the client can match this specific reply against its own hardware address if more than one device somehow shares a segment with colliding transaction IDs.

The options that make the address usable

An address by itself gets a client nowhere. The options attached to the Offer are what turn "here's an IP" into "here's a fully usable network configuration":

sudo tcpdump -i eth0 -n -v port 67 or port 68

12:00:01.104881 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0x3d1e2f8a, Flags [none]
      Your-IP 192.168.1.42
      Client-Ethernet-Address 08:00:27:4e:66:a1
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Offer
        Server-ID Option 54, length 4: 192.168.1.1
        Lease-Time Option 51, length 4: 86400
        Subnet-Mask Option 1, length 4: 255.255.255.0
        Default-Gateway Option 3, length 4: 192.168.1.1
        Domain-Name-Server Option 6, length 8: 192.168.1.1,8.8.8.8

Server-ID (option 54) is worth flagging specifically, because it becomes important two articles from now: it's how the client knows which server to address its Request to, when more than one server made an offer. Lease-Time (option 51) here is 86400 seconds — 24 hours — matching exactly the lease duration the ipconfig article's own capture showed as a full day between Lease Obtained and Lease Expires.

A server can also include options 58 and 59, explicit overrides for the T1 and T2 renewal timers — but most server configurations leave them out entirely, in which case the client falls back to computing them itself as 50% and 87.5% of the lease, exactly as the DHCP article's renewal section already described.

Picking one offer among several

Nothing in RFC 2131 mandates how a client chooses between multiple Offers if more than one server answers — that decision is left entirely to the client's own implementation. In practice, most DHCP clients simply take the first Offer to arrive and ignore the rest, rather than waiting out some collection window and comparing terms. The servers that weren't chosen never get told directly; they simply never see a Request naming their Server-ID, and eventually let their tentatively-held address go, either on their own timeout or when it's needed for another client.

When a second, unwanted server answers

A shared office network has one authorized DHCP server, run by IT. One afternoon, a new employee plugs their personal travel router into an open wall jack, not realizing it has its own DHCP server enabled out of the box for home use. From that point on, roughly half the devices reconnecting to the network get an address that doesn't work — wrong subnet, wrong gateway, nothing reachable beyond the local segment.

Capturing Discover and Offer traffic on the affected segment shows the problem directly:

12:04:02.001 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from a4:5e:60:11:9c:02, length 300, xid 0x7712aa03
12:04:02.006 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0x7712aa03
12:04:02.011 IP 192.168.50.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0x7712aa03

Two servers, 192.168.1.1 (the legitimate one) and 192.168.50.1 (the travel router), both answered the same Discover, identified by the shared xid. Whichever one's packet the client's network stack happens to process first wins — a race with no predictable outcome, which is exactly why some devices end up fine and others end up on the wrong network entirely. This is a rogue DHCP server, and it's a genuinely disruptive class of problem precisely because DHCP has no built-in way for a client to tell an authorized server from an unauthorized one; anything answering on port 67 looks equally legitimate to a client that's never seen either one before.

This isn't fixable from the client side

Telling individual devices to ignore the rogue server isn't a real fix — the race is decided per-request, and there's no client-side setting for "only trust this DHCP server." The actual fix is on the network: identifying and unplugging the offending device, and longer-term, enabling DHCP snooping on managed switches, a feature that only allows DHCP server traffic (Reply packets from port 67) on switch ports explicitly designated as trusted, dropping it everywhere else before it ever reaches other clients.

Practice exercises

  1. Explain why Server-ID in the Offer matters more once a second server is involved than it would on a network with exactly one DHCP server.
  2. Two Offers arrive for the same Discover with lease times of 3600 seconds and 86400 seconds. Nothing in the protocol favors the longer lease — what would you actually want to know about each server before assuming the longer one is the better choice?
  3. A colleague suggests fixing a rogue-DHCP-server incident by configuring the legitimate server with a shorter retry interval so it "wins the race more often." Explain why this doesn't address the actual problem.

An Offer is still just an offer. The next article covers what makes it real: the Request the client sends back, and why that Request looks different depending on whether the client is accepting a brand-new offer or renewing a lease it already holds.

Sources