RFC 3396 (rfc3396) - Page 3 of 9

Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)

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