ietf-corpus

rfc-1533

DHCP Options and BOOTP Vendor Extensions

S. Alexander, R. Droms
date1993-10 streamIETF areaint wgdhc statusPROPOSED STANDARD pages30 canonicalhttps://www.rfc-editor.org/rfc/rfc1533 doi10.17487/RFC1533
This document specifies the current set of DHCP options. [STANDARDS-TRACK]

obsoleted by

obsoletes

Extracted elements (25)

design-rationale §8.4

Vendor-specific information (option 43) uses an encapsulated TLV sub-option format without a magic cookie, allowing vendors to redefine option codes within the encapsulated space while still following the standard tag-length-value syntax. This avoids code space conflicts between vendors while reusing the proven TLV framing.

ip

interoperability-note §2

All DHCP options defined in sections 3–8 may be used as BOOTP vendor information extensions. Only the options in section 9 are specific to DHCP and must not be used as BOOTP vendor extensions.

ip

normative-requirement §3.3 MUST

If both the subnet mask option (code 1) and the router option (code 3) are specified in a DHCP reply, the subnet mask option MUST be first.

ip

normative-requirement §8.4 MUST

Servers not equipped to interpret vendor-specific information (option 43) sent by a client MUST ignore it. Clients that do not receive desired vendor-specific information SHOULD attempt to operate without it, possibly in a degraded mode.

ip

normative-requirement §9.6 MUST

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

ip

protocol-element §9.11

Class-identifier option (code 60, minimum 1 octet) is used by DHCP clients to optionally identify the type and configuration of the client (e.g., hardware configuration). Servers not equipped to interpret it MUST ignore it.

ip

protocol-element §9.12

Client-identifier option (code 61, minimum 2 octets) is used by DHCP clients to specify a unique identifier used by servers to index address bindings. It consists of a hardware type octet followed by the identifier value; typically a hardware type and hardware address.

ip

protocol-element §9.4

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

ip

protocol-element §3.8, 3.17

Domain Name Server option (code 6, minimum 4 octets, must be multiple of 4) specifies a list of DNS (RFC 1035) servers available to the client, listed in order of preference. Domain Name option (code 15, minimum 1 octet) specifies the domain name the client should use when resolving hostnames via DNS.

ip, dns

protocol-element §9.2

IP Address Lease Time option (code 51, 4 octets, unsigned 32-bit integer in seconds) is used in client requests (DHCPDISCOVER or DHCPREQUEST) to request a lease duration, and in server replies (DHCPOFFER) to specify the offered lease time.

ip

protocol-element §9.8

Maximum DHCP Message Size option (code 57, 2 octets, unsigned 16-bit integer) specifies the maximum DHCP message length the client is willing to accept. Minimum legal value is 576 octets. Should not be used in DHCPDECLINE messages.

ip

protocol-element §9.7

Message option (code 56, variable NVT ASCII text) is used by a DHCP server to provide an error message to a client in a DHCPNAK, or by a client in a DHCPDECLINE to explain why the offered parameters were declined.

ip

protocol-element §9.3

Option Overload option (code 52, length 1) indicates that the DHCP 'sname' or 'file' fields are being used to carry options. Value 1 means 'file' holds options; 2 means 'sname' holds options; 3 means both fields hold options. The client must interpret overloaded fields after the standard options field.

ip

protocol-element §3.1, 3.2

Pad option (code 0, 1 octet, no length or data field) is used to align subsequent fields on word boundaries. End option (code 255, 1 octet) marks the end of valid information in the vendor field; subsequent octets should be filled with pad options.

ip

protocol-element §9.6

Parameter Request List option (code 55, variable length) is used by a DHCP client to request values for specific configuration parameters, each identified by its 1-octet option code. The server MUST try to insert requested options in the order requested by the client.

ip

protocol-element §9.9, 9.10

Renewal (T1) Time Value option (code 58, 4 octets) specifies the time interval in seconds from address assignment until the client transitions to the RENEWING state. Rebinding (T2) Time Value option (code 59, 4 octets) specifies the interval until the client transitions to the REBINDING state.

ip

protocol-element §9.1

Requested IP Address option (code 50, 4 octets) is used in a DHCPDISCOVER request to allow the client to request a particular IP address be assigned.

ip

protocol-element §9.5

Server Identifier option (code 54, 4 octets) carries the IP address of the DHCP server. Included in DHCPOFFER to allow the client to distinguish between lease offers; included by the client in DHCPREQUEST to indicate which offer is being accepted.

ip

protocol-element §5.8

Static Route option (code 33, minimum 8 octets, multiple of 8) specifies a list of static routes as destination/router IP address pairs. The default route (0.0.0.0) is illegal as a destination. Multiple routes to the same destination are listed in descending priority order.

ip, routing

protocol-element §3.3, 3.5

Subnet Mask option (code 1, 4 octets) specifies the client's subnet mask per RFC 950. Router option (code 3, minimum 4 octets, must be multiple of 4) specifies a list of IP addresses for routers on the client's subnet; routers SHOULD be listed in preference order.

ip

protocol-element §8.4

Vendor Specific Information option (code 43, minimum 1 octet) allows clients and servers to exchange opaque vendor-specific data. If a vendor encodes multiple items, the content SHOULD use encapsulated code/length/value sub-options using the same TLV syntax, but without a magic cookie, and with codes redefinable by the vendor.

ip

registry §2, 10

Option codes 128–254 (decimal) are reserved for site-specific options. Implementation-specific use of undefined generic types in range 61–127 may conflict with other implementations; registration with IANA is required. New options are registered by contacting IANA at iana@isi.edu.

ip, registry

security-consideration §13

The RFC explicitly states that security issues are not discussed in this memo, meaning RFC 1533 defines no authentication or integrity protection mechanisms for DHCP options or BOOTP vendor extensions.

security, ip

wire-format §2

DHCP options and BOOTP vendor extensions use a tag-length-value (TLV) encoding. Each option begins with a 1-octet tag, followed by a 1-octet length (excluding tag and length octets themselves), followed by that many data octets. Only codes 0 (Pad) and 255 (End) are fixed-length with no length octet. All multi-octet quantities are in network byte order.

ip, registry

wire-format §2

When DHCP/BOOTP options are used with BOOTP, the first 4 octets of the vendor information field contain the magic cookie 99.130.83.99 (hex 63.82.53.63) in network byte order, identifying the mode of interpretation for the succeeding data.

ip