Shared Use of Experimental Hop-by-Hop and Destination Options
draft-herbert-6man-exp-opts-01

INTERNET-DRAFT                                                T. Herbert
Intended Status: Standard                                     Quantonium
Expires: November 2019                                                  
                                                                        
                                                            May 22, 2019

     Shared Use of Experimental Hop-by-Hop and Destination Options
                     draft-herbert-6man-exp-opts-01

Abstract

   This document describes how the experimental IPv6 Hop-by-Hop and
   Destinations Option types can concurrently support different
   experimental options. This is accomplished by employing a format in
   the Option Data for experimental option types. The format contains an
   experiment identifier that indicates an experimental option contained
   in the trailing Option Data. This approach is robust to experiments
   that are not registered and to those that do not use this sharing
   mechanism.  It is recommended for all new Destination and Hop-by-Hop
   options that use experimental codepoints.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
 

T. Herbert             Expires November 23, 2019                [Page 1]
INTERNET DRAFT       draft-herbert-6man-exp-opts-01         May 22, 2019

   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Requirements Language . . . . . . . . . . . . . . . . . . . . .  4
   3  Hop-by-Hop and Destination Experimental Option Format . . . . .  4
     3.1 Selecting an ExID  . . . . . . . . . . . . . . . . . . . . .  5
     3.2 Impact on Option Processing  . . . . . . . . . . . . . . . .  6
     3.3 Interaction with the Authentication Header . . . . . . . . .  6
   4  Reducing the Impact of False Positives  . . . . . . . . . . . .  7
   5  Migration to Assigned Options . . . . . . . . . . . . . . . . .  7
   6  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   7  Security Considerations . . . . . . . . . . . . . . . . . . . .  7
   8  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  7
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1  Normative References  . . . . . . . . . . . . . . . . . . .  9
     9.2  Informative References  . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  9

 

T. Herbert             Expires November 23, 2019                [Page 2]
INTERNET DRAFT       draft-herbert-6man-exp-opts-01         May 22, 2019

1  Introduction

   IPv6 defines Hop-by-Hop and Destination Options extension headers to
   contain a list of TLV (Type-Length-Value) options as the means to
   extend the protocol and to enable new protocol capabilities
   [RFC8200]. This document describes how the experimental IPv6 Hop-by-
   Hop and Destinations Option experimental types can concurrently
   support different experimental options. 

   The space for identifying Hop-by-Hop and Destination options is
   small. An Option Type is eight bits, however the three high order
   bits are defined by [RFC8200] to hold a directive on what processing
   is to be done if the option is not recognized ("act" bits), as well
   as an indication of whether the Option Data is modifiable in flight
   ("chg" bit). Effectively, for a given combination of these three
   control bits there are only thirty-two possible types.

   [RFC4727] defines experimental option types for Hop-by-Hop and
   Destination options. A single base option type is assigned with all
   possible values of the "act" and "chg" fields, resulting in eight
   distinct option type codes (types 0x1e, 0x3e, 0x5e, 0x7e, 0x9e, 0xbe,
   0xde, and 0xfe). These values are intended for testing purposes or
   for use when an assigned codepoint is either not warranted or not
   available, e.g., based on the maturity status of the defined
   capability (i.e., Experimental or Informational, rather than
   Standards Track).

   Here, the term "experimental IPv6 Hop-by-Hop and Destination options"
   refers to options that use the Hop-by-Hop or Destination experimental
   option codepoints [RFC4727]. Such experiments can be described in an
   RFC of any status (e.g., Experimental, Informational, etc.) and are
   intended to be used in controlled environments and are allowed in
   public deployments (when not enabled as default [RFC3692]). Nothing
   prohibits the deployment of multiple experiments in the same
   environment -- controlled or public. Furthermore, some protocols are
   specified in Experimental or Informational RFCs, which either include
   parameters or design choices not yet understood or which might not be
   widely deployed [RFC2026].

   There is currently no mechanism to support shared use of the Hop-by-
   Hop and Destination experimental option codepoints. Different
   implementations use the same experimental option type for different
   purposes which results in collisions in which a single codepoint can
   be received at different times with different meanings intended by
   the sender.

   The approach proposed in this document does not require additional
   Hop-by-Hop and Destination option codepoints and is robust to those
 

T. Herbert             Expires November 23, 2019                [Page 3]
INTERNET DRAFT       draft-herbert-6man-exp-opts-01         May 22, 2019

   who choose either not to support it or not to register their
   experiments. The solution defines a field in the Option Data of
   experimental Hop-by-Hop and Destination options. This field is
   populated with an "experiment identifier" (ExID) defined as part of a
   specific option experiment. The ExID helps reduce the probability of
   a collision of independent experimental uses of the same option
   codepoint, both for those who follow this document (using registered
   ExIDs) and those who do not (squatters who either ignore this
   extension or do not register their ExIDs).

   The solution proposed in this document is recommended for all new
   protocols that use Hop-by-Hop or Destination experimental option
   codepoints.

   The techniques described in this document are adapted from [RFC6994]
   which describes the mechanism to concurrently support different
   experimental TCP options.

