Experimental Code Points

[ran.atkinson@…]

We believe that there are at least 2 different kinds of networking
experiment and that these 2 can be distinguished by having different
scope.

Some network experiments, call them category A, are undertaken
inside a single laboratory or within a single site, or perhaps
independently by several disconnected sites. Experiments in
this category benefit well from the pre-allocated "Experimental"
protocol code points. The experimenter is working in isolation,
so wide-area coordination of which "Experimental" code point
to use for a given purpose is not necessary.

Other network experiments, call them category B, are undertaken
among a diverse set of experimental sites, which most often are
connected via the global Internet. This might include, for example,
sites that take a prototype implementation of some protocol and
use that both within their site but, importantly, among the full
set of other sites interested in that protocol. In this kind
of experiment, it is quite likely that many of those sites also
are experimenting with some different set of researchers on
other protocol items. It is likely, for example, that multiple
IPv6-related experiments might occur concurrently at a single site.
In this case, where many sites are using a protocol experimentally,
it becomes nearly impossible to ensure full de-confliction of
Experimental code points. So in this case, the pre-allocated
Experimental code points really are NOT workable.

Both HIP and LISP clearly fall into category B. We also fully
expect and believe that ILNP will fall into category B. We
know of 2 independent implementations of ILNP that are underway
at present. These are on different continents, by different
university research groups speaking different (human) languages.
Both are based on open-source operating systems. We expect that
one or both will make an experimental release available at
a suitable future point in time, likely later this year. This
leads directly to a much larger set of experimental sites
collaborating among themselves -- but necessarily not in a tightly
coordinated way. This makes it at least impractical, and probably
impossible, to fully coordinate the de-confliction of "experimental"
code points.

Both HIP and LISP are dealing with this by having unique code points
allocated to HIP and LISP, respectively, at time of publication of
their respective Experimental status RFCs.

[bernard_aboba@…]

Proposal is to add a paragraph to the end of Section 3.6.1 so that it now reads as follows:

3.6.1. Experimental and Local Use

In some cases, it may be appropriate to use values designated as
"experimental" or "local use" in early implementations of an
extension. For example, "Experimental Values in IPv4, IPv6, ICMPv4,
ICMPv6, UDP and TCP Headers" [RFC4727] discusses experimental values
for IP and transport headers, and "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474]
defines experimental/local use ranges for differentiated services
code points.

Such values should be used with care and only for their stated
purpose: experiments and local use. They are unsuitable for
Internet-wide use, since they may be used for conflicting purposes
and thereby cause interoperability failures. Packets containing
experimental or local use values must not be allowed out of the
domain in which they are meaningful.

As noted in [RFC5226] Section 4.1:

For private or local use... No attempt is made to prevent multiple
sites from using the same value in different (and incompatible)
ways... assignments are not generally useful for broad
interoperability. It is the responsibility of the sites making
use of the Private Use range to ensure that no conflicts occur
(within the intended scope of use).

"Assigning Experimental and Testing Numbers Considered Useful" BCP 82
[RFC3692] Section 1 provides additional guidance on the use of
experimental code points:

Numbers in the experimentation range.... are not intended to be
used in general deployments or be enabled by default in products
or other general releases. In those cases where a product or
release makes use of an experimental number, the end user must be
required to explicitly enable the experimental feature and
likewise have the ability to chose and assign which number from
the experimental range will be used for a specific purpose (i.e.,
so the end user can ensure that use of a particular number doesn't
conflict with other on-going uses). Shipping a product with a
specific value pre-enabled would be inappropriate and can lead to
interoperability problems when the chosen value collides with a
different usage, as it someday surely will.

From the above, it follows that it would be inappropriate for a
group of vendors, a consortia, or another Standards Development
Organization to agree among themselves to use a particular value
for a specific purpose and then agree to deploy devices using
those values. By definition, experimental numbers are not
guaranteed to be unique in any environment other than one where
the local system administrator has chosen to use a particular
number for a particular purpose and can ensure that a particular
value is not already in use for some other purpose.

There are situations an experiment is undertaken among a diverse
set of experimental sites connected via the global Internet. This
might include, for example, sites that take a prototype
implementation of some protocol and use that both within their
site but, importantly, among the full set of other sites
interested in that protocol. In such a situation it is
impractical and probably impossible to coordinate the de-
confliction of experimental code points. HIP and LISP are
examples where a set of experimental sites are collaborating among
themselves, but not necessarily in a tightly coordinated way.
Both HIP and LISP have dealt with this by having unique non-
experimental code points allocated to HIP and LISP, respectively,
at time of publication of their respective Experimental RFCs.