draft-ietf-tcpm-rfc793bis-11.txt   draft-ietf-tcpm-rfc793bis-12.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, October 22, 2018 Obsoletes: 793, 879, 2873, 6093, 6429, December 5, 2018
6528, 6691 (if approved) 6528, 6691 (if approved)
Updates: 5961, 1122 (if approved) Updates: 5961, 1122 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: April 25, 2019 Expires: June 8, 2019
Transmission Control Protocol Specification Transmission Control Protocol Specification
draft-ietf-tcpm-rfc793bis-11 draft-ietf-tcpm-rfc793bis-12
Abstract Abstract
This document specifies the Internet's Transmission Control Protocol This document specifies the Internet's Transmission Control Protocol
(TCP). TCP is an important transport layer protocol in the Internet (TCP). TCP is an important transport layer protocol in the Internet
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 2, line 10 skipping to change at page 2, line 10
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 April 25, 2019. This Internet-Draft will expire on June 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 44 skipping to change at page 2, line 44
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 1. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Key TCP Concepts . . . . . . . . . . . . . . . . . . . . 5 2.1. Key TCP Concepts . . . . . . . . . . . . . . . . . . . . 5
3. Functional Specification . . . . . . . . . . . . . . . . . . 6 3. Functional Specification . . . . . . . . . . . . . . . . . . 5
3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 15 3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 15
3.4. Establishing a connection . . . . . . . . . . . . . . . . 22 3.4. Establishing a connection . . . . . . . . . . . . . . . . 22
3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 29 3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 29
3.5.1. Half-Closed Connections . . . . . . . . . . . . . . . 31 3.5.1. Half-Closed Connections . . . . . . . . . . . . . . . 31
3.6. Precedence and Security . . . . . . . . . . . . . . . . . 32 3.6. Precedence and Security . . . . . . . . . . . . . . . . . 32
3.7. Segmentation . . . . . . . . . . . . . . . . . . . . . . 33 3.7. Segmentation . . . . . . . . . . . . . . . . . . . . . . 33
3.7.1. Maximum Segment Size Option . . . . . . . . . . . . . 34 3.7.1. Maximum Segment Size Option . . . . . . . . . . . . . 34
3.7.2. Path MTU Discovery . . . . . . . . . . . . . . . . . 36 3.7.2. Path MTU Discovery . . . . . . . . . . . . . . . . . 36
3.7.3. Interfaces with Variable MTU Values . . . . . . . . . 36 3.7.3. Interfaces with Variable MTU Values . . . . . . . . . 36
3.7.4. Nagle Algorithm . . . . . . . . . . . . . . . . . . . 37 3.7.4. Nagle Algorithm . . . . . . . . . . . . . . . . . . . 37
3.7.5. IPv6 Jumbograms . . . . . . . . . . . . . . . . . . . 37 3.7.5. IPv6 Jumbograms . . . . . . . . . . . . . . . . . . . 37
3.8. Data Communication . . . . . . . . . . . . . . . . . . . 37 3.8. Data Communication . . . . . . . . . . . . . . . . . . . 37
3.8.1. Retransmission Timeout . . . . . . . . . . . . . . . 38 3.8.1. Retransmission Timeout . . . . . . . . . . . . . . . 38
3.8.2. TCP Congestion Control . . . . . . . . . . . . . . . 38 3.8.2. TCP Congestion Control . . . . . . . . . . . . . . . 38
3.8.3. TCP Connection Failures . . . . . . . . . . . . . . . 39 3.8.3. TCP Connection Failures . . . . . . . . . . . . . . . 39
3.8.4. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . 40 3.8.4. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . 40
3.8.5. The Communication of Urgent Information . . . . . . . 40 3.8.5. The Communication of Urgent Information . . . . . . . 40
3.8.6. Managing the Window . . . . . . . . . . . . . . . . . 41 3.8.6. Managing the Window . . . . . . . . . . . . . . . . . 41
3.9. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 45 3.9. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 46
3.9.1. User/TCP Interface . . . . . . . . . . . . . . . . . 46 3.9.1. User/TCP Interface . . . . . . . . . . . . . . . . . 46
3.9.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 54 3.9.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 55
3.10. Event Processing . . . . . . . . . . . . . . . . . . . . 56 3.10. Event Processing . . . . . . . . . . . . . . . . . . . . 57
3.11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 82 3.11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 82
4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 87 4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 87
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92
6. Security and Privacy Considerations . . . . . . . . . . . . . 92 6. Security and Privacy Considerations . . . . . . . . . . . . . 92
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 93
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.1. Normative References . . . . . . . . . . . . . . . . . . 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 94
8.2. Informative References . . . . . . . . . . . . . . . . . 95 8.2. Informative References . . . . . . . . . . . . . . . . . 95
Appendix A. Other Implementation Notes . . . . . . . . . . . . . 98 Appendix A. Other Implementation Notes . . . . . . . . . . . . . 99
A.1. IP Security Compartment and Precedence . . . . . . . . . 99 A.1. IP Security Compartment and Precedence . . . . . . . . . 99
A.2. Sequence Number Validation . . . . . . . . . . . . . . . 99 A.2. Sequence Number Validation . . . . . . . . . . . . . . . 99
A.3. Nagle Modification . . . . . . . . . . . . . . . . . . . 99 A.3. Nagle Modification . . . . . . . . . . . . . . . . . . . 100
A.4. Low Water Mark . . . . . . . . . . . . . . . . . . . . . 100 A.4. Low Water Mark . . . . . . . . . . . . . . . . . . . . . 100
Appendix B. TCP Requirement Summary . . . . . . . . . . . . . . 100 Appendix B. TCP Requirement Summary . . . . . . . . . . . . . . 100
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 104
1. Purpose and Scope 1. Purpose and Scope
In 1981, RFC 793 [12] was released, documenting the Transmission In 1981, RFC 793 [12] was released, documenting the Transmission
Control Protocol (TCP), and replacing earlier specifications for TCP Control Protocol (TCP), and replacing earlier specifications for TCP
that had been published in the past. that had been published in the past.
skipping to change at page 4, line 42 skipping to change at page 4, line 42
2. Introduction 2. Introduction
RFC 793 contains a discussion of the TCP design goals and provides RFC 793 contains a discussion of the TCP design goals and provides
examples of its operation, including examples of connection examples of its operation, including examples of connection
establishment, closing connections, and retransmitting packets to establishment, closing connections, and retransmitting packets to
repair losses. repair losses.
This document describes the basic functionality expected in modern This document describes the basic functionality expected in modern
implementations of TCP, and replaces the protocol specification in implementations of TCP, and replaces the protocol specification in
RFC 793. It does not replicate or attempt to update the examples and RFC 793. It does not replicate or attempt to update the introduction
other discussion in RFC 793. Other documents are referenced to and philosophy content in RFC 793 (sections 1 and 2 of that
provide explanation of the theory of operation, rationale, and document). Other documents are referenced to provide explanation of
detailed discussion of design decisions. This document only focuses the theory of operation, rationale, and detailed discussion of design
on the normative behavior of the protocol. decisions. This document only focuses on the normative behavior of
the protocol.
The "TCP Roadmap" [37] provides a more extensive guide to the RFCs The "TCP Roadmap" [37] provides a more extensive guide to the RFCs
that define TCP and describe various important algorithms. The TCP that define TCP and describe various important algorithms. The TCP
Roadmap contains sections on strongly encouraged enhancements that Roadmap contains sections on strongly encouraged enhancements that
improve performance and other aspects of TCP beyond the basic improve performance and other aspects of TCP beyond the basic
operation specified in this document. As one example, implementing operation specified in this document. As one example, implementing
congestion control (e.g. [25]) is a TCP requirement, but is a complex congestion control (e.g. [25]) is a TCP requirement, but is a complex
topic on its own, and not described in detail in this document, as topic on its own, and not described in detail in this document, as
there are many options and possibilities that do not impact basic there are many options and possibilities that do not impact basic
interoperability. Similarly, most common TCP implementations today interoperability. Similarly, most common TCP implementations today
include the high-performance extensions in [35], but these are not include the high-performance extensions in [35], but these are not
strictly required or discussed in this document. strictly required or discussed in this document.
TEMPORARY EDITOR'S NOTE: This is an early revision in the process of
updating RFC 793. Many planned changes are not yet incorporated.
***Please do not use this revision as a basis for any work or
reference.***
A list of changes from RFC 793 is contained in Section 4. A list of changes from RFC 793 is contained in Section 4.
TEMPORARY EDITOR'S NOTE: the current revision of this document does
not yet collect all of the changes that will be in the final version.
The set of content changes planned for future revisions is kept in
Section 4.
2.1. Key TCP Concepts 2.1. Key TCP Concepts
TCP provides a reliable, in-order, byte-stream service to TCP provides a reliable, in-order, byte-stream service to
applications. applications.
The application byte-stream is conveyed over the network via TCP The application byte-stream is conveyed over the network via TCP
segments, with each TCP segment sent as an Internet Protocol (IP) segments, with each TCP segment sent as an Internet Protocol (IP)
datagram. datagram.
TCP reliability consists of detecting packet losses (via sequence TCP reliability consists of detecting packet losses (via sequence
skipping to change at page 7, line 40 skipping to change at page 7, line 32
Reserved for future use. Must be zero in generated segments and Reserved for future use. Must be zero in generated segments and
must be ignored in received segments, if corresponding future must be ignored in received segments, if corresponding future
features are unimplemented by the sending or receiving host. features are unimplemented by the sending or receiving host.
Control Bits: 8 bits (from left to right): Control Bits: 8 bits (from left to right):
CWR: Congestion Window Reduced (see [9]) CWR: Congestion Window Reduced (see [9])
ECE: ECN-Echo (see [9]) ECE: ECN-Echo (see [9])
URG: Urgent Pointer field significant URG: Urgent Pointer field significant
ACK: Acknowledgment field significant ACK: Acknowledgment field significant
PSH: Push Function PSH: Push Function (see Paragraph 5)
RST: Reset the connection RST: Reset the connection
SYN: Synchronize sequence numbers SYN: Synchronize sequence numbers
FIN: No more data from sender FIN: No more data from sender
Window: 16 bits Window: 16 bits
The number of data octets beginning with the one indicated in the The number of data octets beginning with the one indicated in the
acknowledgment field which the sender of this segment is willing to acknowledgment field which the sender of this segment is willing to
accept. accept.
skipping to change at page 41, line 15 skipping to change at page 41, line 15
no urgent data outstanding. no urgent data outstanding.
To send an urgent indication the user must also send at least one To send an urgent indication the user must also send at least one
data octet. If the sending user also indicates a push, timely data octet. If the sending user also indicates a push, timely
delivery of the urgent information to the destination process is delivery of the urgent information to the destination process is
enhanced. enhanced.
A TCP MUST support a sequence of urgent data of any length (MUST-31). A TCP MUST support a sequence of urgent data of any length (MUST-31).
[14] [14]
The urgent pointer MUST point to the sequence number of the octet
following the urgent data (MUST-62).
A TCP MUST (MUST-32) inform the application layer asynchronously A TCP MUST (MUST-32) inform the application layer asynchronously
whenever it receives an Urgent pointer and there was previously no whenever it receives an Urgent pointer and there was previously no
pending urgent data, or whenvever the Urgent pointer advances in the pending urgent data, or whenvever the Urgent pointer advances in the
data stream. There MUST (MUST-33) be a way for the application to data stream. There MUST (MUST-33) be a way for the application to
learn how much urgent data remains to be read from the connection, or learn how much urgent data remains to be read from the connection, or
at least to determine whether or not more urgent data remains to be at least to determine whether or not more urgent data remains to be
read. [14] read. [14]
3.8.6. Managing the Window 3.8.6. Managing the Window
skipping to change at page 43, line 5 skipping to change at page 43, line 9
in response to the probe segments, the sending TCP MUST allow the in response to the probe segments, the sending TCP MUST allow the
connection to stay open (MUST-37). This enables TCP to function in connection to stay open (MUST-37). This enables TCP to function in
scenarios such as the "printer ran out of paper" situation described scenarios such as the "printer ran out of paper" situation described
in Section 4.2.2.17 of RFC1122. The behavior is subject to the in Section 4.2.2.17 of RFC1122. The behavior is subject to the
implementation's resource management concerns, as noted in [31]. implementation's resource management concerns, as noted in [31].
When the receiving TCP has a zero window and a segment arrives it When the receiving TCP has a zero window and a segment arrives it
must still send an acknowledgment showing its next expected sequence must still send an acknowledgment showing its next expected sequence
number and current window (zero). number and current window (zero).
The transmitting host SHOULD send the first zero-window probe when a
zero window has existed for the retransmission timeout period (SHLD-
29) (see Section 3.8.1), and SHOULD increase exponentially the
interval between successive probes (SHLD-30).
3.8.6.2. Silly Window Syndrome Avoidance 3.8.6.2. Silly Window Syndrome Avoidance
The "Silly Window Syndrome" (SWS) is a stable pattern of small The "Silly Window Syndrome" (SWS) is a stable pattern of small
incremental window movements resulting in extremely poor TCP incremental window movements resulting in extremely poor TCP
performance. Algorithms to avoid SWS are described below for both performance. Algorithms to avoid SWS are described below for both
the sending side and the receiving side. RFC 1122 contains more the sending side and the receiving side. RFC 1122 contains more
detailed discussion of the SWS problem. Note that the Nagle detailed discussion of the SWS problem. Note that the Nagle
algorithm and the sender SWS avoidance algorithm play complementary algorithm and the sender SWS avoidance algorithm play complementary
roles in improving performance. The Nagle algorithm discourages roles in improving performance. The Nagle algorithm discourages
sending tiny segments when the data to be sent increases in small sending tiny segments when the data to be sent increases in small
skipping to change at page 48, line 15 skipping to change at page 48, line 27
The DiffServ field value indicated by the user only impacts The DiffServ field value indicated by the user only impacts
outgoing packets, may be altered en route through the network, outgoing packets, may be altered en route through the network,
and has no direct bearing or relation to received packets. and has no direct bearing or relation to received packets.
A local connection name will be returned to the user by the A local connection name will be returned to the user by the
TCP. The local connection name can then be used as a short TCP. The local connection name can then be used as a short
hand term for the connection defined by the <local socket, hand term for the connection defined by the <local socket,
foreign socket> pair. foreign socket> pair.
The optional "local IP address" parameter MUST be supported to The optional "local IP address" parameter MUST be supported to
allow the specification of the local IP address. This enables allow the specification of the local IP address (MUST-43).
applications that need to select the local IP address used when This enables applications that need to select the local IP
multihoming is present (MUST-43). address used when multihoming is present.
A passive OPEN call with a specified "local IP address" A passive OPEN call with a specified "local IP address"
parameter will await an incoming connection request to that parameter will await an incoming connection request to that
address. If the parameter is unspecified, a passive OPEN will address. If the parameter is unspecified, a passive OPEN will
await an incoming connection request to any local IP address, await an incoming connection request to any local IP address,
and then bind the local IP address of the connection to the and then bind the local IP address of the connection to the
particular address that is used. particular address that is used.
For an active OPEN call, a specified "local IP address" For an active OPEN call, a specified "local IP address"
parameter MUST be used for opening the connection (MUST-43). parameter will be used for opening the connection. If the
If the parameter is unspecified, the host will choose an parameter is unspecified, the host will choose an appropriate
appropriate local IP address (see RFC 1122 section local IP address (see RFC 1122 section 3.3.4.2).
3.3.4.2).Editor's note: should this replace the paragraph with
MUST-43 two paragraphs above? These seem to be duplicative of
one another (first from 793, then from 1122)? TBD
If an application on a multihomed host does not specify the If an application on a multihomed host does not specify the
local IP address when actively opening a TCP connection, then local IP address when actively opening a TCP connection, then
the TCP MUST ask the IP layer to select a local IP address the TCP MUST ask the IP layer to select a local IP address
before sending the (first) SYN (MUST-44). See the function before sending the (first) SYN (MUST-44). See the function
GET_SRCADDR() in Section 3.4 of RFC 1122. GET_SRCADDR() in Section 3.4 of RFC 1122.
At all other times, a previous segment has either been sent or At all other times, a previous segment has either been sent or
received on this connection, and TCP MUST use the same local received on this connection, and TCP MUST use the same local
address is used that was used in those previous segments (MUST- address is used that was used in those previous segments (MUST-
45). 45).
A TCP implementation MUST reject as an error a local OPEN call A TCP implementation MUST reject as an error a local OPEN call
for an invalid remote IP address (e.g., a broadcast or for an invalid remote IP address (e.g., a broadcast or
multicast address) (MUST-46). multicast address) (MUST-46).
Send Send
Format: SEND (local connection name, buffer address, byte Format: SEND (local connection name, buffer address, byte
count, PUSH flag, URGENT flag [,timeout]) count, PUSH flag (optional), URGENT flag [,timeout])
This call causes the data contained in the indicated user This call causes the data contained in the indicated user
buffer to be sent on the indicated connection. If the buffer to be sent on the indicated connection. If the
connection has not been opened, the SEND is considered an connection has not been opened, the SEND is considered an
error. Some implementations may allow users to SEND first; in error. Some implementations may allow users to SEND first; in
which case, an automatic OPEN would be done. For example, this which case, an automatic OPEN would be done. For example, this
might be one way for application data to be included in SYN might be one way for application data to be included in SYN
segments. If the calling process is not authorized to use this segments. If the calling process is not authorized to use this
connection, an error is returned. connection, an error is returned.
If the PUSH flag is set, the data must be transmitted promptly A TCP MAY implement PUSH flags on SEND calls (MAY-15). If PUSH
to the receiver, and the PUSH bit will be set in the last TCP flags are not implemented, then the sending TCP: (1) MUST NOT
segment created from the buffer. If the PUSH flag is not set, buffer data indefinitely (MUST-60), and (2) MUST set the PSH
the data may be combined with data from subsequent SENDs for bit in the last buffered segment (i.e., when there is no more
transmission efficiency. Note that when the Nagle algorithm is queued data to be sent) (MUST-61). The remaining description
in use, TCP may buffer the data before sending, without regard below assumes the PUSH flag is supported on SEND calls.
to the PUSH flag (see Section 3.7.4).
If the PUSH flag is set, the application intends the data to be
transmitted promptly to the receiver, and the PUSH bit will be
set in the last TCP segment created from the buffer. When an
application issues a series of SEND calls without setting the
PUSH flag, the TCP MAY aggregate the data internally without
sending it (MAY-16).
The PSH bit is not a record marker and is independent of
segment boundaries. The transmitter SHOULD collapse successive
bits when it packetizes data, to send the largest possible
segment (SHLD-27).
If the PUSH flag is not set, the data may be combined with data
from subsequent SENDs for transmission efficiency. Note that
when the Nagle algorithm is in use, TCP may buffer the data
before sending, without regard to the PUSH flag (see
Section 3.7.4).
An application program is logically required to set the PUSH
flag in a SEND call whenever it needs to force delivery of the
data to avoid a communication deadlock. However, a TCP SHOULD
send a maximum-sized segment whenever possible (SHLD-28), to
improve performance (see Section 3.8.6.2.1).
New applications SHOULD NOT set the URGENT flag [29] due to New applications SHOULD NOT set the URGENT flag [29] due to
implementation differences and middlebox issues (SHLD-13). implementation differences and middlebox issues (SHLD-13).
If the URGENT flag is set, segments sent to the destination TCP If the URGENT flag is set, segments sent to the destination TCP
will have the urgent pointer set. The receiving TCP will will have the urgent pointer set. The receiving TCP will
signal the urgent condition to the receiving process if the signal the urgent condition to the receiving process if the
urgent pointer indicates that data preceding the urgent pointer urgent pointer indicates that data preceding the urgent pointer
has not been consumed by the receiving process. The purpose of has not been consumed by the receiving process. The purpose of
urgent is to stimulate the receiver to process the urgent data urgent is to stimulate the receiver to process the urgent data
skipping to change at page 50, line 40 skipping to change at page 51, line 27
In order for the process to distinguish among error or success In order for the process to distinguish among error or success
indications for different SENDs, it might be appropriate for indications for different SENDs, it might be appropriate for
the buffer address to be returned along with the coded response the buffer address to be returned along with the coded response
to the SEND request. TCP-to-user signals are discussed below, to the SEND request. TCP-to-user signals are discussed below,
indicating the information which should be returned to the indicating the information which should be returned to the
calling process. calling process.
Receive Receive
Format: RECEIVE (local connection name, buffer address, byte Format: RECEIVE (local connection name, buffer address, byte
count) -> byte count, urgent flag, push flag count) -> byte count, urgent flag, push flag (optional)
This command allocates a receiving buffer associated with the This command allocates a receiving buffer associated with the
specified connection. If no OPEN precedes this command or the specified connection. If no OPEN precedes this command or the
calling process is not authorized to use this connection, an calling process is not authorized to use this connection, an
error is returned. error is returned.
In the simplest implementation, control would not return to the In the simplest implementation, control would not return to the
calling program until either the buffer was filled, or some calling program until either the buffer was filled, or some
error occurred, but this scheme is highly subject to deadlocks. error occurred, but this scheme is highly subject to deadlocks.
A more sophisticated implementation would permit several A more sophisticated implementation would permit several
RECEIVEs to be outstanding at once. These would be filled as RECEIVEs to be outstanding at once. These would be filled as
segments arrive. This strategy permits increased throughput at segments arrive. This strategy permits increased throughput at
the cost of a more elaborate scheme (possibly asynchronous) to the cost of a more elaborate scheme (possibly asynchronous) to
notify the calling program that a PUSH has been seen or a notify the calling program that a PUSH has been seen or a
buffer filled. buffer filled.
A TCP receiver MAY pass a received PSH flag to the application
layer via the PUSH flag in the interface (MAY-17), but it is
not required (this was clarified in RFC 1122 section 4.2.2.2).
The remainder of text describing the RECEIVE call below assumes
that passing the PUSH indication is supported.
If enough data arrive to fill the buffer before a PUSH is seen, If enough data arrive to fill the buffer before a PUSH is seen,
the PUSH flag will not be set in the response to the RECEIVE. the PUSH flag will not be set in the response to the RECEIVE.
The buffer will be filled with as much data as it can hold. If The buffer will be filled with as much data as it can hold. If
a PUSH is seen before the buffer is filled the buffer will be a PUSH is seen before the buffer is filled the buffer will be
returned partially filled and PUSH indicated. returned partially filled and PUSH indicated.
If there is urgent data the user will have been informed as If there is urgent data the user will have been informed as
soon as it arrived via a TCP-to-user signal. The receiving soon as it arrived via a TCP-to-user signal. The receiving
user should thus be in "urgent mode". If the URGENT flag is user should thus be in "urgent mode". If the URGENT flag is
on, additional urgent data remains. If the URGENT flag is off, on, additional urgent data remains. If the URGENT flag is off,
skipping to change at page 53, line 36 skipping to change at page 54, line 28
assume this takes the form of an application-supplied assume this takes the form of an application-supplied
ERROR_REPORT routine that may be upcalled asynchronously from ERROR_REPORT routine that may be upcalled asynchronously from
the transport layer: the transport layer:
ERROR_REPORT(local connection name, reason, subreason) ERROR_REPORT(local connection name, reason, subreason)
The precise encoding of the reason and subreason parameters is The precise encoding of the reason and subreason parameters is
not specified here. However, the conditions that are reported not specified here. However, the conditions that are reported
asynchronously to the application MUST include: asynchronously to the application MUST include:
* ICMP error message arrived (see Section 3.9.2.2) (MUST- * ICMP error message arrived (see Section 3.9.2.2) (TODO -
TBD) MUST here is inconsistent with SHOULDs in the section
describing ICMP processing)
* Excessive retransmissions (see Section 3.8.3) (MUST-TBD) * Excessive retransmissions (see Section 3.8.3) (TODO - MUST
here is inconsistent with SHOULD in the section describing
excessive retransmissions)
* Urgent pointer advance (see Section 3.8.5) (MUST-32). * Urgent pointer advance (see Section 3.8.5) (MUST-32).
However, an application program that does not want to receive However, an application program that does not want to receive
such ERROR_REPORT calls SHOULD be able to effectively disable such ERROR_REPORT calls SHOULD be able to effectively disable
these calls (SHLD-20). these calls (SHLD-20).
Set Differentiated Services Field (IPv4 TOS or IPv6 Traffic Class) Set Differentiated Services Field (IPv4 TOS or IPv6 Traffic Class)
The application layer MUST be able to specify the The application layer MUST be able to specify the
skipping to change at page 56, line 33 skipping to change at page 57, line 26
that is in any of the synchronized states. that is in any of the synchronized states.
Note that [23] section 4 describes widespread implementation behavior Note that [23] section 4 describes widespread implementation behavior
that treats soft errors as hard errors during connection that treats soft errors as hard errors during connection
establishment. establishment.
3.9.2.3. Remote Address Validation 3.9.2.3. Remote Address Validation
RFC 1122 requires addresses to be validated in incoming SYN packets: RFC 1122 requires addresses to be validated in incoming SYN packets:
An incoming SYN with an invalid source address must be ignored An incoming SYN with an invalid source address MUST be ignored
either by TCP or by the IP layer (see Section 3.2.1.3 of [14]). either by TCP or by the IP layer (MUST-63) (see Section 3.2.1.3 of
[14]).
A TCP implementation MUST silently discard an incoming SYN segment A TCP implementation MUST silently discard an incoming SYN segment
that is addressed to a broadcast or multicast address (MUST-57). that is addressed to a broadcast or multicast address (MUST-57).
This prevents connection state and replies from being erroneously This prevents connection state and replies from being erroneously
generated, and implementers should note that this guidance is generated, and implementers should note that this guidance is
applicable to all incoming segments, not just SYNs, as specifically applicable to all incoming segments, not just SYNs, as specifically
indicated in RFC 1122. indicated in RFC 1122.
3.10. Event Processing 3.10. Event Processing
skipping to change at page 73, line 7 skipping to change at page 73, line 7
algorithm is implemented, the logic above is not applicable algorithm is implemented, the logic above is not applicable
for incoming SYN segments with timestamp options, received for incoming SYN segments with timestamp options, received
on a connection in the TIME-WAIT state. on a connection in the TIME-WAIT state.
In the following it is assumed that the segment is the In the following it is assumed that the segment is the
idealized segment that begins at RCV.NXT and does not exceed idealized segment that begins at RCV.NXT and does not exceed
the window. One could tailor actual segments to fit this the window. One could tailor actual segments to fit this
assumption by trimming off any portions that lie outside the assumption by trimming off any portions that lie outside the
window (including SYN and FIN), and only processing further window (including SYN and FIN), and only processing further
if the segment then begins at RCV.NXT. Segments with higher if the segment then begins at RCV.NXT. Segments with higher
beginning sequence numbers should be held for later beginning sequence numbers SHOULD be held for later
processing. processing (SHLD-31).
second check the RST bit, second check the RST bit,
RFC 5961 section 3 describes a potential blind reset attack RFC 5961 section 3 describes a potential blind reset attack
and optional mitigation approach that SHOULD be implemented. and optional mitigation approach that SHOULD be implemented.
For stacks implementing RFC 5961, the three checks below For stacks implementing RFC 5961, the three checks below
apply, otherwise processesing for these states is indicated apply, otherwise processesing for these states is indicated
further below. further below.
1) If the RST bit is set and the sequence number is 1) If the RST bit is set and the sequence number is
skipping to change at page 91, line 47 skipping to change at page 91, line 47
on TCP to user messages on TCP to user messages
The -09 revision fixes section numbering problems. The -09 revision fixes section numbering problems.
The -10 revision includes additions to the security considerations The -10 revision includes additions to the security considerations
based on comments from Joe Touch, and suggested edits on RST/FIN based on comments from Joe Touch, and suggested edits on RST/FIN
notification, RFC 2525 reference, and other edits suggested by notification, RFC 2525 reference, and other edits suggested by
Yuchung Cheng, as well as modifications to DiffServ text from Yuchung Yuchung Cheng, as well as modifications to DiffServ text from Yuchung
Cheng and Gorry Fairhurst. Cheng and Gorry Fairhurst.
The -11 revision includes a start at identifying all of the
requirements text and referencing each instance in the common table
at the end of the document.
The -12 revision completes the requirement language indexing started
in -11 and adds necessary description of the PUSH functionality that
was missing.
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. look at Tony Sabatini suggestion for describing DO field 1. look at Tony Sabatini 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
Early in the process of updating RFC 793, Scott Brim mentioned that Early in the process of updating RFC 793, Scott Brim mentioned that
this should include a PERPASS/privacy review. This may be something this should include a PERPASS/privacy review. This may be something
for the chairs or AD to request during WGLC or IETF LC. for the chairs or AD to request during WGLC or IETF LC.
skipping to change at page 100, line 31 skipping to change at page 100, line 41
sending TCP application to help avoid creating large amounts of sending TCP application to help avoid creating large amounts of
buffered data (and corresponding latency). This is useful for buffered data (and corresponding latency). This is useful for
applications that are multiplexing data from multiple upper level applications that are multiplexing data from multiple upper level
streams onto a connection, especially when streams may be a mix of streams onto a connection, especially when streams may be a mix of
interactive/realtime and bulk data transfer. interactive/realtime and bulk data transfer.
Appendix B. TCP Requirement Summary Appendix B. TCP Requirement Summary
This section is adapted from RFC 1122. This section is adapted from RFC 1122.
TODO: This needs to be worked on a little bit still, to fix the Note that there is no requirement related to PLPMTUD in this list,
remaining TBDs. Through this, it became clear that content on PUSH but that PLPMTUD is recommended.
needs to be included from 793/1122 still.
TODO: NOTE that PMTUD+PLPMTUD is not included in this table of
recommendations.
| | | | |S| | | | | | |S| |
| | | | |H| |F | | | | |H| |F
| | | | |O|M|o | | | | |O|M|o
| | |S| |U|U|o | | |S| |U|U|o
| | |H| |L|S|t | | |H| |L|S|t
| |M|O| |D|T|n | |M|O| |D|T|n
| |U|U|M| | |o | |U|U|M| | |o
| |S|L|A|N|N|t | |S|L|A|N|N|t
| |T|D|Y|O|O|t | |T|D|Y|O|O|t
FEATURE | ReqID | | | |T|T|e FEATURE | ReqID | | | |T|T|e
-------------------------------------------------|--------|-|-|-|-|-|-- -------------------------------------------------|--------|-|-|-|-|-|--
| | | | | | | | | | | | | |
Push flag | | | | | | | Push flag | | | | | | |
Aggregate or queue un-pushed data | TBD | | |x| | | Aggregate or queue un-pushed data | MAY-16 | | |x| | |
Sender collapse successive PSH flags | TBD | |x| | | | Sender collapse successive PSH flags | SHLD-27| |x| | | |
SEND call can specify PUSH | TBD | | |x| | | SEND call can specify PUSH | MAY-15 | | |x| | |
If cannot: sender buffer indefinitely | TBD | | | | |x| If cannot: sender buffer indefinitely | MUST-60| | | | |x|
If cannot: PSH last segment | TBD |x| | | | | If cannot: PSH last segment | MUST-61|x| | | | |
Notify receiving ALP of PSH | TBD | | |x| | |1 Notify receiving ALP of PSH | MAY-17 | | |x| | |1
Send max size segment when possible | TBD | |x| | | | Send max size segment when possible | SHLD-28| |x| | | |
| | | | | | | | | | | | | |
Window | | | | | | | Window | | | | | | |
Treat as unsigned number | MUST-1 |x| | | | | Treat as unsigned number | MUST-1 |x| | | | |
Handle as 32-bit number | REC-1 | |x| | | | Handle as 32-bit number | REC-1 | |x| | | |
Shrink window from right | SHLD-14| | | |x| | Shrink window from right | SHLD-14| | | |x| |
- Send new data when window shrinks | SHLD-15| | | |x| | - Send new data when window shrinks | SHLD-15| | | |x| |
- Retransmit old unacked data within window | SHLD-16| |x| | | | - Retransmit old unacked data within window | SHLD-16| |x| | | |
- Time out conn for data past right edge | SHLD-17| | | |x| | - Time out conn for data past right edge | SHLD-17| | | |x| |
Robust against shrinking window | MUST-34|x| | | | | Robust against shrinking window | MUST-34|x| | | | |
Receiver's window closed indefinitely | MAY-8 | | |x| | | Receiver's window closed indefinitely | MAY-8 | | |x| | |
Use standard probing logic | MUST-35|x| | | | | Use standard probing logic | MUST-35|x| | | | |
Sender probe zero window | MUST-36|x| | | | | Sender probe zero window | MUST-36|x| | | | |
First probe after RTO | TBD | |x| | | | First probe after RTO | SHLD-29| |x| | | |
Exponential backoff | TBD | |x| | | | Exponential backoff | SHLD-30| |x| | | |
Allow window stay zero indefinitely | MUST-37|x| | | | | Allow window stay zero indefinitely | MUST-37|x| | | | |
Sender timeout OK conn with zero wind | TBD | | | | |x|
Retransmit old data beyond SND.UNA+SND.WND | MAY-7 | | |x| | | Retransmit old data beyond SND.UNA+SND.WND | MAY-7 | | |x| | |
| | | | | | | | | | | | | |
Urgent Data | | | | | | | Urgent Data | | | | | | |
Include support for urgent pointer | MUST-30|x| | | | | Include support for urgent pointer | MUST-30|x| | | | |
Pointer indicates first non-urgent octet | TBD |x| | | | | Pointer indicates first non-urgent octet | MUST-62|x| | | | |
Arbitrary length urgent data sequence | MUST-31|x| | | | | Arbitrary length urgent data sequence | MUST-31|x| | | | |
Inform ALP asynchronously of urgent data | MUST-32|x| | | | |1 Inform ALP asynchronously of urgent data | MUST-32|x| | | | |1
ALP can learn if/how much urgent data Q'd | MUST-33|x| | | | |1 ALP can learn if/how much urgent data Q'd | MUST-33|x| | | | |1
ALP employ the urgent mechanism | SHLD-13| | | |x| | ALP employ the urgent mechanism | SHLD-13| | | |x| |
| | | | | | | | | | | | | |
TCP Options | | | | | | | TCP Options | | | | | | |
Support the mandatory option set | MUST-4 |x| | | | | Support the mandatory option set | MUST-4 |x| | | | |
Receive TCP option in any segment | MUST-5 |x| | | | | Receive TCP option in any segment | MUST-5 |x| | | | |
Ignore unsupported options | MUST-6 |x| | | | | Ignore unsupported options | MUST-6 |x| | | | |
Cope with illegal option length | MUST-7 |x| | | | | Cope with illegal option length | MUST-7 |x| | | | |
skipping to change at page 102, line 19 skipping to change at page 102, line 24
PRF computable from outside the host | MUST-9 | | | | |x| PRF computable from outside the host | MUST-9 | | | | |x|
| | | | | | | | | | | | | |
Opening Connections | | | | | | | Opening Connections | | | | | | |
Support simultaneous open attempts | MUST-10|x| | | | | Support simultaneous open attempts | MUST-10|x| | | | |
SYN-RECEIVED remembers last state | MUST-11|x| | | | | SYN-RECEIVED remembers last state | MUST-11|x| | | | |
Passive Open call interfere with others | MUST-41| | | | |x| Passive Open call interfere with others | MUST-41| | | | |x|
Function: simultan. LISTENs for same port | MUST-42|x| | | | | Function: simultan. LISTENs for same port | MUST-42|x| | | | |
Ask IP for src address for SYN if necc. | MUST-44|x| | | | | Ask IP for src address for SYN if necc. | MUST-44|x| | | | |
Otherwise, use local addr of conn. | MUST-45|x| | | | | Otherwise, use local addr of conn. | MUST-45|x| | | | |
OPEN to broadcast/multicast IP Address | MUST-46| | | | |x| OPEN to broadcast/multicast IP Address | MUST-46| | | | |x|
Silently discard seg to bcast/mcast addr | TBD |x| | | | | Silently discard seg to bcast/mcast addr | MUST-57|x| | | | |
| | | | | | | | | | | | | |
Closing Connections | | | | | | | Closing Connections | | | | | | |
RST can contain data | SHLD-2 | |x| | | | RST can contain data | SHLD-2 | |x| | | |
Inform application of aborted conn | MUST-12|x| | | | | Inform application of aborted conn | MUST-12|x| | | | |
Half-duplex close connections | MAY-1 | | |x| | | Half-duplex close connections | MAY-1 | | |x| | |
Send RST to indicate data lost | SHLD-3 | |x| | | | Send RST to indicate data lost | SHLD-3 | |x| | | |
In TIME-WAIT state for 2MSL seconds | MUST-13|x| | | | | In TIME-WAIT state for 2MSL seconds | MUST-13|x| | | | |
Accept SYN from TIME-WAIT state | MAY-2 | | |x| | | Accept SYN from TIME-WAIT state | MAY-2 | | |x| | |
Use Timestamps to reduce TIME-WAIT | SHLD-4 | |x| | | | Use Timestamps to reduce TIME-WAIT | SHLD-4 | |x| | | |
| | | | | | | | | | | | | |
Retransmissions | | | | | | | Retransmissions | | | | | | |
Implement RFC 5681 | MUST-19|x| | | | | Implement RFC 5681 | MUST-19|x| | | | |
Retransmit with same IP ident | MAY-4 | | |x| | | Retransmit with same IP ident | MAY-4 | | |x| | |
Karn's algorithm | MUST-18|x| | | | | Karn's algorithm | MUST-18|x| | | | |
| | | | | | | | | | | | | |
Generating ACK's: | | | | | | | Generating ACK's: | | | | | | |
Aggregate whenever possible | MUST-58|x| | | | | Aggregate whenever possible | MUST-58|x| | | | |
Queue out-of-order segments | TBD | |x| | | | Queue out-of-order segments | SHLD-31| |x| | | |
Process all Q'd before send ACK | MUST-59|x| | | | | Process all Q'd before send ACK | MUST-59|x| | | | |
Send ACK for out-of-order segment | MAY-13 | | |x| | | Send ACK for out-of-order segment | MAY-13 | | |x| | |
Delayed ACK's | SHLD-18| |x| | | | Delayed ACK's | SHLD-18| |x| | | |
Delay < 0.5 seconds | MUST-40|x| | | | | Delay < 0.5 seconds | MUST-40|x| | | | |
Every 2nd full-sized segment ACK'd | SHLD-19|x| | | | | Every 2nd full-sized segment ACK'd | SHLD-19|x| | | | |
Receiver SWS-Avoidance Algorithm | MUST-39|x| | | | | Receiver SWS-Avoidance Algorithm | MUST-39|x| | | | |
| | | | | | | | | | | | | |
Sending data | | | | | | | Sending data | | | | | | |
Configurable TTL | MUST-49|x| | | | | Configurable TTL | MUST-49|x| | | | |
Sender SWS-Avoidance Algorithm | MUST-38|x| | | | | Sender SWS-Avoidance Algorithm | MUST-38|x| | | | |
skipping to change at page 103, line 43 skipping to change at page 103, line 48
Receiving ICMP Messages from IP | MUST-54|x| | | | | Receiving ICMP Messages from IP | MUST-54|x| | | | |
Dest. Unreach (0,1,5) => inform ALP | SHLD-25| |x| | | | Dest. Unreach (0,1,5) => inform ALP | SHLD-25| |x| | | |
Dest. Unreach (0,1,5) => abort conn | MUST-56| | | | |x| Dest. Unreach (0,1,5) => abort conn | MUST-56| | | | |x|
Dest. Unreach (2-4) => abort conn | SHLD-26| |x| | | | Dest. Unreach (2-4) => abort conn | SHLD-26| |x| | | |
Source Quench => silent discard | MUST-55|x| | | | | Source Quench => silent discard | MUST-55|x| | | | |
Time Exceeded => tell ALP, don't abort | MUST-56| | | | |x| Time Exceeded => tell ALP, don't abort | MUST-56| | | | |x|
Param Problem => tell ALP, don't abort | MUST-56| | | | |x| Param Problem => tell ALP, don't abort | MUST-56| | | | |x|
| | | | | | | | | | | | | |
Address Validation | | | | | | | Address Validation | | | | | | |
Reject OPEN call to invalid IP address | MUST-46|x| | | | | Reject OPEN call to invalid IP address | MUST-46|x| | | | |
Reject SYN from invalid IP address | TBD |x| | | | | Reject SYN from invalid IP address | MUST-63|x| | | | |
Silently discard SYN to bcast/mcast addr | MUST-57|x| | | | | Silently discard SYN to bcast/mcast addr | MUST-57|x| | | | |
| | | | | | | | | | | | | |
TCP/ALP Interface Services | | | | | | | TCP/ALP Interface Services | | | | | | |
Error Report mechanism | MUST-47|x| | | | | Error Report mechanism | MUST-47|x| | | | |
ALP can disable Error Report Routine | SHLD-20| |x| | | | ALP can disable Error Report Routine | SHLD-20| |x| | | |
ALP can specify DiffServ field for sending | MUST-48|x| | | | | ALP can specify DiffServ field for sending | MUST-48|x| | | | |
Passed unchanged to IP | SHLD-22| |x| | | | Passed unchanged to IP | SHLD-22| |x| | | |
ALP can change DiffServ field during connection| SHLD-21| |x| | | | ALP can change DiffServ field during connection| SHLD-21| |x| | | |
ALP generally changing DiffServ during conn. | SHLD-23| | | |x| | ALP generally changing DiffServ during conn. | SHLD-23| | | |x| |
Pass received DiffServ field up to ALP | MAY-9 | | |x| | | Pass received DiffServ field up to ALP | MAY-9 | | |x| | |
FLUSH call | MAY-14 | | |x| | | FLUSH call | MAY-14 | | |x| | |
Optional local IP addr parm. in OPEN | TBD |x| | | | | Optional local IP addr parm. in OPEN | MUST-43|x| | | | |
| | | | | | | | | | | | | |
RFC 5961 Support: | | | | | | | RFC 5961 Support: | | | | | | |
Implement data injection protection | MAY-12 | | |x| | | Implement data injection protection | MAY-12 | | |x| | |
| | | | | | | | | | | | | |
Explicit Congestion Notification: | | | | | | | Explicit Congestion Notification: | | | | | | |
Support ECN | SHLD-8 | |x| | | | Support ECN | SHLD-8 | |x| | | |
-------------------------------------------------|--------|-|-|-|-|-|-- -------------------------------------------------|--------|-|-|-|-|-|--
FOOTNOTES: (1) "ALP" means Application-Layer program. FOOTNOTES: (1) "ALP" means Application-Layer program.
 End of changes. 35 change blocks. 
73 lines changed or deleted 105 lines changed or added

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