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?
answer
- the address is not an option
- mask, gateway, resolvers, domain, lease
- no router: only the local subnet
- no resolver: addresses work, names fail
basics
~20 sA 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.
solid answer
~50 sThe offered address itself is not an option: it travels in the fixed-header field `yiaddr`. The options carry the rest of the configuration (RFC 2132). Option 1 is the subnet mask, so the host knows which destinations are on its own link. Option 3 is a list of routers in order of preference, and the client takes its default gateway from it. Option 6 lists DNS server addresses, option 15 is the domain name the host uses when resolving names, and option 51 is the lease duration as a 32-bit count of seconds, with `0xffffffff` meaning infinite. If option 3 is missing, the host still reaches everything inside its subnet but has no next hop for anything else. If option 6 is missing, connections to IP addresses work while every name lookup fails, which users report as "the internet is down".
go deeper
Recall the five codes and their meanings: 1 mask, 3 gateway, 6 DNS servers, 15 domain, 51 lease seconds. Then say the address itself lives in yiaddr, not in an option.
Explain the encoding details: lists in options 3 and 6 are multiples of four octets in preference order, the lease is a duration in seconds, and the server returns what the parameter request list asks for.
Diagnose from symptoms: local-only reachability points at option 3, names failing while addresses work points at option 6, and different gateways per host point at two servers handing out different parameters.
Discuss what the options should point at: a virtual gateway address rather than one router, resolvers ordered by health, and lease lengths chosen against pool size and how often hosts come and go.
## The address is not an option A DHCPv4 message is a BOOTP-shaped fixed header followed by a variable **options** field (RFC 2131 §2). The address the server is offering sits in the header field `yiaddr` ("your IP address"). Everything else a host needs to actually use that address arrives as **options**, each identified by a one-octet code defined in RFC 2132. Reading a capture therefore means two things: find `yiaddr` in the header, then walk the options. ## The five options a typical office scope hands out Take an offer for a laptop on `192.168.10.0/24` with the domain `office.example.com`: | Code | Name (RFC 2132) | Example value | What the host does with it | |---|---|---|---| | 1 | Subnet Mask | `255.255.255.0` | Decides which destinations are on-link | | 3 | Router | `192.168.10.1` | Installs it as the default gateway | | 6 | Domain Name Server | `192.168.10.2`, `192.168.10.3` | Sends DNS queries to these, in order | | 15 | Domain Name | `office.example.com` | Uses it as the domain when resolving host names | | 51 | IP Address Lease Time | `3600` | Holds the address for one hour from assignment | A few encoding details matter when you read real traffic: - **Option 1** is exactly 4 octets. RFC 2132 §3.3 says that if a reply carries both the subnet mask and the router option, **the subnet mask MUST come first**. - **Option 3** and **option 6** are lists: the length must be a multiple of 4, and the RFC says the addresses SHOULD be listed in order of preference. - **Option 15** is a text string with no trailing null required. - **Option 51** is a 32-bit unsigned number of **seconds**, a duration rather than a wall-clock time, because client and server clocks are not assumed to agree. RFC 2131 §3.3 reserves `0xffffffff` for an infinite lease. ## What breaks when an option is missing The failure modes are distinctive enough to diagnose from a symptom: 1. **No option 1.** The host has no stated mask and falls back on whatever its implementation assumes, which is implementation behaviour rather than a protocol rule. A wrong assumption either treats remote hosts as local (it ARPs for them and gets nothing) or treats neighbours as remote (it sends them to the gateway). 2. **No option 3.** The host can talk to every machine on its own subnet, including the printer and the DHCP server, but has **no next hop** for anything off-link. Pinging the gateway's address may even work if it is on-link; reaching anything beyond it does not. 3. **No option 6.** Connections to literal IP addresses succeed, yet every name lookup fails because the host has nowhere to send DNS queries. Users describe this as "no internet", which is why checking the resolver list is an early step in triage. 4. **No option 15.** Fully qualified names still resolve; only short, unqualified names that relied on the domain stop working. 5. **No option 51.** RFC 2131 §4.3.1 makes the lease time a MUST in a DHCPOFFER and in a DHCPACK answering a DHCPREQUEST, so a reply without it is not a valid offer. ## Who decides what is in the offer The server builds the options from its configuration for the client's subnet. A client may send a **parameter request list** (option 55) naming the codes it wants; RFC 2131 §4.3.1 says the server returns each requested parameter it has a configured value for, falls back to the Host Requirements default where one exists, and otherwise omits it. RFC 2131 also asks that **every server on a subnet return the same parameters**, so a client gets the same gateway and resolvers whichever server answers first. When two servers disagree, hosts end up with different gateways depending on who replied, which is a configuration fault and not a protocol feature. Two values here commonly point at something other than a single box: - The **router option** often carries the virtual address of a redundant gateway pair. The host neither knows nor cares which physical router currently owns that address; the redundancy protocol decides that. - The **DNS server option** may list a pair of resolvers. RFC 2132 says servers SHOULD be listed in order of preference, so the healthiest resolver belongs first; how a client fails over between them is up to its implementation. ## Reading it in an interview A strong answer separates the header from the options, names each code with its meaning and unit, and links each missing option to a symptom a user would actually report. That last step is what turns a list of numbers into troubleshooting knowledge.
- Why might option 3 carry an address that no single router owns?On a subnet with two gateways, the DHCPv4 router option usually holds the virtual address of a first-hop redundancy group. Hosts keep one default gateway in their configuration while the routers decide between themselves which one answers for that address, so a router failure needs no change on any host and no new DHCP exchange.
- What does an option 51 value of 0xffffffff mean?RFC 2131 §3.3 reserves `0xffffffff` in DHCPv4 time values to mean infinity, so the lease never expires. It is rare in practice because an infinite lease never returns the address to the pool, even after the host has left the network for good.
- Why is the lease in option 51 a duration rather than an expiry timestamp?DHCPv4 does not assume the client's and server's clocks agree. A duration in seconds lets the client count from the moment it sent its request, using only its own clock, so a host with a badly wrong time of day still computes a sensible expiry.
saying these in an interview costs you the question
- The client's IP address arrives in an option like everything else.
- Without option 3 the host cannot reach anything, not even its own subnet.
- Option 6 carries the DNS servers' host names rather than their addresses.
- Option 15 tells the host which DNS server to send its queries to.
- Option 51 is the date and time at which the lease expires.