2  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3  Hop-by-Hop and Destination Experimental Option Format

   Hop-by-Hop and Destination options share a common format [RFC8200],
   in which the first byte is the codepoint (Option Type) and the second
   byte is the length of the option data in bytes (Opt Data Len):

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
     |  Option Type  |  Opt Data Len |  Option Data
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

   This document extends the option format for experimental Hop-by-Hop
   and Destination option codepoints with an experiment identifier
   (ExID), which is four bytes in length. The ExID is used to
   differentiate experiments and is the first field after the Option
   Type and Opt Data Len, as follows:

 

T. Herbert             Expires November 23, 2019                [Page 4]
INTERNET DRAFT       draft-herbert-6man-exp-opts-01         May 22, 2019

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  |   Opt Data Len  |            ExID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          ExID (cont)            |                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                             +
   |                                                               |
   +                         Option contents                       +
   |                                                               |

   All protocols using the experimental Hop-by-Hop or Destination option
   codepoints that are deployed outside controlled environments, such as
   in the public Internet, MUST use ExIDs as described in this document.
   All protocols using ExIDs as described in this document MUST register
   those ExIDs with IANA. Applicants register their desired ExID by
   contacting IANA [IANA].

3.1 Selecting an ExID

   ExIDs are selected at design time, when the protocol designer first
   implements or specifies the experimental option. An ExID is thirty-
   two bits. The value is stored in the header in network-standard (big-
   endian) byte order. ExIDs combine properties of IANA registered
   codepoints with "magic numbers".

   Use of the ExID helps reduce the probability of a false positive
   collision with those who either do not register their experiment or
   who do not implement this mechanism.

   ExIDs are registered with IANA using "first come, first served"
   (FCFS) priority. ExIDs MUST be unique. It is RECOMMENDED to use
   random numbers with sufficient entropy and to avoid any values that
   might commonly be present in unrelated data (e.g. 0x1, 0xffffffff
   would be poor choices). The ExID value of 0x0 is reserved and MAY be
   used internally in an implementation to represent the absence of an
   ExID value.

   The use of randomly assigned 32-bit identifiers in a sparsely
   populated space takes on the characteristics of a "magic number". A
   magic number is a randomized codepoint whose primary value is its
   unlikely collision with values selected by others [RFC6994].

   A thirty-bit ExID maintains four byte alignment of the trailing
   Option Data. A common alignment requirement of Hop-by-Hop and
   Destination Options is 4n + 2, so maintaining four byte alignment
   reduces the potential for implementation errors, especially in using
   the same word-alignment padding, if the same software is later
 

T. Herbert             Expires November 23, 2019                [Page 5]
INTERNET DRAFT       draft-herbert-6man-exp-opts-01         May 22, 2019

   modified to use a conventional codepoint.

3.2 Impact on Option Processing

   The ExID number is part of the Hop-by-Hop or Destination Option Data.
   The presence of the ExID increases the effective Option Data Length
   field by the size of the ExID. The presence of an ExID is transparent
   to implementations that do not implement the experimental option
   types or the mechanism described here.

   During receive processing, ExIDs in experimental options are matched
   against the ExIDs for each implemented protocol. If an ExID is not
   recognized, then the whole option is assumed to be unrecognized per
   the definition in [RFC8200]. The high order 2 bits of the Option Type
   specify the action in this case. If the action bits indicate that an
   ICMP error is warranted then an ICMP Parameter Problem, Code 2, is
   sent pointing to the first byte of the unrecognized ExID. 

   Although an ExID is in Option Data, it is considered to always be
   immutable in flight even if the change bit is set in the Option Type.
   Intermediate nodes MUST NOT modify an experimental identifier, or
   equivalently, intermediate nodes MUST NOT modify the first four bytes
   of Option Data in an option with an experimental Hop-by-Hop or
   Destination option type. 

