2.1. Requirements Language

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 BCP 14 [3] [12] when, and only when, they appear in all capitals, as shown here.¶

Each use of RFC 2119 keywords in the document is individually labeled and referenced in Appendix B, which summarizes implementation requirements.¶

Sentences using "MUST" are labeled as "MUST-X" with X being a numeric identifier enabling the requirement to be located easily when referenced from Appendix B.¶

Similarly, sentences using "SHOULD" are labeled with "SHLD-X", "MAY" with "MAY-X", and "RECOMMENDED" with "REC-X".¶

For the purposes of this labeling, "SHOULD NOT" and "MUST NOT" are labeled the same as "SHOULD" and "MUST" instances.¶

2.2. Key TCP Concepts

TCP provides a reliable, in-order, byte-stream service to applications.¶

The application byte-stream is conveyed over the network via TCP segments, with each TCP segment sent as an Internet Protocol (IP) datagram.¶

TCP reliability consists of detecting packet losses (via sequence numbers) and errors (via per-segment checksums), as well as correction via retransmission.¶

TCP supports unicast delivery of data. There are anycast applications that can successfully use TCP without modifications, though there is some risk of instability due to changes of lower-layer forwarding behavior [46].¶

TCP is connection oriented, though it does not inherently include a liveness detection capability.¶

Data flow is supported bidirectionally over TCP connections, though applications are free to send data only unidirectionally, if they so choose.¶

TCP uses port numbers to identify application services and to multiplex distinct flows between hosts.¶

A more detailed description of TCP features compared to other transport protocols can be found in Section 3.1 of [52]. Further description of the motivations for developing TCP and its role in the Internet protocol stack can be found in Section 2 of [16] and earlier versions of the TCP specification.¶

3.1. Header Format

TCP segments are sent as internet datagrams. The Internet Protocol (IP) header carries several information fields, including the source and destination host addresses [1] [13]. A TCP header follows the IP headers, supplying information specific to TCP. This division allows for the existence of host-level protocols other than TCP. In the early development of the Internet suite of protocols, the IP header fields had been a part of TCP.¶

This document describes TCP, which uses TCP headers.¶

A TCP header, followed by any user data in the segment, is formatted as follows, using the style from [66]:¶

    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                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |       |C|E|U|A|P|R|S|F|                               |
   | Offset| Rsrvd |W|C|R|C|S|S|Y|I|            Window             |
   |       |       |R|E|G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           [Options]                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               :
   :                             Data                              :
   :                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Note that one tick mark represents one bit position.

where:¶

Source Port:

16 bits¶

The source port number.¶

Destination Port:

16 bits¶

The destination port number.¶

Sequence Number:

32 bits¶

The sequence number of the first data octet in this segment (except when the SYN flag is set). If SYN is set, the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1.¶

Acknowledgment Number:

32 bits¶

If the ACK control bit is set, this field contains the value of the next sequence number the sender of the segment is expecting to receive. Once a connection is established, this is always sent.¶

Data Offset (DOffset):

4 bits¶

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 integer multiple of 32 bits long.¶

Reserved (Rsrvd):

4 bits¶

A set of control bits reserved for future use. Must be zero in generated segments and must be ignored in received segments if the corresponding future features are not implemented by the sending or receiving host.¶

Control bits:

The control bits are also known as "flags". Assignment is managed by IANA from the "TCP Header Flags" registry [62]. The currently assigned control bits are CWR, ECE, URG, ACK, PSH, RST, SYN, and FIN.¶

CWR:

1 bit¶

Congestion Window Reduced (see [6]).¶

ECE:

1 bit¶

ECN-Echo (see [6]).¶

URG:

1 bit¶

Urgent pointer field is significant.¶

ACK:

1 bit¶

Acknowledgment field is significant.¶

PSH:

1 bit¶

Push function (see the Send Call description in Section 3.9.1).¶

RST:

1 bit¶

Reset the connection.¶

SYN:

1 bit¶

Synchronize sequence numbers.¶

FIN:

1 bit¶

No more data from sender.¶

Window:

16 bits¶

The number of data octets beginning with the one indicated in the acknowledgment field that the sender of this segment is willing to accept. The value is shifted when the window scaling extension is used [47].¶

