< draft-ietf-tcpm-rfc793bis-27.txt   draft-ietf-tcpm-rfc793bis-28.txt >
Internet Engineering Task Force W. Eddy, Ed. Internet Engineering Task Force W. Eddy, Ed.
Internet-Draft MTI Systems Internet-Draft MTI Systems
Obsoletes: 793, 879, 2873, 6093, 6429, 6528, 22 February 2022 Obsoletes: 793, 879, 2873, 6093, 6429, 6528, 7 March 2022
6691 (if approved) 6691 (if approved)
Updates: 5961, 1011, 1122 (if approved) Updates: 5961, 1011, 1122 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: 26 August 2022 Expires: 8 September 2022
Transmission Control Protocol (TCP) Specification Transmission Control Protocol (TCP) Specification
draft-ietf-tcpm-rfc793bis-27 draft-ietf-tcpm-rfc793bis-28
Abstract Abstract
This document specifies the Transmission Control Protocol (TCP). TCP This document specifies the Transmission Control Protocol (TCP). TCP
is an important transport layer protocol in the Internet protocol is an important transport layer protocol in the Internet protocol
stack, and has continuously evolved over decades of use and growth of stack, and has continuously evolved over decades of use and growth of
the Internet. Over this time, a number of changes have been made to 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 TCP as it was specified in RFC 793, though these have only been
documented in a piecemeal fashion. This document collects and brings documented in a piecemeal fashion. This document collects and brings
those changes together with the protocol specification from RFC 793. those changes together with the protocol specification from RFC 793.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 August 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 49, line 44 skipping to change at page 49, line 44
(where RMSS is the MSS specified by the TCP endpoint receiving the (where RMSS is the MSS specified by the TCP endpoint receiving the
segments to be acknowledged, or the default value if not specified) segments to be acknowledged, or the default value if not specified)
(SHLD-19). Excessive delays on ACKs can disturb the round-trip (SHLD-19). Excessive delays on ACKs can disturb the round-trip
timing and packet "clocking" algorithms. More complete discussion of timing and packet "clocking" algorithms. More complete discussion of
delayed ACK behavior is in Section 4.2 of RFC 5681 [8], including delayed ACK behavior is in Section 4.2 of RFC 5681 [8], including
recommendations to immediately acknowledge out-of-order segments, recommendations to immediately acknowledge out-of-order segments,
segments above a gap in sequence space, or segments that fill all or segments above a gap in sequence space, or segments that fill all or
part of a gap, in order to accelerate loss recovery. part of a gap, in order to accelerate loss recovery.
Note that there are several current practices that further lead to a Note that there are several current practices that further lead to a
reduced number of ACKs, including generic receive offload (GRO), ACK reduced number of ACKs, including generic receive offload (GRO) [73],
compression, and ACK decimation [29]. ACK compression, and ACK decimation [29].
3.9. Interfaces 3.9. Interfaces
There are of course two interfaces of concern: the user/TCP interface There are of course two interfaces of concern: the user/TCP interface
and the TCP/lower level interface. We have a fairly elaborate model and the TCP/lower level interface. We have a fairly elaborate model
of the user/TCP interface, but the interface to the lower level of the user/TCP interface, but the interface to the lower level
protocol module is left unspecified here, since it will be specified protocol module is left unspecified here, since it will be specified
in detail by the specification of the lower level protocol. For the in detail by the specification of the lower level protocol. For the
case that the lower level is IP we note some of the parameter values case that the lower level is IP we note some of the parameter values
that TCP implementations might use. that TCP implementations might use.
skipping to change at page 60, line 52 skipping to change at page 60, line 52
classified as either "soft" or "hard" errors that may bear different classified as either "soft" or "hard" errors that may bear different
responses. Treatment for classes of ICMP messages is described responses. Treatment for classes of ICMP messages is described
below: below:
Source Quench Source Quench
TCP implementations MUST silently discard any received ICMP Source TCP implementations MUST silently discard any received ICMP Source
Quench messages (MUST-55). See [11] for discussion. Quench messages (MUST-55). See [11] for discussion.
Soft Errors Soft Errors
For IPv4 ICMP these include: Destination Unreachable -- codes 0, 1, For IPv4 ICMP these include: Destination Unreachable -- codes 0, 1,
5, Time Exceeded -- codes 0, 1, and Parameter Problem. 5; Time Exceeded -- codes 0, 1; and Parameter Problem.
For ICMPv6 these include: Destination Unreachable -- codes 0 and 3, For ICMPv6 these include: Destination Unreachable -- codes 0, 3;
Time Exceeded -- codes 0, 1, and Parameter Problem -- codes 0, 1, Time Exceeded -- codes 0, 1; and Parameter Problem -- codes 0, 1,
2. 2.
Since these Unreachable messages indicate soft error conditions, Since these Unreachable messages indicate soft error conditions,
TCP implementations MUST NOT abort the connection (MUST-56), and it TCP implementations MUST NOT abort the connection (MUST-56), and it
SHOULD make the information available to the application (SHLD-25). SHOULD make the information available to the application (SHLD-25).
Hard Errors Hard Errors
For ICMP these include Destination Unreachable -- codes 2-4. For ICMP these include Destination Unreachable -- codes 2-4.
These are hard error conditions, so TCP implementations SHOULD These are hard error conditions, so TCP implementations SHOULD
skipping to change at page 63, line 29 skipping to change at page 63, line 29
CLOSED STATE (i.e., TCB does not exist) CLOSED STATE (i.e., TCB does not exist)
- Create a new transmission control block (TCB) to hold - Create a new transmission control block (TCB) to hold
connection state information. Fill in local socket identifier, connection state information. Fill in local socket identifier,
remote socket, DiffServ field, security/compartment, and user remote socket, DiffServ field, security/compartment, and user
timeout information. Note that some parts of the remote socket timeout information. Note that some parts of the remote socket
may be unspecified in a passive OPEN and are to be filled in by may be unspecified in a passive OPEN and are to be filled in by
the parameters of the incoming SYN segment. Verify the the parameters of the incoming SYN segment. Verify the
security and DiffServ value requested are allowed for this security and DiffServ value requested are allowed for this
user, if not return "error: precedence not allowed" or "error: user, if not return "error: DiffServ value not allowed" or
security/compartment not allowed." If passive enter the LISTEN "error: security/compartment not allowed." If passive enter
state and return. If active and the remote socket is the LISTEN state and return. If active and the remote socket
unspecified, return "error: remote socket unspecified"; if is unspecified, return "error: remote socket unspecified"; if
active and the remote socket is specified, issue a SYN segment. active and the remote socket is specified, issue a SYN segment.
An initial send sequence number (ISS) is selected. A SYN An initial send sequence number (ISS) is selected. A SYN
segment of the form <SEQ=ISS><CTL=SYN> is sent. Set SND.UNA to segment of the form <SEQ=ISS><CTL=SYN> is sent. Set SND.UNA to
ISS, SND.NXT to ISS+1, enter SYN-SENT state, and return. ISS, SND.NXT to ISS+1, enter SYN-SENT state, and return.
- If the caller does not have access to the local socket - If the caller does not have access to the local socket
specified, return "error: connection illegal for this process". specified, return "error: connection illegal for this process".
If there is no room to create a new connection, return "error: If there is no room to create a new connection, return "error:
insufficient resources". insufficient resources".
skipping to change at page 76, line 44 skipping to change at page 76, line 44
o SYN-RECEIVED STATE o SYN-RECEIVED STATE
+ If the RST bit is set + If the RST bit is set
* If this connection was initiated with a passive OPEN * If this connection was initiated with a passive OPEN
(i.e., came from the LISTEN state), then return this (i.e., came from the LISTEN state), then return this
connection to LISTEN state and return. The user need connection to LISTEN state and return. The user need
not be informed. If this connection was initiated not be informed. If this connection was initiated
with an active OPEN (i.e., came from SYN-SENT state) with an active OPEN (i.e., came from SYN-SENT state)
then the connection was refused, signal the user then the connection was refused, signal the user
"connection refused". In either case, all segments on "connection refused". In either case, the
the retransmission queue should be removed. And in retransmission queue should be flushed. And in the
the active OPEN case, enter the CLOSED state and active OPEN case, enter the CLOSED state and delete
delete the TCB, and return. the TCB, and return.
o ESTABLISHED o ESTABLISHED
FIN-WAIT-1 FIN-WAIT-1
FIN-WAIT-2 FIN-WAIT-2
CLOSE-WAIT CLOSE-WAIT
+ If the RST bit is set then, any outstanding RECEIVEs and + If the RST bit is set then, any outstanding RECEIVEs and
SEND should receive "reset" responses. All segment SEND should receive "reset" responses. All segment
skipping to change at page 85, line 5 skipping to change at page 85, line 5
Destination Address Destination Address
The network layer address of the endpoint intended to receive The network layer address of the endpoint intended to receive
a segment. a segment.
FIN FIN
A control bit (finis) occupying one sequence number, which A control bit (finis) occupying one sequence number, which
indicates that the sender will send no more data or control indicates that the sender will send no more data or control
occupying sequence space. occupying sequence space.
flush
To remove all of the contents (data or segments) from a store
(buffer or queue).
fragment fragment
A portion of a logical unit of data, in particular an A portion of a logical unit of data, in particular an
internet fragment is a portion of an internet datagram. internet fragment is a portion of an internet datagram.
header header
Control information at the beginning of a message, segment, Control information at the beginning of a message, segment,
fragment, packet or block of data. fragment, packet or block of data.
host host
A computer. In particular a source or destination of A computer. In particular a source or destination of
messages from the point of view of the communication network. messages from the point of view of the communication network.
Identification Identification
An Internet Protocol field. This identifying value assigned An Internet Protocol field. This identifying value assigned
by the sender aids in assembling the fragments of a datagram. by the sender aids in assembling the fragments of a datagram.
internet address internet address
A network layer address. A network layer address.
internet datagram internet datagram
The unit of data exchanged between an internet module and the A unit of data exchanged between internet hosts, together
higher level protocol together with the internet header. with the internet header that allows the datagram to be
routed from source to destination.
internet fragment internet fragment
A portion of the data of an internet datagram with an A portion of the data of an internet datagram with an
internet header. internet header.
IP IP
Internet Protocol. See [1] and [13]. Internet Protocol. See [1] and [13].
IRS IRS
The Initial Receive Sequence number. The first sequence The Initial Receive Sequence number. The first sequence
skipping to change at page 95, line 51 skipping to change at page 95, line 51
The -25 revision incorporates changes based on the GENART review from The -25 revision incorporates changes based on the GENART review from
Francis Dupont, SECDIR review from Kyle Rose, and OPSDIR review from Francis Dupont, SECDIR review from Kyle Rose, and OPSDIR review from
Sarah Banks. Sarah Banks.
The -26 revision incorporates changes stemming from the IESG reviews, The -26 revision incorporates changes stemming from the IESG reviews,
and INTDIR review from Bernie Volz. and INTDIR review from Bernie Volz.
The -27 revision fixes a few small editorial incompatibilities that The -27 revision fixes a few small editorial incompatibilities that
Stephen McQuistin found related to automated code generation. Stephen McQuistin found related to automated code generation.
The -28 revision addresses some COMMENTs from Ben Kaduk's IESG
review.
Some other suggested changes that will not be incorporated in this Some other suggested changes that will not be incorporated in this
793 update unless TCPM consensus changes with regard to scope are: 793 update unless TCPM consensus changes with regard to scope are:
1. Tony Sabatini's suggestion for describing DO field 1. Tony Sabatini's suggestion for describing DO field
2. Per discussion with Joe Touch (TAPS list, 6/20/2015), the 2. Per discussion with Joe Touch (TAPS list, 6/20/2015), the
description of the API could be revisited description of the API could be revisited
3. Reducing the R2 value for SYNs has been suggested as a possible 3. Reducing the R2 value for SYNs has been suggested as a possible
topic for future consideration. topic for future consideration.
Early in the process of updating RFC 793, Scott Brim mentioned that Early in the process of updating RFC 793, Scott Brim mentioned that
skipping to change at page 107, line 41 skipping to change at page 107, line 41
454-473, December 1978. 454-473, December 1978.
[71] Faber, T., Touch, J., and W. Yui, "The TIME-WAIT state in [71] Faber, T., Touch, J., and W. Yui, "The TIME-WAIT state in
TCP and Its Effect on Busy Servers", Proceedings of IEEE TCP and Its Effect on Busy Servers", Proceedings of IEEE
INFOCOM pp. 1573-1583, March 1999. INFOCOM pp. 1573-1583, March 1999.
[72] Postel, J., "Comments on Action Items from the January [72] Postel, J., "Comments on Action Items from the January
Meeting", IEN 177, March 1981, Meeting", IEN 177, March 1981,
<https://www.rfc-editor.org/ien/ien177.txt>. <https://www.rfc-editor.org/ien/ien177.txt>.
[73] "Segmentation Offloads", Linux Networking Documentation ,
<https://www.kernel.org/doc/html/latest/networking/
segmentation-offloads.html>.
Appendix A. Other Implementation Notes Appendix A. Other Implementation Notes
This section includes additional notes and references on TCP This section includes additional notes and references on TCP
implementation decisions that are currently not a part of the RFC implementation decisions that are currently not a part of the RFC
series or included within the TCP standard. These items can be series or included within the TCP standard. These items can be
considered by implementers, but there was not yet a consensus to considered by implementers, but there was not yet a consensus to
include them in the standard. include them in the standard.
A.1. IP Security Compartment and Precedence A.1. IP Security Compartment and Precedence
 End of changes. 13 change blocks. 
19 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/