idnits 2.17.1 draft-bradner-iana-allocation-02.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 1999) is 8959 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) ** Obsolete normative reference: RFC 758 (ref. 'AN80') (Obsoleted by RFC 762) ** Obsolete normative reference: RFC 2434 (ref. 'CONS') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2481 (ref. 'ECN') (Obsoleted by RFC 3168) ** Downref: Normative reference to an Informational RFC: RFC 2375 (ref. 'MASGN') ** Obsolete normative reference: RFC 988 (ref. 'MULT') (Obsoleted by RFC 1054, RFC 1112) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (ref. 'V6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2373 (ref. 'V6AD') (Obsoleted by RFC 3513) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Scott Bradner 2 Internet-Draft Harvard University 3 Vern Paxson 4 ACIRI 5 October 1999 7 IANA Allocation Guidelines For Values In 8 the Internet Protocol and Related Headers 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document will expire in February 2000. 35 Abstract 37 This memo provides guidance for the IANA to use in assigning 38 parameters for fields in the IPv4, TCP, UDP, ICMP and IPv6 protocol 39 headers. 41 Copyright Notice 43 Copyright (C) The Internet Society (1999). All Rights Reserved. 45 1. Introduction 47 For many years the Internet Assigned Numbers Authority (IANA) 48 (www.iana.org) has allocated parameter values for fields in the 49 network protocols which have been created or are maintained by the 50 Internet Engineering Task Force (IETF). Starting a few years ago the 51 IETF began to provide the IANA with guidance for the assignment of 52 parameters for fields in newly developed protocols. Unfortunately 53 this type of guidance was not consistently provided for the fields in 54 protocols developed before 1998. This memo attempts to codify 55 existing IANA practice used in the assignment of parameters in the 56 specific case of some of these protocols. It is expected that 57 additional memos will be developed in the future to codify existing 58 practice in other cases. 60 This memo addresses the fields within the IPv4, TCP, UDP, ICMP and 61 IPv6 headers for which the IANA assigns values. 63 The terms "Specification Required", "Expert Review", "IESG Approval", 64 "IETF Consensus", and "Standards Action", are used in this memo to 65 refer to the processes described in [CONS]. 67 2. Temporary Assignments 69 From time to time temporary assignments are made in the values for 70 fields in these headers for use in experiments. IESG Approval is 71 required for any such temporary assignments. 73 3. IANA Considerations for fields in the IPv4 header 75 The IPv4 header [V4] contains the following fields that carry values 76 assigned by the IANA: Version (by definition always 4 in IPv4), Type 77 of Service, Protocol, Source Address, Destination Address, and Option 78 Type. 80 3.1 IPv4 IP Version field 82 The IANA allocates values from the IP Version name space following 83 a Standards Action process. 85 3.2 IPv4 Type of Service field 87 The Type of Service field described in [V4] has been superceded 88 [DIFF] by the 6-bit Differentiated Services (DS) field and a 2-bit 89 "currently unused" field. The IANA allocates values in the DS 90 field following the IANA Considerations section in [DIFF]. [ECN] 91 describes an experimental use of the 2-bit "currently unused" 92 field. Other experimental uses of this field are assigned after 93 IESG Approval processes. Permanent values in this field are 94 allocated following a Standards Action process. 96 3.3 IPv4 Protocol field 98 IANA allocates values from the IPv4 Protocol name space following 99 an Expert Review, IESG Approval or Standards Action process. The 100 Expert Review process should only be used in those special cases 101 where non-disclosure information is involved. In these cases the 102 expert should be designated by the IESG. 104 3.4 IPv4 Source and Destination addresses 106 The IPv4 source and destination addresses use the same values. 107 These values fall into a number of ranges defined in [V4] and 108 [MULT]. 110 3.4.1 IPv4 Unicast addresses 112 The Internet Corporation for Assigned Names and Numbers (ICANN) 113 recently accepted responsibility for the formulation of 114 specific guidelines for the allocation of the values from the 115 IPv4 unicast address space (values 0.0.0.0 through 116 223.255.255.255 ) other than values from the ranges 0/8 (which 117 was reserved in [AN80]) and 127/8 (from which the loopback 118 address has been taken) along with other values already 119 assigned by the IETF for special functions or purposes. (For 120 example, the private addresses defined in RFC 1918.) Further 121 assignments in the 0/8 and 127/8 ranges require a Standards 122 Action process since current IP implementations may break if 123 this is done. 125 3.4.2 IPv4 Multicast addresses 127 IPv4 addresses that fall in the range from 224.0.0.0 through 128 239.255.255.255 are known as multicast addresses. The IETF has 129 assigned a number of IPv4 multicast addresses for special 130 purposes. For example, the values in the range from 224.0.0.0 131 to 224.0.0.255 , inclusive, are reserved for the use of routing 132 protocols and other low-level topology discovery or maintenance 133 protocols, such as gateway discovery and group membership 134 reporting. (See the IANA web page) New values in this range are 135 assigned following an IESG Approval or Standards Action 136 process. Assignments of individual multicast address follow an 137 Expert Review, IESG Approval or Standards Action process. 138 Until further work is done on multicast protocols large-scale 139 assignments of IPv4 multicast addresses is not recommended. 141 3.4.3 IPv4 Reserved addresses 143 IPv4 addresses in the range from 240.0.0.0 through 144 247.255.255.255 are reserved [MULT] and compliant IPv4 145 implementations will discard any packets that make use of them. 146 Addresses in this range are not to be assigned unless an IETF 147 Standards Action modifies the IPv4 protocol in such a way as to 148 make these addresses valid. 150 3.5 IPv4 Option Type field 152 The IANA allocates values from the IPv4 Option Type name space 153 following an IESG Approval, IETF Consensus or Standards Action 154 process. 156 4. IANA Considerations for fields in the IPv6 header 158 The IPv6 header [V6] contains the following fields that carry values 159 assigned from IANA-managed name spaces: Version (by definition always 160 6 in IPv6), Traffic Class, Next Header, Source and Destination 161 Address. In addition, the IPv6 Hop-by-Hop Options and Destination 162 Options extension headers include an Option Type field with values 163 assigned from an IANA-managed name space. 165 4.1 IPv6 Version field 167 The Version field in the IPv6 header uses the same name space as 168 the Version field in the IPv4 header. Values in this field are 169 allocated as described in Section 3.1. 171 4.2 IPv6 Traffic Class field 173 The IPv6 Traffic Class uses the same namespace as the IPv4 6-bit 174 DS field and 2-bit unused field. Values in these fields are 175 allocated as described in Section 3.2. 177 4.3 IPv6 Next Header field 179 The IPv6 Next Header field carries values from the same name space 180 as the IPv4 Protocol name space. These values are allocated as 181 discussed in Section 3.3. 183 4.4 IPv6 Source and Destination Unicast Addresses 185 The IPv6 Source and Destination address fields both use the same 186 values and are described in [V6AD]. The addresses are divided 187 into ranges defined by a variable length Format Prefix (FP). 189 4.4.1 IPv4 Aggregatable Global Unicast Addresses 191 The Internet Corporation for Assigned Names and Numbers (ICANN) 192 recently accepted responsibility for the formulation of 193 specific guidelines for the assignment of values in the 194 Aggregatable Global Unicast Addresses FP (FP 001). 196 4.4.2 IPv6 Anycast Addresses 198 IPv6 anycast addresses are defined in [V6AD]. Anycast 199 addresses are allocated from the unicast address space and 200 anycast addresses are syntactically indistinguishable from 201 unicast addresses. Assignment of IPv6 Anycast addresses 202 follows the process used for IPv6 Aggregatable Global Unicast 203 Addresses. (section 4.4) 205 4.4.3 IPv6 Multicast Addresses 207 IPv6 multicast addresses are defined in [V6AD]. They are 208 identified by a FP of 0xFF. Assignment guidelines for IPv6 209 multicast addresses are described in [MASGN]. 211 4.4.4 IPv6 Unassigned and Reserved IPv6 Format Prefixes 213 The responsibility for assigning values in each of the 214 "unassigned" and "reserved" Format Prefixes is delegated by 215 IESG Approval or Standards Action processes since the 216 processing rules for these Format Prefixes have not been 217 defined. 219 4.5 IPv6 Hop-by-Hop and Destination Option Fields 221 Values for the IPv6 Hop-by-Hop Options and Destination Options 222 fields are allocated using an IESG Approval, IETF Consensus or 223 Standards Action processes. 225 5. IANA Considerations for fields in the ICMP header 227 The ICMP header [ICMP] contains the following fields that carry 228 values assigned from IANA-managed name spaces: Type and Code. 230 Values for the ICMP Type and Code fields are allocated using an IESG 231 Approval or Standards Action processes. 233 6. IANA Considerations for fields in the UDP header 235 The UDP header [UDP] contains the following fields that carry values 236 assigned from IANA-managed name spaces: Source and Destination Port. 238 Both the Source and Destination Port fields use the same namespace. 239 Values in this namespace are assigned following a Specification 240 Required, Expert Review, IESG Approval, IETF Consensus, or Standards 241 Action process. Note that some assignments may involve non- 242 disclosure information. 244 7. IANA Considerations for fields in the TCP header 246 The TCP header [TCP] contains the following fields that carry values 247 assigned from IANA-managed name spaces: Source and Destination Port, 248 Reserved Bits, and Option Kind. 250 7.1 TCP Source and Destination Port fields 252 Both the Source and Destination Port fields use the same 253 namespace. Values in this namespace are assigned following a 254 Specification Required, Expert Review, IESG Approval, IETF 255 Consensus, or Standards Action process. Note that some 256 assignments may involve non-disclosure information. 258 7.2 Reserved Bits in TCP Header 260 The reserved bits in the TCP header are assigned following a 261 Standards Action process. 263 7.3 TCP Option Kind field 265 Values in the Option Kind field are assigned following an IESG 266 Approval or Standards Action process. 268 8. Security Considerations 270 Security analyzers such as firewalls and network intrusion detection 271 monitors often rely on unambiguous interpretations of the fields 272 described in this memo. As new values for the fields are assigned, 273 existing security analyzers that do not understand the new values may 274 fail, resulting in either loss of connectivity if the analyzer 275 declines to forward the unrecognized traffic, or loss of security if 276 it does forward the traffic and the new values are used as part of an 277 attack. This vulnerability argues for high visibility (which the 278 Standards Action and IETF Consensus processes ensure) for the 279 assignments whenever possible. 281 9. References 283 [AN80] Postel, J., "Assigned numbers", RFC 758, August 1979 285 [CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 286 Considerations Section in RFCs", RFC 2434, October 1998. 288 [DIFF] Nichols, K., S. Blake, F. Baker, D. Black, " Definition of the 289 Differentiated Services Field (DS Field) in the IPv4 and IPv6 290 Headers", RFC 2474, December 1998. 292 [ECN] Ramakrishnan, K., S. Floyd, "A Proposal to add Explicit 293 Congestion Notification (ECN) to IP", RFC 2481, January 1999 295 [ICMP] Postel, J., "Internet Control Message Protocol", RFC 792, 296 September 1981. 298 [MASGN] Hinden, R., and S. Deering, "IPv6 Multicast Address 299 Assignments", RFC 2375, July 1998. 301 [MULT] Deering, S. E., "Host extensions for IP multicasting", RFC 302 988, July 1986 304 [TCP] Postel, J., "Transmission Control Protocol", RFC 793, September 305 1981. 307 [UDP] Postel, J., "User Datagram Protocol", RFC 768, August 1980. 309 [V4] Postel, J., "Internet Protocol", RFC 791, September, 1981. 311 [V6] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6) 312 Specification", RFC 2460, December 1998. 314 [V6AD] Hinden, R., S. Deering, "IP Version 6 Addressing 315 Architecture", RFC 2373, July 1998 317 10. Author's Addressees 319 Scott Bradner 320 Harvard University 321 Cambridge MA - USA 322 02138 324 sob@harvard.edu 325 +1 617 495 3864 326 Vern Paxson 327 ACIRI / ICSI 328 1947 Center Street, Suite 600 329 Berkeley, CA - USA 330 94704-1198 332 vern@aciri.org 333 +1 510/642-4274 x302 335 Full Copyright Statement 337 Copyright (C) The Internet Society (1999). All Rights Reserved. 339 This document and translations of it may be copied and furnished to 340 others, and derivative works that comment on or otherwise explain it 341 or assist in its implementation may be prepared, copied, published 342 and distributed, in whole or in part, without restriction of any 343 kind, provided that the above copyright notice and this paragraph are 344 included on all such copies and derivative works. However, this 345 document itself may not be modified in any way, such as by removing 346 the copyright notice or references to the Internet Society or other 347 Internet organizations, except as needed for the purpose of 348 developing Internet standards in which case the procedures for 349 copyrights defined in the Internet Standards process must be 350 followed, or as required to translate it into languages other than 351 English. 353 The limited permissions granted above are perpetual and will not be 354 revoked by the Internet Society or its successors or assigns. 356 This document and the information contained herein is provided on an 357 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 358 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 359 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 360 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 361 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.