idnits 2.17.1 draft-narten-ipv6-iana-considerations-00.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 22, 2002) is 7856 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: 'V6' is mentioned on line 78, but not defined == Missing Reference: 'IPv4' is mentioned on line 93, but not defined == Missing Reference: 'IPV6' is mentioned on line 149, but not defined == Missing Reference: 'RFC 2780' is mentioned on line 102, but not defined == Unused Reference: 'IPV4' is defined on line 256, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CONS' == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-icmp-v3-02 -- Possible downref: Normative reference to a draft: ref. 'ICMPV6' ** Downref: Normative reference to an Informational RFC: RFC 1881 (ref. 'V6AA') ** Downref: Normative reference to an Informational RFC: RFC 2928 (ref. 'V6SUBTLA') -- Obsolete informational reference (is this intentional?): RFC 1825 (ref. 'IPSEC') (Obsoleted by RFC 2401) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. 'NDV6') (Obsoleted by RFC 4861) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Thomas Narten 2 IBM 3 October 22, 2002 5 IANA Allocation Guidelines for Values in IPv6 and Related Headers 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 This document provides guidelines to IANA on the procedures for 32 assigning values for various IPv6-related fields. This document 33 updates and replaces the IPv6-related guidelines in RFC 2780. 35 Contents 37 Status of this Memo.......................................... 1 39 1. Introduction............................................. 2 41 2. IANA Considerations for fields in the IPv6 header........ 2 42 2.1. IPv6 Version field.................................. 2 43 2.2. IPv6 Traffic Class field............................ 3 44 2.3. IPv6 Next Header field.............................. 3 45 2.4. IPv6 Source and Destination Unicast Addresses....... 3 46 2.5. IPv6 Global Unicast Addresses....................... 3 47 2.6. IPv6 Anycast Addresses.............................. 3 48 2.7. IPv6 Unassigned and Reserved IPv6 Address Ranges.... 4 49 2.8. IPv6 Multicast Addresses............................ 4 50 2.9. IPv6 Hop-by-Hop and Destination Option Fields....... 4 51 2.10. ICMPv6............................................. 4 52 2.10.1. IPv6 Neighbor Discovery Fields................ 5 54 3. IANA Considerations...................................... 5 56 4. Security Considerations.................................. 5 58 5. Acknowledgments.......................................... 5 60 6. Normative References..................................... 5 62 7. Informative References................................... 6 64 1. Introduction 66 IANA allocation guidelines for the assignment of values in IPv6 67 header fields were originally defined in RFC 2780 [RFC2780]. This 68 document revises and updates the IPv6 aspects of RFC 2780, taking 69 into account updates to existing IPv6 documents as well as the 70 creation of new ones that have taken place since RFC 2780 was issued. 72 The terms "Specification Required", "Expert Review", "IESG Approval", 73 "IETF Consensus", and "Standards Action", are used in this memo to 74 refer to the processes described in [CONS]. 76 2. IANA Considerations for fields in the IPv6 header 78 The IPv6 header [V6] contains the following fields that carry values 79 assigned from IANA-managed name spaces: Version (by definition always 80 6 in IPv6), Traffic Class, Next Header, Source and Destination 81 Address. In addition, the IPv6 Hop-by-Hop Options and Destination 82 Options extension headers include an Option Type field with values 83 assigned from an IANA-managed name space. 85 2.1. IPv6 Version field 87 The IPv6 Version field is always 6. 89 2.2. IPv6 Traffic Class field 91 The IPv6 Traffic Class field is a 6-bit Differentiated Services field 92 (DSField) as defined in [DIFF,DIFF2] and a 2-bit field as defined in 93 RFC 3168 [ECN]. The IPv4 Type-of-Service (TOS) field [IPv4] and the 94 IPv6 traffic class field [IPV6] are now defined to have identical 95 meanings and there are no IPv6-specific IANA considerations for these 96 fields. 98 2.3. IPv6 Next Header field 100 The IPv6 Next Header field carries values from the same name space as 101 the IPv4 Protocol name space. These values are allocated as discussed 102 in Section 4.3 of [RFC 2780]. 104 2.4. IPv6 Source and Destination Unicast Addresses 106 The IPv6 Source and Destination address fields both use the same 107 values and are described in [V6AD]. All addresses except those 108 specifically assigned for other uses are treated as global unicast 109 addresses. 111 In some cases, it is necessary to assign IPv6 address space for 112 purposes other than the assignment of globally unique address space 113 to physical devices. Examples of such assignments include IPv6 114 mapped addresses, multicast address ranges, link-local addresses, 115 anycast subnet addresses, etc. Assignments for such purposes are 116 made following a Standards Action or IESG Approval. 118 2.5. IPv6 Global Unicast Addresses 120 The IANA was given responsibility for all IPv6 address space by the 121 IAB in [V6AA]. The IANA, in turn, further delegates allocation of 122 address space to the Regional Internet Registries (e.g., APNIC, ARIN, 123 and RIPE) [V6SUBTLA]. At present, IANA has been asked to restrict 124 its allocation of global addresses space to that starting with a 125 binary value of 001 [V6AA] (i.e., roughly 1/8th of the total). 127 2.6. IPv6 Anycast Addresses 129 IPv6 anycast addresses are defined in [V6AD]. Anycast addresses are 130 allocated from the unicast address space and are syntactically 131 indistinguishable from unicast addresses. Assignment of IPv6 Anycast 132 subnet addresses follow the process described in [V6SUB]. Assignment 133 of other IPv6 Anycast addresses follows the process defined in 134 section 2.4 above. 136 2.7. IPv6 Unassigned and Reserved IPv6 Address Ranges 138 The assignment of values in each of the "unassigned" and "reserved" 139 Address Ranges requires IESG Approval or Standards Action processes. 141 2.8. IPv6 Multicast Addresses 143 IPv6 multicast addresses are defined in [V6AD]. Guidelines for 144 assigning IPv6 multicast addresses are described in [RFC3306] 146 2.9. IPv6 Hop-by-Hop and Destination Option Fields 148 8-bit IPv6 Hop-by-Hop Option and Destination Option types consist of 149 three components [IPV6]: 151 act - a 2-bit action type defining how the option is to be 152 processed if it is not understood. 154 chg - a 1-bit indication of whether or not the value of the option 155 when it reaches its destination can be predicted. The IPsec 156 Authentication Header (AH) [IPSEC] uses this bit to determine 157 whether an option should be included in its message intergrity 158 checks. 160 rest - the rest of the option 162 Values for the IPv6 Hop-by-Hop Options and Destination Options fields 163 are allocated through an IESG Approval, IETF Consensus or Standards 164 Action process. Note that the requestor of an option must specify the 165 value for the "act" and "chg" portions of the option type value; IANA 166 assigns a unique value for "rest". 168 2.10. ICMPv6 170 The assignment of ICMPv6 values is defined in [ICMPV6]. (XXX text is 171 not in that ID yet, it also needs to talk about split between error 172 and info messages). 174 2.10.1. IPv6 Neighbor Discovery Fields 176 IPv6 Neighbor Discovery messages [NDV6] are ICMPv6 messages using 177 type values 133-137. At present, all Neighbor Discovery messages use 178 a Code value of 0. Assignment of type values require a Standards 179 Action. 181 Some IPv6 Neighbor Discovery messages carry optional Neighbor 182 Discovery Option fields [NDV6], which consist of type-length-value 183 triples. Additional Neighbor Discovery Option Type values are 184 assigned following Standards Action or IESG Approval. 186 3. IANA Considerations 188 This document clarifies the IANA considerations for a number of 189 IPv6-related protocols. 191 In addition, experience with IPv4 has shown that it is useful to 192 reserve an address block for documentation purposes that will never 193 be assigned for actual use in a network [DOC]. Such addresses can 194 safely be used in documentation, without the worry that someone will 195 accidentally (and incorrectly) configure them on a real network and 196 cause traffic intended for the legitimate owner of those addresses to 197 be impacted. 199 This document reserves the IPv6 address block XXXX::/32 for 200 documentation purposes. 202 4. Security Considerations 204 This document has no known security implications. 206 5. Acknowledgments 208 This document was started by copying text from RFC 2780 authored by 209 Scott Bradner and Vern Paxson. 211 6. Normative References 213 [RFC2780] IANA Allocation Guidelines For Values In the Internet 214 Protocol and Related Headers. S. Bradner, V. Paxson. March 215 2000, RFC 2780. 217 [CONS] Guidelines for Writing an IANA Considerations Section in RFCs. 219 T. Narten, H. Alvestrand. October 1998. RFC 2434. 221 [ICMPV6] draft-ietf-ipngwg-icmp-v3-02.txt 223 [V6AA] IAB, IESG, "IPv6 Address Allocation Management", RFC 1881, 224 December 1995. 226 [V6AD] Hinden, R. and S. Deering, draft-ietf-ipngwg-addr-arch- 227 v3-10.txt. 229 [V6SUB] Reserved IPv6 Subnet Anycast Addresses. D. Johnson, S. 230 Deering. March 1999. RFC 2526. 232 [V6SUBTLA] Initial IPv6 Sub-TLA ID Assignments. R. Hinden, S. 233 Deering, R. Fink, T. Hain. RFC 2928, September 2000. 235 [RFC3306] Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman, 236 D. Thaler. August 2002. RFC 3306. 238 7. Informative References 240 [DOC] draft-iana-special-ipv4-05.txt 242 [ECN] The Addition of Explicit Congestion Notification (ECN) to IP. 243 K. Ramakrishnan, S. Floyd, D. Black. September 2001. RFC 244 3168. 246 [DIFF] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of 247 the Differentiated Services Field (DS Field) in the IPv4 and 248 IPv6 Headers", RFC 2474, December 1998. 250 [DIFF2] New Terminology and Clarifications for Diffserv. D. Grossman. 251 April 2002. RFC 3260. 253 [IPSEC] 1825 Security Architecture for the Internet Protocol. R. 254 Atkinson. August 1995. RFC 1825. 256 [IPV4] Internet Protocol. J. Postel. Sep-01-1981. RFC 791. 258 [NDV6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 259 for IP Version 6 (IPv6)", RFC 2461, December 1998. 261 8. 262 Authors' Addresses 264 Thomas Narten 265 IBM Corporation 266 P.O. Box 12195 267 Research Triangle Park, NC 27709-2195 268 USA 270 Phone: +1 919 254 7798 271 EMail: narten@us.ibm.com