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)
|
|
---|---|---|---|
Author | Thomas Narten | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3692 (Best Current Practice) | |
Action Holders |
(None)
|
||
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 to assign a range of numbers specifically earmarked for testing and experimentation purposes. Mutually consenting devices could useShow full document text