Assigning Experimental and Testing Numbers Considered Useful
RFC 3692

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

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