Internet-Draft tcp-ext-opt May 2025
Bonica & Li Expires 1 December 2025 [Page]
Workgroup:
TCPM Working Group
Internet-Draft:
draft-bonica-tcpm-extended-options-00
Published:
Intended Status:
Experimental
Expires:
Authors:
R. Bonica
Juniper Networks
T. Li
Juniper Networks

TCP Extended Options

Abstract

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 the extension procedures described herein are implementable and deployable. It will also demonstrate that they maintain backwards compatibility.

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 December 2025.

Table of Contents

1. Introduction

Figure 1 depicts a TCP [RFC9293] 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                              :
:                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  =
Figure 1: TCP 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 last field in the TCP header is called the Options field. When present, the Options field contains a list of TCP options [TCPOPTS]. 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 the extension procedures described herein are implementable and deployable. It will also demonstrate that they maintain backwards compatibility.

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. Extending The TCP Options field

According to [RFC9293]:

This document allows TCP options to be present when the Data Offset field has 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 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    |                                               :
+-+-+-+-+-+-+-+-+                                               :
|                          Individual Options                   :
:                                                               :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: TCP Options

When a TCP segment contains 40 bytes of TCP Options or fewer, it MUST be formatted exactly as described in [RFC9293]. 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.

4. Checksum Considerations

As per [RFC9293], checksums are calculated over the entire Options field.

5. Backwards Compatibility Considerations

Legacy TCP implementations, including middleboxes, cannot parse segments in which the Data Offset is equal to 0. [RFC9293] is silent regarding the required behavior when a TCP implementation receives a segment with Data Offset equal to 0.

The following TCP implementations have been tested and are known to discard the segment:

6. Security Considerations

Legacy middleboxes, including firewalls, cannot parse segments in which the Data Offset is equal to 0. They are likely to discard packets that they cannot parse.

7. IANA Considerations

This document does not request any IANA actions.

8. 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:

9. Acknowledgements

The authors wish to acknowledge Keshwan Hamlin, Jordan Head, and Joe Touch for their review and helpful comments.

10. References

10.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9293]
Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, , <https://www.rfc-editor.org/rfc/rfc9293>.

10.2. Informative References

[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
Juniper Networks
Herndon, Virginia
United States of America
Tony Li
Juniper Networks
Sunnyvale, California
United States of America