TCP Extended Options

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

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 https://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 28 December 2026.¶

Copyright Notice

Copyright (c) 2026 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Figure 1 depicts a TCP [RFC9293] segment.¶

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 final field in the TCP header contains TCP options [TCPOPTS]. Its length varies from 0 to 40 octets.¶

The Data Offset field represents the TCP data offset, 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 space between the fixed length fields in the TCP header and the TCP data.¶

The Data Offset field contains 4 bits. So, its nominal value ranges from 0 to 15. However, the value of the Data Offset field must be 5 or greater. This is because TCP data must follow the fixed-length header fields, and those fields occupy 20 octets.¶

Because the value of the Data Offset field cannot exceed 15, the TCP data offset cannot exceed 60 and the length of the Options field cannot exceed 40 (i.e., 60 minus 20).¶

In the future, applications may require more than 40 octets of TCP options. For example, an application may require a TCP Authentication Option (TCP-AO) [RFC5925] with a 384-bit MAC [I-D.bonica-tcpm-tcp-ao-long-algs]. This option requires 52 octets of option space.¶

This document defines a TCP extension that accommodates up to 1,016 octets of TCP options while maintaining backward compatibility with legacy implementations.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Terminology

This document uses the following terms:¶

• TCP Client - The TCP endpoint that initiates a session.¶

• TCP Server - The TCP endpoint that communicates with the TCP Client.¶

• Ordinary Segment (SEG-O) - A TCP segment, as defined in [RFC9293]. In a SEG-O, the Data Offset field has a value from 5 to 15.¶

• Updated Segment (SEG-U) - A TCP segment, as defined in [RFC9293]. However, in a SEG-U, the Data Offset field must be equal to 0. That value identifies the segment as a SEG-U. See Section 4.1.¶

• Ordinary SYN (SYN-O) - A SEG-O whose SYN bit is set and ACK bit is not set.¶

• Updated SYN (SYN-U) - A SEG-U whose SYN bit is set and ACK bit is not set.¶

• Ordinary SYN/ACK (SYN/ACK-O) - A SEG-O whose SYN and ACK bits are set.¶

• Updated SYN/ACK (SYN/ACK-U) - A SEG-U whose SYN and ACK bits are set.¶

• Ordinary TCP Connection (TCP-O) - A TCP connection, as defined in [RFC9293]. A TCP-O exchanges only SEG-O's.¶

• Updated TCP Connection (TCP-U) - A TCP connection, as defined in [RFC9293]. However, a TCP-U can exchange both SEG-O's and SEG-U's. See Section 4.¶

• Legacy TCP - A TCP implementation that supports TCP-O only.¶

• Upgraded TCP - A TCP implementation that supports both TCP-O and TCP-U.¶

4. The Updated TCP Connection (TCP-U)

A TCP-U sends SEG-U's:¶

• During the three-way handshake, even if those segments do not contain options¶

• When the segment contains more than 40 octets of options.¶

When neither of the above conditions is true, a TCP-U MAY send either SEG-O's or SEG-U's.¶

5. Backwards Compatibility Considerations

When a legacy TCP client initiates a session with an updated TCP server, it sends a SYN-O. Depending upon local policy and application requirements, the server can refuse the connection request or continue with a TCP-O.¶

When an updated TCP client initiates a session with a legacy TCP server, it sends a SYN-U. The server can ignore the SYN-U and allow the session to time out, as per [RFC9293] or respond with a SYN/ACK-O, in violation of [RFC9293].¶

In the latter case, depending upon local policy and application requirements, the updated TCP client can either terminate the connection or continue with a TCP-O.¶

The behavior described above is acceptable in environments where extended TCP options are essential. However, it is not acceptable in environments where extended TCP options are desirable, but not essential. In these environments, implementations SHOULD implement the Dual Three-Way Handshake described in Appendix A. In the Dual Three-Way Handshake, the client simultaneously initiates both a TCP-U and a TCP-O connection, and proceeds with whichever is accepted, preferring TCP-U when it is accepted.¶

6. Middleboxes and Accelerators

Legacy middleboxes and hardware accelerators ignore packets with Data Offset equal to 0. So, when a TCP client sends a SYN-U and receives no response, it cannot tell whether the packet was ignored by a middlebox, an accelerator, or the server.¶

Regardless of where the packet was ignored, the client observes the behavior described in Section 5 and behaves as if the packet were ignored by a legacy server.¶

7. Security Considerations

This document inherits security considerations from [RFC9293].¶

Setting the Data Offset field to 0 intentionally violates [RFC9293] Section 3.1, which mandates that the Data Offset field MUST be 5 or greater. This approach is acceptable because:¶

• [RFC9293] compliant implementations will reject or discard segments with invalid Data Offset values (less than 5) before processing options. This ensures that legacy TCP implementations cannot be exploited by SEG-U segments, as the segments will be discarded at the validation stage rather than processed.¶

• Upgraded TCP implementations MUST validate that the Data Offset field is either within the range [5, 15] (indicating a SEG-O) or exactly 0 (indicating a SEG-U). Any other value is malformed and MUST be discarded. Implementations MUST NOT attempt to infer meaning from intermediate values.¶

• Legacy middleboxes that strictly validate TCP headers per [RFC9293] will discard or ignore SEG-U segments, which is the desired behavior for backward compatibility. Middleboxes that do not validate Data Offset values may forward SEG-U segments unchanged.¶

8. IANA Considerations

This document makes no IANA requests.¶

9. 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?¶

  • Did you implement the Dual Three-Way Handshake?¶

• Effectiveness and sufficiency of OAM mechanisms¶

  • Did Wireshark work?¶

  • Did TCPDUMP work?¶

10. Acknowledgements

The authors wish to acknowledge Keshawn Hamlin, Jordan Head, C. M. Heard, Rahul Khali, Prashant Kumar, Amalesh Maity, Erin MacNeil, Jainam Parikh, Joe Touch and Michael Tuexen for their review and helpful comments.¶

Special thanks to Bob Briscoe, who contributed the Dual Three-Way Handshake in [I-D.briscoe-tcpm-inner-space].¶

11. References

Appendix A. Dual Three-Way Handshake

In this procedure an upgraded TCP client executes two three-way handshakes in parallel. One three-way handshake begins with a SYN-U while the other begins with a SYN-O. Both SYN segments have the same source address, destination address, and destination port. However, they use different source ports. So, while both SYN segments are directed to the same peer, they initiate different TCP sessions. The session that begins with a SYN-U is a TCP-U while the session that begins with SYN-O is a TCP-O.¶

Having sent a SYN-U and a SYN-O, the client may receive:¶

• A SYN/ACK-U and a SYN/ACK-O, in that order¶

• A SYN/ACK-U but not a SYN/ACK-O¶

• A SYN/ACK-O and a SYN/ACK-U, in that order¶

• A SYN/ACK-O but not a SYN/ACK-U¶

• Neither a SYN/ACK-U nor a SYN/ACK-O¶

The following subsections describe each scenario.¶

Authors' Addresses