RFC 3692 (rfc3692) - Page 2 of 7
Assigning Experimental and Testing Numbers Considered Useful
Alternative Format: Original Text Document
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