INTERNET-DRAFT Thomas Narten IBM October 22, 2002 IANA Allocation Guidelines for Values in IPv6 and Related Headers Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document provides guidelines to IANA on the procedures for assigning values for various IPv6-related fields. This document updates and replaces the IPv6-related guidelines in RFC 2780. Contents Status of this Memo.......................................... 1 1. Introduction............................................. 2 2. IANA Considerations for fields in the IPv6 header........ 2 2.1. IPv6 Version field.................................. 2 2.2. IPv6 Traffic Class field............................ 3 2.3. IPv6 Next Header field.............................. 3 2.4. IPv6 Source and Destination Unicast Addresses....... 3 2.5. IPv6 Global Unicast Addresses....................... 3 2.6. IPv6 Anycast Addresses.............................. 3 draft-narten-ipv6-iana-considerations-00.txt [Page 1] INTERNET-DRAFT October 22, 2002 2.7. IPv6 Unassigned and Reserved IPv6 Address Ranges.... 4 2.8. IPv6 Multicast Addresses............................ 4 2.9. IPv6 Hop-by-Hop and Destination Option Fields....... 4 2.10. ICMPv6............................................. 4 2.10.1. IPv6 Neighbor Discovery Fields................ 5 3. IANA Considerations...................................... 5 4. Security Considerations.................................. 5 5. Acknowledgments.......................................... 5 6. Normative References..................................... 5 7. Informative References................................... 6 1. Introduction IANA allocation guidelines for the assignment of values in IPv6 header fields were originally defined in RFC 2780 [RFC2780]. This document revises and updates the IPv6 aspects of RFC 2780, taking into account updates to existing IPv6 documents as well as the creation of new ones that have taken place since RFC 2780 was issued. The terms "Specification Required", "Expert Review", "IESG Approval", "IETF Consensus", and "Standards Action", are used in this memo to refer to the processes described in [CONS]. 2. IANA Considerations for fields in the IPv6 header The IPv6 header [V6] contains the following fields that carry values assigned from IANA-managed name spaces: Version (by definition always 6 in IPv6), Traffic Class, Next Header, Source and Destination Address. In addition, the IPv6 Hop-by-Hop Options and Destination Options extension headers include an Option Type field with values assigned from an IANA-managed name space. 2.1. IPv6 Version field The IPv6 Version field is always 6. draft-narten-ipv6-iana-considerations-00.txt [Page 2] INTERNET-DRAFT October 22, 2002 2.2. IPv6 Traffic Class field The IPv6 Traffic Class field is a 6-bit Differentiated Services field (DSField) as defined in [DIFF,DIFF2] and a 2-bit field as defined in RFC 3168 [ECN]. The IPv4 Type-of-Service (TOS) field [IPv4] and the IPv6 traffic class field [IPV6] are now defined to have identical meanings and there are no IPv6-specific IANA considerations for these fields. 2.3. IPv6 Next Header field The IPv6 Next Header field carries values from the same name space as the IPv4 Protocol name space. These values are allocated as discussed in Section 4.3 of [RFC 2780]. 2.4. IPv6 Source and Destination Unicast Addresses The IPv6 Source and Destination address fields both use the same values and are described in [V6AD]. All addresses except those specifically assigned for other uses are treated as global unicast addresses. In some cases, it is necessary to assign IPv6 address space for purposes other than the assignment of globally unique address space to physical devices. Examples of such assignments include IPv6 mapped addresses, multicast address ranges, link-local addresses, anycast subnet addresses, etc. Assignments for such purposes are made following a Standards Action or IESG Approval. 2.5. IPv6 Global Unicast Addresses The IANA was given responsibility for all IPv6 address space by the IAB in [V6AA]. The IANA, in turn, further delegates allocation of address space to the Regional Internet Registries (e.g., APNIC, ARIN, and RIPE) [V6SUBTLA]. At present, IANA has been asked to restrict its allocation of global addresses space to that starting with a binary value of 001 [V6AA] (i.e., roughly 1/8th of the total). 2.6. IPv6 Anycast Addresses IPv6 anycast addresses are defined in [V6AD]. Anycast addresses are allocated from the unicast address space and are syntactically indistinguishable from unicast addresses. Assignment of IPv6 Anycast subnet addresses follow the process described in [V6SUB]. Assignment draft-narten-ipv6-iana-considerations-00.txt [Page 3] INTERNET-DRAFT October 22, 2002 of other IPv6 Anycast addresses follows the process defined in section 2.4 above. 2.7. IPv6 Unassigned and Reserved IPv6 Address Ranges The assignment of values in each of the "unassigned" and "reserved" Address Ranges requires IESG Approval or Standards Action processes. 2.8. IPv6 Multicast Addresses IPv6 multicast addresses are defined in [V6AD]. Guidelines for assigning IPv6 multicast addresses are described in [RFC3306] 2.9. IPv6 Hop-by-Hop and Destination Option Fields 8-bit IPv6 Hop-by-Hop Option and Destination Option types consist of three components [IPV6]: act - a 2-bit action type defining how the option is to be processed if it is not understood. chg - a 1-bit indication of whether or not the value of the option when it reaches its destination can be predicted. The IPsec Authentication Header (AH) [IPSEC] uses this bit to determine whether an option should be included in its message intergrity checks. rest - the rest of the option Values for the IPv6 Hop-by-Hop Options and Destination Options fields are allocated through an IESG Approval, IETF Consensus or Standards Action process. Note that the requestor of an option must specify the value for the "act" and "chg" portions of the option type value; IANA assigns a unique value for "rest". 2.10. ICMPv6 The assignment of ICMPv6 values is defined in [ICMPV6]. (XXX text is not in that ID yet, it also needs to talk about split between error and info messages). draft-narten-ipv6-iana-considerations-00.txt [Page 4] INTERNET-DRAFT October 22, 2002 2.10.1. IPv6 Neighbor Discovery Fields IPv6 Neighbor Discovery messages [NDV6] are ICMPv6 messages using type values 133-137. At present, all Neighbor Discovery messages use a Code value of 0. Assignment of type values require a Standards Action. Some IPv6 Neighbor Discovery messages carry optional Neighbor Discovery Option fields [NDV6], which consist of type-length-value triples. Additional Neighbor Discovery Option Type values are assigned following Standards Action or IESG Approval. 3. IANA Considerations This document clarifies the IANA considerations for a number of IPv6-related protocols. In addition, experience with IPv4 has shown that it is useful to reserve an address block for documentation purposes that will never be assigned for actual use in a network [DOC]. Such addresses can safely be used in documentation, without the worry that someone will accidentally (and incorrectly) configure them on a real network and cause traffic intended for the legitimate owner of those addresses to be impacted. This document reserves the IPv6 address block XXXX::/32 for documentation purposes. 4. Security Considerations This document has no known security implications. 5. Acknowledgments This document was started by copying text from RFC 2780 authored by Scott Bradner and Vern Paxson. 6. Normative References [RFC2780] IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers. S. Bradner, V. Paxson. March 2000, RFC 2780. [CONS] Guidelines for Writing an IANA Considerations Section in RFCs. draft-narten-ipv6-iana-considerations-00.txt [Page 5] INTERNET-DRAFT October 22, 2002 T. Narten, H. Alvestrand. October 1998. RFC 2434. [ICMPV6] draft-ietf-ipngwg-icmp-v3-02.txt [V6AA] IAB, IESG, "IPv6 Address Allocation Management", RFC 1881, December 1995. [V6AD] Hinden, R. and S. Deering, draft-ietf-ipngwg-addr-arch- v3-10.txt. [V6SUB] Reserved IPv6 Subnet Anycast Addresses. D. Johnson, S. Deering. March 1999. RFC 2526. [V6SUBTLA] Initial IPv6 Sub-TLA ID Assignments. R. Hinden, S. Deering, R. Fink, T. Hain. RFC 2928, September 2000. [RFC3306] Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman, D. Thaler. August 2002. RFC 3306. 7. Informative References [DOC] draft-iana-special-ipv4-05.txt [ECN] The Addition of Explicit Congestion Notification (ECN) to IP. K. Ramakrishnan, S. Floyd, D. Black. September 2001. RFC 3168. [DIFF] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [DIFF2] New Terminology and Clarifications for Diffserv. D. Grossman. April 2002. RFC 3260. [IPSEC] 1825 Security Architecture for the Internet Protocol. R. Atkinson. August 1995. RFC 1825. [IPV4] Internet Protocol. J. Postel. Sep-01-1981. RFC 791. [NDV6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. draft-narten-ipv6-iana-considerations-00.txt [Page 6] INTERNET-DRAFT October 22, 2002 8. Authors' Addresses Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA Phone: +1 919 254 7798 EMail: narten@us.ibm.com draft-narten-ipv6-iana-considerations-00.txt [Page 7]