Network Working Group S. Bradner Request for Comments: 2780 Harvard University BCP: 37 V. Paxson Category: Best Current Practice ACIRI March 2000 IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThis memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. CONS].
HC], while the three hi-order bits are used by IP Header Compression [IPHC]. V4] contains the following fields that carry values assigned by the IANA: Version, Type of Service, Protocol, Source Address, Destination Address, and Option Type. V4] has been superseded[DIFF] by the 6-bit Differentiated Services (DS) field and a 2-bit field which is currently reserved. The IANA allocates values in the DS field following the IANA Considerations section in [DIFF]. [ECN] describes an experimental use of the 2-bit "currently unused" field. Other experimental uses of this field may be assigned after IESG Approval processes. Permanent values in this field are allocated following a Standards Action process.
V4] and [MULT]. AN80]) and 127/8 (from which the loopback address has been taken) along with other values already assigned by the IETF for special functions or purposes. (For example, the private addresses defined in RFC 1918.) Further assignments in the 0/8 and 127/8 ranges require a Standards Action process since current IP implementations may break if this is done. ADSCP] assigned a number of IPv4 multicast address to correspond to IPv6 scoped multicast addresses. Also, the values in the range from 220.127.116.11 to 18.104.22.168 , inclusive, are reserved by the IANA for the use of routing protocols and other low-level topology discovery or maintenance protocols, such as gateway discovery and group membership reporting. (See the IANA web page) New values in this range are assigned following an IESG Approval or Standards Action process. Assignments of individual multicast address follow an Expert Review, IESG Approval or Standards Action process. Until further work is done on multicast protocols, large-scale assignments of IPv4 multicast addresses is not recommended. From time to time, there are requests for temporary assignment of multicast space for experimental purposes. These will originate in an IESG Approval process and should be for a limited duration such as one year. AN81, MULT] and compliant IPv4 implementations will discard any packets that make use of them. Addresses in this range
are not to be assigned unless an IETF Standards Action modifies the IPv4 protocol in such a way as to make these addresses valid. Address 255.255.255.255 is the limited broadcast address. 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. DIFF] as a 6- bit Differentiated Services (DS) field and a 2-bit field which is currently reserved. See Section 4.2 for assignment guidelines for these fields. Section 4.3. V6AD]. The addresses are divided into ranges defined by a variable length Format Prefix (FP). V6AA]. Recently the IANA agreed to specific guidelines for the assignment of values in the Aggregatable Global Unicast Addresses FP (FP 001) formulated by the Regional Internet Registries.
V6AD]. Anycast addresses are allocated from the unicast address space and anycast addresses are syntactically indistinguishable from unicast addresses. Assignment of IPv6 Anycast subnet addresses follows the process described in [V6AD]. Assignment of other IPv6 Anycast addresses follows the process used for IPv6 Aggregatable Global Unicast Addresses. (section 5.4.1) V6AD]. They are identified by a FP of 0xFF. Assignment guidelines for IPv6 multicast addresses are described in [MASGN]. NDV6] contains the following fields that carry values assigned from IANA- managed name spaces: Type, Code and Option Type. Values for the IPv6 Neighbor Discovery Type, Code, and Option Type fields are allocated using an IESG Approval or Standards Action process. ICMP] contains the following fields that carry values assigned from IANA-managed name spaces: Type and Code. Code field values are defined relative to a specific Type value. Values for the IPv4 ICMP Type fields are allocated using an IESG Approval or Standards Action processes. Code Values for existing IPv4 ICMP Type fields are allocated using IESG Approval or Standards
Action processes. The policy for assigning Code values for new IPv4 ICMP Types should be defined in the document defining the new Type value. ICMPV6] contains the following fields that carry values assigned from IANA-managed name spaces: Type and Code. Code field values are defined relative to a specific Type value. Values for the IPv6 ICMP Type fields are allocated using an IESG Approval or Standards Action processes. Code Values for existing IPv6 ICMP Type fields are allocated using IESG Approval or Standards Action processes. The policy for assigning Code values for new IPv6 ICMP Types should be defined in the document defining the new Type value. UDP] contains the following fields that carry values assigned from IANA-managed name spaces: Source and Destination Port. Both the Source and Destination Port fields use the same namespace. Values in this namespace are assigned following a Specification Required, Expert Review, IESG Approval, IETF Consensus, or Standards Action process. Note that some assignments may involve non- disclosure information. TCP] contains the following fields that carry values assigned from IANA-managed name spaces: Source and Destination Port, Reserved Bits, and Option Kind.
[ADSCP] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998. [AN80] Postel, J., "Assigned Numbers", RFC 758, August 1979. [AN81] Postel, J., "Assigned Numbers", RFC 790, September 1981. [CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [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. [ECN] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999. [HC] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990. [ICMP] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [ICMPV6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[IPHC] Degermark, M., Nordgren, S. and B. Pink, "IP Header Compression", RFC 2507, February 1999. [MASGN] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998. [MULT] Deering, S., "Host extensions for IP multicasting", RFC 988, July 1986. [NDV6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [V4] Postel, J., "Internet Protocol", STD 5, RFC 791, September, 1981. [V6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [V6AA] IAB, IESG, "IPv6 Address Allocation Management", RFC 1881, December 1995. [V6AD] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.