ietf-corpus

rfc-2132

DHCP Options and BOOTP Vendor Extensions

S. Alexander, R. Droms
date1997-03 streamIETF areaint wgdhc statusDRAFT STANDARD pages34 canonicalhttps://www.rfc-editor.org/rfc/rfc2132 doi10.17487/RFC2132 errataview
This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK]

obsoletes

updated by

Extracted elements (31)

design-rationale §8.4

If a vendor encodes multiple items in the Vendor Specific Information option, it SHOULD use 'Encapsulated vendor-specific options': a nested TLV sequence identical in syntax to the DHCP options field but without a magic cookie, allowing vendor-defined sub-codes within code 43.

ip

design-rationale §2

Many options supply 32-bit IP addresses rather than FQDNs. The RFC notes that use of IP addresses may make future renumbering more difficult and explicitly discourages their use at sites that may require renumbering.

ip, dns

interoperability-note §2

Option codes 128–254 (decimal) are reserved for site-specific options, allowing local customization without conflicting with IANA-assigned option codes.

ip, registry

interoperability-note §2

Options defined in section 9 (DHCP Extensions) are specific to DHCP and MUST NOT be used as BOOTP vendor information extensions. All options in sections 3–8 may be used with either DHCP or BOOTP.

ip

normative-requirement §2 MUST

Any options defined subsequent to this document MUST contain a length octet even if the length is fixed or zero. All multi-octet quantities MUST be in network byte order.

ip

normative-requirement §9.14 MUST

Each client's client-identifier MUST be unique among client-identifiers on the subnet to which the client is attached. Identifiers SHOULD be treated as opaque objects by DHCP servers.

ip

normative-requirement §3.3 MUST

If both the subnet mask and the router option are specified in a DHCP reply, the subnet mask option MUST be first.

ip

normative-requirement §2 MUST

Options containing NVT ASCII data SHOULD NOT include a trailing NULL; however, receivers MUST be prepared to delete trailing nulls if present and MUST NOT require a trailing null.

ip

normative-requirement §8.4 MUST

Servers not equipped to interpret vendor-specific information MUST ignore it. Clients not receiving desired vendor-specific information SHOULD attempt to operate without it, possibly in a degraded mode.

ip

normative-requirement §9.8 MUST

The DHCP server MUST try to insert requested options in the order requested by the client via the Parameter Request List option, though it is not required to return only those options.

ip

protocol-element §9.14

Client-identifier option (code 61, minimum length 2): a type-value pair providing a client's unique identifier for indexing server address bindings. A hardware type of 0 indicates the value is not a hardware address (e.g., an FQDN).

ip

protocol-element §9.6

DHCP Message Type option (code 53, length 1): conveys the message type with values 1=DHCPDISCOVER, 2=DHCPOFFER, 3=DHCPREQUEST, 4=DHCPDECLINE, 5=DHCPACK, 6=DHCPNAK, 7=DHCPRELEASE, 8=DHCPINFORM.

ip

protocol-element §3.8

Domain Name Server option (code 6, minimum length 4, multiple of 4): a list of DNS (RFC 1035) server addresses available to the client, in order of preference.

ip, dns

protocol-element §9.2

IP Address Lease Time option (code 51, length 4): a 32-bit unsigned integer specifying the lease duration in seconds, carried in both client requests and server offers.

ip

protocol-element §9.10

Maximum DHCP Message Size option (code 57, length 2): a 16-bit unsigned integer specifying the maximum DHCP message the client will accept; minimum legal value is 576 octets.

ip

protocol-element §8.3

NTP Servers option (code 42, minimum length 4, multiple of 4): a list of IP addresses indicating NTP servers available to the client, listed in order of preference.

ip, ntp

protocol-element §9.3

Option Overload option (code 52, length 1): signals that the 'file' field (value 1), 'sname' field (value 2), or both (value 3) carry DHCP options when the standard options area is insufficient.

ip

protocol-element §9.8

Parameter Request List option (code 55, minimum length 1): a list of option codes the client requests. The server MUST try to insert the requested options in the order listed by the client.

ip

protocol-element §9.11

Renewal (T1) Time Value option (code 58, length 4) and Rebinding (T2) Time Value option (code 59, length 4): 32-bit unsigned integers in seconds specifying when the client transitions to the RENEWING and REBINDING states respectively.

ip

protocol-element §9.1

Requested IP Address option (code 50, length 4): used in DHCPDISCOVER to allow the client to request assignment of a specific IP address.

ip

protocol-element §3.5

Router option (code 3, minimum length 4, multiple of 4): a list of 32-bit IP addresses for routers on the client's subnet, listed in order of preference.

ip, routing

protocol-element §9.7

Server Identifier option (code 54, length 4): the IP address of the DHCP server, used in DHCPOFFER and DHCPREQUEST to distinguish between servers and as the unicast destination for subsequent client messages.

ip

protocol-element §5.8

Static Route option (code 33, minimum length 8, multiple of 8): a list of destination/router IP address pairs for static routes the client should install. The default route (0.0.0.0) is an illegal destination.

ip, routing

protocol-element §3.3

Subnet Mask option (code 1, length 4): specifies the client's subnet mask as per RFC 950. If both the subnet mask option and the router option are specified in a DHCP reply, the subnet mask option MUST appear first.

ip

protocol-element §9.4

TFTP Server Name option (code 66, minimum length 1) and Bootfile Name option (code 67, minimum length 1): used to carry TFTP server and boot filename when the 'sname' and 'file' header fields have been repurposed via the Option Overload option.

ip

protocol-element §2

The BOOTP magic cookie is a 4-octet field (99.130.83.99 in dotted decimal, 0x63825363 in hex) in network byte order at the start of the vendor information field, identifying the mode for interpreting subsequent option data.

ip

protocol-element §9.13

Vendor Class Identifier option (code 60, minimum length 1): a string identifying the vendor type and configuration of the client. Servers that respond using this information SHOULD return vendor-specific data only via option 43.

ip

protocol-element §8.4

Vendor Specific Information option (code 43, minimum length 1): an opaque object interpreted by vendor-specific code, with the vendor identified via the Vendor Class Identifier option (code 60). Servers not equipped to interpret it MUST ignore it.

ip

registry §10

DHCP option numbers are assigned by IANA upon request. New options must be documented as Internet Drafts and progress through the IETF standards process. If an option fails to gain acceptance, its assigned number is returned to IANA for reassignment.

ip, registry

security-consideration §13

Security issues are not discussed in this memo. The RFC provides no analysis of authentication, protection against rogue servers, or defense against option spoofing — a significant gap for a protocol that configures host network parameters.

ip, security

wire-format §2

DHCP options use TLV encoding: a 1-octet tag, a 1-octet length (excluding tag and length), and data. Only options 0 (Pad) and 255 (End) are fixed-length with no length octet; all others carry an explicit length field.

ip