Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options
RFC 3942

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

Network Working Group                                            B. Volz
Request for Comments: 3942                           Cisco Systems, Inc.
Updates: 2132                                              November 2004
Category: Standards Track

           Reclassifying Dynamic Host Configuration Protocol
                      version 4 (DHCPv4) Options

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 (2004).

Abstract

   This document updates RFC 2132 to reclassify Dynamic Host
   Configuration Protocol version 4 (DHCPv4) option codes 128 to 223
   (decimal) as publicly defined options to be managed by IANA in
   accordance with RFC 2939.  This document directs IANA to make these
   option codes available for assignment as publicly defined DHCP
   options for future options.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  2
   3.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  2
       3.1.  Publicly Defined Options Range . . . . . . . . . . . . .  2
       3.2.  Site-Specific Options Range  . . . . . . . . . . . . . .  3
   4.  Reclassifying Options  . . . . . . . . . . . . . . . . . . . .  3
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
       8.1.  Normative References . . . . . . . . . . . . . . . . . .  5
       8.2.  Informative References . . . . . . . . . . . . . . . . .  6
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  6
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .  7

Volz                        Standards Track                     [Page 1]
RFC 3942              Reclassifying DHCPv4 Options         November 2004

1.  Introduction

   The DHCPv4 [RFC2131] publicly defined options range, options 1 - 127,
   is nearly used up.  Efforts such as [RFC3679] help extend the life of
   this space, but ultimately the space will be exhausted.

   This document reclassifies much of the site-specific option range,
   which has not been widely used for its original intended purpose, to
   extend the publicly defined options space.

2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Background

   The DHCP option space (0 - 255) is divided into two ranges [RFC2132]:

   1. 1 - 127 are publicly defined options, now allocated in accordance
      with [RFC2939].

   2. 128 - 254 are site-specific options.

   Options 0 (pad) and 255 (end) are special and defined in [RFC2131].

3.1.  Publicly Defined Options Range

   The publicly defined options space (1 - 127) is nearly exhausted.
   Recent work [RFC3679] will buy more time, as several allocated but
   unused option codes have been reclaimed.  A review could be made from
   time to time to determine whether there are other option codes that
   can be reclaimed.

   A longer-term solution to the eventual exhaustion of the publicly
   defined options space is desired.  The DHC WG evaluated several
   solutions:

   1. Using options 126 and 127 to carry 16-bit options as originally
      proposed by Ralph Droms in late 1996.  However, this significantly
      penalizes the first option assigned to this new space, as it
      requires implementing the 16-bit option support.  Because of this,
      options 126 and 127 have been reclaimed [RFC3679].

   2. Using a new magic cookie and 16-bit option code format.  However,
      this proposal

Volz                        Standards Track                     [Page 2]
RFC 3942              Reclassifying DHCPv4 Options         November 2004

      *  penalizes the first option assigned to this new space, as it
         requires significant changes to clients, servers, and relay
         agents,

      *  could adversely impact existing clients, servers, and relay
         agents that fail to properly check the magic cookie value,

      *  requires support of both message formats for the foreseeable
         future, and

      *  requires clients to send multiple DHCPDISCOVER messages -- one
         for each magic cookie.

   3. Reclassifying a portion of the site-specific option codes as
      publicly defined.  The impact is minimal, as only those sites