workbench/network/stacks/AROSTCP/dhcp/doc/rfc2489.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                           R. Droms
   8 Request for Comments: 2489                           Bucknell University
   9 BCP: 29                                                     January 1999
  10 Category: Best Current Practice
  11
  12
  13                 Procedure for Defining New DHCP Options
  14
  15 Status of this Memo
  16
  17    This document specifies an Internet Best Current Practices for the
  18    Internet Community, and requests discussion and suggestions for
  19    improvements.  Distribution of this memo is unlimited.
  20
  21 Copyright Notice
  22
  23    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  24
  25 Abstract
  26
  27    The Dynamic Host Configuration Protocol (DHCP) provides a framework
  28    for passing configuration information to hosts on a TCP/IP network.
  29    Configuration parameters and other control information are carried in
  30    tagged data items that are stored in the 'options' field of the DHCP
  31    message.  The data items themselves are also called "options."
  32
  33    New DHCP options may be defined after the publication of the DHCP
  34    specification to accommodate requirements for conveyance of new
  35    configuration parameters.  This document describes the procedure for
  36    defining new DHCP options.
  37
  38 1. Introduction
  39
  40    The Dynamic Host Configuration Protocol (DHCP) [1] provides a
  41    framework for passing configuration information to hosts on a TCP/IP
  42    network.  Configuration parameters and other control information are
  43    carried in tagged data items that are stored in the 'options' field
  44    of the DHCP message.  The data items themselves are also called
  45    "options." [2]
  46
  47    This document describes the procedure for defining new DHCP options.
  48    The procedure will guarantee that:
  49
  50    * allocation of new option numbers is coordinated from a single
  51      authority,
  52    * new options are reviewed for technical correctness and
  53      appropriateness, and
  54    * documentation for new options is complete and published.
  55
  56
  57
  58 Droms                    Best Current Practice                  [Page 1]
  59 \f
  60 RFC 2489               Defining New DCHP Options            January 1999
  61
  62
  63    As indicated in "Guidelines for Writing an IANA Considerations
  64    Section in RFCs" (see references), IANA acts as a central authority
  65    for assignment of numbers such as DHCP option codes.  The new
  66    procedure outlined in this document will provide guidance to IANA in
  67    the assignment of new option codes.
  68
  69 2. Overview and background
  70
  71    The procedure described in this document modifies and clarifies the
  72    procedure for defining new options in RFC 2131 [2].  The primary
  73    modification is to the time at which a new DHCP option is assigned an
  74    option number.  In the procedure described in this document, the
  75    option number is not assigned until specification for the option is
  76    about to be published as an RFC.
  77
  78    Since the publication of RFC 2132, the option number space for
  79    publically defined DHCP options (1-127) has almost been exhausted.
  80    Many of the defined option numbers have not been followed up with
  81    Internet Drafts submitted to the DHC WG.  There has been a lack of
  82    specific guidance to IANA from the DHC WG as to the assignment of
  83    DHCP option numbers
  84
  85    The procedure as specified in RFC 2132 does not clearly state that
  86    new options are to be reviewed individually for technical
  87    correctness, appropriateness and complete documentation.  RFC 2132
  88    also does not require that new options are to be submitted to the
  89    IESG for review, and that the author of the option specification is
  90    responsible for bringing new options to the attention of the IESG.
  91    Finally, RFC 2132 does not make clear that newly defined options are
  92    not to be incorporated into products, included in other
  93    specifications or otherwise used until the specification for the
  94    option is published as an RFC.
  95
  96    In the future, new DHCP option codes will be assigned by IETF
  97    consensus.  New DHCP options will be documented in RFCs approved by
  98    the IESG, and the codes for those options will be assigned at the
  99    time the relevant RFCs are published.  Typically, the IESG will seek
 100    input on prospective assignments from appropriate sources (e.g., a
 101    relevant Working Group if one exists).  Groups of related options may
 102    be combined  into a single specification and reviewed as a set by the
 103    IESG.  Prior to assignment of an option code, it is not appropriate
 104    to incorporate new options into products, include the specification
 105    in other documents or otherwise make use of the new options.
 106
 107    The DHCP option number space (1-254) is split into two parts.  The
 108    site-specific options (128-254) are defined as "Private Use" and
 109    require no review by the DHC WG.  The public options (1-127) are
 110
 111
 112
 113
 114 Droms                    Best Current Practice                  [Page 2]
 115 \f
 116 RFC 2489               Defining New DCHP Options            January 1999
 117
 118
 119    defined as "Specification Required" and new options must be reviewed
 120    prior to assignment of an option number by IANA.  The details of the
 121    review process are given in the following section of this document.
 122
 123 3. Procedure
 124
 125    The author of a new DHCP option will follow these steps to obtain
 126    approval for the option and publication of the specification of the
 127    option as an RFC:
 128
 129    1. The author devises the new option.
 130
 131    2. The author documents the new option, leaving the option code as
 132       "To Be Determined" (TBD), as an Internet Draft.
 133
 134       The requirement that the new option be documented as an Internet
 135       Draft is a matter of expediency.  In theory, the new option could
 136       be documented on the back of an envelope for submission; as a
 137       practical matter, the specification will eventually become an
 138       Internet Draft as part of the review process.
 139
 140    3. The author submits the Internet Draft for review by the IESG.
 141       Preferably, the author will submit the Internet Draft to the DHC
 142       Working Group, but the author may choose to submit the Internet
 143       Draft directly to the IESG.
 144
 145       Note that simply publishing the new option as an Internet Draft
 146       does not automatically bring the option to the attention of the
 147       IESG.  The author of the new option must explicitly forward a
 148       request for action on the new option to the DHC WG or the IESG.
 149
 150    4. The specification of the new option is reviewed by the IESG.  The
 151       specification is reviewed by the DHC WG (if it exists) or by the
 152       IETF.  If the option is accepted for inclusion in the DHCP
 153       specification, the specification of the option is published as an
 154       RFC.  It may be published as either a standards-track or a non-
 155       standards-track RFC.
 156
 157    5. At the time of publication as an RFC, IANA assigns a DHCP option
 158       number to the new option.
 159
 160 4. References
 161
 162    [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
 163        March 1997.
 164
 165    [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
 166        Extensions", RFC 2132, March 1997.
 167
 168
 169
 170 Droms                    Best Current Practice                  [Page 3]
 171 \f
 172 RFC 2489               Defining New DCHP Options            January 1999
 173
 174
 175    [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
 176        RFC 2142, November 1997.
 177
 178    [4] Narten, T. and  H. Alvestrand, "Guidelines for Writing an IANA
 179        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 180
 181 5. Security Considerations
 182
 183    Information that creates or updates an option number assignment needs
 184    to be authenticated.
 185
 186    An analysis of security issues is required for all newly defined DHCP
 187    options.  The description of security issues in the specification of
 188    new options must be as accurate as possible.  The specification for a
 189    new option may reference the "Security Considerations" section in the
 190    DHCP specification [1]; e.g. (from "NetWare/IP Domain Name and
 191    Information" [3]):
 192
 193       DHCP currently provides no authentication or security mechanisms.
 194       Potential exposures to attack are discussed in section 7 of the
 195       DHCP protocol specification [RFC 2131].
 196
 197 6. IANA Considerations
 198
 199    RFC 2132 provided guidance to the IANA on the procedure it should
 200    follow when assigning option numbers for new DHCP options.  This
 201    document updates and replaces those instructions.  In particular,
 202    IANA is requested to assign DHCP option numbers only for options that
 203    have been approved for publication as RFCs; i.e., documents that have
 204    been approved through "IETF consensus" as defined in RFC 2434 [4].
 205
 206 7. Author's Address
 207
 208    Ralph Droms
 209    Computer Science Department
 210    323 Dana Engineering
 211    Bucknell University
 212    Lewisburg, PA 17837
 213
 214    Phone: (717) 524-1145
 215    EMail: droms@bucknell.edu
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Droms                    Best Current Practice                  [Page 4]
 227 \f
 228 RFC 2489               Defining New DCHP Options            January 1999
 229
 230
 231 8.  Full Copyright Statement
 232
 233    Copyright (C) The Internet Society (1999).  All Rights Reserved.
 234
 235    This document and translations of it may be copied and furnished to
 236    others, and derivative works that comment on or otherwise explain it
 237    or assist in its implementation may be prepared, copied, published
 238    and distributed, in whole or in part, without restriction of any
 239    kind, provided that the above copyright notice and this paragraph are
 240    included on all such copies and derivative works.  However, this
 241    document itself may not be modified in any way, such as by removing
 242    the copyright notice or references to the Internet Society or other
 243    Internet organizations, except as needed for the purpose of
 244    developing Internet standards in which case the procedures for
 245    copyrights defined in the Internet Standards process must be
 246    followed, or as required to translate it into languages other than
 247    English.
 248
 249    The limited permissions granted above are perpetual and will not be
 250    revoked by the Internet Society or its successors or assigns.
 251
 252    This document and the information contained herein is provided on an
 253    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 254    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 255    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 256    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 257    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Droms                    Best Current Practice                  [Page 5]
 283 \f