1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc3692.txt b/doc/rfc/rfc3692.txt
new file mode 100644
index 0000000..c67d4e3
--- /dev/null
+++ b/doc/rfc/rfc3692.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                          T. Narten
+Request for Comments: 3692                                           IBM
+BCP: 82                                                     January 2004
+Updates: 2434
+Category: Best Current Practice
+
+
+      Assigning Experimental and Testing Numbers Considered Useful
+
+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 (2004).  All Rights Reserved.
+
+Abstract
+
+   When experimenting with or extending protocols, it is often necessary
+   to use some sort of protocol number or constant in order to actually
+   test or experiment with the new function, even when testing in a
+   closed environment.  For example, to test a new DHCP option, one
+   needs an option number to identify the new function.  This document
+   recommends that when writing IANA Considerations sections, authors
+   should consider assigning a small range of numbers for
+   experimentation purposes that implementers can use when testing
+   protocol extensions or other new features.  This document reserves
+   some ranges of numbers for experimentation purposes in specific
+   protocols where the need to support experimentation has been
+   identified.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+       1.1.  Recommendation for Protocols . . . . . . . . . . . . . .  4
+   2.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  5
+       2.1.  IP Protocol Field. . . . . . . . . . . . . . . . . . . .  5
+       2.2.  Existing Name Spaces . . . . . . . . . . . . . . . . . .  5
+   3.  Security Considerations. . . . . . . . . . . . . . . . . . . .  5
+   4.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  5
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+       5.1.  Normative References . . . . . . . . . . . . . . . . . .  5
+       5.2.  Informative References . . . . . . . . . . . . . . . . .  6
+   6.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
+   7.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  7
+
+
+
+Narten                   Best Current Practice                  [Page 1]
+
+RFC 3692       Assigning Experimental and Testing Numbers   January 2004
+
+
+1.  Introduction
+
+   When experimenting with or extending protocols, it is often necessary
+   to have a protocol number as part of the implementation [RFC2434].
+   For example, to develop a protocol that runs directly above IP, one
+   needs an IP Protocol Number to place in the Protocol field of the IP
+   header [RFC791].  In some cases, obtaining a new number is
+   straightforward (e.g., a well-known TCP or UDP port) or not even
+   necessary (e.g., TCP and UDP port numbers for testing purposes).  In
+   other cases, obtaining a number is more difficult.  For example, the
+   number of available and unassigned values in a name space may be
+   small enough that there is concern that all available numbers will be
+   used up if assigned carelessly.  Even in cases where numbers are
+   potentially plentiful, it may be undesirable to assign numbers unless
+   the proposed usage has been adequately reviewed by the broader
+   community.  Consequently, some number spaces specify that IANA only
+   make assignments in cases where there is strong community support for
+   a proposed protocol.  For example, values out of some name spaces are
+   only assigned through an "IETF Standards Action" [RFC2434], which
+   requires that the proposed use be in an IETF Standards Track RFC.
+
+   In order to experiment with a new protocol, an experimental value may
+   be needed that won't collide with an existing or future usage.
+
+   One approach is to allow IANA to make temporary assignments for such
+   purposes.  The idea is that a protocol value can be assigned to allow
+   experimentation, but after the experiment ends, the number would be
+   returned to IANA.  There are several drawbacks to this approach,
+   however.  First, experience has shown that it can be difficult to
+   reclaim numbers once assigned.  For example, contact information
+   becomes outdated and it can become difficult to find out what the
+   status of an experiment actually is.  Second, should deployment with
+   the temporarily assigned number take place (e.g., it is included as
+   part of a product), it becomes very difficult to determine whether or
+   not reuse of that number would lead to adverse impact with regards to
+   deployed devices.  Finally, it can be difficult to determine when an
+   experiment has ended and whether the number needs to be returned.
+
+   An alternate approach, and the one recommended in this document, is
+   to assign a range of numbers specifically earmarked for testing and
+   experimentation purposes.  Mutually consenting devices could use
+   these numbers for whatever purposes they desire, but under the
+   understanding that they are reserved for generic testing purposes,
+   and other implementations may use the same numbers for different
+   experimental uses.
+
+
+
+
+
+
+Narten                   Best Current Practice                  [Page 2]
+
+RFC 3692       Assigning Experimental and Testing Numbers   January 2004
+
+
+   Numbers in the experimentation range are similar to those called
+   "Private Use" in RFC 2434 [IANA-CONSIDERATIONS].  They are not
+   intended to be used in general deployments or be enabled by default
+   in products or other general releases.  In those cases where a
+   product or release makes use of an experimental number, the end user
+   must be required to explicitly enable the experimental feature and
+   likewise have the ability to chose and assign which number from the
+   experimental range will be used for a specific purpose (i.e., so the
+   end user can ensure that use of a particular number doesn't conflict
+   with other on-going uses).  Shipping a product with a specific value
+   pre-enabled would be inappropriate and can lead to interoperability
+   problems when the chosen value collides with a different usage, as it
+   someday surely will.
+
+   From the above, it follows that it would be inappropriate for a group
+   of vendors, a consortia, or another Standards Development
+   Organization to agree among themselves to use a particular value for
+   a specific purpose and then agree to deploy devices using those
+   values.  By definition, experimental numbers are not guaranteed to be
+   unique in any environment other than one where the local system
+   administrator has chosen to use a particular number for a particular
+   purpose and can ensure that a particular value is not already in use
+   for some other purpose.
+
+   Once an extension has been tested and shown to be useful, a permanent
+   number could be obtained through the normal assignment procedures.
+
+   Most implementations will not do anything special with numbers
+   assigned for testing purposes.  In particular, unless a packet or
+   other Protocol Data Unit (PDU) is specifically directed at a device,
+   that device will not even look at the field while processing the PDU.
+   For example, IP routers do not need to examine or understand the
+   Protocol Type field of IP datagrams in order to know how to correctly
+   forward them.  In those cases where a packet or PDU is directed at a
+   device, and that device has not been configured to recognize the
+   extension, the device will either ignore the PDU, discard it, or
+   signal an error, depending on the protocol-specific rules that
+   indicate how to process unknown options or features.  In those cases
+   where a protocol has different ways of handling unrecognized
+   extensions (e.g., silently discard vs. signal an error), that
+   protocol needs to reserve values for testing purposes from all the
+   appropriate ranges.  Only those implementations specifically enabled
+   or configured to make use of an extension or feature that is being
+   experimented with would process the data further.
+
+
+
+
+
+
+
+Narten                   Best Current Practice                  [Page 3]
+
+RFC 3692       Assigning Experimental and Testing Numbers   January 2004
+
+
+1.1.  Recommendation for Protocols
+
+   To make it possible to experiment with protocol extensions safely,
+   protocol documents should consider reserving a small set of protocol
+   numbers for experimentation.  Such reservations can be made through
+   an explicit reservation in an IANA Considerations section.
+
+   The exact number of values to reserve for experimentation will depend
+   on the specific protocol and factors specific to that protocol.  For
+   example, in cases where the values of a field are subdivided into
+   ranges that are treated differently (e.g., "silently ignore" vs.
+   "return an error" if the value is not understood), one or more values
+   from each sub-range may need to be reserved.
+
+   For protocols that return error codes, it may also be appropriate to
+   reserve a small number of experimental error values that can be used
+   in conjunction with possible experimental uses.  For example, an
+   experimental message might result (even under normal conditions) in
+   an error, with a special error code (or sub-code) indicating the type
+   of error condition.
+
+   In many, if not most cases, reserving a single value for experimental
+   use will suffice.  While it may be tempting to reserve more in order
+   to make it easy to test many things at once, reserving many may also
+   increase the temptation for someone using a particular value to
+   assume that a specific experimental value can be used for a given
+   purpose exclusively.  Values reserved for experimental use are never
+   to be made permanent; permanent assignments should be obtained
+   through standard processes.  As described above, experimental numbers
+   are intended for experimentation and testing and are not intended for
+   wide or general deployments.
+
+   When protocols that use experimental numbers are included in
+   products, the shipping versions of the products must disable
+   recognition of protocol experimental numbers by default -- that is,
+   the end user of the product must explicitly "turn on" the
+   experimental protocol functionality.  In most cases, a product
+   implementation must require the end user to configure the value
+   explicitly prior to enabling its usage.  Should a product not have a
+   user interface for such end user configuration, the product must
+   require explicit re-programming (e.g., a special firmware download,
+   or installation of a feature card) to configure the experimental
+   number(s) of the protocol(s) implicitly.
+
+
+
+
+
+
+
+
+Narten                   Best Current Practice                  [Page 4]
+
+RFC 3692       Assigning Experimental and Testing Numbers   January 2004
+
+
+2.  IANA Considerations
+
+2.1.  IP Protocol Field
+
+   Assignment of new values for the IP Protocol field requires an IETF
+   Standards Action per [RFC2780].  For the purposes of experimentation
+   and testing, IANA has assigned the two values 253 and 254 for this
+   purpose.  These values have been allocated from the upper end of the
+   available number space in order to make them easy to identify by
+   having them stand out relative to the existing assignments that have
+   been made.
+
+2.2.  Existing Name Spaces
+
+   Numerous name spaces exist for which no values have been reserved for
+   experimentation or testing purpose.  Experimental values for such
+   protocols can of course be assigned through the normal process of
+   publishing an RFC that documents the details of such an allocation.
+   To simplify the process in those cases where the publication of a
+   documentation just for the purpose of assigning an experimental
+   allocation seems overkill, experimental values can be made through
+   IESG Approval [RFC2434].
+
+3.  Security Considerations
+
+   This document has no known security implications.
+
+4.  Acknowledgments
+
+   Improvements to this document came as a result of specific feedback
+   from Steve Bellovin, Scott Bradner, Randy Bush, Bill Fenner, Steve
+   Hanna, Paul Hoffman, Henrik Levkowetz, John Loughney, Allison Mankin,
+   and Richard Woundy.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
+             Values In the Internet Protocol and Related Headers", BCP
+             37, RFC 2780, March 2000.
+
+   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+             October 1998.
+
+
+
+
+
+
+Narten                   Best Current Practice                  [Page 5]
+
+RFC 3692       Assigning Experimental and Testing Numbers   January 2004
+
+
+5.2.  Informative References
+
+   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
+             1981.
+
+6.  Author's Address
+
+   Thomas Narten
+   IBM Corporation
+   P.O. Box 12195
+   Research Triangle Park, NC 27709-2195
+   USA
+
+   Phone: +1 919 254 7798
+   EMail: narten@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Narten                   Best Current Practice                  [Page 6]
+
+RFC 3692       Assigning Experimental and Testing Numbers   January 2004
+
+
+7.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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 assignees.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Narten                   Best Current Practice                  [Page 7]
+