Network Working Group W. Eddy
Internet-Draft NASA GRC/Verizon FNS
Expires: September 30, 2004 April 2004
Extending the Space Available for TCP Options
draft-eddy-tcp-loo-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3667.
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes a method for increasing the space available
for TCP options. Two new negotiable TCP options (LO and SLO) are
detailed which reduce the limitations imposed by the TCP header's
Data Offset field. The LO option provides this extension after
connection establishment, and the SLO option aids in transmission of
lengthy connection initialization and configuration options.
Eddy Expires September 30, 2004 [Page 1]
Internet-Draft TCP Long Options April 2004
1. Requirements Notation
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.
Eddy Expires September 30, 2004 [Page 2]
Internet-Draft TCP Long Options April 2004
2. Introduction
Every TCP header contains a 4-bit Data Offset (DO) field implying the
length of that segment's TCP header. The DO field has been specified
[1] as: "The number of 32 bit words in the TCP Header. This
indicates where the data begins. The TCP header (even one including
options) is an integral number of 32 bits long." For a TCP
implementation, this means that the boundary separating TCP control
data and application data is always exactly DO * 4 bytes from the
beginning of the TCP header.
As a 4-bit unsigned integer, DO's value is bounded between 0 and 15.
This allows for a maximum TCP header length of 60 bytes (15 * 4
bytes). The required fields in a TCP header occupy a fixed 20 bytes.
This leaves 40 bytes as the maximum amount of space for use by TCP
options.
While 40 bytes is a reasonable amount of space, sufficient for the
concurrent use of several presently defined TCP options, there are
cases where more space might be useful. For example, the SACK option
[2] uses a fixed 2 bytes for kind and length fields, and requires an
additional 8 bytes per SACK block. Thus, the maximum number of SACK
blocks a TCP acknowledgement may carry is limited to 4 (with 6 bytes
left over). Since SACK is commonly used with the Timestamp option
[3], which uses 10 bytes, this further limits the number of SACK
blocks that may be carried to 3. For specific scenarios involving
large windows and combinations of data and acknowledgement loss,
additional capacity for SACK blocks is useful.
Creation of new TCP options is also hindered by the lack of space
left over after currently-used options are accounted for. For long
options that must be present at connection-startup time, this is a
particular problem, as all negotiable options need to share 40 bytes
of space in a SYN segment. One way that has been used to get around
this limitation is overloading the Timestamp bytes in the SYN
segments [4]. There are other header fields that might be similarly
overloaded (e.g. the urgent pointer), but this approach is of
obviously limited utility, as it does not address the fundamental
limitation imposed by the DO field, and there are a finite number of
overloadable bits.
This document specifies two new TCP options, LO and SLO. The Long
Options (LO) option allows two hosts to negotiate for the ability to
use TCP headers longer than 60 bytes (and thus options space of
greater than 40 bytes) on subsequent segments. This is accomplished
by ignoring the DO field's value and adding a 16 bit field at a fixed
location in the header's options to replace it. The format and usage
of the LO option is detailed in section Section 3.
Eddy Expires September 30, 2004 [Page 3]
Internet-Draft TCP Long Options April 2004
Attempting to process initial SYN segements with greater than 60
bytes of TCP headers might cause errors if received by hosts that
consider anything past the DO-specified boundary to be application
data. For backwards compatibility reasons, the maximum length of
options on a connection-initiating SYN segment remains 40. The SYN
Long Options (SLO) option is used in the case where these 40 bytes
are not enough space to carry the desired startup configuration
options, and negotiates for later reliable delivery of the left-off
options. Section Section 4 describes the format and usage of the SLO
option.
Eddy Expires September 30, 2004 [Page 4]
Internet-Draft TCP Long Options April 2004
3. The Long Options (LO) Option
A host might implement some set of TCP options allowing it to predict
that greater than 40 bytes of TCP options space may be useful (for
example SACK, Timestamps, alternate checksums, etc). In this case, a
host MAY implement the LO option. When initiating connections
through an active open, hosts implementing the LO option SHOULD place
a LO option of the form shown in figure Figure 1 somewhere in the SYN
segment's options. The 16-bit field labelled "Header Length" should
filled in with the same value as the DO field in the required portion
of the TCP header.
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
+---------------+---------------+-------------------------------+
| Kind: # | Length = 4 | Header Length |
+---------------+---------------+-------------------------------+
TCP Long Options (LO) Option
Figure 1
Receipt of an acknowledgement covering the SYN and also containing a
LO option means the LO option MUST be used as the first option on all
subsequent segments, and the DO field on all subsequent segments
SHOULD be set to 6. The value 6 represents the length of the
required portions of the TCP header plus the LO option. The Header
Length field of a LO option overrides the DO field in the fixed
header, and has an identical meaning, but with 16 bits of unsigned
precision rather than 4. Semantically, this still represents the
offset from the beginning of the TCP header bounding the start of
application data bytes. Since the LO option is found in a fixed place
on all susbequent segments, it essentially becomes part of the
required header, and looking up the Header Length field is of similar
computational complexity to that required when the DO field is used.
Since an LO option's Header Length field is of the same range as the
IP header's Total Length field [5], this allows TCP options to
consume an entire maximum-sized IP datagram's length (minus the IP
header and required TCP header fields). No matter what size the
options section of a TCP header is, it must still be appended with
zero-padding to make the total header a multiple of 32 bits, per RFC
793 [1].
Hosts implementing the LO option that receive a SYN segment with the
LO option present, SHOULD reply with an LO option present in their
SYN-ACK, if they accept the connection. The LO option is then used
on all subsequent segments to override the DO field. It can be seen
Eddy Expires September 30, 2004 [Page 5]
Internet-Draft TCP Long Options April 2004
that in both the normal case where one host passively opens and
another actively opens, and the more rare case where two hosts
simultaneously initiate active opens, the LO option's use can be
successfully negotiated.
Eddy Expires September 30, 2004 [Page 6]
Internet-Draft TCP Long Options April 2004
4. The SYN Long Options (SLO) Option
If a host wants to send more than 40 bytes of initialization options,
it uses the SYN Long Options OK (SLO-OK) option, as shown in Figure
2, in the SYN segment generated by an active open. A passive opening
host receiving this option on a SYN SHOULD echo the option back on
the SYN-ACK it generates, if it implements the SLO option. If a host
has both sent and received SYN segments with the SLO-OK option, then
the SLO option is safe to use for transmitting additional bytes of
options that would have ideally been in the SYN.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
| Kind: # | Length = 2 |
+---------------+---------------+
TCP SYN Long Options OK (SLO-OK) Option
Figure 2
Since there is no guarantee that the SLO option will be successfully
negotiated via SLO-OKs, the additional 38 bytes left over aside from
the 2 byte SLO-OK option should be filled with the most important
remaining options that will fit. Since there is also the unlikely
case where a host implementing the SLO option, but not needing it for
a particular SYN it sends, will be simultaneously active opening with
another host that does need the SLO option, a host MAY choose to send
the SLO-OK option with a SYN, even if it does not plan to use the SLO
option later. In this case, the SLO option in later segments will
simply have the value of its Additional Bytes field (see Figure 3)
set to 0.
After successful SLO-OK negotiation, additional data or
acknowledgement segments MUST carry a SLO option until the first data
byte has been acknowledged. The SLO option, shown in figure Figure
3, is identified by the same Kind field as the SLO-OK option, but its
Length is 4 instead of 2. The trailing 2 bytes hold a 16 bit
unsigned count of the additional bytes that would have been in the
SYN segment's options, if it had been possible. This represents an
offset from the end of the SLO option, to the last byte that should
be considered a SYN option. The next "Additional Byte Count"-number
of bytes trailing the SLO option MUST be the ones that did not fit in
the SYN segment. The SLO option should always come first (or second
if LO is in use) if it is used in a segment's options, followed by
the additional SYN options, and then by normal options.
Eddy Expires September 30, 2004 [Page 7]
Internet-Draft TCP Long Options April 2004
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
+---------------+---------------+-------------------------------+
| Kind: # | Length = 4 | Additional Byte Count |
+---------------+---------------+-------------------------------+
TCP SYN Long Options (SLO) Option
Figure 3
Since TCP connection establishment is often concluded by a pure
acknowledgement (carrying no data), only placing the SLO option and
additional SYN options in such a single, unreliable segment would be
risky. This is why a host MUST continue transmitting SLO options on
all segments until its first byte of sent data is acknowledged.
Acknowledgement of the first data-byte implicitly covers the SLO and
trailing options, as these must have been received end-to-end with
the first data byte.
If a host does not sent any data bytes, but if by some means (perhaps
through the received options) it is possible to derive either an
explicit or implicit acknowledgement of even a single option
transmitted in the SLO data (for example via a Timestamp echo), then
a host MAY choose to stop transmitting the SLO data. This special
case overrides the previously specified MUST condition.
A host SHOULD NOT continue sending SLO options after it has received
acknowledgement of the first data byte, nor should a host process
incoming SLO options other than on the first valid segment it
receives that carries them.
Using the LO option in no way requires the use of SLO option, nor
does SLO require the use of LO. Without LO, however, the
connection-establishment options space is only doubled. With LO, SLO
can reliably transmit up to a full IP payload (minus headers) worth
of initialization options. If the LO option's use is desired, it
MUST be in the SYN segment (with or without SLO-OK). If LO and
SLO-OK are successfully negotiated, then LO MUST be the first option
in subsequent segments, immediately followed by the SLO option,
additional bytes of SYN options, and finally non-SYN options after
the delimeter specified in the SLO option.
Eddy Expires September 30, 2004 [Page 8]
Internet-Draft TCP Long Options April 2004
5. Security Considerations
The TCP options presented in this document open no additional
vulnerabilities that we are aware of.
Eddy Expires September 30, 2004 [Page 9]
Internet-Draft TCP Long Options April 2004
6. Acknowledgements
This document benefitted specifically from discussions with Josh
Blanton and Shawn Ostermann concerning another proposed TCP
extension.
Eddy Expires September 30, 2004 [Page 10]
Internet-Draft TCP Long Options April 2004
References
[1] Postel, J., "Transmission Control Protocol", RFC 793, September
1981.
[2] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgement Option", RFC 2018, October 1996.
[3] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High
Performance", RFC 1323, May 1992.
[4] Snoeren, A. and H. Balakrishnan, "An End-to-End Approach to Host
Mobility", Proc. of the Sixth Annual ACM/IEEE International
Conference on Mobile Computing and Networking, August 2000.
[5] Postel, J., "Internet Protocol", RFC 791, September 1981.
Author's Address
Wesley M. Eddy
NASA GRC/Verizon FNS
EMail: weddy@grc.nasa.gov
Eddy Expires September 30, 2004 [Page 11]
Internet-Draft TCP Long Options April 2004
Intellectual Property Statement
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 IETF's procedures with respect to rights in IETF 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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eddy Expires September 30, 2004 [Page 12]