The window size MUST be treated as an unsigned number, or else large window sizes will appear like negative windows and TCP will not work (MUST-1). It is RECOMMENDED that implementations will reserve 32-bit fields for the send and receive window sizes in the connection record and do all window computations with 32 bits (REC-1).¶

Checksum:

16 bits¶

The checksum field is the 16-bit ones' complement of the ones' complement sum of all 16-bit words in the header and text. The checksum computation needs to ensure the 16-bit alignment of the data being summed. If a segment contains an odd number of header and text octets, alignment can be achieved by padding the last octet with zeros on its right to form a 16-bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros.¶

The checksum also covers a pseudo-header (Figure 2) conceptually prefixed to the TCP header. The pseudo-header is 96 bits for IPv4 and 320 bits for IPv6. Including the pseudo-header in the checksum gives the TCP connection protection against misrouted segments. This information is carried in IP headers and is transferred across the TCP/network interface in the arguments or results of calls by the TCP implementation on the IP layer.¶

                +--------+--------+--------+--------+
                |           Source Address          |
                +--------+--------+--------+--------+
                |         Destination Address       |
                +--------+--------+--------+--------+
                |  zero  |  PTCL  |    TCP Length   |
                +--------+--------+--------+--------+

Pseudo-header components for IPv4:

Source Address:

the IPv4 source address in network byte order¶

Destination Address:

the IPv4 destination address in network byte order¶

zero:

bits set to zero¶

PTCL:

the protocol number from the IP header¶

TCP Length:

the TCP header length plus the data length in octets (this is not an explicitly transmitted quantity but is computed), and it does not count the 12 octets of the pseudo-header.¶

For IPv6, the pseudo-header is defined in Section 8.1 of RFC 8200 [13] and contains the IPv6 Source Address and Destination Address, an Upper-Layer Packet Length (a 32-bit value otherwise equivalent to TCP Length in the IPv4 pseudo-header), three bytes of zero padding, and a Next Header value, which differs from the IPv6 header value if there are extension headers present between IPv6 and TCP.¶

The TCP checksum is never optional. The sender MUST generate it (MUST-2) and the receiver MUST check it (MUST-3).¶

Urgent Pointer:

16 bits¶

This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. The urgent pointer points to the sequence number of the octet following the urgent data. This field is only to be interpreted in segments with the URG control bit set.¶

Options:

[TCP Option]; size(Options) == (DOffset-5)*32; present only when DOffset > 5. Note that this size expression also includes any padding trailing the actual options present.¶

Options may occupy space at the end of the TCP header and are a multiple of 8 bits in length. All options are included in the checksum. An option may begin on any octet boundary. There are two cases for the format of an option:¶

Case 1:

A single octet of option-kind.¶

Case 2:

An octet of option-kind (Kind), an octet of option-length, and the actual option-data octets.¶

The option-length counts the two octets of option-kind and option-length as well as the option-data octets.¶

Note that the list of options may be shorter than the Data Offset field might imply. The content of the header beyond the End of Option List Option MUST be header padding of zeros (MUST-69).¶

The list of all currently defined options is managed by IANA [62], and each option is defined in other RFCs, as indicated there. That set includes experimental options that can be extended to support multiple concurrent usages [45].¶

A given TCP implementation can support any currently defined options, but the following options MUST be supported (MUST-4 -- note Maximum Segment Size Option support is also part of MUST-14 in Section 3.7.1):¶

Table 1: Mandatory Option Set

Kind	Length	Meaning
0	-	End of Option List Option.
1	-	No-Operation.
2	4	Maximum Segment Size.

These options are specified in detail in Section 3.2.¶

A TCP implementation MUST be able to receive a TCP Option in any segment (MUST-5).¶

A TCP implementation MUST (MUST-6) ignore without error any TCP Option it does not implement, assuming that the option has a length field. All TCP Options except End of Option List Option (EOL) and No-Operation (NOP) MUST have length fields, including all future options (MUST-68). TCP implementations MUST be prepared to handle an illegal option length (e.g., zero); a suggested procedure is to reset the connection and log the error cause (MUST-7).¶

Note: There is ongoing work to extend the space available for TCP Options, such as [65].¶

Data:

variable length¶

User data carried by the TCP segment.¶

3.3. TCP Terminology Overview

This section includes an overview of key terms needed to understand the detailed protocol operation in the rest of the document. There is a glossary of terms in Section 4.¶