GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4727

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4727.txt · Last modified: 2006/11/29 18:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki