RFC 3396 (rfc3396) - Page 3 of 9
Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)
Alternative Format: Original Text Document
RFC 3396 Encoding Long Options in DHCPv4 November 2002
Option overload
The DHCP packet format is based on the BOOTP packet format defined
in RFC 951 [1]. When used by DHCP protocol agents, BOOTP packets
have three fields that can contain options. These are the
optional parameters field, the sname field, and the filename
field. The DHCP options specification [4] defines the DHCP
Overload option, which specifies which of these three fields is
actually being used in any given DHCP message to store DHCP
options.
3. Requirements Language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in BCP 14, RFC 2119 [2].
4. Applicability
This specification applies when a DHCP agent is encoding a packet
containing options, where some of those options must be broken into
parts. This need can occur for two reasons. First, it can occur
because the value of an option that needs to be sent is longer than
255 bytes. In this case, the encoding agent MUST follow the
algorithm specified here. It can also occur because there is not
sufficient space in the current output buffer to store the option,
but there is space for part of the option, and there is space in
another output buffer for the rest. In this case, the encoding agent
MUST either use this algorithm or not send the option at all.
This specification also applies in any case where a DHCP protocol
agent has received a DHCP packet that contains more than one instance
of an option of a given type. In this case, the agent MUST
concatenate these separate instances of the same option in the way
that we specify here.
This option updates the Dynamic Host Configuration Protocol [3] and
DHCP Options and BOOTP vendor extensions [4] documents. However,
because many currently-deployed DHCP protocol agents do not implement
option concatenation, DHCP protocol agents should be careful not to
transmit split options unless either it will not matter if the
recipient cannot correctly reassemble the options, or it is certain
that the recipient implements concatenation.
Let us divide all DHCP options into two categories - those that, by
definition, require implementation of the mechanisms defined in this
document, and those that do not. We will refer to the former as
concatenation-requiring options, and the latter as non-
concatenation-requiring options. In order for an option to be a
Lemon & Cheshire Standards Track