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]