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

Document Type RFC - Proposed Standard (November 2002; No errata)
Updates RFC 2131
Authors Ted Lemon  , Stuart Cheshire 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3396 (Proposed Standard)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Thomas Narten
Send notices to <rdroms@cisco.com>
Network Working Group                                           T. Lemon
Request for Comments: 3396                                 Nominum, Inc.
Updates: 2131                                                S. Cheshire
Category: Standards Track                           Apple Computer, Inc.
                                                           November 2002

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

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


   This document specifies the processing rules for Dynamic Host
   Configuration Protocol (DHCPv4) options that appear multiple times in
   the same message.  Multiple instances of the same option are
   generated when an option exceeds 255 octets in size (the maximum size
   of a single option) or when an option needs to be split apart in
   order to take advantage of DHCP option overloading.  When multiple
   instances of the same option appear in the options, file and/or sname
   fields in a DHCP packet, the contents of these options are
   concatenated together to form a single option prior to processing.

1. Introduction

   This document updates RFC 2131 [3] by clarifying the rules for option
   concatenation specified in section 4.1.  It is expected that the
   reader will be familiar with this portion of RFC 2131.  The text in
   section 4.1 that reads "Options may appear only once, unless
   otherwise specified in the options document."  should be considered
   as deleted.

   The DHCP protocol [3] specifies objects called "options" that are
   encoded in the DHCPv4 packet to pass information between DHCP
   protocol agents.  These options are encoded as a one-byte type code,
   a one-byte length, and a buffer consisting of the number of bytes
   specified in the length, from zero to 255.

Lemon & Cheshire            Standards Track                     [Page 1]
RFC 3396            Encoding Long Options in DHCPv4        November 2002

   However, in some cases it may be useful to send options that are
   longer than 255 bytes.  RFC 2131 [3] specifies that when more than
   one option with a given type code appears in the DHCP packet, all
   such options should be concatenated together.  It does not, however,
   specify the order in which this concatenation should occur.

   We specify here the ordering that MUST be used by DHCP protocol
   agents when sending options with more than 255 bytes.  This method
   also MUST be used for splitting options that are shorter than 255
   bytes, if for some reason the encoding agent needs to do so.  DHCP
   protocol agents MUST use this method whenever they receive a DHCP
   packet containing more than one occurrence of a certain type of

2. Terminology

      Throughout this document, the acronym "DHCP" is used to refer to
      the Dynamic Host Configuration Protocol as specified in RFC 2131
      [3] and RFC 2132 [4].

      We have used the term "DHCPv4" in the abstract for this document
      to distinguish between the DHCP protocol for IPv4 as defined in
      RFC 2131 and RFC 2132 and the DHCP protocol for IPv6, which, at
      the time that this document was written, was still under

   DHCP protocol agents
      This refers to any device on the network that sends or receives
      DHCP packets - any DHCP client, server or relay agent.  The nature
      of these devices is not important to this specification.

   Encoding agent
      The DHCP protocol agent that is composing a DHCP packet to send.

   Decoding agent
      The DHCP protocol agent that is processing a DHCP packet it has

      DHCP options are collections of data with type codes that indicate
      how the options should be used.  Options can specify information
      that is required for the DHCP protocol, IP stack configuration
      parameters for the client, information allowing the client to
      rendezvous with DHCP servers, and so on.

Lemon & Cheshire            Standards Track                     [Page 2]
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
Show full document text