Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers
Reserved numbers for testing new protocols without taking a real value.
Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, DOI 10.17487/RFC4727, November 2006, <https://www.rfc-editor.org/info/rfc4727>.
@misc{rfc4727,
series = {Request for Comments},
number = 4727,
howpublished = {RFC 4727},
publisher = {RFC Editor},
doi = {10.17487/RFC4727},
url = {https://www.rfc-editor.org/info/rfc4727},
author = {B. Fenner},
title = {{Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers}},
pagetotal = 11,
year = 2006,
month = nov,
} RFC text
Contents
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.
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.
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.
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.
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.
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
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.
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
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.
[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
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.
ISO Plain Language
On this page
§1Why Experiments Need Reserved Numbers
Testing or extending a protocol usually requires a protocol number or a constant, even when the test happens in a closed environment. The values come from registries that IANA administers, and RFC 3692 sets out how numbers should be assigned for experiments and testing. This document lists the assignments that were needed for particular header fields, and follows the form of RFC 2780.
Using one of these values takes care. The advice in Sections 1 and 1.1 of RFC 3692 applies: it is not appropriate to simply select one of the values and hard code it into a system.
RFC 3692 also says it may not be necessary to allocate values for UDP and TCP ports, but this document reserves two anyway, in Sections 6 and 7.1, to remove any chance of a conflict.
Every protocol field has a registry of numbers that decide what each value means. This RFC lists the entries in those registries that are kept for experiments, so a test does not collide with a real service.
- IPv4 ProtocolValues 253 and 254 are reserved for experiments.
- IPv6 Next HeaderValues 253 and 254 are reserved for experiments.
- IPv4 addressesMulticast group 224.0.0.254 and relative group 254. No experimental unicast addresses.
- IPv6 addressesMulticast group FF0X::114 at every scope level.
- IPv4 optionsOption type codes 30, 94, 158 and 222.
- IPv6 optionsOption type codes 0x1e, 0x3e, 0x5e, 0x7e, 0x9e, 0xbe, 0xde and 0xfe.
- ICMPICMPv4 types 253 and 254; ICMPv6 informational types 200 and 201 and error types 100 and 101.
- UDP and TCPPorts 1021 and 1022, and TCP option kinds 253 and 254.
§2.3Protocol Numbers in the IP Headers
The IPv4 header has fields whose values are assigned by IANA: Version, Type of Service, Protocol, Source Address, Destination Address and Option Type. The IPv6 header has its own set: Version, Traffic Class, Next Header, Source and Destination Address, plus Option Type fields in the Hop-by-Hop and Destination Options extension headers.
Some fields need no new entries. The IPv4 Version field is always 4 and the IPv6 Version field is always 6. RFC 2474 already defines Pool 2, all code points of the form xxxx11, as Experimental or Local Use, so the Type of Service and Traffic Class fields need no extra code points, and the Explicit Congestion Notification field has no free code points to assign at all.
Two code points, 253 and 254, are available for experiments in the IPv4 Protocol field, and the same two values are available in the IPv6 Next Header field. They come from the experimental allocations made by RFC 3692.
The Protocol field in IPv4 and the Next Header field in IPv6 say which protocol a packet carries. The values 253 and 254 are kept aside so a test can use them without colliding with a real protocol.
§2.4Experimental Addresses and Multicast Groups
For IPv4 unicast addresses, no experimental addresses are defined. The address ranges set aside for private internets by RFC 1918 may be useful for some experiments, but the other special-purpose IPv4 addresses listed in RFC 3330 are not appropriate. Some registries have policies that allow experimental assignments from the number spaces they control, which may be a path to pursue depending on the experiment.
For IPv4 multicast, the globally routable group 224.0.1.20 is set aside for experimentation, and the administratively scoped multicast groups of RFC 2365 may also be useful. This document assigns a single link-local scoped group, 224.0.0.254, and a single scope-relative group, 254.
For IPv6 unicast, no RFC 3692 style experimental addresses are assigned at the time of writing, although RFC 2928 sets aside the block of Sub-TLA IDs assigned to IANA, from 2001:0000::/29 to 2001:01F8::/29, for testing and experimental usage. Unique Local Addresses from RFC 4193 may be useful, but the documentation prefix of RFC 3849 is not appropriate. For IPv6 multicast, the group FF0X::114 is set aside for experimentation at all scope levels, and multicast addresses with the transient bit set may be useful.
An experiment also needs addresses to send to. The RFC points at the address ranges and multicast groups that are safe to use, and names the ones that are not meant for experiments.
§2.5Experimental Options in IPv4 and IPv6
The IPv4 Option Type field is assigned a single option number with all defined values of its copy and class fields, which results in four distinct option type codes: 30, 94, 158 and 222.
The IPv6 Hop-by-Hop and Destination Option fields are assigned a single option type with all possible values of the act and chg fields, which results in eight distinct option type codes: 0x1e, 0x3e, 0x5e, 0x7e, 0x9e, 0xbe, 0xde and 0xfe.
The IPv6 Routing Header has a Type field for which there is no explicit IANA assignment policy, so this document assigns two values to it, 253 and 254.
Options are extra fields that can be added to a packet header. This RFC sets aside a handful of option codes in IPv4, IPv6 and the IPv6 routing header so an experiment can carry an option nobody else uses.
§4ICMP, Neighbor Discovery and Port Numbers
This document assigns two ICMPv4 type numbers, 253 and 254. ICMPv4 code values are allocated per type, so it is not feasible to assign experimental values for them here.
For ICMPv6, RFC 4443 already includes experimental type values for Informational messages, 200 and 201, and for Error messages, 100 and 101. ICMPv6 code values are also allocated per type. In IPv6 Neighbor Discovery, the Type field is the same as the ICMPv6 Type field, the Code field is not used, and two Option Types, 253 and 254, are assigned.
Two system ports, 1021 and 1022, are reserved for experimentation for UDP and TCP. The TCP header has too few reserved bits to allocate any for experiments, but two TCP options, 253 and 254, are reserved for experimentation with TCP options.
The same pattern applies to the control messages and to the transport protocols. Two ICMPv4 types, two Neighbor Discovery options, two TCP options and the ports 1021 and 1022 are kept aside for tests.
§8The Registered Values
The new assignments are summarized in the registry tables. The IPv4 multicast registry receives 224.0.0.254 in the Local Network Control Block section and the relative address 254. The IPv4 option number registry receives 30, 94, 158 and 222. The IPv6 option type registry receives 0x1e, 0x3e, 0x5e, 0x7e, 0x9e, 0xbe, 0xde and 0xfe, and the IPv6 Routing Header type registry receives 253 and 254. The ICMPv4 type registry receives 253 and 254, the IPv6 Neighbor Discovery option registry receives 253 and 254, the TCP option registry receives 253 and 254, and the system port registry receives the keywords exp1 and exp2 for 1021 and 1022 over both UDP and TCP.
Every one of these registrations carries the same footnote: it is only appropriate to use these values in explicitly configured experiments, and they MUST NOT be shipped as defaults in implementations.
The RFC lists each reserved value in the registry it belongs to. Every entry carries a warning that the value is for configured experiments only and must never be the default in a product.
- 253, 254IPv4 Protocol — Experimental code points for the IPv4 Protocol field.
- 253, 254IPv6 Next Header — Experimental code points for the IPv6 Next Header field.
- 30, 94, 158, 222IPv4 Option Numbers — One option number with every combination of the copy and class fields.
- 0x1e, 0x3e, 0x5e, 0x7e, 0x9e, 0xbe, 0xde, 0xfeIPv6 Option Types — One option type with every combination of the act and chg fields.
- 253, 254IPv6 Routing Header Types — Experimental values for the Routing Type field.
- 253, 254ICMPv4 Types — Experimental ICMPv4 type numbers.
- 253, 254IPv6 Neighbor Discovery Options — Experimental Option Types for Neighbor Discovery.
- 253, 254TCP Option Kinds — Experimental TCP option kinds.
- 1021, 1022System Ports — Reserved for experiments over UDP and TCP, with the keywords exp1 and exp2.
- 224.0.0.254IPv4 Multicast — Link-local scoped group for RFC 3692 style experiments.
- 254IPv4 Multicast Relative — Scope-relative group for RFC 3692 style experiments.
- FF0X::114IPv6 Multicast — Group set aside for experimentation at all scope levels.
§9Security Considerations
Production networks do not necessarily support experimental code points in IP headers. The reach of that support should be evaluated before an experiment is deployed across extended network domains such as the public Internet, because disrupting the stable operation of the network is a serious consideration when planning an experiment.
Security analyzers such as firewalls and intrusion detection monitors rely on unambiguous interpretations of these fields. An analyzer that does not understand a new value may fail, which results in either loss of connectivity if it declines to forward the traffic, or loss of security if it forwards traffic whose values are part of an attack. Assigning known values for experiments lets such analyzers take a known action for explicitly experimental traffic.
The experimental IPv4 options defined in Section 2.5 are not included in the IPsec Authentication Header calculations, so their use cannot be authenticated. Users of the experimental IPv6 options defined in Section 3.5 can choose whether the option is included in those calculations by choosing the value of the chg field.
Finally, within an administratively self-contained network domain, the administrators should ensure that each code point is used consistently, to avoid interference between experiments. When experimental code points cross several administrative domains, experimenters should assume that other experiments may be using the same code points at the same time, and pay attention to the security threats that such interference might create.
Firewalls and other security tools may not know what an experimental value means, and may block the traffic or let it through unchecked. The RFC also warns that two experiments elsewhere could pick the same numbers by accident.