idnits 2.17.1 draft-bradner-iana-allocation-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 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 (January 2000) is 8867 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 790 (ref. 'AN81') (Obsoleted by RFC 820) ** Obsolete normative reference: RFC 2434 (ref. 'CONS') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2481 (ref. 'ECN') (Obsoleted by RFC 3168) ** Obsolete normative reference: RFC 2463 (ref. 'ICMPV6') (Obsoleted by RFC 4443) ** 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 2461 (ref. 'NDV6') (Obsoleted by RFC 4861) ** 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: 15 errors (**), 0 flaws (~~), 4 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 January 2000 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 July 2000. 35 Abstract 37 This memo provides guidance for the IANA to use in assigning 38 parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol 39 headers. 41 Copyright Notice 43 Copyright (C) The Internet Society (2000). 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 protocols 49 which have been created or are maintained by the Internet Engineering 50 Task Force (IETF). Starting a few years ago the IETF began to 51 provide the IANA with guidance for the assignment of parameters for 52 fields in newly developed protocols. Unfortunately this type of 53 guidance was not consistently provided for the fields in protocols 54 developed before 1998. This memo attempts to codify existing IANA 55 practice used in the assignment of parameters in the specific case of 56 some of these protocols. It is expected that additional memos will 57 be developed in the future to codify existing practice in other 58 cases. 60 This memo addresses the fields within the IPv4, IPv6, ICMP, UDP and 61 TCP protocol 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. Version field in the IP header. 75 The first field in the IP header of all current versions of IP is the 76 Version field. New values in the Version field define new versions 77 of the IP protocol and are allocated only after an IETF Standards 78 Action. 80 4. IANA Considerations for fields in the IPv4 header 82 The IPv4 header [V4] contains the following fields that carry values 83 assigned by the IANA: Version, Type of Service, Protocol, Source 84 Address, Destination Address, and Option Type. 86 4.1 IPv4 IP Version field 88 The IPv4 Version field is always 4. 90 4.2 IPv4 Type of Service field 92 The Type of Service field described in [V4] has been superceded 93 [DIFF] by the 6-bit Differentiated Services (DS) field and a 2-bit 94 field which is currently reserved. The IANA allocates values in 95 the DS field following the IANA Considerations section in [DIFF]. 96 [ECN] describes an experimental use of the 2-bit "currently 97 unused" field. Other experimental uses of this field may be 98 assigned after IESG Approval processes. Permanent values in this 99 field are allocated following a Standards Action process. 101 4.3 IPv4 Protocol field 103 IANA allocates values from the IPv4 Protocol name space following 104 an Expert Review, IESG Approval or Standards Action process. The 105 Expert Review process should only be used in those special cases 106 where non-disclosure information is involved. In these cases the 107 expert(s) should be designated by the IESG. 109 4.4 IPv4 Source and Destination addresses 111 The IPv4 source and destination addresses use the same namespace 112 but do not necessarily use the same values. Values in these 113 fields fall into a number of ranges defined in [V4] and [MULT]. 115 4.4.1 IPv4 Unicast addresses 117 The Internet Corporation for Assigned Names and Numbers (ICANN) 118 recently accepted responsibility for the formulation of 119 specific guidelines for the allocation of the values from the 120 IPv4 unicast address space (values 0.0.0.0 through 121 223.255.255.255 ) other than values from the ranges 0/8 (which 122 was reserved in [AN80]) and 127/8 (from which the loopback 123 address has been taken) along with other values already 124 assigned by the IETF for special functions or purposes. (For 125 example, the private addresses defined in RFC 1918.) Further 126 assignments in the 0/8 and 127/8 ranges require a Standards 127 Action process since current IP implementations may break if 128 this is done. 130 4.4.2 IPv4 Multicast addresses 132 IPv4 addresses that fall in the range from 224.0.0.0 through 133 239.255.255.255 are known as multicast addresses. The IETF has 134 assigned a number of IPv4 multicast addresses for special 135 purposes. For example, [ADSCP] assigned a number of IPv4 136 multicast address to correspond to IPv6 scoped multicast 137 addresses also, the values in the range from 224.0.0.0 to 138 224.0.0.255 , inclusive, are reserved by the IANA for the use 139 of routing protocols and other low-level topology discovery or 140 maintenance protocols, such as gateway discovery and group 141 membership reporting. (See the IANA web page) New values in 142 this range are assigned following an IESG Approval or Standards 143 Action process. Assignments of individual multicast address 144 follow an Expert Review, IESG Approval or Standards Action 145 process. Until further work is done on multicast protocols 146 large-scale assignments of IPv4 multicast addresses is not 147 recommended. 149 From time to time, there are requests for temporary assignment 150 of multicast space for experimental purposes. these will 151 originate in an IESG Approval process and should be for a 152 limited duration such as one year. 154 4.4.3 IPv4 Reserved addresses 156 IPv4 addresses in the range from 240.0.0.0 through 157 255.255.255.255 are reserved [AN81, MULT] and compliant IPv4 158 implementations will discard any packets that make use of them. 159 Addresses in this range are not to be assigned unless an IETF 160 Standards Action modifies the IPv4 protocol in such a way as to 161 make these addresses valid. 163 4.5 IPv4 Option Type field 165 The IANA allocates values from the IPv4 Option Type name space 166 following an IESG Approval, IETF Consensus or Standards Action 167 process. 169 5. IANA Considerations for fields in the IPv6 header 171 The IPv6 header [V6] contains the following fields that carry values 172 assigned from IANA-managed name spaces: Version (by definition always 173 6 in IPv6), Traffic Class, Next Header, Source and Destination 174 Address. In addition, the IPv6 Hop-by-Hop Options and Destination 175 Options extension headers include an Option Type field with values 176 assigned from an IANA-managed name space. 178 5.1 IPv6 Version field 180 The IPv6 Version field is always 6. 182 5.2 IPv6 Traffic Class field 184 The IPv6 Traffic Class field is described in [DIFF] as a 6-bit 185 Differentiated Services (DS) field and a 2-bit field which is 186 currently reserved. See Section 4.2 for assignment guidelines for 187 these fields. 189 5.3 IPv6 Next Header field 191 The IPv6 Next Header field carries values from the same name space 192 as the IPv4 Protocol name space. These values are allocated as 193 discussed in Section 4.3. 195 5.4 IPv6 Source and Destination Unicast Addresses 197 The IPv6 Source and Destination address fields both use the same 198 values and are described in [V6AD]. The addresses are divided 199 into ranges defined by a variable length Format Prefix (FP). 201 5.4.1 IPv6 Aggregatable Global Unicast Addresses 203 The IANA was given responsibility for all IPv6 address space by 204 the IAB in RFC 1881. Recently the IANA agreed to specific 205 guidelines for the assignment of values in the Aggregatable 206 Global Unicast Addresses FP (FP 001) formulated by the Regional 207 Internet Registries. 209 5.4.2 IPv6 Anycast Addresses 211 IPv6 anycast addresses are defined in [V6AD]. Anycast 212 addresses are allocated from the unicast address space and 213 anycast addresses are syntactically indistinguishable from 214 unicast addresses. Assignment of IPv6 Anycast subnet addresses 215 follows the process used described in [V6AD]. Assignment of 216 other IPv6 Anycast addresses follows the process used for IPv6 217 Aggregatable Global Unicast Addresses. (section 5.4.1) 219 5.4.3 IPv6 Multicast Addresses 221 IPv6 multicast addresses are defined in [V6AD]. They are 222 identified by a FP of 0xFF. Assignment guidelines for IPv6 223 multicast addresses are described in [MASGN]. 225 5.4.4 IPv6 Unassigned and Reserved IPv6 Format Prefixes 227 The responsibility for assigning values in each of the 228 "unassigned" and "reserved" Format Prefixes is delegated by 229 IESG Approval or Standards Action processes since the rules for 230 processing these Format Prefixes in IPv6 implementations have 231 not been defined. 233 5.5 IPv6 Hop-by-Hop and Destination Option Fields 235 Values for the IPv6 Hop-by-Hop Options and Destination Options 236 fields are allocated using an IESG Approval, IETF Consensus or 237 Standards Action processes. 239 5.6 IPv6 Neighbor Discovery Fields 241 The IPv6 Neighbor Discovery header [NDV6] contains the following 242 fields that carry values assigned from IANA-managed name spaces: 243 Type, Code and Option Type. 245 Values for the IPv6 Neighbor Discovery Type, Code, and Option Type 246 fields are allocated using an IESG Approval or Standards Action 247 process. 249 6. IANA Considerations for fields in the IPv4 ICMP header 251 The IPv4 ICMP header [ICMP] contains the following fields that carry 252 values assigned from IANA-managed name spaces: Type and Code. 254 Values for the IPv4 ICMP Type and Code fields are allocated using an 255 IESG Approval or Standards Action processes. 257 7. IANA Considerations for fields in the IPv6 ICMP header 259 The IPv6 ICMP header [ICMPV6] contains the following fields that 260 carry values assigned from IANA-managed name spaces: Type and Code. 262 Values for the IPv6 ICMP Type and Code fields are allocated using an 263 IESG Approval or Standards Action processes. 265 8. IANA Considerations for fields in the UDP header 267 The UDP header [UDP] contains the following fields that carry values 268 assigned from IANA-managed name spaces: Source and Destination Port. 270 Both the Source and Destination Port fields use the same namespace. 271 Values in this namespace are assigned following a Specification 272 Required, Expert Review, IESG Approval, IETF Consensus, or Standards 273 Action process. Note that some assignments may involve non- 274 disclosure information. 276 9. IANA Considerations for fields in the TCP header 277 The TCP header [TCP] contains the following fields that carry values 278 assigned from IANA-managed name spaces: Source and Destination Port, 279 Reserved Bits, and Option Kind. 281 9.1 TCP Source and Destination Port fields 283 Both the Source and Destination Port fields use the same 284 namespace. Values in this namespace are assigned following a 285 Specification Required, Expert Review, IESG Approval, IETF 286 Consensus, or Standards Action process. Note that some 287 assignments may involve non-disclosure information. 289 9.2 Reserved Bits in TCP Header 291 The reserved bits in the TCP header are assigned following a 292 Standards Action process. 294 9.3 TCP Option Kind field 296 Values in the Option Kind field are assigned following an IESG 297 Approval or Standards Action process. 299 10. Security Considerations 301 Security analyzers such as firewalls and network intrusion detection 302 monitors often rely on unambiguous interpretations of the fields 303 described in this memo. As new values for the fields are assigned, 304 existing security analyzers that do not understand the new values may 305 fail, resulting in either loss of connectivity if the analyzer 306 declines to forward the unrecognized traffic, or loss of security if 307 it does forward the traffic and the new values are used as part of an 308 attack. This vulnerability argues for high visibility (which the 309 Standards Action and IETF Consensus processes ensure) for the 310 assignments whenever possible. 312 11. References 314 [ADSCP] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, 315 July 1998 317 [AN80] Postel, J., "Assigned numbers", RFC 758, August 1979 319 [AN81] Postel, J., "Assigned numbers", RFC 790, September 1981 321 [CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 322 Considerations Section in RFCs", RFC 2434, October 1998. 324 [DIFF] Nichols, K., S. Blake, F. Baker, D. Black, "Definition of the 325 Differentiated Services Field (DS Field) in the IPv4 and IPv6 326 Headers", RFC 2474, December 1998. 328 [ECN] Ramakrishnan, K., S. Floyd, "A Proposal to add Explicit 329 Congestion Notification (ECN) to IP", RFC 2481, January 2000 331 [ICMP] Postel, J., "Internet Control Message Protocol", RFC 792, 332 September 1981. 334 [ICMPV6] Conta, A., S. Deering, "Internet Control Message Protocol 335 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463, 336 December 1998. 338 [MASGN] Hinden, R., and S. Deering, "IPv6 Multicast Address 339 Assignments", RFC 2375, July 1998. 341 [MULT] Deering, S. E., "Host extensions for IP multicasting", RFC 342 988, July 1986 344 [NDV6] Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery for 345 IP Version 6 (IPv6)", RFC 2461, December 1998. 347 [TCP] Postel, J., "Transmission Control Protocol", RFC 793, September 348 1981. 350 [UDP] Postel, J., "User Datagram Protocol", RFC 768, August 1980. 352 [V4] Postel, J., "Internet Protocol", RFC 791, September, 1981. 354 [V6] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6) 355 Specification", RFC 2460, December 1998. 357 [V6AD] Hinden, R., S. Deering, "IP Version 6 Addressing 358 Architecture", RFC 2373, July 1998 360 12. Author's Addresses 362 Scott Bradner 363 Harvard University 364 Cambridge MA - USA 365 02138 367 sob@harvard.edu 368 +1 617 495 3864 369 Vern Paxson 370 ACIRI / ICSI 371 1947 Center Street, Suite 600 372 Berkeley, CA - USA 373 94704-1198 375 vern@aciri.org 376 +1 510/642-4274 x302 378 Full Copyright Statement 380 Copyright (C) The Internet Society (2000). All Rights Reserved. 382 This document and translations of it may be copied and furnished to 383 others, and derivative works that comment on or otherwise explain it 384 or assist in its implementation may be prepared, copied, published 385 and distributed, in whole or in part, without restriction of any 386 kind, provided that the above copyright notice and this paragraph are 387 included on all such copies and derivative works. However, this 388 document itself may not be modified in any way, such as by removing 389 the copyright notice or references to the Internet Society or other 390 Internet organizations, except as needed for the purpose of 391 developing Internet standards in which case the procedures for 392 copyrights defined in the Internet Standards process must be 393 followed, or as required to translate it into languages other than 394 English. 396 The limited permissions granted above are perpetual and will not be 397 revoked by the Internet Society or its successors or assigns. 399 This document and the information contained herein is provided on an 400 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 401 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 402 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 403 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 404 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.