doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc6994.txt b/doc/rfc/rfc6994.txt
new file mode 100644
index 0000000..b145880
--- /dev/null
+++ b/doc/rfc/rfc6994.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          J. Touch
+Request for Comments: 6994                                       USC/ISI
+Category: Standards Track                                    August 2013
+ISSN: 2070-1721
+
+
+                 Shared Use of Experimental TCP Options
+
+Abstract
+
+   This document describes how the experimental TCP option codepoints
+   can concurrently support multiple TCP extensions, even within the
+   same connection, using a new IANA TCP experiment identifier.  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 TCP options that use these codepoints.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6994.
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   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.
+
+
+
+
+
+
+Touch                        Standards Track                    [Page 1]
+
+RFC 6994         Shared Use of Experimental TCP Options      August 2013
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................3
+   3. TCP Experimental Option Structure ...............................4
+      3.1. Selecting an ExID ..........................................5
+      3.2. Impact on TCP Option Processing ............................6
+   4. Reducing the Impact of False Positives ..........................7
+   5. Migration to Assigned Options ...................................7
+   6. Rationale .......................................................8
+   7. Security Considerations .........................................9
+   8. IANA Considerations .............................................9
+   9. References .....................................................10
+      9.1. Normative References ......................................10
+      9.2. Informative References ....................................10
+   10. Acknowledgments ...............................................11
+
+1.  Introduction
+
+   TCP includes options to enable new protocol capabilities that can be
+   activated only where needed and supported [RFC793].  The space for
+   identifying such options is small -- 256 values, of which 30 are
+   assigned at the time of this document's publication [IANA].  Two of
+   these codepoints (253, 254) are allocated to support experiments
+   [RFC4727].  These values are intended for testing purposes or for use
+   when an assigned codepoint is either not warranted or 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 TCP options" refers to options that use
+   the TCP 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.
+   Further, 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].
+   Typically, these TCP options are not eligible to receive assigned
+   codepoints [RFC2780], so they need a way to share their use of the
+   experimental codepoints.
+
+   There is currently no mechanism to support shared use of the TCP
+   experimental option codepoints, either by different experiments on
+   different connections or for more than two experimental options in
+   the same connection.  Experimental options 253 and 254 are already
+   deployed in operational code to support an early version of TCP
+
+
+
+Touch                        Standards Track                    [Page 2]
+
+RFC 6994         Shared Use of Experimental TCP Options      August 2013
+
+
+   authentication.  Option 253 is also documented for the experimental
+   TCP Cookie Transaction option [RFC6013].  This shared use results in
+   collisions in which a single codepoint can appear multiple times in a
+   single TCP segment and for which each use is ambiguous.
+
+   Other codepoints have been used without assignment (known as
+   "squatting"), notably 31-32 (TCP cookie transactions, as originally
+   distributed and in its API doc) and 76-78 (tcpcrypt) [Bi11] [Si11].
+   Commercial products reportedly also use unassigned options 33, 69-70,
+   and 76-78.  Even though these uses are unauthorized, they currently
+   impact legitimate assignees.
+
+   Both such misuses (squatting on both experimental and assigned
+   codepoints) are expected to continue, but there are several
+   approaches that can alleviate the impact on cooperating protocol
+   designers.  One proposal relaxes the requirements for assignment of
+   TCP options, allowing them to be assigned more readily for protocols
+   that have not been standardized through the IETF process [RFC5226].
+   Another proposal assigns a larger pool to the TCP experiment option
+   codepoints and manages their sharing through IANA coordination
+   [Ed11].
+
+   The approach proposed in this document does not require additional
+   TCP option codepoints and is robust to those who choose either not to
+   support it or not to register their experiments.  The solution adds a
+   field to the structure of the experimental TCP option.  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 TCP experimental option codepoints.  The
+   techniques described here may also enable shared use of other
+   experimental codepoints, but that issue is out of scope for this
+   document.
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   In this document, these words will appear with that interpretation
+   only when in ALL CAPS.  Lowercase uses of these words are not to be
+   interpreted as carrying RFC 2119 significance.
+
+
+
+Touch                        Standards Track                    [Page 3]
+
+RFC 6994         Shared Use of Experimental TCP Options      August 2013
+
+
+   In this document, the characters ">>" preceding an indented line(s)
+   indicates a compliance requirement statement using the key words
+   listed above.  This convention aids reviewers in quickly identifying
+   or finding the explicit compliance requirements of this RFC.
+
+3.  TCP Experimental Option Structure
+
+   TCP options have the current common structure [RFC793], in which the
+   first byte is the codepoint (Kind) and the second byte is the length
+   of the option in bytes (Length):
+
+                    0          1          2          3
+                    01234567 89012345 67890123 45678901
+                   +--------+--------+--------+--------+
+                   |  Kind  | Length |       ...       |
+                   +--------+--------+--------+--------+
+                   |    ...
+                   +--------
+
+                     Figure 1.  TCP Option Structure [RFC793]
+
+   This document extends the option structure for experimental
+   codepoints (253, 254) with an experiment identifier (ExID), which is
+   either 2 or 4 bytes in length.  The ExID is used to differentiate
+   experiments and is the first field after Kind and Length, as follows:
+
+                    0          1          2          3
+                    01234567 89012345 67890123 45678901
+                   +--------+--------+--------+--------+
+                   |  Kind  | Length |       ExID      |
+                   +--------+--------+--------+--------+
+                   |  option contents...
+                   +--------+--------+--------+---
+
+               Figure 2.  TCP Experimental Option with a 16-bit ExID
+
+                    0          1          2          3
+                    01234567 89012345 67890123 45678901
+                   +--------+--------+--------+--------+
+                   |  Kind  | Length |       ExID      |
+                   +--------+--------+--------+--------+
+                   |   ExID (con't)  |  option contents...
+                   +--------+--------+--------+---
+
+               Figure 3.  TCP Experimental Option with a 32-bit ExID
+
+
+
+
+
+
+Touch                        Standards Track                    [Page 4]
+
+RFC 6994         Shared Use of Experimental TCP Options      August 2013
+
+
+   This mechanism is encouraged for all TCP options that are not yet
+   eligible for assigned codepoints:
+
+   >> Protocols requiring new TCP option codepoints that are not
+      eligible for assigned values SHOULD use the existing TCP
+      experimental option codepoints (253, 254) with ExIDs as described
+      in this document.
+
+   This mechanism is encouraged for all TCP options using the current
+   experimental codepoints in controlled environments:
+
+   >> All protocols using the TCP experimental option codepoints (253,
+      254), even those deployed in controlled environments, SHOULD use
+      ExIDs as described in this document.
+
+   This mechanism is required for all TCP options using the current
+   experimental codepoints that are publicly deployed, whether enabled
+   by default or not:
+
+   >> All protocols using the TCP experimental option codepoints (253,
+      254) that are deployed outside controlled environments, such as in
+      the public Internet, MUST use ExIDs as described in this document.
+
+   Once a TCP option uses the mechanism in this document, registration
+   of the ExID with IANA is required:
+
+   >> 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.  ExIDs can be either
+   16 bits or 32 bits.  In both cases, the value is stored in the header
+   in network-standard (big-endian) byte order.  ExIDs combine
+   properties of IANA registered codepoints with "magic numbers".
+
+   >> All ExIDs MUST be either 16 bits or 32 bits long.
+
+   Use of the ExID, whether 16 bit or 32 bit, 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.
+
+
+
+
+
+
+
+Touch                        Standards Track                    [Page 5]
+
+RFC 6994         Shared Use of Experimental TCP Options      August 2013
+
+
+   In order to conserve TCP option space, either for use within a
+   specific option or to be available for other options:
+
+   >> Options implementing the mechanism of this document SHOULD use
+      16-bit ExIDs, except where explicitly motivating the need for
+      32-bit ExIDs, e.g., to avoid false positives or maintain alignment
+      with an expected future assigned codepoint.
+
+   ExIDs are registered with IANA using "first come, first served"
+   (FCFS) priority based on the first two bytes.  Those two bytes are
+   thus sufficient to interpret which experimental option is contained
+   in the option field.
+
+   >> All ExIDs MUST be unique based on their first 16 bits.
+
+   The second two bytes serve as a "magic number".  A magic number is a
+   self-selected codepoint whose primary value is its unlikely collision
+   with values selected by others.  Magic numbers are used in other
+   protocols, e.g., bootstrap protocol (BOOTP) [RFC951] and DHCP
+   [RFC2131].
+
+   Using the additional magic number bytes helps the option contents
+   have the same byte alignment in the TCP header as they would have if
+   (or when) a conventional (non-experiment) TCP option codepoint is
+   assigned.  Use of the same alignment reduces the potential for
+   implementation errors, especially in using the same word-alignment
+   padding, if the same software is later modified to use a conventional
+   codepoint.  Use of the longer, 32-bit ExID further decreases the
+   probability of such a false positive compared to those using shorter,
+   16-bit ExIDs.
+
+   Use of the ExID does consume TCP option space but enables concurrent
+   use of the experimental codepoints and provides protection against
+   false positives, leaving less space for other options (including
+   other experiments).  Use of the longer, 32-bit ExID consumes more
+   space, but provides more protection against false positives.
+
+3.2.  Impact on TCP Option Processing
+
+   The ExID number is considered part of the TCP option, not the TCP
+   option header.  The presence of the ExID increases the effective
+   option Length field by the size of the ExID.  The presence of this
+   ExID is thus transparent to implementations that do not support TCP
+   options.
+
+   During TCP processing, ExIDs in experimental options are matched
+   against the ExIDs for each implemented protocol.  The remainder of
+   the option is specified by the particular experimental protocol.
+
+
+
+Touch                        Standards Track                    [Page 6]
+
+RFC 6994         Shared Use of Experimental TCP Options      August 2013
+
+
+   >> Experimental options with ExIDs that do not match implemented
+      protocols MUST be ignored.
+
+   The ExID mechanism must be coordinated during connection
+   establishment, just as with any TCP option.
+
+   >> TCP ExID, if used in any TCP segment of a connection, MUST be
+      present in TCP SYN segments of that connection.
+
+   >> TCP experimental option ExIDs, if used in any TCP segment of a
+      connection, SHOULD be used in all TCP segments of that connection
+      in which any experimental option is present.
+
+   Use of an ExID uses additional space in the TCP header and requires
+   additional protocol processing by experimental protocols.  Because
+   these are experiments, neither consideration is a substantial
+   impediment; a finalized protocol can avoid both issues with the
+   assignment of a dedicated option codepoint later.
+
+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.  Use of checksums or signatures may help an
+   experiment use the shorter ExID while reducing the corresponding
+   increased potential for false positives.
+
+   >> 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 TCP option codepoint.  This document
+   does not recommend a specific migration plan to transition from use
+   of the experimental TCP options/ExIDs to use of an assigned
+   codepoint.
+
+   However, once an assigned codepoint is allocated, use of an ExID
+   represents unnecessary overhead.  As a result:
+
+   >> Once a TCP option codepoint is assigned to a protocol, that
+      protocol SHOULD NOT continue to use an ExID as part of that
+      assigned codepoint.
+
+
+
+
+
+Touch                        Standards Track                    [Page 7]
+
+RFC 6994         Shared Use of Experimental TCP Options      August 2013
+
+
+   This document does not recommend whether or how an implementation of
+   an assigned codepoint can be backward compatible with use of the
+   experimental codepoint/ExID.
+
+   However, some implementers may be tempted to include both the
+   experimental and assigned codepoint in the same segment, e.g., in a
+   SYN to support backward compatibility during connection
+   establishment.  This is a poor use of limited resources; so, to
+   ensure conservation of the TCP option space:
+
+   >> A TCP segment MUST NOT contain both an assigned TCP option
+      codepoint and a TCP experimental option codepoint for the same
+      protocol.
+
+   Instead, a TCP that intends backward compatibility might send
+   multiple SYNs with alternates of the same option and discard all but
+   the most desired successful connection.  Although this approach may
+   resolve more slowly or require additional effort at the endpoints, it
+   is preferable to excessively consuming TCP option space.
+
+6.  Rationale
+
+   The ExIDs described in this document combine properties of IANA
+   FCFS-registered values with magic numbers.  Although IANA FCFS
+   registries are common, so too are those who either fail to register
+   or who 'squat' by deliberately using codepoints that are assigned to
+   others.  The approach in this document is intended to recognize this
+   reality and be more robust to its consequences than would be a
+   conventional IANA FCFS registry.
+
+   Existing ID spaces were considered as ExIDs in the development of
+   this mechanism, including IEEE Organizationally Unique Identifier
+   (OUI) and IANA Private Enterprise Numbers (PENs) [IEEE802] [OUI]
+   [RFC1155].
+
+   OUIs are 24-bit identifiers that are combined with 24 to 40 bits of
+   privately assigned space to create identifiers that are commonly
+   assigned to a unique piece of hardware.  OUIs are already longer than
+   the smaller ExID value, and obtaining an OUI is costly (currently
+   $1,885.00 USD).  An OUI could be obtained for each experiment, but
+   this could be considered expensive.  An OUI already assigned to an
+   organization could be shared if extended (to support multiple
+   experiments within an organization), but this would either require
+   coordination within an organization or an IANA registry; the former
+   is prohibitive, and the latter is more complicated than having IANA
+   manage the entire space.
+
+
+
+
+
+Touch                        Standards Track                    [Page 8]
+
+RFC 6994         Shared Use of Experimental TCP Options      August 2013
+
+
+   PENs were originally used in the Simple Network Management Protocol
+   (SNMP) [RFC1157].  PENs are identifiers that can be obtained without
+   cost from IANA [PEN].  Despite the current registry, the size of the
+   PEN assignment space is currently undefined and has only recently
+   been proposed (as 32 bits) [IANA-PEN].  PENs are currently assigned
+   to organizations, and there is no current process for assigning them
+   to individuals.  Finally, if the PENs are 32 bits as expected, they
+   would be larger than needed in many cases.
+
+7.  Security Considerations
+
+   The mechanism described in this document is not intended to enhance,
+   nor does it weaken the existing state of security for TCP option
+   processing.
+
+8.  IANA Considerations
+
+   IANA has created a "TCP Experimental Option Experiment Identifiers
+   (TCP ExIDs)" registry.  The registry records both 16-bit and 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 both of the TCP experimental option
+   codepoints, i.e., with TCP options with values of 253 and 254.
+
+   Entries are assigned on a First Come, First Served (FCFS) basis
+   [RFC5226].  The registry operates FCFS on the first two bytes of the
+   ExID (in network-standard order) but records the entire ExID (in
+   network-standard order).  Some examples are:
+
+   o  0x12340000 collides with a previous registration of 0x1234abcd
+
+   o  0x5678 collides with a previous registration of 0x56780123
+
+   o  0xabcd1234 collides with a previous registration of 0xabcd
+
+   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.
+
+
+
+
+
+Touch                        Standards Track                    [Page 9]
+
+RFC 6994         Shared Use of Experimental TCP Options      August 2013
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7, RFC
+              793, September 1981.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
+              ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+9.2.  Informative References
+
+   [Bi11]     Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres,
+              D., and Q. Slack, "Cryptographic protection of TCP
+              Streams", Work in Progress, September 2012.
+
+   [Ed11]
+              Eddy, W., "Additional TCP Experimental-Use Options", Work
+              in Progress, August 2011.
+
+   [IANA]     IANA, <http://www.iana.org/>.
+
+   [IANA-PEN] Liang, P. and A. Melnikov, "Private Enterprise Number
+              (PEN) Practices and Internet Assigned Numbers: Authority
+              (IANA) Considerations for Registration Procedures", Work
+              in Progress, June 2012.
+
+   [IEEE802]  IEEE, "IEEE Standard for Local and Metropolitan Area
+              Networks: Overview and Architecture", IEEE 802-2001, 8
+              March 2002.
+
+   [OUI]      IEEE, "Organizationally Unique Identifier (OUI) or
+              'Company_ID'",
+              <http://standards.ieee.org/develop/regauth/oui/>.
+
+   [PEN]      IANA, "Private Enterprise Numbers",
+              <http://www.iana.org/assignments/enterprise-numbers>.
+
+   [RFC951]   Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
+              September 1985.
+
+
+
+
+Touch                        Standards Track                   [Page 10]
+
+RFC 6994         Shared Use of Experimental TCP Options      August 2013
+
+
+   [RFC1155]  Rose, M. and K. McCloghrie, "Structure and Identification
+              of Management Information for TCP/IP-Based Internets", STD
+              16, RFC 1155, May 1990.
+
+   [RFC1157]  Case, J., Fedor, M., Schoffstall, M., and J. Davin,
+              "Simple Network Management Protocol (SNMP)", RFC 1157, May
+              1990.
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
+              2131, March 1997.
+
+   [RFC2780]  Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
+              Values In the Internet Protocol and Related Headers", BCP
+              37, RFC 2780, March 2000.
+
+   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
+              Considered Useful", BCP 82, RFC 3692, January 2004.
+
+   [RFC6013]  Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013,
+              January 2011.
+
+   [Si11]     Simpson, W., "TCP Cookie Transactions (TCPCT) Sockets
+              Application Program Interface (API)", Work in Progress,
+              April 2011.
+
+10.  Acknowledgments
+
+   This document was motivated by discussions on the IETF TCPM mailing
+   list and by Wes Eddy's proposal [Ed11].  Yoshifumi Nishida, Pasi
+   Sarolathi, and Michael Scharf provided detailed feedback.
+
+   This document was originally prepared using 2-Word-v2.0.template.dot.
+
+Author's Address
+
+   Joe Touch
+   USC/ISI
+   4676 Admiralty Way
+   Marina del Rey, CA 90292-6695 U.S.A.
+
+   Phone: +1 (310) 448-9151
+   EMail: touch@isi.edu
+
+
+
+
+
+
+Touch                        Standards Track                   [Page 11]
+