RFC 3692 (rfc3692) - Page 2 of 7

Assigning Experimental and Testing Numbers Considered Useful

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 [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 (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" [RFC 2434], 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