idnits 2.17.1 draft-narten-iana-experimental-allocations-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 14, 2002) is 7987 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 791' is mentioned on line 64, but not defined == Missing Reference: 'RFC 2780' is mentioned on line 139, but not defined == Unused Reference: 'RFC2780' is defined on line 151, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Thomas Narten 2 IBM 3 June 14, 2002 5 Assigning Experimental and Testing Numbers Considered Useful 7 9 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as work in progress. 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 When experimenting with or extending protocols, it is often necessary 32 to use some sort of protocol number or constant in order to actually 33 test or experiment with the new function, even when testing in a 34 closed environment. For example, to test a new DHCP option, one needs 35 an option number to identify the new function. This document 36 recommends that when writing IANA Considerations sections, authors 37 should consider assigning a small range of numbers for 38 experimentation purposes that implementers can use when testing 39 protocol extensions or other new features. This document reserves 40 some ranges of numbers for experimentation purposes in specific 41 protocols where the need to support experimentation has been 42 identified. 44 Contents 46 Status of this Memo.......................................... 1 47 1. Introduction............................................. 2 49 2. IANA Considerations...................................... 3 50 2.1. IP Protocol Field................................... 4 52 3. Security Considerations.................................. 4 54 4. Acknowledgments.......................................... 4 56 5. References............................................... 4 58 1. Introduction 60 When experimenting with or extending protocols, it is often necessary 61 to have a protocol number as part of the implementation [IANA- 62 CONSIDERATIONS]. For example, to develop a protocol that runs 63 directly above IP, one needs an IP Protocol Number to place in the 64 Protocol field of the IP header [RFC 791]. In some cases, obtaining a 65 new number is straightforward (e.g., a well-known TCP or UDP port), 66 or not even necessary for testing purposes (e.g., TCP and UDP port 67 numbers). In other cases, obtaining a number is more difficult. For 68 example, the number of available and unassigned values in a name 69 space may be small enough that there is concern that all available 70 numbers will be used up if assigned carelessly. Consequently, some 71 number spaces specify that IANA only make assignments in cases where 72 there is strong community support for a proposed protocol. For 73 example, values out of some name spaces are only assigned through an 74 "IETF Standards Action" [IANA-CONSIDERATIONS], which requires that 75 the proposed use be in an IETF Standards Track RFC. 77 Restricting the assignment of numbers to protocols that enjoy broad 78 support may well be prudent from the perspective of managing a name 79 space, but can also stifle innovation by creating a chicken-and-egg 80 situation with regards to new protocols. It may not be possible to 81 test or experiment a new protocol without a number, but without a 82 number there may be no way to experiment with and build support for 83 the protocol. 85 One approach is to allow IANA to make temporary assignments for such 86 purposes. The idea is that a protocol value can be assigned to allow 87 experimentation, but after the experiment ends, the number would be 88 returned to IANA. There are several drawbacks to this approach, 89 however. First, experience has shown that it can be difficult to 90 reclaim numbers once assigned. For example, contact information 91 becomes outdated and it can become difficult to find out what the 92 status of an experiment actually is. Second, should deployment with 93 the temporarily assigned number take place (e.g., it is included as 94 part of a product), it becomes very difficult to determine whether or 95 not reuse of that number would lead to adverse impact with regards to 96 deployed devices. Finally, it can be difficult to determine when an 97 experiment has ended and whether the number needs to be returned. 99 An alternate approach, and the one recommended in this document, is 100 to assign a range of numbers specifically earmarked for testing and 101 experimentation purposes. Mutually consenting devices could use these 102 numbers for whatever purposes they desire, but under the 103 understanding that they are reserved for generic testing purposes, 104 and other implementations may use the same numbers for different 105 experimental uses. 107 Numbers in the experimentation range are similar to those called 108 "Private Use" in RFC 2434 [IANA-CONSIDERATIONS]. They are not 109 intended to be used in products, unless the customer is required to 110 explicitly enable a feature and likewise has the ability to chose and 111 assign which number from the experimental range will be used for a 112 specific purpose (i.e., so the customer can ensure that use of a 113 particular number doesn't conflict with other on-going uses). 114 Shipping a product with a specific value pre-enabled would be 115 inappropriate. Once an extension has been tested and shown to be 116 useful, a permanent number could be obtained through the normal 117 assignment procedures. 119 Most implementations will not do anything special with numbers 120 assigned for testing purposes. In particular, unless a packet or 121 other Protocol Data Unit (PDU) is specifically directed at a device, 122 that device will not even look at the field while processing the PDU. 123 For example, IP routers typically forward IP packets without regards 124 to what Protocol Type they carry. In those cases where a packet or 125 PDU is directed at a device, and that device has not been configured 126 to recognize the extension, the device will either ignore the PDU, 127 discard it, or signal an error, depending on the specifics of the 128 protocol. In those cases where a protocol has different ways of 129 handling unrecognized extensions (e.g., silently discard vs. signal 130 an error), that protocol needs to assign values for testing purposes 131 from the appropriate ranges. Only those implementations specifically 132 enabled or configured to make use of an extension or feature that is 133 being experimented with would process the data further. 135 2. IANA Considerations 136 2.1. IP Protocol Field 138 Assignment of new values for the IP Protocol field requires an IETF 139 Standards Action per [RFC 2780]. For the purposes of experimentation 140 and testing, IANA has assigned the range of values TBD for this 141 purpose [XXX 4 numbers suggested]. 143 3. Security Considerations 145 This document has no known security implications. 147 4. Acknowledgments 149 5. References 151 [RFC2780] IANA Allocation Guidelines For Values In the Internet 152 Protocol and Related Headers. S. Bradner, V. Paxson. March 153 2000, RFC 2780. 155 [IANA-CONSIDERATIONS] Guidelines for Writing an IANA Considerations 156 Section in RFCs. T. Narten, H. Alvestrand. October 1998. RFC 157 2434. 159 6. 160 Authors' Addresses 162 Thomas Narten 163 IBM Corporation 164 P.O. Box 12195 165 Research Triangle Park, NC 27709-2195 166 USA 168 Phone: +1 919 254 7798 169 EMail: narten@us.ibm.com