DHCPv6 Options for Network Boot
Extracted elements (24)
The Boot File URL option does not constrain the download protocol beyond requiring URL expressibility. HTTP (RFC 2616) is strongly recommended over TFTP for administrative simplicity; this supersedes RFC 906's recommendation of TFTP for IPv6 network boot, reflecting the maturity of HTTP as a transfer protocol.
When using iSCSI for booting, the 'iscsi' URI is formed as defined in RFC 4173. The functionality attributed to a root path option in RFC 4173 is provided for IPv6 by OPT_BOOTFILE_URL instead, eliminating the need for a separate root path option.
Clients that have DNS implementations SHOULD support the use of domain names in the boot file URL.
If the client used OPTION_CLIENT_ARCH_TYPE in its request, the server SHOULD include this option in the reply to inform the client about supported pre-boot environments for the boot file.
In OPTION_CLIENT_ARCH_TYPE, if a client supports more than one pre-boot environment, the most preferred architecture type MUST be listed first, followed by others in descending priority. The server's response list MUST only contain architecture types initially queried by the client, also in descending priority order.
The boot-file-url string MUST comply with STD 66 (RFC 3986). If the host in the URL is expressed as an IPv6 address, the address MUST be enclosed in '[' and ']' characters per RFC 3986.
The four network boot options (OPT_BOOTFILE_URL, OPT_BOOTFILE_PARAM, OPTION_CLIENT_ARCH_TYPE, OPTION_NII) MUST NOT appear in DHCPv6 messages other than Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply.
The information required for booting over the network MUST include at least the server location, the download protocol, and the path and name of the boot file.
The option-codes of the network boot options MAY appear in the Option Request option in DHCPv6 message types Solicit, Request, Renew, Rebind, Information-Request, and Reconfigure.
The option-len field of OPTION_CLIENT_ARCH_TYPE MUST be an even number greater than zero, reflecting that the architecture-types field is a list of 16-bit (2-octet) values.
When boot firmware executes the boot file specified by OPT_BOOTFILE_URL, it MUST pass the parameters from OPT_BOOTFILE_PARAM, if present, in the order they appear in the option.
OPT_BOOTFILE_PARAM (option code 60) carries one or more UTF-8 (RFC 3629) strings sent by the server to the client, each preceded by a 16-bit param-len field. These strings specify boot parameters analogous to command-line arguments (e.g., kernel parameters, root filesystem location).
OPT_BOOTFILE_URL (option code 59) carries a variable-length URL string (STD 66 / RFC 3986 compliant, not NUL-terminated) that the DHCPv6 server sends to inform the client of the location of the network boot file. This is the only mandatory option for network booting.
OPTION_CLIENT_ARCH_TYPE (option code 61) carries a list of 16-bit architecture type identifiers representing the pre-boot runtime environments supported by the client, listed in descending order of preference. It provides DHCPv6 parity with the DHCPv4 option defined in RFC 4578 Section 2.1.
OPTION_NII (option code 62) is sent by clients that support the Universal Network Device Interface (UNDI) to inform the server of their UNDI support level. It contains three 1-octet fields (Type, Major, Minor) as defined in RFC 4578 Section 2.2 and the UEFI specification.
IANA assigned four DHCPv6 option codes from the RFC 3315 option number space: OPT_BOOTFILE_URL (59), OPT_BOOTFILE_PARAM (60), OPTION_CLIENT_ARCH_TYPE (61), and OPTION_NII (62).
This document introduces a new IANA registry named 'Processor Architecture Types', containing 16-bit integer values (in decimal) with descriptive names. Initial values are taken from RFC 4578 Section 2.1. New assignments require Expert Review per RFC 5226.
DHCPv6 messages are sent unencrypted by default, exposing boot file URLs—which may contain credentials—over the network. It is strongly RECOMMENDED not to include sensitive information such as usernames or passwords in boot file URLs in untrusted networks.
In untrusted networks, a rogue DHCPv6 server can send fraudulent boot options causing clients to boot an incorrect or malicious operating system. Clients SHOULD use DHCPv6 message authentication (RFC 3315 Section 21) to mitigate this threat.
Securing the DHCPv6 transaction does not protect the boot file download channel. Implementers should use HTTPS (RFC 2818) or TLS within HTTP (RFC 2817) to prevent spoofing, or implement boot image signing with a configurable key so malicious images can be detected and rejected.
OPT_BOOTFILE_PARAM wire format: 2-octet option-code (60), 2-octet option-len, then a sequence of (param-len: 16-bit integer, parameter: UTF-8 string of param-len octets, not NUL-terminated) tuples.
OPT_BOOTFILE_URL wire format: 2-octet option-code (59), 2-octet option-len (length of URL in octets), followed by the boot-file-url string (variable length, not NUL-terminated).
OPTION_CLIENT_ARCH_TYPE wire format: 2-octet option-code (61), 2-octet option-len (MUST be an even number greater than zero), followed by a variable-length list of 16-bit architecture type values.
OPTION_NII wire format: 2-octet option-code (62), 2-octet option-len (fixed at 3), followed by Type (1 octet), Major (1 octet), and Minor (1 octet) fields as specified in RFC 4578 Section 2.2.