3.3 Interaction with the Authentication Header

   When an Authentication header is present, the ExID in any
   experimental Hop-by-Hop or Destination option is included in the
   computation for authenticating a packet, regardless of whether the
   change bit is set. Specifically, the requirements of [RFC8200] are
   updated so that if the Hop-by-Hop or Destination option type is 0x3e,
   0x7e, 0xbe, or 0xfe, and an authentication header is present in a
   packet, then the bytes in the Option Data field after the first four
   bytes MUST be treated as zero-valued octets when computing or
   verifying the packet's authenticating value (note that the first four
   bytes of Option Data are not treated as zero-valued octets).

   In a controlled environment, not on the public Internet for instance,
   this requirement MAY be relaxed at the discretion of the
   administrator in order to maintain backwards compatibility. In a
   controlled environment, for Hop-by-Hop and Destination option types
   0x3e, 0x7e, 0xbe, or 0xfe, the first four bytes of the Option Data
   MAY be treated as zero-valued octets when computing or verifying the
   packet's authenticating value. This SHOULD be controlled by
   configuration where the RECOMMENED default is to always include the
   first four bytes in authentication calculations. Configuration can be
   system wide or selective based on matching the ExID (e.g. if a
 

T. Herbert             Expires November 23, 2019                [Page 6]
INTERNET DRAFT       draft-herbert-6man-exp-opts-01         May 22, 2019

   receiver receives an experimental option with a known ExID it might
   include the ExID in calculations, otherwise it could zero the first
   four bytes for calculation). Note that the sender and receiver MUST
   agree on whether the ExID bytes are included or not included in
   calculations for authentication. Mechanisms to achieve such agreement
   are out of scope of this document.

4  Reducing the Impact of False Positives

   False positives occur where the registered ExID of an experiment
   matches the value of an option that does not use ExIDs.  Such
   collisions can cause an option to be interpreted by the incorrect
   processing routine. Experiments that are not robust to ExID false
   positives SHOULD implement other detection measures, such as
   checksums or minimal digital signatures over the experimental options
   they support.

5  Migration to Assigned Options

   Some experiments may transition away from being experimental and
   become eligible for an assigned Hop-by-Hop or Destination option
   codepoint.  This document does not recommend a specific migration
   plan to transition from use of the experimental Hop-by-Hop or
   Destination options/ExIDs to use of an assigned codepoint.

   Once an assigned codepoint is allocated, use of an ExID represents
   unnecessary overhead. Therefore, once a Hop-by-Hop or Destination
   option codepoint is assigned to a protocol, that protocol SHOULD NOT
   continue to send the corresponding experimental option. An
   implementation MAY continue receiving the experimental option and MAY
   allow a fallback to sending the experimental option during some
   transition period to maintain backwards compatibility.

6  Rationale

   The rationale for 32-bit ExIDs as a combination of an assigned value
   and a magic number is provided in section 6 of [RFC6994].

7  Security Considerations

   The interaction between the mechanisms described in this document and
   the Authentication Header is described in section 3.3. Otherwise, the
   mechanism neither weakens nor enhances the existing state of security
   for Hop-by-Hop and Destination options.

8  IANA Considerations

   IANA is requested to create an "IPv6 Hop-by-Hop and Destination
 

T. Herbert             Expires November 23, 2019                [Page 7]
INTERNET DRAFT       draft-herbert-6man-exp-opts-01         May 22, 2019

   Option Experiment Identifiers (IPv6 Opt ExIDs)" registry. The
   registry records 32-bit ExIDs, as well as a reference (description,
   document pointer, or assignee name and e-mail contact) for each
   entry. ExIDs are registered for use with any of the experimental Hop-
   by-Hop and Destination option codepoints (i.e. option types 0x1e,
   0x3e, 0x5e, 0x7e, 0x9e, 0xbe, 0xde, and 0xfe).

   Entries are assigned on a First Come, First Served (FCFS) basis
   [RFC5226]. The registry operates FCFS on the entire ExID (in network-
   standard order).

   IANA will advise applicants of duplicate entries to select an
   alternate value, as per typical FCFS processing.

   IANA will record known duplicate uses to assist the community in both
   debugging assigned uses as well as correcting unauthorized duplicate
   uses.

   IANA should impose no requirements on making a registration other
   than indicating the desired codepoint and providing a point of
   contact. A short description or acronym for the use is desired but
   should not be required.

   Initial assignments are:

      +----------------+----------------+---------------+
      |      ExI D     | Description    | Reference     |
      +----------------+----------------+---------------+
      | 0              | Invalid ExID,  | This document |
      |                | Implementation |               |
      |                | internal use   |               |
      |                |                |               |
      | 1..x0ffffffff  | Unassigned     |               |
      +----------------+----------------+---------------+

 

T. Herbert             Expires November 23, 2019                [Page 8]
INTERNET DRAFT       draft-herbert-6man-exp-opts-01         May 22, 2019

9  References

9.1  Normative References

   [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", STD 86, RFC 8200, DOI
             10.17487/RFC8200, July 2017, <https://www.rfc-
             editor.org/info/rfc8200>.

   [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
             ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.

9.2  Informative References

   [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
             Considered Useful", BCP 82, RFC 3692, January 2004.

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
             3", BCP 9, RFC 2026, October 1996.

   [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC
             6994, DOI 10.17487/RFC6994, August 2013, <https://www.rfc-
             editor.org/info/rfc6994>.

   [IANA]    IANA, <http://www.iana.org/>.

Author's Address

   Tom Herbert
   Quantonium
   Santa Clara, CA
   USA

   Email: tom@quantonium.net

T. Herbert             Expires November 23, 2019                [Page 9]