[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 rfc3692                                     
INTERNET-DRAFT                                             Thomas Narten
<draft-narten-iana-experimental-allocations-00.txt>                  IBM
                                                           July 13, 2001

       Assigning Experimental and Testing Numbers Considered Useful

            <draft-narten-iana-experimental-allocations-00.txt>


Status of this Memo
   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as work in progress.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

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, the 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.

   Contents

   Status of this Memo..........................................    1




draft-narten-iana-experimental-allocations-00.txt               [Page 1]


INTERNET-DRAFT                                             July 13, 2001


   1.  Introduction.............................................    2

   2.  IANA Considerations......................................    3
      2.1.  IP Protocol Field...................................    3

   3.  Security Considerations..................................    4

   4.  Acknowledgments..........................................    4

   5.  References...............................................    4


1.  Introduction

   When experimenting with or extending protocols, it is often necessary
   to have a protocol number as part of the implementation [RFC 2434].
   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 [RFC 791]. In some cases, obtaining a new number is
   straightforward (e.g., a well-known TCP or UDP port), or not even
   necessary for testing purposes (e.g., TCP and UDP port numbers). 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. 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" [IANA-CONSIDERATIONS], which requires that the proposed use
   be in an IETF Standards Track RFC.

   Restricting the assignment of numbers to protocols that enjoy broad
   support may well be prudent from the perspective of managing a name
   space, but can also stifle innovation by creating a chicken-and-egg
   situation with regards to new protocols. It may not be possible to
   test or experiment a new protocol without a number, but without a
   number there may be no way to experiment with and build support for
   the protocol.

   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 the is 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



draft-narten-iana-experimental-allocations-00.txt               [Page 2]


INTERNET-DRAFT                                             July 13, 2001


   part of a product), it becomes very difficult to determine whether
   reuse of that number would have no 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.

   Numbers in the experimentation range are similar to those called
   "Private Use" in RFC 2434. They are not intended to be used in
   products, unless the customer is required to explicitly enable a
   feature and likewise has the ability to chose and assign which number
   from the experimental range will be used for a specific purpose.
   Shipping a product with a specific value pre-enabled would be
   inappropriate. Once an extension has been tested and shown to be
   useful, a proper number would be assigned through the normal
   assignment procedure (i.e., through IANA).

   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 typically forward IP packets without regards
   to what Protocol Type they carry. 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 specifics of the
   protocol. 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 assign values for testing purposes
   from 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.


2.  IANA Considerations


2.1.  IP Protocol Field

   Assignment of new values for the IP Protocol field requires an IETF
   Standards Action per [RFC 2780]. For the purposes of experimentation
   and testing, IANA has assigned the range of values TBD for this



draft-narten-iana-experimental-allocations-00.txt               [Page 3]


INTERNET-DRAFT                                             July 13, 2001


   purpose [XXX 4 numbers suggested].


3.  Security Considerations
   This document has no known security implications.


4.  Acknowledgments


5.  References

   [RFC2780] IANA Allocation Guidelines For Values In the Internet
           Protocol and Related Headers. S. Bradner, V. Paxson. March
           2000, RFC 2780.

   [IANA-CONSIDERATIONS] Guidelines for Writing an IANA Considerations
           Section in RFCs. T. Narten, H. Alvestrand. October 1998. RFC
           2434.


6.
   Authors' Addresses

   Thomas Narten
   IBM Corporation
   P.O. Box 12195
   Research Triangle Park, NC 27709-2195
   USA

   Phone: +1 919 254 7798
   EMail: narten@raleigh.ibm.com



















draft-narten-iana-experimental-allocations-00.txt               [Page 4]