]> TCP Extended Options HPE
Herndon Virginia USA rbonica@juniper.net
HPE
Sunnyvale California USA tli@juniper.net
Transport TCPM Working Group TCP The TCP header can accommodates 40 octets of TCP options. However, modern applications may require more than 40 octets of TCP Options. Therefore, this document describes an experiment that extends the TCP Options field. If this experiment is successful, it will demonstrate that the extension procedures described herein are implementable and deployable. It will also demonstrate that they maintain backwards compatibility.
Introduction depicts a TCP segment.
TCP Segment 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 = Source Port Destination Port Sequence Number T C Acknowledgment Number P Data C E U A P R S F H Offset Rsrvd W C R C S S Y I Window E R E G K H T N N A D Checksum Urgent Pointer E R [Options] = : : Data : : =
Every TCP segment contains a header. Some TCP segments also contain data. Each field in the TCP header, except for the last, has a fixed length. The fixed length fields in the TCP header occupy 20 octets. One of these fields is called the Data Offset field. The last field in the TCP header is called the Options field. When present, the Options field contains a list of TCP options . Its length varies from 0 to 40 octets. The Data Offset field represents the offset of the Data field in the TCP segment, measured in 4-octet units. The Data Offset field also determines the length of the Options field. This is because the Options field consumes all of the space between the fixed length fields in the TCP header and the Data field. The Data Offset field contains 4 bits. So, its value ranges nominally from 0 to 15. However, the value of the Data Offset field must be 5 or greater. This is because the Data field must follow the fixed length fields in the TCP header. As stated above, those fields occupy 20 octets. Because the value of the Data Offset field cannot exceed 15, the offset of the Data field cannot exceed 60 and the length of the Options field cannot exceed 40 (i.e., 60 minus 20). Modern applications may require more than 40 octets of TCP Options. Therefore, this document describes an experiment that extends the TCP Options field. If this experiment is successful, it will demonstrate that the extension procedures described herein are implementable and deployable. It will also demonstrate that they maintain backwards compatibility.
Conventions and Definitions 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 BCP14 when, and only when, they appear in all capitals, as shown here.
Extending The TCP Options field According to :
  • The Data Offset field must have a value of 5 or greater
  • TCP Options can be present only when the Data Offset field has a value greater than 5.
This document allows the Data Offset field to have a value of 0. When the Data Offset field has a value of 0, the format of the TCP Options field is as depicted in .
TCP Options 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 Length Reserved : : Individual Options : : :
  • Length: 8-bit unsigned integer. Represents the length of the TCP Options field, including the length and reserved fields. Measured in 4-octet units. Value MUST be greater than 11.
  • Reserved: MUST be set to 0 by the sender and MUST be ignored by the receiver.
  • Individual Options: Defined in .
When a TCP segment contains 40 bytes of TCP Options or fewer, it MUST be formatted exactly as described in . When a TCP segment contains more than 40 bytes of TCP Options, the Data Offset field MUST be equal to 0 and the Options field MUST be formatted as described in this section. When the Data Offset field is equal to 0, a TCP segment can include over 1,000 bytes of options. While this may be required in the distant future, it is RECOMMENDED that TCP options not exceed 256 bytes.
Checksum Considerations As per , checksums are calculated over the entire Options field.
Backwards Compatibility Considerations
Extended Options Used During Connection Establishment When one TCP endpoint is not capable of processing segments with Data Offset equal to 0, and such a segment is sent during connection establishment, the segment will be ignored and the connection will not establish.
Extended Options Used After Connection Establishment Once a TCP session has been established, TCP implementations MUST NOT send segments with Data Offset equal to 0 unless extended options were used during connection establishment.
Future Work In the future, the WG may develop a signaling mechanism so that the restriction mentioned in can be lifted.
Middleboxes and Accelerators Legacy middleboxes and hardware accelerators discard packets with Data Offset equal to 0. Therefore, this experiment should not be performed in the presence of such devices.
Security Considerations This document inherits security considerations from .
IANA Considerations This document makes no IANA requests.
Experimental Results Parties participating in this experiment should publish experimental results within one year of the publication of this document Experimental results should address the following:
  • Effort required to deploy
    • Was deployment incremental or network-wide?
    • Was there a need to synchronize configurations at each node or could nodes be configured independently?
    • Did the deployment require hardware upgrade?
  • Scale of deployment
  • Interoperability
    • Did you deploy two interoperable implementations?
    • Did you experience interoperability problems?
  • Effectiveness and sufficiency of OAM mechanisms
    • Did Wireshark work?
    • Did TCPDUMP work?
Acknowledgements The authors wish to acknowledge Keshawn Hamlin, Jordan Head, Rahul Khali, Prashant Kumar, Amalesh Maity, Erin MacNeil, Jainam Parikh, Joe Touch and Michael Tuexen for their review and helpful comments.
References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Transmission Control Protocol (TCP) This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. Informative References Transmission Control Protocol (TCP) Parameters - Internet Assigned Numbers Authority (IANA)