doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc2939.txt b/doc/rfc/rfc2939.txt
new file mode 100644
index 0000000..7ed1be0
--- /dev/null
+++ b/doc/rfc/rfc2939.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                            R. Droms
+Request for Comments: 2939                            Bucknell University
+BCP: 43                                                    September 2000
+Obsoletes: 2489
+Category: Best Current Practice
+
+
+            Procedures and IANA Guidelines for Definition of
+                   New DHCP Options and Message Types
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   The Dynamic Host Configuration Protocol (DHCP) provides a framework
+   for passing configuration information to hosts on a Transmission
+   Control Protocol/Internet Protocol (TCP/IP) network.  Configuration
+   parameters and other control information are carried in tagged data
+   items that are stored in the 'options' field of the DHCP message.
+   The data items themselves are also called "options".
+
+   DHCP protocol messages are identified by the 'DHCP Message Type'
+   option (option code 51).  Each message type is defined by the data
+   value carried in the 'DHCP Message Type' option.
+
+   New DHCP options and message types may be defined after the
+   publication of the DHCP specification to accommodate requirements for
+   conveyance of new configuration parameters or to accommodate new
+   protocol semantics.  This document describes the procedure for
+   defining new DHCP options and message types.
+
+1. Introduction
+
+   The Dynamic Host Configuration Protocol (DHCP) [1] provides a
+   framework for passing configuration information to hosts on a TCP/IP
+   network.  Configuration parameters and other control information are
+   carried in tagged data items that are stored in the 'options' field
+   of the DHCP message.  The data items themselves are also called
+   "options" [2].
+
+
+
+
+Droms                    Best Current Practice                  [Page 1]
+
+RFC 2939            Procedures for New DHCP Options       September 2000
+
+
+   DHCP protocol messages are identified by the 'DHCP Message Type'
+   option (option code 51).  Each message type is defined by the data
+   value carried in the 'DHCP Message Type' option.
+
+   This document describes the procedure for defining new DHCP options
+   and message types.  The procedure will guarantee that:
+
+   * allocation of new option numbers and message type numbers is
+     coordinated from a single authority,
+   * new options and message types are reviewed for technical
+     correctness and appropriateness, and
+   * documentation for new options and message types is complete and
+     published.
+
+   As indicated in, "Guidelines for Writing an IANA Considerations
+   Section in RFCs", (see references), IANA acts as a central authority
+   for assignment of numbers such as DHCP option and message type codes.
+   The new procedure outlined in this document will provide guidance to
+   IANA in the assignment of new option and message type codes.
+
+   This document updates and replaces RFC 2489.
+
+2. Overview and background
+
+   This document specifies procedures for defining new option codes and
+   message types.
+
+2.1 New DHCP option codes
+
+   The procedure described in this document modifies and clarifies the
+   procedure for defining new options in RFC 2131 [2].  The primary
+   modification is to the time at which a new DHCP option is assigned an
+   option number.  In the procedure described in this document, the
+   option number is not assigned until specification for the option is
+   about to be published as an RFC.
+
+   Since the publication of RFC 2132, the option number space for
+   publicly defined DHCP options (1-127) has almost been exhausted.
+   Many of the defined option numbers have not been followed up with
+   Internet Drafts submitted to the DHC WG.  There has been a lack of
+   specific guidance to IANA from the DHC WG as to the assignment of
+   DHCP option numbers.
+
+   The procedure as specified in RFC 2132 does not clearly state that
+   new options are to be reviewed individually for technical
+   correctness, appropriateness and complete documentation.  RFC 2132
+   also does not require that new options are to be submitted to the
+   IESG for review, and that the author of the option specification is
+
+
+
+Droms                    Best Current Practice                  [Page 2]
+
+RFC 2939            Procedures for New DHCP Options       September 2000
+
+
+   responsible for bringing new options to the attention of the IESG.
+   Finally, RFC 2132 does not make clear that newly defined options are
+   not to be incorporated into products, included in other
+   specifications or otherwise used until the specification for the
+   option is published as an RFC.
+
+   In the future, new DHCP option codes will be assigned by IETF
+   consensus.  New DHCP options will be documented in RFCs approved by
+   the IESG, and the codes for those options will be assigned at the
+   time the relevant RFCs are published.  Typically, the IESG will seek
+   input on prospective assignments from appropriate sources (e.g., a
+   relevant Working Group if one exists).  Groups of related options may
+   be combined  into a single specification and reviewed as a set by the
+   IESG.  Prior to assignment of an option code, it is not appropriate
+   to incorporate new options into products, include the specification
+   in other documents or otherwise make use of the new options.
+
+   The DHCP option number space (1-254) is split into two parts.  The
+   site-specific option codes [2] (128-254) are defined as "Private Use"
+   and require no review by the DHC WG.  Site-specific options codes
+   (128-254) MUST NOT be defined for use by any publicly distributed
+   DHCP server, client or relay agent implementations.  These option
+   codes are explicitly reserved for private definition and use within a
+   site or an organization.
+
+   The public option codes (0-127, 255) are defined as "Specification
+   Required" and new options must be reviewed prior to assignment of an
+   option number by IANA.  The details of the review process are given
+   in the following section of this document.
+
+2.2 New DHCP message types
+
+   RFC 2131 does not specify any mechanism for defining new DHCP message
+   types.  In the future, new DHCP message types will be documented in
+   RFCs approved by the IESG, and the codes for these new message types
+   will be assigned at the time the relevant RFCs are published.
+
+   Typically, the IESG will seek input on new message types from
+   appropriate sources (e.g., a relevant Working Group if one exists).
+   Prior to assignment of a message type code, it is not appropriate to
+   incorporate new message types into products, include the
+   specification in other documents or otherwise make use of the new
+   message types.
+
+
+
+
+
+
+
+
+Droms                    Best Current Practice                  [Page 3]
+
+RFC 2939            Procedures for New DHCP Options       September 2000
+
+
+3. Procedure
+
+   The author of a new DHCP option or message type will follow these
+   steps to obtain approval for the option and publication of the
+   specification of the option as an RFC:
+
+   1. The author devises the new option or message type.
+
+   2. The author documents the new option or message type, leaving the
+      option code or message type code as "To Be Determined" (TBD), as
+      an Internet Draft.
+
+      The requirement that the new option or message type be documented
+      as an Internet Draft is a matter of expediency.  In theory, the
+      new option or message type could be documented on the back of an
+      envelope for submission; as a practical matter, the specification
+      will eventually become an Internet Draft as part of the review
+      process.
+
+   3. The author submits the Internet Draft for review by the IESG.
+      Preferably, the author will submit the Internet Draft to the DHC
+      Working Group, but the author may choose to submit the Internet
+      Draft directly to the IESG.
+
+      Note that simply publishing the new option or message type as an
+      Internet Draft does not automatically bring the option to the
+      attention of the IESG.  The author of the new option or message
+      type must explicitly forward a request for action on the new
+      option to the DHC WG or the IESG.
+
+   4. The specification of the new option or message type is reviewed by
+      the IESG.  The specification is reviewed by the DHC WG (if it
+      exists) or by the IETF.  If the option or message type is accepted
+      for inclusion in the DHCP specification, the specification of the
+      option or message type is published as an RFC.  It may be
+      published as either a standards-track or a non-standards-track
+      RFC.
+
+   5. At the time of publication as an RFC, IANA assigns a DHCP option
+      code or message type code to the new option or message type.
+
+4. References
+
+   [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
+       1997.
+
+   [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+       Extensions", RFC 2132, March 1997.
+
+
+
+Droms                    Best Current Practice                  [Page 4]
+
+RFC 2939            Procedures for New DHCP Options       September 2000
+
+
+   [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
+       RFC 2142, November 1997.
+
+   [4] Narten, T. and  H. Alvestrand, "Guidelines for Writing an IANA
+       Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [5] Droms, R., "Procedure for Defining New DHCP Options", RFC 2489,
+       January 1999.
+
+5. Changes from RFC 2489
+
+   This document extends the procedures for defining new DHCP options
+   specified in RFC 2489 [5] to include the definition of new DHCP
+   message types.  The language reserving site-specific option codes has
+   been strengthened to emphasize the requirement that site-specific
+   option codes must not be encoded in publicly distributed DHCP
+   implementations.
+
+6. Security Considerations
+
+   Information that creates or updates an option code or message type
+   code assignment needs to be authenticated.
+
+   An analysis of security issues is required for all newly defined DHCP
+   options or message types.  The description of security issues in the
+   specification of new options or message types must be as accurate as
+   possible.  The specification for a new option or message type may
+   reference the "Security Considerations" section in the DHCP
+   specification [1]; e.g., (from "NetWare/IP Domain Name and
+   Information" [3]):
+
+      DHCP currently provides no authentication or security mechanisms.
+      Potential exposures to attack are discussed in section 7 of the
+      DHCP protocol specification [RFC 2131].
+
+7. IANA Considerations
+
+   RFC 2132 and RFC 2489 provided guidance to the IANA on the procedure
+   it should follow when assigning option numbers for new DHCP options
+   or message types.  This document updates and replaces those
+   instructions.  In particular, IANA is requested to assign DHCP option
+   codes or message type codes only for options or message types that
+   have been approved for publication as RFCs; i.e., documents that have
+   been approved through "IETF consensus" as defined in RFC 2434 [4].
+
+
+
+
+
+
+
+Droms                    Best Current Practice                  [Page 5]
+
+RFC 2939            Procedures for New DHCP Options       September 2000
+
+
+8. Author's Address
+
+   Ralph Droms
+   Computer Science Department
+   323 Dana Engineering
+   Bucknell University
+   Lewisburg, PA 17837
+
+   Phone: (570) 524-1145
+   EMail: droms@bucknell.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms                    Best Current Practice                  [Page 6]
+
+RFC 2939            Procedures for New DHCP Options       September 2000
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms                    Best Current Practice                  [Page 7]
+