skip to content

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%

answer

  1. BOOTP's header fields
  2. next server is not the DHCP server
  3. 66 and 67 cover the overloaded case
  4. options first, then file, then sname
  5. vendor class picks the answer

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.

solid answer

~40 s

A network-boot client needs an address, a server to fetch its image from and the image's name. DHCPv4 keeps three BOOTP header fields for this: `siaddr`, the address of the next server in the bootstrap, `sname`, a 64-octet server host name, and `file`, a 128-octet boot file path. When the options outgrow the options field, a server may reuse `file`, `sname` or both as option space and say so with option 52, value 1, 2 or 3. The client reads the options field first, then `file`, then `sname`. Because an overloaded field no longer holds a name, RFC 2132 defines option 66, TFTP server name, and option 67, bootfile name, to carry them. The client's option 60, vendor class identifier, lets the server answer boot firmware differently from an installed system.

go deeper

for a junior

Remember that a booting client learns a server and a file name from DHCP, either from header fields or from options 66 and 67.

for a middle

Explain siaddr versus option 54, the three overload values of option 52 and the order the client reads options, file and sname.

for a senior

Debug a boot that gets an address but no image: compare siaddr with option 54, look for option 52, and check whether option 60 steered the reply.

for a principal

Decide how boot service is split from address service, keeping DHCP replies small enough to avoid overloading and keying boot answers on vendor class rather than per host.

## What a network-boot client needs A machine booting from the network has no disk image yet. Its boot firmware must learn three things from one DHCPv4 exchange: **an address**, **which server to fetch an image from**, and **the image's name**. The address comes in `yiaddr` with the usual options. The other two can travel in two different places, and knowing both is what makes a failed network boot debuggable. ## The BOOTP header fields DHCPv4 kept the BOOTP header (RFC 951, RFC 2131 §2), including three fields that exist for booting: | Field | Size | Meaning in a server reply | |---|---|---| | `siaddr` | 4 octets | Address of the **next server** in the client's bootstrap | | `sname` | 64 octets | Optional server host name, null-terminated | | `file` | 128 octets | Boot file name; a generic name or null from the client, a full path from the server | `siaddr` is easy to confuse with option 54, **server identifier**. RFC 2131 separates them: the server identifier is always the DHCP server's own address, used to tell offers apart and to address later DHCP messages, while `siaddr` points at whichever server provides the next boot step. A DHCP server puts its own address there only if it also serves the boot image. ## Overloading: option 52 A client must accept an options field of at least 312 octets, and more only if it says so with option 57. When a reply needs more room than that, the server can reuse the 128-octet `file` field, the 64-octet `sname` field or both as more option space, and RFC 2132 §9.3 defines option 52, **Option Overload**, to say which: | Value | Fields holding options | |---|---| | 1 | `file` | | 2 | `sname` | | 3 | both | RFC 2131 §4.1 fixes how such a message is read: 1. The **options field is interpreted first**, so option 52 is found. 2. Then the `file` field, if option 52 says it holds options. 3. Then the `sname` field, if option 52 says it holds options. Each overloaded field starts with an option at its first octet, ends with the end option and is filled with pads. **No option may straddle two fields**; each must sit entirely inside one. ## Options 66 and 67 Once `sname` or `file` carries options, it can no longer carry a name. RFC 2132 §9.4 and §9.5 define two options for exactly that case: - **Option 66, TFTP server name**, identifies the boot server when `sname` holds options; - **Option 67, Bootfile name**, identifies the boot file when `file` holds options. They are in RFC 2132 §9, the DHCP-only section, so a pure BOOTP client never sees them. Boot firmware differs in which source it reads, so operators commonly fill in both the header fields and options 66 and 67. That is an operating convention for compatibility, not an RFC rule. The image itself is classically fetched with TFTP, as RFC 951 already anticipated. ## Telling boot firmware from the installed system The same machine asks for an address twice: once from its boot firmware and later from its installed operating system. The server usually wants to hand a boot file only to the first. The tool for that is **option 60, vendor class identifier** (RFC 2132 §9.13), a string the client sends to describe its vendor type and configuration: - RFC 2131 §4.2 lets a server consider the vendor class when choosing a client's parameters. - A server that does not understand a class MUST ignore it. - A server returning vendor-specific information SHOULD use **option 43**, whose contents the vendor defines, often as encapsulated code-length-value sub-options. ## Diagnosing a boot that gets an address but no image - Check `siaddr` against option 54: the boot server is often a different host from the DHCP server. - Check whether option 52 is present; if it is, the names must be in 66 and 67, not in the header. - Check whether the reply depended on option 60, and whether the firmware's class string matched what the server expects.

  • In DHCPv4, why can't a client fetch its boot image from the address in option 54?
    Option 54, server identifier, is always the DHCP server's own address, used to choose between offers and to address later DHCP messages. The boot image may live on another host, and RFC 2131 points the client at it with the `siaddr` field, the next server in the bootstrap.
  • Why does a DHCPv4 server read option 52 before anything in the file or sname fields?
    Only option 52 says whether those header fields hold names or more options. RFC 2131 therefore has the options field interpreted first, then `file`, then `sname`, and requires every option to sit wholly inside one field so each can be parsed on its own.

saying these in an interview costs you the question

  • Option 54 tells the client which host to fetch its boot file from.
  • Options 66 and 67 are unrelated to the sname and file header fields.
  • With overloading, one option may continue from the options field into file.
  • Option 60 is sent by the server to tell the client its class.
  • The DHCP server must always be the host that serves the boot image.