INTERNET-DRAFT Thomas Narten <draft-narten-iana-experimental-allocations-01.txt> IBM June 14, 2002 Assigning Experimental and Testing Numbers Considered Useful <draft-narten-iana-experimental-allocations-01.txt> Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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. Contents Status of this Memo.......................................... 1 draft-narten-iana-experimental-allocations-01.txt [Page 1]
INTERNET-DRAFT June 14, 2002 1. Introduction............................................. 2 2. IANA Considerations...................................... 3 2.1. IP Protocol Field................................... 4 3. Security Considerations.................................. 4 4. Acknowledgments.......................................... 4 5. References............................................... 4 1. Introduction When experimenting with or extending protocols, it is often necessary to have a protocol number as part of the implementation [IANA- CONSIDERATIONS]. 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 for testing purposes (e.g., TCP and UDP port numbers). 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. 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" [IANA-CONSIDERATIONS], which requires that the proposed use be in an IETF Standards Track RFC. Restricting the assignment of numbers to protocols that enjoy broad support may well be prudent from the perspective of managing a name space, but can also stifle innovation by creating a chicken-and-egg situation with regards to new protocols. It may not be possible to test or experiment a new protocol without a number, but without a number there may be no way to experiment with and build support for the protocol. 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 draft-narten-iana-experimental-allocations-01.txt [Page 2]
INTERNET-DRAFT June 14, 2002 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. Numbers in the experimentation range are similar to those called "Private Use" in RFC 2434 [IANA-CONSIDERATIONS]. They are not intended to be used in products, unless the customer is required to explicitly enable a feature and likewise has the ability to chose and assign which number from the experimental range will be used for a specific purpose (i.e., so the customer can ensure that use of a particular number doesn't conflict with other on-going uses). Shipping a product with a specific value pre-enabled would be inappropriate. Once an extension has been tested and shown to be useful, a permanent number could be obtained through the normal assignment procedures. Most implementations will not do anything special with numbers assigned for testing purposes. In particular, unless a packet or other Protocol Data Unit (PDU) is specifically directed at a device, that device will not even look at the field while processing the PDU. For example, IP routers typically forward IP packets without regards to what Protocol Type they carry. In those cases where a packet or PDU is directed at a device, and that device has not been configured to recognize the extension, the device will either ignore the PDU, discard it, or signal an error, depending on the specifics of the protocol. In those cases where a protocol has different ways of handling unrecognized extensions (e.g., silently discard vs. signal an error), that protocol needs to assign values for testing purposes from the appropriate ranges. Only those implementations specifically enabled or configured to make use of an extension or feature that is being experimented with would process the data further. 2. IANA Considerations draft-narten-iana-experimental-allocations-01.txt [Page 3]
INTERNET-DRAFT June 14, 2002 2.1. IP Protocol Field Assignment of new values for the IP Protocol field requires an IETF Standards Action per [RFC 2780]. For the purposes of experimentation and testing, IANA has assigned the range of values TBD for this purpose [XXX 4 numbers suggested]. 3. Security Considerations This document has no known security implications. 4. Acknowledgments 5. References [RFC2780] IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers. S. Bradner, V. Paxson. March 2000, RFC 2780. [IANA-CONSIDERATIONS] Guidelines for Writing an IANA Considerations Section in RFCs. T. Narten, H. Alvestrand. October 1998. RFC 2434. 6. Authors' Addresses Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA Phone: +1 919 254 7798 EMail: narten@us.ibm.com draft-narten-iana-experimental-allocations-01.txt [Page 4]
