summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4727.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4727.txt')
-rw-r--r--doc/rfc/rfc4727.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc4727.txt b/doc/rfc/rfc4727.txt
new file mode 100644
index 0000000..350d34d
--- /dev/null
+++ b/doc/rfc/rfc4727.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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).
+
+Abstract
+
+ When 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner Standards Track [Page 1]
+
+RFC 4727 Experimental Values in Headers November 2006
+
+
+1. Introduction
+
+ [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.
+
+2. Fields in the IPv4 Header
+
+ The IPv4 header [RFC0791] contains the following fields that carry
+ values assigned by the IANA: Version, Type of Service, Protocol,
+ Source Address, Destination Address, and Option Type.
+
+2.1. IP Version Field in the IPv4 Header
+
+ The Version field in IPv4 packets is always 4.
+
+2.2. IPv4 Type of Service Field
+
+ [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.
+
+2.3. IPv4 Protocol Field
+
+ [RFC3692] allocates two experimental code points (253 and 254) for
+ the IPv4 Protocol field.
+
+2.4. IPv4 Source and Destination Addresses
+
+2.4.1. IPv4 Unicast
+
+ No experimental IPv4 addresses are defined. For certain experiments,
+ the address ranges set aside for Private Internets in [RFC1918] may
+ be useful. It is not appropriate to use other special-purpose IPv4
+ addresses [RFC3330] for experimentation.
+
+
+
+
+
+
+Fenner Standards Track [Page 2]
+
+RFC 4727 Experimental Values in Headers November 2006
+
+
+ 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.
+
+2.4.2. IPv4 Multicast
+
+ The globally routable group 224.0.1.20 is set aside for
+ experimentation. For certain experiments, the administratively
+ scoped multicast groups defined in [RFC2365] may be useful. This
+ document assigns a single link-local scoped group, 224.0.0.254, and a
+ single scope-relative group, 254.
+
+2.5. IPv4 Option Type Field
+
+ This document assigns a single option number, with all defined values
+ of the "copy" and "class" fields, resulting in four distinct option
+ type codes. See Section 8 for the assigned values.
+
+3. Fields in the IPv6 Header
+
+ The IPv6 header [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.
+
+3.1. IP Version Field in the IPv6 Header
+
+ The Version field in IPv6 packets is always 6.
+
+3.2. IPv6 Traffic Class Field
+
+ [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.
+
+3.3. IPv6 Next Header Field
+
+ [RFC3692] allocates two experimental code points (253 and 254) for
+ the IPv6 Next Header field.
+
+
+
+
+
+
+
+Fenner Standards Track [Page 3]
+
+RFC 4727 Experimental Values in Headers November 2006
+
+
+3.4. IPv6 Source and Destination Addresses
+
+3.4.1. IPv6 Unicast Addresses
+
+ [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.
+
+3.4.2. IPv6 Multicast Addresses
+
+ The group FF0X::114 is set aside for experimentation at all scope
+ levels. Smaller scopes may be particularly useful for
+ experimentation, since they are defined not to leak out of a given
+ defined boundary, which can be set to be the boundary of the
+ experiment. For certain experiments, other multicast addresses with
+ the T (non-permanently-assigned or "transient" address) bit [RFC4291]
+ set may be useful.
+
+3.5. IPv6 Hop-by-Hop and Destination Option Fields
+
+ This document assigns a single option type, with all possible values
+ of the "act" and "chg" fields, resulting in eight distinct option
+ type codes. See Section 8 for the assigned values.
+
+3.6. IPv6 Routing Header Routing Type
+
+ This document assigns two values for the Routing Type field in the
+ IPv6 Routing Header, 253 and 254.
+
+
+
+
+
+
+
+Fenner Standards Track [Page 4]
+
+RFC 4727 Experimental Values in Headers November 2006
+
+
+4. Fields in the IPv4 ICMP Header
+
+ This document assigns two ICMPv4 type numbers, 253 and 254. ICMPv4
+ code values are allocated per type, so it's not feasible to assign
+ experimental values in this document.
+
+5. Fields in the IPv6 ICMP Header
+
+ [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.
+
+5.1. IPv6 Neighbor Discovery Fields
+
+ The IPv6 Neighbor Discovery header [RFC2461] contains the following
+ fields that carry values assigned from IANA-managed name spaces:
+ Type, Code, and Option Type.
+
+5.1.1. IPv6 Neighbor Discovery Type
+
+ The Neighbor Discovery Type field is the same as the ICMPv6 Type
+ field. See Section 5 for those code points.
+
+5.1.2. IPv6 Neighbor Discovery Code
+
+ The ICMPv6 Code field is not used in IPv6 Neighbor Discovery, so no
+ experimental code points are necessary.
+
+5.1.3. IPv6 Neighbor Discovery Option Type
+
+ This document assigns two IPv6 Neighbor Discovery Option Types, 253
+ and 254.
+
+6. Fields in the UDP Header
+
+ Two system ports, 1021 and 1022, have been reserved for
+ experimentation for UDP and TCP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner Standards Track [Page 5]
+
+RFC 4727 Experimental Values in Headers November 2006
+
+
+7. Fields in the TCP Header
+
+7.1. TCP Source and Destination Port Fields
+
+ Two system ports, 1021 and 1022, have been reserved for
+ experimentation for UDP and TCP.
+
+7.2. Reserved Bits in TCP Header
+
+ There are not enough reserved bits to allocate any for
+ experimentation.
+
+7.3. TCP Option Kind Field
+
+ Two TCP options, 253 and 254, have been reserved for experimentation
+ with TCP Options.
+
+8. IANA Considerations
+
+ The new assignments are summarized below.
+
+
+ IPv4 Multicast Addresses (multicast-addresses (224.0.0/24) Local
+ Network Control Block section) (Section 2.4.2)
+
+ Group Address Name
+ ------------- ----------------------------
+ 224.0.0.254 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
+
+
+
+
+
+Fenner Standards Track [Page 6]
+
+RFC 4727 Experimental Values in Headers November 2006
+
+
+ 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 (*)
+
+
+
+Fenner Standards Track [Page 7]
+
+RFC 4727 Experimental Values in Headers November 2006
+
+
+ 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.
+
+9. Security Considerations
+
+ Production networks do not necessarily support the use of
+ experimental code points in IP headers. The network scope of support
+ for experimental values should carefully be evaluated before
+ deploying any experiment across extended network domains, such as the
+ public Internet. The potential to disrupt the stable operation of
+ the network hosting the experiment through the use of unsupported
+ experimental code points is a serious consideration when planning an
+ experiment using such code points.
+
+ Security analyzers such as firewalls and network intrusion detection
+ monitors often rely on unambiguous interpretations of the fields
+ described in this memo. As new values for the fields are assigned,
+ existing security analyzers that do not understand the new values may
+ fail, resulting in either loss of connectivity, if the analyzer
+ declines to forward the unrecognized traffic, or in loss of security
+ if it does forward the traffic and the new values are used as part of
+ an attack. Assigning known values for experiments can allow such
+ analyzers to take a known action for explicitly experimental traffic.
+
+ Because the experimental IPv4 options defined in 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
+
+
+
+Fenner Standards Track [Page 8]
+
+RFC 4727 Experimental Values in Headers November 2006
+
+
+ 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.
+
+10. References
+
+10.1. Normative References
+
+ [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.
+
+
+
+Fenner Standards Track [Page 9]
+
+RFC 4727 Experimental Values in Headers November 2006
+
+
+ [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.
+
+10.2. Informative References
+
+ [HUSTON05] Huston, G., "Administration of the IANA Special Purpose
+ Address Block", Work in Progress, December 2005.
+
+Author's Address
+
+ Bill Fenner
+ AT&T Labs - Research
+ 75 Willow Rd
+ Menlo Park, CA 94025
+ USA
+
+ Phone: +1 650 330-7893
+ EMail: fenner@research.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenner Standards Track [Page 10]
+
+RFC 4727 Experimental Values in Headers November 2006
+
+
+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
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+Fenner Standards Track [Page 11]
+