An Upgraded TCP Session Type
draft-bonica-tcpm-extended-options-05
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ron Bonica , Tony Li , Ping Chen , Prashant Kumar , Reji Thomas , A Sujeet Nayak , Ayan Banerjee | ||
| Last updated | 2026-08-29 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bonica-tcpm-extended-options-05
TCPM Working Group R. Bonica
Internet-Draft T. Li
Intended status: Experimental P. Chen
Expires: 1 March 2027 P. Kumar
HPE
R. Thomas
Arista Networks
A. Sujeet Nayak
A. Banerjee
Cisco Systems
28 August 2026
An Upgraded TCP Session Type
draft-bonica-tcpm-extended-options-05
Abstract
Currently, TCP maintains ordinary sessions (SES-O) in which ordinary
segments (SEG-O) are exchanged. Each SEG-O can accommodate up to 40
octets of options.
In the future, applications may require more than 40 octets of
options. For example, an application may use a 36-byte TCP
Authentication Option (TCP-AO), leaving insufficient space for other
required options.
Therefore, this document describes an experiment in which upgraded
sessions (SES-U) and upgraded segments (SEG-U) are introduced. Each
SEG-U can accommodate up to 1,016 octets of Individual 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 1 March 2027.
Bonica, et al. Expires 1 March 2027 [Page 1]
Internet-Draft TCP-U August 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. SEG-O Versus SEG-U . . . . . . . . . . . . . . . . . . . . . 4
4. SES-O Versus SES-U . . . . . . . . . . . . . . . . . . . . . 5
5. TCP-AO Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 6
7. Middleboxes and Accelerators . . . . . . . . . . . . . . . . 7
8. Applicability and Disclaimer . . . . . . . . . . . . . . . . 7
9. Application Layer Considerations . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
12. Experimental Results . . . . . . . . . . . . . . . . . . . . 8
12.1. Success Criteria . . . . . . . . . . . . . . . . . . . . 9
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
14.1. Normative References . . . . . . . . . . . . . . . . . . 9
14.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
[RFC9293] defines TCP sessions and segments. In this document, those
sessions and segments are called ordinary sessions (SES-O) and
ordinary segments (SEG-O). Figure 1 depicts an SEG-O.
Bonica, et al. Expires 1 March 2027 [Page 2]
Internet-Draft TCP-U August 2026
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 :
: |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
Figure 1: Ordinary TCP Segment (SEG-O)
Every SEG-O contains a header. Some SEG-O's also contain data.
Each field in the header, except for the last, has a fixed length.
These initial fixed-length fields occupy 20 octets, collectively.
One of these fields is called the Data Offset field.
The last field in the header contains options [TCPOPTS]. Its length
varies from 0 to 40 octets.
The Data Offset field identifies the boundary between the segment
header and the segment data. It is 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 initial fixed-length fields and the data.
The Data Offset field contains 4 bits. So, its nominal value ranges
from 0 to 15. However, values 0 to 4 are invalid. This is because
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 data
offset cannot exceed 60 and the length of the Options field cannot
exceed 40 (i.e., 60 minus 20).
Bonica, et al. Expires 1 March 2027 [Page 3]
Internet-Draft TCP-U August 2026
In the future, applications may require more than 40 octets of
options. For example, an application may use a 36-byte TCP
Authentication Option (TCP-AO) [RFC5925]
[I-D.bonica-tcpm-tcp-ao-long-algs], leaving insufficient space for
other required options.
Therefore, this document describes an experiment in which upgraded
sessions (SES-U) exchange upgraded segments (SEG-U). Each SEG-U can
accommodate up to 1,016 octets of Individual Options.
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. SEG-O Versus SEG-U
SEG-O and SEG-U are semantically identical, except that SEG-O can
accommodate only 40 octets of options while SEG-U can accommodate
1,016 octets of Individual Options.
SEG-O and SEG-U share the format depicted in Figure 1. However:
* In SEG-O, the Data Offset value ranges from 5 to 15, inclusive.
Values 0 to 4 are invalid.
* In SEG-U, the Data Offset value MUST be equal to 0. All other
values are invalid.
The Data Offset value is the only attribute by which a SEG-O can be
distinguished from a SEG-U. In a SEG-U, the Options field MUST be as
depicted in Figure 2.
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 :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SEG-U TCP Options
Bonica, et al. Expires 1 March 2027 [Page 4]
Internet-Draft TCP-U August 2026
* Length: 8-bit unsigned integer. Represents the length of TCP
Options, including the Length and Reserved fields. Measured in
4-octet units. Value MUST be 1 or greater. A value of 1
indicates that only the Length and Reserved fields are present,
with no Individual Options (i.e., the options region is empty).
* Reserved: MUST be set to 0 by the sender and MUST be ignored by
the receiver.
* Individual Options: Defined in [TCPOPTS].
In a SEG-U, the receiver MUST use the Length field to determine the
boundary between the Options field and segment data. Segment data
begins at byte offset 20 + (Length x 4) from the start of the TCP
header, where 20 is the length of the fixed-length header fields.
This replaces the role of the Data Offset field, which MUST NOT be
used as an offset in a SEG-U.
Before accessing the Options field or segment data, the receiver MUST
verify that the received TCP segment is at least 20 + (Length x 4)
octets long. If the received TCP segment is shorter than the length
indicated by the Length field, the receiver MUST discard the SEG-U as
malformed.
The TCP checksum for a SEG-U MUST be calculated and validated as
specified in [RFC5925]. It covers the IP pseudo-header, the entire
TCP header (including the fixed-length fields, the Data Offset field,
and the complete Options field), and the segment data. When the MKT
TCP option flag excludes TCP options from the MAC, the four-byte
Length/Reserved prefix and TCP-AO (with its MAC field zeroed) are
still included in the MAC input.
The receiver MUST validate the checksum before processing Individual
Options or delivering segment data.
A SEG-U can include up to 1,016 octets of Individual Options.
However, options consume space within the path MTU, leaving less
space for segment data and increasing the risk that a segment will
exceed the path MTU. Therefore, although larger options fields may
be required in the distant future, TCP options are RECOMMENDED not to
exceed 256 octets.
4. SES-O Versus SES-U
TCP clients initiate a SES-O by sending a SEG-O with the SYN bit set.
The TCP server MAY respond with a SEG-O with the SYN and ACK bits
set. However, the TCP server MUST NOT respond with a SEG-U.
Bonica, et al. Expires 1 March 2027 [Page 5]
Internet-Draft TCP-U August 2026
Within the context of a SES-O, SEG-O's can be sent, received and
processed. However, SEG-U's MUST NOT be sent. If they are received,
they MUST be silently discarded.
Likewise, TCP clients initiate a SES-U by sending a SEG-U with the
SYN bit set. The TCP server MAY respond with a SEG-U with the SYN
and ACK bits set. However, the TCP server MUST NOT respond with a
SEG-O.
Within the context of a SES-U, SEG-U's can be sent, received and
processed. However, SEG-O's MUST NOT be sent. If they are received,
they MUST be silently discarded.
In all other respects, a SES-U conforms to the specifications of
[RFC9293].
5. TCP-AO Considerations
This document is compliant with TCP-AO [RFC5925]. According to
[RFC5925], the Master Key Tuple (MKT) has a TCP option flag. This
flag indicates whether TCP options other than TCP-AO are included in
the MAC calculation. When options are included, the content of all
options, in the order present, is included in the MAC, with TCP-AO's
MAC field zeroed out. When the options are not included, all options
other than TCP-AO are excluded from all MAC calculations (skipped
over, not zeroed).
In order to remain compliant with [RFC5925], the first 4 octets of
the Options field MUST be included in the MAC calculation, regardless
of whether the TCP option flag is set.
6. Backwards Compatibility
Legacy TCP implementations support SES-O only. TCP implementations
participating in this experiment support both SES-O and SES-U.
Therefore:
* A legacy TCP client can establish an SES-O with TCP server
participating in this experiment.
* A TCP client participating in this experiment can establish an
SES-O with a legacy server.
* A TCP client participating in this experiment can establish an
SES-U with a TCP server participating in this experiment.
Bonica, et al. Expires 1 March 2027 [Page 6]
Internet-Draft TCP-U August 2026
However, a TCP client participating in this experiment cannot
establish an SES-U with a legacy server. The legacy server will
silently discard the SEG-U SYN and the three-way handshake will time
out.
7. Middleboxes and Accelerators
Legacy middleboxes and hardware accelerators may discard, reject, or
mishandle packets with Data Offset equal to 0. So, when a TCP client
sends a SEG-U with the SYN bit set and receives no response, it
cannot tell whether the packet was discarded or mishandled by a
middlebox or accelerator, or discarded by the server.
Regardless of where the packet was ignored, the client observes the
behavior described in Section 6 and behaves as if the packet were
ignored by a legacy server.
8. Applicability and Disclaimer
Given the limitations mentioned in Section 6 and Section 7, TCP
clients participating in this experiment SHOULD initiate a SES-U only
under the following conditions:
* When the TCP peer is known to be participating in the experiment
and capable of supporting SES-U
* When the application requires more than 40 octets of options and
the TCP session should not be established unless 1,016 octets of
Individual Options can be supported.
Furthermore, TCP clients participating in this experiment SHOULD NOT
initiate a SES-U in the presence of legacy middleboxes.
9. Application Layer Considerations
In order to acheive backwards compatibility at the application layer,
an application may initiate two separate TCP sessions with a peer,
with one session being a SES-U and the other being a SES-O.
Depending upon which session or sessions initiate successfully, the
application uses one session and terminates the other. This approach
is similar to that described in Happy Eyeballs [RFC6555].
Because this is orchestrated at the application layer, it is beyond
the scope of this document.
Bonica, et al. Expires 1 March 2027 [Page 7]
Internet-Draft TCP-U August 2026
10. 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.
11. IANA Considerations
This document makes no IANA requests.
12. 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
Bonica, et al. Expires 1 March 2027 [Page 8]
Internet-Draft TCP-U August 2026
- Did you deploy two interoperable implementations?
- Did you experience interoperability problems?
* Effectiveness and sufficiency of OAM mechanisms
- Did Wireshark work?
- Did TCPDUMP work?
12.1. Success Criteria
Successful experimental deployment SHOULD demonstrate the following:
1. Implementation and testing by at least two independent developers
or organizations
2. Interoperability validation between implementations,
demonstrating that SEG-U segments are correctly generated and
processed
3. At least one deployment in a testbed or production environment
4. No critical security vulnerabilities discovered during the
experiment
5. Positive or neutral feedback regarding middlebox compatibility
and packet handling
13. Acknowledgements
The authors wish to acknowledge Keshawn Hamlin, Jordan Head, C. M.
Heard, Rahul Khali, Amalesh Maity, Erin MacNeil, Bob Briscoe, Jainam
Parikh, Joe Touch and Michael Tuexen for their review and helpful
comments.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Bonica, et al. Expires 1 March 2027 [Page 9]
Internet-Draft TCP-U August 2026
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/rfc/rfc9293>.
14.2. Informative References
[I-D.bonica-tcpm-tcp-ao-long-algs]
Bonica, R. P., Li, T., Chen, P., Thomas, R., Ammunje, S.
N., and A. Banerjee, "Cryptographic Algorithms That
Produce 256-bit MACs For Use With TCP-AO", Work in
Progress, Internet-Draft, draft-bonica-tcpm-tcp-ao-long-
algs-05, 3 August 2026,
<https://datatracker.ietf.org/doc/html/draft-bonica-tcpm-
tcp-ao-long-algs-05>.
[I-D.briscoe-tcpm-inner-space]
Briscoe, B., "Inner Space for TCP Options", Work in
Progress, Internet-Draft, draft-briscoe-tcpm-inner-space-
01, 27 October 2014,
<https://datatracker.ietf.org/doc/html/draft-briscoe-tcpm-
inner-space-01>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/rfc/rfc5925>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <https://www.rfc-editor.org/rfc/rfc6555>.
[TCPOPTS] Internet Assigned Numbers Authority (IANA), "Transmission
Control Protocol (TCP) Parameters -", Web
<https://www.iana.org/assignments/tcp-parameters/tcp-
parameters.xhtml#tcp-parameters-1>.
Authors' Addresses
Ron Bonica
HPE
Herndon, Virginia
United States of America
Email: ronald.bonica@hpe.com
Tony Li
HPE
Sunnyvale, California
United States of America
Bonica, et al. Expires 1 March 2027 [Page 10]
Internet-Draft TCP-U August 2026
Email: tony.li@tony.li
Ping Chen
HPE
Canada
Email: ping.chen@hpe.com
Prashant Kumar
HPE
India
Email: prashant.kumar5@hpe.com
Reji Thomas
Arista Networks
India
Email: reji.thomas@arista.com
Sujeet Nayak Ammunje
Cisco Systems
India
Email: sua@cisco.com
Ayan Banerjee
Cisco Systems
United States of America
Email: ayabaner@cisco.com
Bonica, et al. Expires 1 March 2027 [Page 11]