GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:bcp:bcp82

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]

/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp82.txt · Last modified: 2004/01/27 18:42 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki