Movatterモバイル変換

Network Working Group                                          T. NartenRequest for Comments: 3692                                           IBMBCP: 82                                                     January 2004Updates:2434Category: Best Current PracticeAssigning Experimental and Testing Numbers Considered UsefulStatus 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 Contents1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .21.1.  Recommendation for Protocols . . . . . . . . . . . . . .42.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .52.1.  IP Protocol Field. . . . . . . . . . . . . . . . . . . .52.2.  Existing Name Spaces . . . . . . . . . . . . . . . . . .53.  Security Considerations. . . . . . . . . . . . . . . . . . . .54.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .55.  References . . . . . . . . . . . . . . . . . . . . . . . . . .55.1.  Normative References . . . . . . . . . . . . . . . . . .55.2.  Informative References . . . . . . . . . . . . . . . . .66.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .67.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .7Narten                   Best Current Practice                  [Page 1]

RFC 3692       Assigning Experimental and Testing Numbers   January 20041.  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" inRFC 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 20041.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 20042.  IANA Considerations2.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.  References5.1.  Normative References   [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For             Values In the Internet Protocol and Related Headers",BCP37,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 20045.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.comNarten                   Best Current Practice                  [Page 6]

RFC 3692       Assigning Experimental and Testing Numbers   January 20047.  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]