idnits 2.17.1 draft-narten-iana-experimental-allocations-04.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 (October 7, 2003) is 7505 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: 'IANA-CONSIDERATIONS' is mentioned on line 108, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 2 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 October 7, 2003 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.................................. 5 54 4. Acknowledgments.......................................... 5 56 5. Normative References..................................... 5 58 6. Informative References................................... 5 60 1. Introduction 62 When experimenting with or extending protocols, it is often necessary 63 to have a protocol number as part of the implementation [IANA- 64 CONSIDERATIONS]. For example, to develop a protocol that runs 65 directly above IP, one needs an IP Protocol Number to place in the 66 Protocol field of the IP header [RFC791]. In some cases, obtaining a 67 new number is straightforward (e.g., a well-known TCP or UDP port) or 68 not even necessary (e.g., TCP and UDP port numbers for testing 69 purposes). In other cases, obtaining a number is more difficult. For 70 example, the number of available and unassigned values in a name 71 space may be small enough that there is concern that all available 72 numbers will be used up if assigned carelessly. Even in cases where 73 number are potentially plentiful, it may be desired that numbers not 74 be assigned unless the proposed usage has been adequately reviewed by 75 the broader community. Consequently, some number spaces specify that 76 IANA only make assignments in cases where there is strong community 77 support for a proposed protocol. For example, values out of some name 78 spaces are only assigned through an "IETF Standards Action" [IANA- 79 CONSIDERATIONS], which requires that the proposed use be in an IETF 80 Standards Track RFC. 82 In order to experiment with a new protocol, an experimental value may 83 be needed that won't collide with an existing or future usage. 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 general deployments or be enabled by default 110 in products or other general releases. In those cases where a product 111 or release makes use of an experimental number, the end user must be 112 required to explicitly enable the experimental feature and likewise 113 have the ability to chose and assign which number from the 114 experimental range will be used for a specific purpose (i.e., so the 115 end user can ensure that use of a particular number doesn't conflict 116 with other on-going uses). Shipping a product with a specific value 117 pre-enabled would be inappropriate and can lead to interoperability 118 problems when the chosen value collides with a different usage, as it 119 someday surely will. 121 From the above, it follows that it would be inappropriate for a group 122 of vendors, a consortia, or another Standards Development 123 Organization to agree among themselves to use a particular value for 124 a specific purpose and then agree to deploy devices using those 125 values. By definition, experimental numbers are not guaranteed to be 126 unique in any environment other than one where the the local system 127 administrator has chosen to use a particular number for a particular 128 purpose and can ensure that a particular value is not already in use 129 for some other purpose. 131 Once an extension has been tested and shown to be useful, a permanent 132 number could be obtained through the normal assignment procedures. 134 Most implementations will not do anything special with numbers 135 assigned for testing purposes. In particular, unless a packet or 136 other Protocol Data Unit (PDU) is specifically directed at a device, 137 that device will not even look at the field while processing the PDU. 138 For example, IP routers do not need to examine or understand the 139 Protocol Type field of IP datagrams in order to know how to correctly 140 forward them. In those cases where a packet or PDU is directed at a 141 device, and that device has not been configured to recognize the 142 extension, the device will either ignore the PDU, discard it, or 143 signal an error, depending on the protocol-specific rules that 144 indicate how to process unknown options or features. In those cases 145 where a protocol has different ways of handling unrecognized 146 extensions (e.g., silently discard vs. signal an error), that 147 protocol needs to reserve values for testing purposes from all the 148 appropriate ranges. Only those implementations specifically enabled 149 or configured to make use of an extension or feature that is being 150 experimented with would process the data further. 152 The exact number of values to reserve for experimentation will depend 153 on the specific protocol and factors specific to that protocol. For 154 example, in cases where the values of a field are subdivided into 155 ranges that are treated differently (e.g., "silently ignore" vs. 156 "return an error" if the value is not understood), one or more values 157 from each sub-range may need to be reserved. 159 In many, if not most cases, reserving a single value for experimental 160 use will suffice. While it may be tempting to reserve more in order 161 to make it easy to test many things at once, reserving many may also 162 increase the temptation for someone using a particular value to 163 assume that a specific experimental value can be used for a given 164 purpose exclusively. Values reserved for experimental use are never 165 to be made permanent; permanent assignments should be obtained 166 through standard processes. As described above, experimental numbers 167 are intended for experimentation and testing and are not intended for 168 wide or general deployments. 170 When protocols that use experimental numbers are included in 171 products, the shipping versions of the products must disable 172 recognition of protocol experimental numbers by default -- that is, 173 the end user of the product must explicitly "turn on" the 174 experimental protocol functionality. In most cases, a product 175 implementation must require the end user to configure the value 176 explicitly prior to enabling its usage. Should a product not have a 177 user interface for such end user configuration, the product must 178 require explicit re-programming (e.g. a special firmware download, or 179 installation of a feature card) to configure the experimental 180 number(s) of the protocol(s) implicitly. 182 2. IANA Considerations 184 2.1. IP Protocol Field 186 Assignment of new values for the IP Protocol field requires an IETF 187 Standards Action per [RFC2780]. For the purposes of experimentation 188 and testing, IANA has assigned the two values TBD1 and TBD2 for this 189 purpose. These values have been allocated from the upper end of the 190 available number space in order to make them easy to identify by 191 having them stand out relative to the existing assignments that have 192 been made. 194 Existing Name Spaces 196 Numerous name spaces exist for which no values have been reserved for 197 experimentation or testing purpose. Experimental values for such 198 protocols can of course be assigned through the normal process of 199 publishing an RFC that documents the details of such an allocation. 200 To simplify the process in those cases where the publication of a 201 documentation just for the purpose of assigning an experimental 202 allocation seems overkill, experimental values can be made through 203 IESG Approval [RFC2434]. 205 3. Security Considerations 207 This document has no known security implications. 209 4. Acknowledgments 211 Improvements to this document came as a result of specific feedback 212 from Steve Bellovin, Scott Bradner, Bill Fenner, Steve Hanna, Paul 213 Hoffman, John Loughney, Richard Woundy. 215 5. Normative References 217 [RFC2780] IANA Allocation Guidelines For Values In the Internet 218 Protocol and Related Headers. S. Bradner, V. Paxson. March 219 2000, RFC 2780. 221 [RFC2434] Guidelines for Writing an IANA Considerations Section in 222 RFCs. T. Narten, H. Alvestrand. October 1998. RFC 2434. 224 6. Informative References 226 [RFC791] Internet Protocol. J. Postel. September, 1981. RFC 791. 228 7. 229 Authors' Addresses 231 Thomas Narten 232 IBM Corporation 233 P.O. Box 12195 234 Research Triangle Park, NC 27709-2195 235 USA 237 Phone: +1 919 254 7798 238 EMail: narten@us.ibm.com