idnits 2.17.1 draft-narten-iana-experimental-allocations-03.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 : ---------------------------------------------------------------------------- No issues found here. 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 (December 20, 2002) is 7797 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 166, but not defined == Unused Reference: 'RFC2780' is defined on line 196, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) Summary: 4 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 December 20, 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...................................... 4 50 2.1. IP Protocol Field................................... 4 52 3. Security Considerations.................................. 4 54 4. Acknowledgments.......................................... 5 56 5. Normative References..................................... 5 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 In order to experiment with a new protocol, an experimental value may 78 be needed that won't collide with an existing or future usage. 80 One approach is to allow IANA to make temporary assignments for such 81 purposes. The idea is that a protocol value can be assigned to allow 82 experimentation, but after the experiment ends, the number would be 83 returned to IANA. There are several drawbacks to this approach, 84 however. First, experience has shown that it can be difficult to 85 reclaim numbers once assigned. For example, contact information 86 becomes outdated and it can become difficult to find out what the 87 status of an experiment actually is. Second, should deployment with 88 the temporarily assigned number take place (e.g., it is included as 89 part of a product), it becomes very difficult to determine whether or 90 not reuse of that number would lead to adverse impact with regards to 91 deployed devices. Finally, it can be difficult to determine when an 92 experiment has ended and whether the number needs to be returned. 94 An alternate approach, and the one recommended in this document, is 95 to assign a range of numbers specifically earmarked for testing and 96 experimentation purposes. Mutually consenting devices could use these 97 numbers for whatever purposes they desire, but under the 98 understanding that they are reserved for generic testing purposes, 99 and other implementations may use the same numbers for different 100 experimental uses. 102 Numbers in the experimentation range are similar to those called 103 "Private Use" in RFC 2434 [IANA-CONSIDERATIONS]. They are not 104 intended to be used in products, unless the customer is required to 105 explicitly enable a feature and likewise has the ability to chose and 106 assign which number from the experimental range will be used for a 107 specific purpose (i.e., so the customer can ensure that use of a 108 particular number doesn't conflict with other on-going uses). 109 Shipping a product with a specific value pre-enabled would be 110 inappropriate and can lead to interoperability problems when the 111 chosen value collides with a different usage, as it someday surely 112 will. 114 From the above, it follows that it would be inappropriate for a group 115 of vendors, a consortia, or another Standards Development 116 Organization to agree amongst themselves to use a particular value 117 for a specific purpose. By definition, experimental numbers are not 118 guaranteed to be unique in any environment other than one where the 119 the local system administrator has chosen to use a particular number 120 for a particular purpose and can ensure that a particular value is 121 not already in use for some other purpose. 123 Once an extension has been tested and shown to be useful, a permanent 124 number could be obtained through the normal assignment procedures. 126 Most implementations will not do anything special with numbers 127 assigned for testing purposes. In particular, unless a packet or 128 other Protocol Data Unit (PDU) is specifically directed at a device, 129 that device will not even look at the field while processing the PDU. 130 For example, IP routers do not need to examine or understand the 131 Protocol Type field of IP datagrams in order to know how to correctly 132 forward them. In those cases where a packet or PDU is directed at a 133 device, and that device has not been configured to recognize the 134 extension, the device will either ignore the PDU, discard it, or 135 signal an error, depending on the specifics of the protocol. In those 136 cases where a protocol has different ways of handling unrecognized 137 extensions (e.g., silently discard vs. signal an error), that 138 protocol needs to assign values for testing purposes from the 139 appropriate ranges. Only those implementations specifically enabled 140 or configured to make use of an extension or feature that is being 141 experimented with would process the data further. 143 The exact number of values to reserve for experimentation will depend 144 on the specific protocol and factors specific to that protocol. For 145 example, in cases where the values of a field are subdivided into 146 ranges that are treated differently (e.g., "silently ignore" vs. 147 "return an error" if the value is not understood), one or more values 148 from each sub-range may need to be reserved. 150 In many, if not most cases, reserving a single value for experimental 151 use will suffice. While it may be tempting to reserve more in order 152 to make it easy to test many things at once, reserving many may also 153 increase the temptation for someone using a particular value to 154 assume that a specific experimental value can be used for a given 155 purpose exclusively. Values reserved for experimental use are never 156 to be made permanent; permanent assignments should be obtained 157 through standard processes. As described above, anyone making use of 158 an experimental number should require the user or customer to 159 explicitly configure the value prior to enabling its usage. 161 2. IANA Considerations 163 2.1. IP Protocol Field 165 Assignment of new values for the IP Protocol field requires an IETF 166 Standards Action per [RFC 2780]. For the purposes of experimentation 167 and testing, IANA has assigned the two values TBD1 and TBD2 for this 168 purpose. These values have bee allocated from the upper end of the 169 available number space in order to make them easy to identify by 170 having them stand out relative to the existing assignments that have 171 been made. 173 Existing Name Spaces 175 Numerous name spaces exist for which no values have been reserved for 176 experimentation or testing purpose. Experimental values for such 177 protocols can of course be assigned through the normal process of 178 publishing an RFC that documents the details of such an allocation. 179 To simplify the process in those cases where the publication of a 180 documentation just for the purpose of assigning an experimental 181 allocation seems overkill, experimental values can be made through 182 IESG Approval [IANA-CONSIDERATIONS]. 184 3. Security Considerations 186 This document has no known security implications. 188 4. Acknowledgments 190 Improvements to this document came as a result of specific feedback 191 from Bill Fenner, Steve Hanna, Paul Hoffman, John Loughney and IESG 192 review. 194 5. Normative References 196 [RFC2780] IANA Allocation Guidelines For Values In the Internet 197 Protocol and Related Headers. S. Bradner, V. Paxson. March 198 2000, RFC 2780. 200 [IANA-CONSIDERATIONS] Guidelines for Writing an IANA Considerations 201 Section in RFCs. T. Narten, H. Alvestrand. October 1998. RFC 202 2434. 204 6. 205 Authors' Addresses 207 Thomas Narten 208 IBM Corporation 209 P.O. Box 12195 210 Research Triangle Park, NC 27709-2195 211 USA 213 Phone: +1 919 254 7798 214 EMail: narten@us.ibm.com