One document matched: draft-narten-iana-experimental-allocations-03.txt

Differences from draft-narten-iana-experimental-allocations-02.txt

INTERNET-DRAFT                                             Thomas Narten
<draft-narten-iana-experimental-allocations-03.txt>                  IBM
                                                       December 20, 2002

       Assigning Experimental and Testing Numbers Considered Useful

            <draft-narten-iana-experimental-allocations-03.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, 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.

   Contents

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




draft-narten-iana-experimental-allocations-03.txt               [Page 1]

INTERNET-DRAFT                                        December  20, 2002


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

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

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

   4.  Acknowledgments..........................................    5

   5.  Normative References.....................................    5


1.  Introduction

   When experimenting with or extending protocols, it is often necessary
   to have a protocol number as part of the implementation [IANA-
   CONSIDERATIONS]. 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.

   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.




draft-narten-iana-experimental-allocations-03.txt               [Page 2]

INTERNET-DRAFT                                        December  20, 2002


   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 [IANA-CONSIDERATIONS]. 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 (i.e., so the customer 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 amongst themselves to use a particular value
   for a specific purpose. By definition, experimental numbers are not
   guaranteed to be unique in any environment other than one where the
   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 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.



draft-narten-iana-experimental-allocations-03.txt               [Page 3]

INTERNET-DRAFT                                        December  20, 2002


   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.

   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, anyone making use of
   an experimental number should require the user or customer to
   explicitly configure the value prior to enabling its usage.


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 two values TBD1 and TBD2 for this
   purpose. These values have bee 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.

   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 [IANA-CONSIDERATIONS].


3.  Security Considerations

   This document has no known security implications.




draft-narten-iana-experimental-allocations-03.txt               [Page 4]

INTERNET-DRAFT                                        December  20, 2002


4.  Acknowledgments

   Improvements to this document came as a result of specific feedback
   from Bill Fenner, Steve Hanna, Paul Hoffman, John Loughney and IESG
   review.


5.  Normative 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@us.ibm.com






















draft-narten-iana-experimental-allocations-03.txt               [Page 5]