One document matched: draft-eddy-tcpm-addl-exp-options-00.txt
Network Working Group W. Eddy
Internet-Draft MTI Systems
Updates: 4727 (if approved) August 16, 2011
Intended status: Standards Track
Expires: February 17, 2012
Additional TCP Experimental-Use Options
draft-eddy-tcpm-addl-exp-options-00
Abstract
There have been multiple issues with the allocation of TCP option
kind numbers recently. Two of these issues, which this document
attempts to address, are that there were only a small number of
options reserved by RFC 4727 for experiment and test use in the RFC
3692 style to begin with, and both of these have been used in
shipping products. This impacts the ability of other research and
experimental efforts to develop and test running code since
registration of other option numbers requires either IESG Approval or
Standards Action. This document proposes designation of additional
experimental options in the IANA registry for TCP Option Kind
Numbers, intended to resolve the possible barriers to using the
existing RFC 3962 experimental-use options.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it
for publication as an RFC and to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 17, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Eddy Expires February 17, 2012 [Page 1]
Internet-Draft TCP Experimental Options August 2011
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. Additional Experimental-Use Options . . . . . . . . . . . . . . 4
3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Eddy Expires February 17, 2012 [Page 2]
Internet-Draft TCP Experimental Options August 2011
1. Introduction
TCP options are a fundamental mechanism for extending and enhancing
TCP's functionality. In the past, the addition of TCP options (e.g.
Window Scale, Timestamp [RFC1323], and Selective Acknowledgements
[RFC2018]) has supported the protocol's evolution and helped its
applicability to expand as the Internet and types of links available
grew.
However, there has been significant confusion with regards to how TCP
option kind numbers are managed. This is, frankly, dangerous to the
Internet, if it persists. There is a limited pool of options and due
to misunderstandings the usable portion of this pool has shrunk to an
unknown extent.
Registration of TCP option kind numbers is a function of the IANA
[RFC2780]. Values are assigned following either (1) IESG Approval,
or (2) Standards Action process, which are defined in [RFC2434].
Some vendors have not followed these procedures and simply shipped
products using option kind numbers chosen themselves. This poisons
the pool of options available, as it potentially causes conflicts if
IANA later registers those same kind numbers for a use that followed
the proper registration process. This has been recognized as a
mistake, and vendors have expressed a desire to avoid it in the
future and are working towards possible transition of such products
to registered options numbers.
Two TCP option numbers have been designated for experimental use
[RFC4727], which are not intended to be used in general deployments
or enabled by default in products or other general releases unless
explicitly enabled by an end-user [RFC3692].
Unfortunately, at least one vendor intending to avoid shipping its
products using unregistered option numbers, actually shipped products
using the experimental-use numbers. These numbers are being used by
some deployed middleboxes and the impacts to other people trying to
use the same kind numbers for other purposes is not broadly
understood, especially since the presence of such middleboxes on a
path may be unknown a priori.
A recent TCP research effort testing running code over the Internet
that would have been a perfect candidate for using the experimental-
use numbers shied away from this due to the deployed middlebox issue
and chose to improperly use yet more unregistered TCP option kind
numbers.
Another recent issue is that with multiple ongoing efforts to extend
TCP, there may be implementations that integrate a number of
Eddy Expires February 17, 2012 [Page 3]
Internet-Draft TCP Experimental Options August 2011
extensions requiring experimental-use options. Two kind numbers may
not be sufficient for such cases, and adding sub-kind identifiers
within the option payload may be complex or even impossible.
This document attempts to mitigate the situation and remove excuses
for such instances in the future by requesting IANA to register a
greater number of TCP experimental-use options that would also follow
the RFC 3692 spirit for their intended use.
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]
2. Additional Experimental-Use Options
This document proposes to create an additional sixteen experimental-
use TCP option kinds in the spirit of RFC 3692. As this may seem
like a large number compared to the current two that RFC 4727
requested, some rationale is provided in the next section.
Of these sixteen option kinds, the option-length field for all of
them will be defined as variable, but in all cases will hold a value
of at least 2 in order to account for the kind and length fields.
The option kind numbers allocated should be contiguous in order to
support potential ease of updating filter rules and other databases
used in firewalls and other middleboxes, as well as various other
software tools for packet analysis and other uses.
3. Rationale
There are only 8 bits that comprise a TCP Option Kind field, lending
256 possible unique codepoints. Of these, there are the 2 identified
in RFC 4727 for experimental-use and 19 with registrations that are
currently not identified as obsolete (historic and currently unused)
or unassigned due to release of prior registrations. Of these,
several are not known to be in general use and could likely be reaped
if needed. Additionally, 11 kind numbers have been identified as
obsolete or unassigned due to registration being released, and 6 more
are known to be deployed without proper IANA assignment. One further
protocol under development in the IETF (Multipath TCP) requires an
IANA option kind assignment yet-to-be-made.
This leaves 217 option kind values that both have never been
registered and are not known to have been under deployment without
registration. Even though this document proposes to claim 16 of
Eddy Expires February 17, 2012 [Page 4]
Internet-Draft TCP Experimental Options August 2011
these values for experimental-use, there will still be 201 option
kind values seemingly fully available, which represents over 78% of
the option kind numbers. Based on TCP's existence for several
decades without even using a quarter of the available options space,
the remaining pool of kind numbers should be sufficient for many more
decades to come.
Further, 16 option numbers for experimental use should be more than
sufficient by a factor of 2 to 4 in order to permit implementing and
testing combinations of experimental TCP extensions that do not yet
have their own registered option kind numbers. This is especially
true as recently Multipath TCP design has set an example for using a
sub-kind / subtype field in order to avoid requiring multiple kind
numbers from the TCP registry. This practice could be reused by
future similar extensions making extensive use of TCP options.
4. Security Considerations
This document creates no additional security considerations for TCP
implementations.
Firewalls and other network devices that aggressively filter
unrecognized TCP options may cause difficulties in using the new
experimental-use kind numbers defined by this document. Managers and
vendors of such firewalls should reconsider whether such filtering is
necessary or useful as this practice represents a major impediment to
innovation in TCP.
5. IANA Considerations
This document requests that IANA allocate sixteen contiguous TCP
option values for experimental-use in the spirit of RFC 3692, which
will be described in the registry as:
o Length: N
o Meaning: RFC3692-style Experiment - MUST NOT be used by default in
shipping products, or other uncontrolled wide-scale deployments
outside of an experimental context
o Reference: (this document's RFC number, to be filled in)
Allocation from the rear of the available reserved space adjacent
below the two existing experimental-use options (253 and 254) is
desirable.
Eddy Expires February 17, 2012 [Page 5]
Internet-Draft TCP Experimental Options August 2011
6. References
6.1. Normative References
[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.
6.2. Informative References
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 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.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
Author's Address
Wesley M. Eddy
MTI Systems
MS 500-ASRC
NASA Glenn Research Center
21000 Brookpark Road
Cleveland, OH 44135
USA
Phone: +1-216-433-6682
Email: wes@mti-systems.com
Eddy Expires February 17, 2012 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-24 01:56:12 |