Assigning Experimental and Testing Numbers Considered Useful
RFC 3692
| Document | Type |
RFC - Best Current Practice
(January 2004; No errata)
Updates RFC 2434
Also known as BCP 82
Was draft-narten-iana-experimental-allocations (individual in ops area)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 3692 (Best Current Practice) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Harald Alvestrand | ||
| IESG note | Published as RFC 3692 | ||
| Send notices to | (None) | ||
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
Show full document text