Network Working Group B. Fenner Request for Comments: 4727 AT&T Labs - Research Category: Standards Track November 2006 Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2006).
AbstractWhen experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents.
RFC3692] recommends assigning option numbers for experiments and testing. This document documents several such assignments for the number spaces whose IANA considerations are documented in [RFC2780]. This document generally follows the form of [RFC2780]. When using these values, carefully consider the advice in Sections 1 and 1.1 of [RFC3692]. It is not appropriate to simply select one of these values and hard code it into a system. Note: while [RFC3692] says that it may not be necessary to allocate values for UDP and TCP ports, Sections 6 and 7.1 explicitly reserve ports for this purpose to avoid any possible conflict. RFC0791] contains the following fields that carry values assigned by the IANA: Version, Type of Service, Protocol, Source Address, Destination Address, and Option Type. RFC2474] defines Pool 2 (all code points xxxx11, where 'x' refers to either '0' or '1') as Experimental/Local Use, so no additional code points should be needed. The Explicit Congestion Notification (ECN) field [RFC3168] has no free code points to assign. RFC3692] allocates two experimental code points (253 and 254) for the IPv4 Protocol field. RFC1918] may be useful. It is not appropriate to use other special-purpose IPv4 addresses [RFC3330] for experimentation.
At the time of this writing, some Internet Registries have policies allowing experimental assignments from number spaces that they control. Depending on the experiment, the registry, and their policy, this may be an appropriate path to pursue. RFC2365] may be useful. This document assigns a single link-local scoped group, 18.104.22.168, and a single scope-relative group, 254. Section 8 for the assigned values. RFC2460] contains the following fields that carry values assigned from IANA-managed name spaces: Version, 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. The IPv6 Routing Header contains a Type field for which there is not currently an explicit IANA assignment policy. RFC2474] defines Pool 2 (all code points xxxx11, where 'x' refers to either '0' or '1') as Experimental/Local Use, so no additional code points should be needed. The ECN field [RFC3168] has no free code points to assign. RFC3692] allocates two experimental code points (253 and 254) for the IPv6 Next Header field.
RFC2928] defines a set of IPv6 addresses for testing and experimental usage: The block of Sub-TLA IDs assigned to the IANA (i.e., 2001:0000::/29 - 2001:01F8::/29) is for assignment for testing and experimental usage to support activities such as the 6bone, and for new approaches like exchanges. However, at this writing, there are no RFC3692-style experimental IPv6 addresses assigned. [HUSTON05] creates an IANA registry that may in the future contain such assignments. For certain experiments, Unique Local Addresses [RFC4193] may be useful. It is not appropriate to use addresses in the documentation prefix [RFC3849] for experimentation. At the time of this writing, some Internet Registries have policies allowing experimental assignments from number spaces that they control. Depending on the experiment, the registry, and their policy, this may be an appropriate path to pursue. RFC4291] set may be useful. Section 8 for the assigned values.
RFC4443] includes experimental ICMPv6 type values for Informational (200, 201) and Error (100, 101) message types. ICMPv6 code values are allocated per type, so it's not feasible to assign experimental values in this document. RFC2461] contains the following fields that carry values assigned from IANA-managed name spaces: Type, Code, and Option Type. Section 5 for those code points.
Section 2.4.2) Group Address Name ------------- ---------------------------- 22.214.171.124 RFC3692-style Experiment (*) IPv4 Multicast Addresses (multicast-addresses relative addresses section) (Section 2.4.2) Relative Description -------- ---------------------------- 254 RFC3692-style Experiment (*) IPv4 Option Numbers (ip-parameters initial section) (Section 2.5) Copy Class Number Value ---- ----- ------ ----- 0 0 30 30 0 2 30 94 1 0 30 158 1 2 30 222
IPv6 Option Types (ipv6-parameters Section 5.b.) (Section 3.5) HEX act chg rest ---- --- --- ----- 0x1e 00 0 11110 0x3e 00 1 11110 0x5e 01 0 11110 0x7e 01 1 11110 0x9e 10 0 11110 0xbe 10 1 11110 0xde 11 0 11110 0xfe 11 1 11110 IPv6 Neighbor Discovery Option Formats (icmpv6-parameters) (Section 5.1.3) Type Description ---- ------------------------------ 253 RFC3692-style Experiment 1 (*) 254 RFC3692-style Experiment 2 (*) IPv6 Routing Header Routing Types (ipv6-parameters Section 5.c.) (Section 3.6) Type Description ---- ------------------------------ 253 RFC3692-style Experiment 1 (*) 254 RFC3692-style Experiment 2 (*) ICMPv4 Type Numbers (icmp-parameters) (Section 4) Type Name ---- ------------------------------ 253 RFC3692-style Experiment 1 (*) 254 RFC3692-style Experiment 2 (*) System Port Numbers (port-numbers) (Sections 6 and 7.1) Keyword Decimal Description ------- -------- ------------------------------ exp1 1021/udp RFC3692-style Experiment 1 (*) exp1 1021/tcp RFC3692-style Experiment 1 (*) exp2 1022/udp RFC3692-style Experiment 2 (*) exp2 1022/tcp RFC3692-style Experiment 2 (*)
TCP Option Numbers (tcp-parameters) (Section 7.3) Kind Length Meaning ---- ------ ------------------------------ 253 N RFC3692-style Experiment 1 (*) 254 N RFC3692-style Experiment 2 (*) Each of these registrations is accompanied by the following footnote: (*) It is only appropriate to use these values in explicitly- configured experiments; they MUST NOT be shipped as defaults in implementations. See RFC 3692 for details. Section 2.5 are not included in the IPsec AH [RFC4302] calculations, it is not possible for one to authenticate their use. Experimenters ought to keep this in mind when designing their experiments. Users of the experimental IPv6 options defined in Section 3.5 can choose whether or not the option is included in the AH calculations by choosing the value of the "chg" field. When experimental code points are deployed within an administratively self-contained network domain, the network administrators should ensure that each code point is used consistently to avoid interference between experiments. When experimental code points are used in traffic that crosses multiple administrative domains, the
experimenters should assume that there is a risk that the same code points will be used simultaneously by other experiments and thus that there is a possibility that the experiments will interfere. Particular attention should be given to security threats that such interference might create. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2474] 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. [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC2928] Hinden, R., Deering, S., Fink, R., and T. Hain, "Initial IPv6 Sub-TLA ID Assignments", RFC 2928, September 2000. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [HUSTON05] Huston, G., "Administration of the IANA Special Purpose Address Block", Work in Progress, December 2005.
Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.