draft-ietf-tcpm-rfc793bis-03.txt   draft-ietf-tcpm-rfc793bis-04.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, 6093, 6528, 6691 August 1, 2016 Obsoletes: 793, 879, 6093, 6429, 6528, December 8, 2016
(if approved) 6691 (if approved)
Updates: 1122 (if approved) Updates: 1122 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: February 2, 2017 Expires: June 11, 2017
Transmission Control Protocol Specification Transmission Control Protocol Specification
draft-ietf-tcpm-rfc793bis-03 draft-ietf-tcpm-rfc793bis-04
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.
This document obsoletes RFC 793 and several other RFCs (TODO: list This document obsoletes RFC 793 and several other RFCs (TODO: list
all actual RFCs when finished). all actual RFCs when finished).
RFC EDITOR NOTE: If approved for publication as an RFC, this should RFC EDITOR NOTE: If approved for publication as an RFC, this should
be marked additionally as "STD: 7" and replace RFC 793 in that role. be marked additionally as "STD: 7" and replace RFC 793 in that role.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [4].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 2, 2017. This Internet-Draft will expire on June 11, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 39 skipping to change at page 2, line 39
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
3. Functional Specification . . . . . . . . . . . . . . . . . . 5 3. Functional Specification . . . . . . . . . . . . . . . . . . 5
3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 14 3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 15
3.4. Establishing a connection . . . . . . . . . . . . . . . . 20 3.4. Establishing a connection . . . . . . . . . . . . . . . . 21
3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 27 3.4.1. Remote Address Validation . . . . . . . . . . . . . . 28
3.5.1. Half-Closed Connections . . . . . . . . . . . . . . . 30 3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 28
3.6. Precedence and Security . . . . . . . . . . . . . . . . . 30 3.5.1. Half-Closed Connections . . . . . . . . . . . . . . . 31
3.7. Segmentation . . . . . . . . . . . . . . . . . . . . . . 31 3.6. Precedence and Security . . . . . . . . . . . . . . . . . 31
3.7.1. Maximum Segment Size Option . . . . . . . . . . . . . 32 3.7. Segmentation . . . . . . . . . . . . . . . . . . . . . . 32
3.7.2. Path MTU Discovery . . . . . . . . . . . . . . . . . 33 3.7.1. Maximum Segment Size Option . . . . . . . . . . . . . 33
3.7.3. Interfaces with Variable MTU Values . . . . . . . . . 34 3.7.2. Path MTU Discovery . . . . . . . . . . . . . . . . . 34
3.7.4. Nagle Algorithm . . . . . . . . . . . . . . . . . . . 34 3.7.3. Interfaces with Variable MTU Values . . . . . . . . . 35
3.7.5. IPv6 Jumbograms . . . . . . . . . . . . . . . . . . . 35 3.7.4. Nagle Algorithm . . . . . . . . . . . . . . . . . . . 35
3.8. Data Communication . . . . . . . . . . . . . . . . . . . 35 3.7.5. IPv6 Jumbograms . . . . . . . . . . . . . . . . . . . 36
3.8.1. Retransmission Timeout . . . . . . . . . . . . . . . 36
3.8.2. The Communication of Urgent Information . . . . . . . 36 3.8. Data Communication . . . . . . . . . . . . . . . . . . . 36
3.8.3. Managing the Window . . . . . . . . . . . . . . . . . 37 3.8.1. Retransmission Timeout . . . . . . . . . . . . . . . 37
3.9. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 41 3.8.2. TCP Connection Failures . . . . . . . . . . . . . . . 37
3.9.1. User/TCP Interface . . . . . . . . . . . . . . . . . 42 3.8.3. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . 38
3.9.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 50 3.8.4. The Communication of Urgent Information . . . . . . . 38
3.10. Event Processing . . . . . . . . . . . . . . . . . . . . 52 3.8.5. Managing the Window . . . . . . . . . . . . . . . . . 39
3.11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 75 3.9. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 44
4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 80 3.9.1. User/TCP Interface . . . . . . . . . . . . . . . . . 44
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 3.9.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 52
6. Security and Privacy Considerations . . . . . . . . . . . . . 84 3.10. Event Processing . . . . . . . . . . . . . . . . . . . . 54
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84 3.11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 78
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 85 4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 83
8.1. Normative References . . . . . . . . . . . . . . . . . . 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87
8.2. Informative References . . . . . . . . . . . . . . . . . 85 6. Security and Privacy Considerations . . . . . . . . . . . . . 87
Appendix A. TCP Requirement Summary . . . . . . . . . . . . . . 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 88
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.1. Normative References . . . . . . . . . . . . . . . . . . 88
8.2. Informative References . . . . . . . . . . . . . . . . . 89
Appendix A. TCP Requirement Summary . . . . . . . . . . . . . . 90
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 94
1. Purpose and Scope 1. Purpose and Scope
In 1981, RFC 793 [6] was released, documenting the Transmission In 1981, RFC 793 [8] 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.
Since then, TCP has been implemented many times, and has been used as Since then, TCP has been implemented many times, and has been used as
a transport protocol for numerous applications on the Internet. a transport protocol for numerous applications on the Internet.
For several decades, RFC 793 plus a number of other documents have For several decades, RFC 793 plus a number of other documents have
combined to serve as the specification for TCP [17]. Over time, a combined to serve as the specification for TCP [20]. Over time, a
number of errata have been identified on RFC 793, as well as number of errata have been identified on RFC 793, as well as
deficiencies in security, performance, and other aspects. A number deficiencies in security, performance, and other aspects. A number
of enhancements has grown and been documented separately. These were of enhancements has grown and been documented separately. These were
never accumulated together into an update to the base specification. never accumulated together into an update to the base specification.
The purpose of this document is to bring together all of the IETF The purpose of this document is to bring together all of the IETF
Standards Track changes that have been made to the basic TCP Standards Track changes that have been made to the basic TCP
functional specification and unify them into an update of the RFC 793 functional specification and unify them into an update of the RFC 793
protocol specification. Some companion documents are referenced for protocol specification. Some companion documents are referenced for
important algorithms that TCP uses (e.g. for congestion control), but important algorithms that TCP uses (e.g. for congestion control), but
skipping to change at page 4, line 34 skipping to change at page 4, line 36
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 examples and
other discussion in RFC 793. Other documents are referenced to other discussion in RFC 793. Other documents are referenced to
provide explanation of the theory of operation, rationale, and provide explanation of the theory of operation, rationale, and
detailed discussion of design decisions. This document only focuses detailed discussion of design decisions. This document only focuses
on the normative behavior of the protocol. on the normative behavior of the protocol.
The "TCP Roadmap" [17] provides a more extensive guide to the RFCs The "TCP Roadmap" [20] 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. [11]) is a TCP requirement, but is a complex congestion control (e.g. [13]) 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 [16], but these are not include the high-performance extensions in [19], 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 TEMPORARY EDITOR'S NOTE: This is an early revision in the process of
updating RFC 793. Many planned changes are not yet incorporated. updating RFC 793. Many planned changes are not yet incorporated.
***Please do not use this revision as a basis for any work or ***Please do not use this revision as a basis for any work or
reference.*** 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.
skipping to change at page 5, line 16 skipping to change at page 5, line 21
not yet collect all of the changes that will be in the final version. 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 The set of content changes planned for future revisions is kept in
Section 4. Section 4.
3. Functional Specification 3. Functional Specification
3.1. Header Format 3.1. Header Format
TCP segments are sent as internet datagrams. The Internet Protocol TCP segments are sent as internet datagrams. The Internet Protocol
header carries several information fields, including the source and header carries several information fields, including the source and
destination host addresses [2]. A TCP header follows the internet destination host addresses [1]. A TCP header follows the internet
header, supplying information specific to the TCP protocol. This header, supplying information specific to the TCP protocol. This
division allows for the existence of host level protocols other than division allows for the existence of host level protocols other than
TCP. TCP. (Editorial TODO - this last sentence makes sense in 793
context, but may be a candidate to remove here? ... additionally,
Section 2 of 793 is not includeed here, but some parts may be useful,
to quickly define basic concepts of ports, bytestream service, etc.
at high-level before delving into protocol details?)
TCP Header Format TCP Header Format
0 1 2 3 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 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 | | Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number | | Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| | | Data | |U|A|P|R|S|F| |
skipping to change at page 7, line 21 skipping to change at page 8, line 4
form a 16 bit word for checksum purposes. The pad is not form a 16 bit word for checksum purposes. The pad is not
transmitted as part of the segment. While computing the checksum, transmitted as part of the segment. While computing the checksum,
the checksum field itself is replaced with zeros. the checksum field itself is replaced with zeros.
The checksum also covers a 96 bit pseudo header conceptually The checksum also covers a 96 bit pseudo header conceptually
prefixed to the TCP header. This pseudo header contains the Source prefixed to the TCP header. This pseudo header contains the Source
Address, the Destination Address, the Protocol, and TCP length. Address, the Destination Address, the Protocol, and TCP length.
This gives the TCP protection against misrouted segments. This This gives the TCP protection against misrouted segments. This
information is carried in the Internet Protocol and is transferred information is carried in the Internet Protocol and is transferred
across the TCP/Network interface in the arguments or results of across the TCP/Network interface in the arguments or results of
calls by the TCP on the IP. calls by the TCP on the IP. (TODO: this is IPv4-specific, need to
mention IPv6 psuedoheader as well)
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source Address | | Source Address |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Destination Address | | Destination Address |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| zero | PTCL | TCP Length | | zero | PTCL | TCP Length |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
The TCP Length is the TCP header length plus the data length in The TCP Length is the TCP header length plus the data length in
skipping to change at page 8, line 27 skipping to change at page 9, line 13
Option option must be header padding (i.e., zero). Option option must be header padding (i.e., zero).
Currently defined options include (kind indicated in octal): Currently defined options include (kind indicated in octal):
Kind Length Meaning Kind Length Meaning
---- ------ ------- ---- ------ -------
0 - End of option list. 0 - End of option list.
1 - No-Operation. 1 - No-Operation.
2 4 Maximum Segment Size. 2 4 Maximum Segment Size.
TODO - I think we may need to include designated experimental
options and RFC 6994 reference here
A TCP MUST be able to receive a TCP option in any segment. A TCP MUST be able to receive a TCP option in any segment.
A TCP MUST ignore without error any TCP option it does not A TCP MUST ignore without error any TCP option it does not
implement, assuming that the option has a length field (all TCP implement, assuming that the option has a length field (all TCP
options except End of option list and No-Operation have length options except End of option list and No-Operation have length
fields). TCP MUST be prepared to handle an illegal option length fields). TCP MUST be prepared to handle an illegal option length
(e.g., zero) without crashing; a suggested procedure is to reset (e.g., zero) without crashing; a suggested procedure is to reset
the connection and log the reason. the connection and log the reason.
Specific Option Definitions Specific Option Definitions
skipping to change at page 17, line 33 skipping to change at page 18, line 33
ISN = M + F(localip, localport, remoteip, remoteport, secretkey) ISN = M + F(localip, localport, remoteip, remoteport, secretkey)
where M is the 4 microsecond timer, and F() is a pseudorandom where M is the 4 microsecond timer, and F() is a pseudorandom
function (PRF) of the connection's identifying parameters ("localip, function (PRF) of the connection's identifying parameters ("localip,
localport, remoteip, remoteport") and a secret key ("secretkey"). localport, remoteip, remoteport") and a secret key ("secretkey").
F() MUST NOT be computable from the outside, or an attacker could F() MUST NOT be computable from the outside, or an attacker could
still guess at sequence numbers from the ISN used for some other still guess at sequence numbers from the ISN used for some other
connection. The PRF could be implemented as a cryptographic has of connection. The PRF could be implemented as a cryptographic has of
the concatenation of the TCP connection parameters and some secret the concatenation of the TCP connection parameters and some secret
data. For discussion of the selection of a specific hash algorithm data. For discussion of the selection of a specific hash algorithm
and management of the secret key data, please see Section 3 of [14]. and management of the secret key data, please see Section 3 of [17].
For each connection there is a send sequence number and a receive For each connection there is a send sequence number and a receive
sequence number. The initial send sequence number (ISS) is chosen by sequence number. The initial send sequence number (ISS) is chosen by
the data sending TCP, and the initial receive sequence number (IRS) the data sending TCP, and the initial receive sequence number (IRS)
is learned during the connection establishing procedure. is learned during the connection establishing procedure.
For a connection to be established or initialized, the two TCPs must For a connection to be established or initialized, the two TCPs must
synchronize on each other's initial sequence numbers. This is done synchronize on each other's initial sequence numbers. This is done
in an exchange of connection establishing segments carrying a control in an exchange of connection establishing segments carrying a control
bit called "SYN" (for synchronize) and the initial sequence numbers. bit called "SYN" (for synchronize) and the initial sequence numbers.
skipping to change at page 27, line 32 skipping to change at page 28, line 32
The receiver of a RST first validates it, then changes state. If the The receiver of a RST first validates it, then changes state. If the
receiver was in the LISTEN state, it ignores it. If the receiver was receiver was in the LISTEN state, it ignores it. If the receiver was
in SYN-RECEIVED state and had previously been in the LISTEN state, in SYN-RECEIVED state and had previously been in the LISTEN state,
then the receiver returns to the LISTEN state, otherwise the receiver then the receiver returns to the LISTEN state, otherwise the receiver
aborts the connection and goes to the CLOSED state. If the receiver aborts the connection and goes to the CLOSED state. If the receiver
was in any other state, it aborts the connection and advises the user was in any other state, it aborts the connection and advises the user
and goes to the CLOSED state. and goes to the CLOSED state.
TCP SHOULD allow a received RST segment to include data. TCP SHOULD allow a received RST segment to include data.
3.4.1. Remote Address Validation
TODO - figure out if this section would fit better elsewhere, for
instance in the more detailed description of the OPEN call later on
A TCP implementation MUST reject as an error a local OPEN call for an
invalid remote IP address (e.g., a broadcast or multicast address).
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 [10]).
A TCP implementation MUST silently discard an incoming SYN segment
that is addressed to a broadcast or multicast address.
3.5. Closing a Connection 3.5. Closing a Connection
CLOSE is an operation meaning "I have no more data to send." The CLOSE is an operation meaning "I have no more data to send." The
notion of closing a full-duplex connection is subject to ambiguous notion of closing a full-duplex connection is subject to ambiguous
interpretation, of course, since it may not be obvious how to treat interpretation, of course, since it may not be obvious how to treat
the receiving side of the connection. We have chosen to treat CLOSE the receiving side of the connection. We have chosen to treat CLOSE
in a simplex fashion. The user who CLOSEs may continue to RECEIVE in a simplex fashion. The user who CLOSEs may continue to RECEIVE
until he is told that the other side has CLOSED also. Thus, a until he is told that the other side has CLOSED also. Thus, a
program could initiate several SENDs followed by a CLOSE, and then program could initiate several SENDs followed by a CLOSE, and then
continue to RECEIVE until signaled that a RECEIVE failed because the continue to RECEIVE until signaled that a RECEIVE failed because the
skipping to change at page 30, line 41 skipping to change at page 31, line 43
(2) returns to TIME-WAIT state if the SYN turns out to be an old (2) returns to TIME-WAIT state if the SYN turns out to be an old
duplicate. duplicate.
3.6. Precedence and Security 3.6. Precedence and Security
The intent is that connection be allowed only between ports operating The intent is that connection be allowed only between ports operating
with exactly the same security and compartment values and at the with exactly the same security and compartment values and at the
higher of the precedence level requested by the two ports. higher of the precedence level requested by the two ports.
The precedence and security parameters used in TCP are exactly those The precedence and security parameters used in TCP are exactly those
defined in the Internet Protocol (IP) [2]. Throughout this TCP defined in the Internet Protocol (IP) [1]. Throughout this TCP
specification the term "security/compartment" is intended to indicate specification the term "security/compartment" is intended to indicate
the security parameters used in IP including security, compartment, the security parameters used in IP including security, compartment,
user group, and handling restriction. user group, and handling restriction.
A connection attempt with mismatched security/compartment values or a A connection attempt with mismatched security/compartment values or a
lower precedence value must be rejected by sending a reset. lower precedence value must be rejected by sending a reset.
Rejecting a connection due to too low a precedence only occurs after Rejecting a connection due to too low a precedence only occurs after
an acknowledgment of the SYN has been received. an acknowledgment of the SYN has been received.
Note that TCP modules which operate only at the default value of Note that TCP modules which operate only at the default value of
skipping to change at page 31, line 26 skipping to change at page 32, line 26
The term "segmentation" refers to the activity TCP performs when The term "segmentation" refers to the activity TCP performs when
ingesting a stream of bytes from a sending application and ingesting a stream of bytes from a sending application and
packetizing that stream of bytes into TCP segments. Individual TCP packetizing that stream of bytes into TCP segments. Individual TCP
segments often do not correspond one-for-one to individual send (or segments often do not correspond one-for-one to individual send (or
socket write) calls from the application. Applications may perform socket write) calls from the application. Applications may perform
writes at the granularity of messages in the upper layer protocol, writes at the granularity of messages in the upper layer protocol,
but TCP guarantees no boundary coherence between the TCP segments but TCP guarantees no boundary coherence between the TCP segments
sent and received versus user application data read or write buffer sent and received versus user application data read or write buffer
boundaries. In some specific protocols, such as RDMA using DDP and boundaries. In some specific protocols, such as RDMA using DDP and
MPA [10], there are performance optimizations possible when the MPA [12], there are performance optimizations possible when the
relation between TCP segments and application data units can be relation between TCP segments and application data units can be
controlled, and MPA includes a specific mechanism for detecting and controlled, and MPA includes a specific mechanism for detecting and
verifying this relationship between TCP segments and application verifying this relationship between TCP segments and application
message data strcutures, but this is specific to applications like message data strcutures, but this is specific to applications like
RDMA. In general, multiple goals influence the sizing of TCP RDMA. In general, multiple goals influence the sizing of TCP
segments created by a TCP implementation. segments created by a TCP implementation.
Goals driving the sending of larger segments include: Goals driving the sending of larger segments include:
o Reducing the number of packets in flight within the network. o Reducing the number of packets in flight within the network.
skipping to change at page 33, line 25 skipping to change at page 34, line 25
o IPoptionsize is the size of any IP options associated with a TCP o IPoptionsize is the size of any IP options associated with a TCP
connection. Note that some options may not be included on all connection. Note that some options may not be included on all
packets, but that for each segment sent, the sender should adjust packets, but that for each segment sent, the sender should adjust
the data length accordingly, within the Eff.snd.MSS. the data length accordingly, within the Eff.snd.MSS.
The MSS value to be sent in an MSS option should be equal to the The MSS value to be sent in an MSS option should be equal to the
effective MTU minus the fixed IP and TCP headers. By ignoring both effective MTU minus the fixed IP and TCP headers. By ignoring both
IP and TCP options when calculating the value for the MSS option, if IP and TCP options when calculating the value for the MSS option, if
there are any IP or TCP options to be sent in a packet, then the there are any IP or TCP options to be sent in a packet, then the
sender must decrease the size of the TCP data accordingly. RFC 6691 sender must decrease the size of the TCP data accordingly. RFC 6691
[15] discusses this in greater detail. [18] discusses this in greater detail.
The MSS value to be sent in an MSS option must be less than or equal The MSS value to be sent in an MSS option must be less than or equal
to: to:
MMS_R - 20 MMS_R - 20
where MMS_R is the maximum size for a transport-layer message that where MMS_R is the maximum size for a transport-layer message that
can be received (and reassembled). TCP obtains MMS_R and MMS_S from can be received (and reassembled). TCP obtains MMS_R and MMS_S from
the IP layer; see the generic call GET_MAXSIZES in Section 3.4 of RFC the IP layer; see the generic call GET_MAXSIZES in Section 3.4 of RFC
1122. 1122.
skipping to change at page 34, line 7 skipping to change at page 35, line 7
A TCP implementation may be aware of the MTU on directly connected A TCP implementation may be aware of the MTU on directly connected
links, but will rarely have insight about MTUs across an entire links, but will rarely have insight about MTUs across an entire
network path. For IPv4, RFC 1122 provides an IP-layer recommendation network path. For IPv4, RFC 1122 provides an IP-layer recommendation
on the default effective MTU for sending to be less than or equal to on the default effective MTU for sending to be less than or equal to
576 for destinations not directly connected. For IPv6, this would be 576 for destinations not directly connected. For IPv6, this would be
1280. In all cases, however, implementation of Path MTU Discovery 1280. In all cases, however, implementation of Path MTU Discovery
(PMTUD) and Packetization Layer Path MTU Discovery (PLPMTUD) is (PMTUD) and Packetization Layer Path MTU Discovery (PLPMTUD) is
strongly recommended in order for TCP to improve segmentation strongly recommended in order for TCP to improve segmentation
decisions. decisions.
PMTUD for IPv4 [1] or IPv6 [2] is implemented in conjunction between PMTUD for IPv4 [2] or IPv6 [3] is implemented in conjunction between
TCP, IP, and ICMP protocols. Several adjustments to a TCP TCP, IP, and ICMP protocols. Several adjustments to a TCP
implementation with PMTUD are described in RFC 2923 in order to deal implementation with PMTUD are described in RFC 2923 in order to deal
with problems experienced in practice [5]. PLPMTUD [9] is a with problems experienced in practice [6]. PLPMTUD [11] is a
Standards Track improvement to PMTUD that relaxes the requirement for Standards Track improvement to PMTUD that relaxes the requirement for
ICMP support across a path, and improves performance in cases where ICMP support across a path, and improves performance in cases where
ICMP is not consistently conveyed. The mechanisms in all four of ICMP is not consistently conveyed. The mechanisms in all four of
these RFCs are recommended to be included in TCP implementations. these RFCs are recommended to be included in TCP implementations.
The TCP MSS option specifies an upper bound for the size of packets The TCP MSS option specifies an upper bound for the size of packets
that can be received. Hence, setting the value in the MSS option too that can be received. Hence, setting the value in the MSS option too
small can impact the ability for PMTUD or PLPMTUD to find a larger small can impact the ability for PMTUD or PLPMTUD to find a larger
path MTU. RFC 1191 discusses this implication of many older TCP path MTU. RFC 1191 discusses this implication of many older TCP
implementations setting MSS to 536 for non-local destinations, rather implementations setting MSS to 536 for non-local destinations, rather
than deriving it from the MTUs of connected interfaces as than deriving it from the MTUs of connected interfaces as
recommended. recommended.
3.7.3. Interfaces with Variable MTU Values 3.7.3. Interfaces with Variable MTU Values
The effective MTU can sometimes vary, as when used with variable The effective MTU can sometimes vary, as when used with variable
compression, e.g., RObust Header Compression (ROHC) [12]. It is compression, e.g., RObust Header Compression (ROHC) [14]. It is
tempting for TCP to want to advertise the largest possible MSS, to tempting for TCP to want to advertise the largest possible MSS, to
support the most efficient use of compressed payloads. support the most efficient use of compressed payloads.
Unfortunately, some compression schemes occasionally need to transmit Unfortunately, some compression schemes occasionally need to transmit
full headers (and thus smaller payloads) to resynchronize state at full headers (and thus smaller payloads) to resynchronize state at
their endpoint compressors/decompressors. If the largest MTU is used their endpoint compressors/decompressors. If the largest MTU is used
to calculate the value to advertise in the MSS option, TCP to calculate the value to advertise in the MSS option, TCP
retransmission may interfere with compressor resynchronization. retransmission may interfere with compressor resynchronization.
As a result, when the effective MTU of an interface varies, TCP As a result, when the effective MTU of an interface varies, TCP
SHOULD use the smallest effective MTU of the interface to calculate SHOULD use the smallest effective MTU of the interface to calculate
the value to advertise in the MSS option. the value to advertise in the MSS option.
3.7.4. Nagle Algorithm 3.7.4. Nagle Algorithm
The "Nagle algorithm" was described in RFC 896 [7] and was The "Nagle algorithm" was described in RFC 896 [9] and was
recommended in RFC 1122 [8] for mitigation of an early problem of too recommended in RFC 1122 [10] for mitigation of an early problem of
many small packets being generated. It has been implemented in most too many small packets being generated. It has been implemented in
current TCP code bases, sometimes with minor variations. most current TCP code bases, sometimes with minor variations.
If there is unacknowledged data (i.e., SND.NXT > SND.UNA), then the If there is unacknowledged data (i.e., SND.NXT > SND.UNA), then the
sending TCP buffers all user data (regardless of the PSH bit), until sending TCP buffers all user data (regardless of the PSH bit), until
the outstanding data has been acknowledged or until the TCP can send the outstanding data has been acknowledged or until the TCP can send
a full-sized segment (Eff.snd.MSS bytes). a full-sized segment (Eff.snd.MSS bytes).
TODO - see if SEND description later should be updated to reflect TODO - see if SEND description later should be updated to reflect
this this
A TCP SHOULD implement the Nagle Algorithm to coalesce short A TCP SHOULD implement the Nagle Algorithm to coalesce short
segments. However, there MUST be a way for an application to disable segments. However, there MUST be a way for an application to disable
the Nagle algorithm on an individual connection. In all cases, the Nagle algorithm on an individual connection. In all cases,
sending data is also subject to the limitation imposed by the Slow sending data is also subject to the limitation imposed by the Slow
Start algorithm [11]. Start algorithm [13].
3.7.5. IPv6 Jumbograms 3.7.5. IPv6 Jumbograms
In order to support TCP over IPv6 jumbograms, implementations need to In order to support TCP over IPv6 jumbograms, implementations need to
be able to send TCP segments larger than the 64KB limit that the MSS be able to send TCP segments larger than the 64KB limit that the MSS
option can convey. RFC 2675 [4] defines that an MSS value of 65,535 option can convey. RFC 2675 [5] defines that an MSS value of 65,535
bytes is to be treated as infinity, and Path MTU Discovery [2] is bytes is to be treated as infinity, and Path MTU Discovery [3] is
used to determine the actual MSS. used to determine the actual MSS.
3.8. Data Communication 3.8. Data Communication
Once the connection is established data is communicated by the Once the connection is established data is communicated by the
exchange of segments. Because segments may be lost due to errors exchange of segments. Because segments may be lost due to errors
(checksum test failure), or network congestion, TCP uses (checksum test failure), or network congestion, TCP uses
retransmission (after a timeout) to ensure delivery of every segment. retransmission (after a timeout) to ensure delivery of every segment.
Duplicate segments may arrive due to network or TCP retransmission. Duplicate segments may arrive due to network or TCP retransmission.
As discussed in the section on sequence numbers the TCP performs As discussed in the section on sequence numbers the TCP performs
skipping to change at page 36, line 7 skipping to change at page 37, line 7
communication. The amount by which the variables are advanced is the communication. The amount by which the variables are advanced is the
length of the data and SYN or FIN flags in the segment. Note that length of the data and SYN or FIN flags in the segment. Note that
once in the ESTABLISHED state all segments must carry current once in the ESTABLISHED state all segments must carry current
acknowledgment information. acknowledgment information.
The CLOSE user call implies a push function, as does the FIN control The CLOSE user call implies a push function, as does the FIN control
flag in an incoming segment. flag in an incoming segment.
3.8.1. Retransmission Timeout 3.8.1. Retransmission Timeout
NOTE: TODO this needs to be updated in light of 1122 4.2.2.15 and
errata 573; this will be done as part of RFC 1122 incorporation into
this document.
Because of the variability of the networks that compose an Because of the variability of the networks that compose an
internetwork system and the wide range of uses of TCP connections the internetwork system and the wide range of uses of TCP connections the
retransmission timeout must be dynamically determined. One procedure retransmission timeout (RTO) must be dynamically determined.
for determining a retransmission timeout is given here as an
illustration.
An Example Retransmission Timeout Procedure The RTO MUST be computed according to the algorithm in [7], including
Karn's algorithm for taking RTT samples.
Measure the elapsed time between sending a data octet with a RFC 793 contains an early example procedure for computing the RTO.
particular sequence number and receiving an acknowledgment that This was then replaced by the algorithm described in RFC 1122, and
covers that sequence number (segments sent do not have to match subsequently updated in RFC 2988, and then again in RFC 6298.
segments received). This measured elapsed time is the Round Trip
Time (RTT). Next compute a Smoothed Round Trip Time (SRTT) as:
SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT) If a retransmitted packet is identical to the original packet (which
implies not only that the data boundaries have not changed, but also
that the window and acknowledgment fields of the header have not
changed), then the same IP Identification field MAY be used (see
Section 3.2.1.5 of RFC 1122).
and based on this, compute the retransmission timeout (RTO) as: 3.8.2. TCP Connection Failures
RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]] Excessive retransmission of the same segment by TCP indicates some
failure of the remote host or the Internet path. This failure may be
of short or long duration. The following procedure MUST be used to
handle excessive retransmissions of data segments:
where UBOUND is an upper bound on the timeout (e.g., 1 minute), (a) There are two thresholds R1 and R2 measuring the amount of
LBOUND is a lower bound on the timeout (e.g., 1 second), ALPHA is retransmission that has occurred for the same segment. R1 and R2
a smoothing factor (e.g., .8 to .9), and BETA is a delay variance might be measured in time units or as a count of retransmissions.
factor (e.g., 1.3 to 2.0).
3.8.2. The Communication of Urgent Information (b) When the number of transmissions of the same segment reaches
or exceeds threshold R1, pass negative advice (see [10]
Section 3.3.1.4) to the IP layer, to trigger dead-gateway
diagnosis.
(c) When the number of transmissions of the same segment reaches a
threshold R2 greater than R1, close the connection.
(d) An application MUST be able to set the value for R2 for a
particular connection. For example, an interactive application
might set R2 to "infinity," giving the user control over when to
disconnect.
(d) TCP SHOULD inform the application of the delivery problem
(unless such information has been disabled by the application; see
RFC1122 Section 4.2.4.1 - TODO update to error reporting
description in this document), when R1 is reached and before R2.
This will allow a remote login (User Telnet) application program
to inform the user, for example.
The value of R1 SHOULD correspond to at least 3 retransmissions, at
the current RTO. The value of R2 SHOULD correspond to at least 100
seconds.
An attempt to open a TCP connection could fail with excessive
retransmissions of the SYN segment or by receipt of a RST segment or
an ICMP Port Unreachable. SYN retransmissions MUST be handled in the
general way just described for data retransmissions, including
notification of the application layer.
However, the values of R1 and R2 may be different for SYN and data
segments. In particular, R2 for a SYN segment MUST be set large
enough to provide retransmission of the segment for at least 3
minutes. The application can close the connection (i.e., give up on
the open attempt) sooner, of course.
3.8.3. TCP Keep-Alives
Implementors MAY include "keep-alives" in their TCP implementations,
although this practice is not universally accepted. If keep-alives
are included, the application MUST be able to turn them on or off for
each TCP connection, and they MUST default to off.
Keep-alive packets MUST only be sent when no data or acknowledgement
packets have been received for the connection within an interval.
This interval MUST be configurable and MUST default to no less than
two hours.
It is extremely important to remember that ACK segments that contain
no data are not reliably transmitted by TCP. Consequently, if a
keep-alive mechanism is implemented it MUST NOT interpret failure to
respond to any specific probe as a dead connection.
An implementation SHOULD send a keep-alive segment with no data;
however, it MAY be configurable to send a keep-alive segment
containing one garbage octet, for compatibility with erroneous TCP
implementations.
3.8.4. The Communication of Urgent Information
As a result of implementation differences and middlebox interactions, As a result of implementation differences and middlebox interactions,
new applications SHOULD NOT employ the TCP urgent mechanism. new applications SHOULD NOT employ the TCP urgent mechanism.
However, TCP implementations MUST still include support for the However, TCP implementations MUST still include support for the
urgent mechanism. Details can be found in RFC 6093 [13]. urgent mechanism. Details can be found in RFC 6093 [15].
The objective of the TCP urgent mechanism is to allow the sending The objective of the TCP urgent mechanism is to allow the sending
user to stimulate the receiving user to accept some urgent data and user to stimulate the receiving user to accept some urgent data and
to permit the receiving TCP to indicate to the receiving user when to permit the receiving TCP to indicate to the receiving user when
all the currently known urgent data has been received by the user. all the currently known urgent data has been received by the user.
This mechanism permits a point in the data stream to be designated as This mechanism permits a point in the data stream to be designated as
the end of urgent information. Whenever this point is in advance of the end of urgent information. Whenever this point is in advance of
the receive sequence number (RCV.NXT) at the receiving TCP, that TCP the receive sequence number (RCV.NXT) at the receiving TCP, that TCP
must tell the user to go into "urgent mode"; when the receive must tell the user to go into "urgent mode"; when the receive
skipping to change at page 37, line 18 skipping to change at page 39, line 30
transmitted. The URG control flag indicates that the urgent field is transmitted. The URG control flag indicates that the urgent field is
meaningful and must be added to the segment sequence number to yield meaningful and must be added to the segment sequence number to yield
the urgent pointer. The absence of this flag indicates that there is the urgent pointer. The absence of this flag indicates that there is
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. [8] A TCP MUST support a sequence of urgent data of any length. [10]
A TCP MUST inform the application layer asynchronously whenever it A TCP MUST inform the application layer asynchronously whenever it
receives an Urgent pointer and there was previously no pending urgent receives an Urgent pointer and there was previously no pending urgent
data, or whenvever the Urgent pointer advances in the data stream. data, or whenvever the Urgent pointer advances in the data stream.
There MUST be a way for the application to learn how much urgent data There MUST be a way for the application to learn how much urgent data
remains to be read from the connection, or at least to determine remains to be read from the connection, or at least to determine
whether or not more urgent data remains to be read. [8] whether or not more urgent data remains to be read. [10]
3.8.3. Managing the Window 3.8.5. Managing the Window
The window sent in each segment indicates the range of sequence The window sent in each segment indicates the range of sequence
numbers the sender of the window (the data receiver) is currently numbers the sender of the window (the data receiver) is currently
prepared to accept. There is an assumption that this is related to prepared to accept. There is an assumption that this is related to
the currently available data buffer space available for this the currently available data buffer space available for this
connection. connection.
The sending TCP packages the data to be transmitted into segments The sending TCP packages the data to be transmitted into segments
which fit the current window, and may repackage segments on the which fit the current window, and may repackage segments on the
retransmission queue. Such repackaging is not required, but may be retransmission queue. Such repackaging is not required, but may be
skipping to change at page 38, line 19 skipping to change at page 40, line 32
The mechanisms provided allow a TCP to advertise a large window and The mechanisms provided allow a TCP to advertise a large window and
to subsequently advertise a much smaller window without having to subsequently advertise a much smaller window without having
accepted that much data. This, so called "shrinking the window," is accepted that much data. This, so called "shrinking the window," is
strongly discouraged. The robustness principle dictates that TCPs strongly discouraged. The robustness principle dictates that TCPs
will not shrink the window themselves, but will be prepared for such will not shrink the window themselves, but will be prepared for such
behavior on the part of other TCPs. behavior on the part of other TCPs.
A TCP receiver SHOULD NOT shrink the window, i.e., move the right A TCP receiver SHOULD NOT shrink the window, i.e., move the right
window edge to the left. However, a sending TCP MUST be robust window edge to the left. However, a sending TCP MUST be robust
against window shrinking, which may cause the "useable window" (see against window shrinking, which may cause the "useable window" (see
Section 3.8.3.2.1) to become negative. Section 3.8.5.2.1) to become negative.
If this happens, the sender SHOULD NOT send new data, but SHOULD If this happens, the sender SHOULD NOT send new data, but SHOULD
retransmit normally the old unacknowledged data between SND.UNA and retransmit normally the old unacknowledged data between SND.UNA and
SND.UNA+SND.WND. The sender MAY also retransmit old data beyond SND.UNA+SND.WND. The sender MAY also retransmit old data beyond
SND.UNA+SND.WND, but SHOULD NOT time out the connection if data SND.UNA+SND.WND, but SHOULD NOT time out the connection if data
beyond the right window edge is not acknowledged. If the window beyond the right window edge is not acknowledged. If the window
shrinks to zero, the TCP MUST probe it in the standard way (described shrinks to zero, the TCP MUST probe it in the standard way (described
below). below).
3.8.3.1. Zero Window Probing 3.8.5.1. Zero Window Probing
The sending TCP must be prepared to accept from the user and send at The sending TCP must be prepared to accept from the user and send at
least one octet of new data even if the send window is zero. The least one octet of new data even if the send window is zero. The
sending TCP must regularly retransmit to the receiving TCP even when sending TCP must regularly retransmit to the receiving TCP even when
the window is zero, in order to "probe" the window. Two minutes is the window is zero, in order to "probe" the window. Two minutes is
recommended for the retransmission interval when the window is zero. recommended for the retransmission interval when the window is zero.
This retransmission is essential to guarantee that when either TCP This retransmission is essential to guarantee that when either TCP
has a zero window the re-opening of the window will be reliably has a zero window the re-opening of the window will be reliably
reported to the other. This is referred to as Zero-Window Probing reported to the other. This is referred to as Zero-Window Probing
(ZWP) in other documents. (ZWP) in other documents.
Probing of zero (offered) windows MUST be supported. Probing of zero (offered) windows MUST be supported.
A TCP MAY keep its offered receive window closed indefinitely. As A TCP MAY keep its offered receive window closed indefinitely. As
long as the receiving TCP continues to send acknowledgments in long as the receiving TCP continues to send acknowledgments in
response to the probe segments, the sending TCP MUST allow the response to the probe segments, the sending TCP MUST allow the
connection to stay open. connection to stay open. This enables TCP to function in 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
implementation's resource management concerns, as noted in [16].
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).
3.8.3.2. Silly Window Syndrome Avoidance 3.8.5.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
increments, while the SWS avoidance algorithm discourages small increments, while the SWS avoidance algorithm discourages small
segments resulting from the right window edge advancing in small segments resulting from the right window edge advancing in small
increments. increments.
3.8.3.2.1. Sender's Algorithm - When to Send Data 3.8.5.2.1. Sender's Algorithm - When to Send Data
A TCP MUST include a SWS avoidance algorithm in the sender. A TCP MUST include a SWS avoidance algorithm in the sender.
A TCP SHOULD implement the Nagle Algorithm to coalesce short A TCP SHOULD implement the Nagle Algorithm to coalesce short
segments. However, there MUST be a way for an application to disable segments. However, there MUST be a way for an application to disable
the Nagle algorithm on an individual connection. In all cases, the Nagle algorithm on an individual connection. In all cases,
sending data is also subject to the limitation imposed by the Slow sending data is also subject to the limitation imposed by the Slow
Start algorithm. Start algorithm.
The sender's SWS avoidance algorithm is more difficult than the The sender's SWS avoidance algorithm is more difficult than the
skipping to change at page 40, line 24 skipping to change at page 42, line 38
[SND.NXT = SND.UNA and] [SND.NXT = SND.UNA and]
min(D.U) >= Fs * Max(SND.WND); min(D.U) >= Fs * Max(SND.WND);
(4) or if data is PUSHed and the override timeout occurs. (4) or if data is PUSHed and the override timeout occurs.
Here Fs is a fraction whose recommended value is 1/2. The override Here Fs is a fraction whose recommended value is 1/2. The override
timeout should be in the range 0.1 - 1.0 seconds. It may be timeout should be in the range 0.1 - 1.0 seconds. It may be
convenient to combine this timer with the timer used to probe zero convenient to combine this timer with the timer used to probe zero
windows (Section Section 3.8.3.1). windows (Section Section 3.8.5.1).
3.8.3.2.2. Receiver's Algorithm - When to Send a Window Update 3.8.5.2.2. Receiver's Algorithm - When to Send a Window Update
A TCP MUST include a SWS avoidance algorithm in the receiver. A TCP MUST include a SWS avoidance algorithm in the receiver.
The receiver's SWS avoidance algorithm determines when the right The receiver's SWS avoidance algorithm determines when the right
window edge may be advanced; this is customarily known as "updating window edge may be advanced; this is customarily known as "updating
the window". This algorithm combines with the delayed ACK algorithm the window". This algorithm combines with the delayed ACK algorithm
(see Section 3.8.3.3) to determine when an ACK segment containing the (see Section 3.8.5.3) to determine when an ACK segment containing the
current window will really be sent to the receiver. current window will really be sent to the receiver.
The solution to receiver SWS is to avoid advancing the right window The solution to receiver SWS is to avoid advancing the right window
edge RCV.NXT+RCV.WND in small increments, even if data is received edge RCV.NXT+RCV.WND in small increments, even if data is received
from the network in small segments. from the network in small segments.
Suppose the total receive buffer space is RCV.BUFF. At any given Suppose the total receive buffer space is RCV.BUFF. At any given
moment, RCV.USER octets of this total may be tied up with data that moment, RCV.USER octets of this total may be tied up with data that
has been received and acknowledged but which the user process has not has been received and acknowledged but which the user process has not
yet consumed. When the connection is quiescent, RCV.WND = RCV.BUFF yet consumed. When the connection is quiescent, RCV.WND = RCV.BUFF
skipping to change at page 41, line 33 skipping to change at page 43, line 45
where Fr is a fraction whose recommended value is 1/2, and where Fr is a fraction whose recommended value is 1/2, and
Eff.snd.MSS is the effective send MSS for the connection (see Eff.snd.MSS is the effective send MSS for the connection (see
Section 3.7.1). When the inequality is satisfied, RCV.WND is set to Section 3.7.1). When the inequality is satisfied, RCV.WND is set to
RCV.BUFF-RCV.USER. RCV.BUFF-RCV.USER.
Note that the general effect of this algorithm is to advance RCV.WND Note that the general effect of this algorithm is to advance RCV.WND
in increments of Eff.snd.MSS (for realistic receive buffers: in increments of Eff.snd.MSS (for realistic receive buffers:
Eff.snd.MSS < RCV.BUFF/2). Note also that the receiver must use its Eff.snd.MSS < RCV.BUFF/2). Note also that the receiver must use its
own Eff.snd.MSS, assuming it is the same as the sender's. own Eff.snd.MSS, assuming it is the same as the sender's.
3.8.3.3. Delayed Acknowledgements - When to Send an ACK Segment 3.8.5.3. Delayed Acknowledgements - When to Send an ACK Segment
A host that is receiving a stream of TCP data segments can increase A host that is receiving a stream of TCP data segments can increase
efficiency in both the Internet and the hosts by sending fewer than efficiency in both the Internet and the hosts by sending fewer than
one ACK (acknowledgment) segment per data segment received; this is one ACK (acknowledgment) segment per data segment received; this is
known as a "delayed ACK". known as a "delayed ACK".
A TCP SHOULD implement a delayed ACK, but an ACK should not be A TCP SHOULD implement a delayed ACK, but an ACK should not be
excessively delayed; in particular, the delay MUST be less than 0.5 excessively delayed; in particular, the delay MUST be less than 0.5
seconds, and in a stream of full-sized segments there SHOULD be an seconds, and in a stream of full-sized segments there SHOULD be an
ACK for at least every second segment. Excessive delays on ACK's can ACK for at least every second segment. Excessive delays on ACK's can
skipping to change at page 44, line 34 skipping to change at page 46, line 45
multihoming is present. 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 will be used for opening the connection. If the parameter MUST be used for opening the connection. If the
parameter is unspecified, the TCP will choose an appropriate parameter is unspecified, the TCP will choose an appropriate
local IP address (see RFC 1122 section 3.3.4.2). local IP address (see RFC 1122 section 3.3.4.2).
TODO - the previous and next paragraphs are mildly in conflict. TODO - the previous and next paragraphs are mildly in conflict.
Previous paragraph says that the TCP chooses an address, but Previous paragraph says that the TCP chooses an address, but
next paragraph says that it asks IP to choose ... need to make next paragraph says that it asks IP to choose ... need to make
this consistent this consistent
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
skipping to change at page 45, line 24 skipping to change at page 47, line 36
which case, an automatic OPEN would be done. If the calling which case, an automatic OPEN would be done. If the calling
process is not authorized to use this connection, an error is process is not authorized to use this connection, an error is
returned. returned.
If the PUSH flag is set, the data must be transmitted promptly If the PUSH flag is set, the data must be transmitted promptly
to the receiver, and the PUSH bit will be set in the last TCP to the receiver, and the PUSH bit will be set in the last TCP
segment created from the buffer. If the PUSH flag is not set, segment created from the buffer. If the PUSH flag is not set,
the data may be combined with data from subsequent SENDs for the data may be combined with data from subsequent SENDs for
transmission efficiency. transmission efficiency.
New applications SHOULD NOT set the URGENT flag [13] due to New applications SHOULD NOT set the URGENT flag [15] due to
implementation differences and middlebox issues. implementation differences and middlebox issues.
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
and to indicate to the receiver when all the currently known and to indicate to the receiver when all the currently known
urgent data has been received. The number of times the sending urgent data has been received. The number of times the sending
skipping to change at page 50, line 17 skipping to change at page 52, line 29
Buffer Address Send & Receive Buffer Address Send & Receive
Byte count (counts bytes received) Receive Byte count (counts bytes received) Receive
Push flag Receive Push flag Receive
Urgent flag Receive Urgent flag Receive
3.9.2. TCP/Lower-Level Interface 3.9.2. TCP/Lower-Level Interface
The TCP calls on a lower level protocol module to actually send and The TCP calls on a lower level protocol module to actually send and
receive information over a network. One case is that of the ARPA receive information over a network. One case is that of the ARPA
internetwork system where the lower level module is the Internet internetwork system where the lower level module is the Internet
Protocol (IP) [2]. Protocol (IP) [1].
If the lower level protocol is IP it provides arguments for a type of If the lower level protocol is IP it provides arguments for a type of
service and for a time to live. TCP uses the following settings for service and for a time to live. TCP uses the following settings for
these parameters: these parameters:
Type of Service = Precedence: given by user, Delay: normal, Type of Service = Precedence: given by user, Delay: normal,
Throughput: normal, Reliability: normal; or binary XXX00000, where Throughput: normal, Reliability: normal; or binary XXX00000, where
XXX are the three bits determining precedence, e.g. 000 means XXX are the three bits determining precedence, e.g. 000 means
routine precedence. routine precedence.
skipping to change at page 68, line 8 skipping to change at page 70, line 8
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.
In general, the processing of received segments MUST be
implemented to aggregate ACK segments whenever possible.
For example, if the TCP is processing a series of queued
segments, it MUST process them all before sending any ACK
segments. (TODO - see if there's a better place for this
paragraph - taken from RFC1122)
second check the RST bit, second check the RST bit,
SYN-RECEIVED STATE 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
skipping to change at page 72, line 34 skipping to change at page 74, line 42
When the TCP takes responsibility for delivering the data When the TCP takes responsibility for delivering the data
to the user it must also acknowledge the receipt of the to the user it must also acknowledge the receipt of the
data. data.
Once the TCP takes responsibility for the data it Once the TCP takes responsibility for the data it
advances RCV.NXT over the data accepted, and adjusts advances RCV.NXT over the data accepted, and adjusts
RCV.WND as appropriate to the current buffer RCV.WND as appropriate to the current buffer
availability. The total of RCV.NXT and RCV.WND should availability. The total of RCV.NXT and RCV.WND should
not be reduced. not be reduced.
A TCP MAY send an ACK segment acknowledging RCV.NXT when
a valid segment arrives that is in the window but not at
the left window edge.
Please note the window management suggestions in section Please note the window management suggestions in section
3.7. 3.7.
Send an acknowledgment of the form: Send an acknowledgment of the form:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
This acknowledgment should be piggybacked on a segment This acknowledgment should be piggybacked on a segment
being transmitted if possible without incurring undue being transmitted if possible without incurring undue
delay. delay.
skipping to change at page 81, line 25 skipping to change at page 84, line 25
either accepted or held for an update to RFC 793 were incorporated either accepted or held for an update to RFC 793 were incorporated
(Errata IDs: 573, 574, 700, 701, 1283, 1561, 1562, 1564, 1565, 1571, (Errata IDs: 573, 574, 700, 701, 1283, 1561, 1562, 1564, 1565, 1571,
1572, 2296, 2297, 2298, 2748, 2749, 2934, 3213, 3300, 3301). Some 1572, 2296, 2297, 2298, 2748, 2749, 2934, 3213, 3300, 3301). Some
errata were not applicable due to other changes (Errata IDs: 572, errata were not applicable due to other changes (Errata IDs: 572,
575, 1569, 3602). TODO: 3305 575, 1569, 3602). TODO: 3305
Changes to the specification of the Urgent Pointer described in RFC Changes to the specification of the Urgent Pointer described in RFC
1122 and 6093 were incorporated. See RFC 6093 for detailed 1122 and 6093 were incorporated. See RFC 6093 for detailed
discussion of why these changes were necessary. discussion of why these changes were necessary.
The discussion of the RTO from RFC 793 was updated to refer to RFC
6298. The RFC 1122 text on the RTO originally replaced the 793 text,
however, RFC 2988 should have updated 1122, and has subsequently been
obsoleted by 6298.
RFC 1122 contains a collection of other changes and clarifications to
RFC 793. The normative items impacting the protocol have been
incorporated here, though some historically useful implementation
advice and informative discussion from RFC 1122 is not included here.
RFC 1122 contains more than just TCP requirements, so this document
can't obsolete RFC 1122 entirely. It is only marked as "updating"
1122, however, it should be understood to effectively obsolete all of
the RFC 1122 material on TCP.
The more secure Initial Sequence Number generation algorithm from RFC The more secure Initial Sequence Number generation algorithm from RFC
6528 was incorporated. See RFC 6528 for discussion of the attacks 6528 was incorporated. See RFC 6528 for discussion of the attacks
that this mitigates, as well as advice on selecting PRF algorithms that this mitigates, as well as advice on selecting PRF algorithms
and managing secret key data. and managing secret key data.
A note based on RFC 6429 was added to explicitly clarify that system
resource mangement concerns allow connection resources to be
reclaimed. RFC 6429 is obsoleted in the sense that this
clarification has been reflected in this update to the base TCP
specification now.
RFC EDITOR'S NOTE: the content below is for detailed change tracking RFC EDITOR'S NOTE: the content below is for detailed change tracking
and planning, and not to be included with the final revision of the and planning, and not to be included with the final revision of the
document. document.
This document started as draft-eddy-rfc793bis-00, that was merely a This document started as draft-eddy-rfc793bis-00, that was merely a
proposal and rough plan for updating RFC 793. proposal and rough plan for updating RFC 793.
The -01 revision of this draft-eddy-rfc793bis incorporates the The -01 revision of this draft-eddy-rfc793bis incorporates the
content of RFC 793 Section 3 titled "FUNCTIONAL SPECIFICATION". content of RFC 793 Section 3 titled "FUNCTIONAL SPECIFICATION".
Other content from RFC 793 has not been incorporated. The -01 Other content from RFC 793 has not been incorporated. The -01
skipping to change at page 83, line 29 skipping to change at page 87, line 4
avoid document expiration. TCPM working group discussion in 2015 avoid document expiration. TCPM working group discussion in 2015
also indicated that that we should not try to add sections on also indicated that that we should not try to add sections on
implementation advice or similar non-normative information. implementation advice or similar non-normative information.
The -03 revision incorporates more content from RFC 1122: Passive The -03 revision incorporates more content from RFC 1122: Passive
OPEN Calls, Time-To-Live, Multihoming, IP Options, ICMP messages, OPEN Calls, Time-To-Live, Multihoming, IP Options, ICMP messages,
Data Communications, When to Send Data, When to Send a Window Update, Data Communications, When to Send Data, When to Send a Window Update,
Managing the Window, Probing Zero Windows, When to Send an ACK Managing the Window, Probing Zero Windows, When to Send an ACK
Segment. The section on data communications was re-organized into Segment. The section on data communications was re-organized into
clearer subsections (previously headings were embedded in the 793 clearer subsections (previously headings were embedded in the 793
text), and windows management advice from 793 was provisionally text), and windows management advice from 793 was removed (as
removed (to be reviewed by TCPM working group) in favor of the 1122 reviewed by TCPM working group) in favor of the 1122 additions on
additions on SWS, ZWP, and related topics. SWS, ZWP, and related topics.
The -04 revision includes reference to RFC 6429 on the ZWP condition,
RFC1122 material on TCP Connection Failures, TCP Keep-Alives,
Acknowledging Queued Segments, and Remote Address Validation. RTO
computation is referenced from RFC 6298 rather than RFC 1122.
TODO list of other planned changes (these can be added to or made TODO list of other planned changes (these can be added to or made
more specific, as the document proceeds): more specific, as the document proceeds):
1. incorporate all other 1122 additions (sections on Retransmission 1. incorporate relevant parts of 3168 (ECN) - beyond just indicating
Timeout, Event Processing, Acknowledging Queued Segments,
Retransmission Timeout Calculation, TCP Connection Failures, TCP
Keep-Alives, remote address validation)
2. incorporate relevant parts of 3168 (ECN) - beyond just indicating
the names of the 2 bits already done the names of the 2 bits already done
3. point to 5461 (soft errors) 2. point to 5461 (soft errors)
4. mention 5961 state machine option 3. mention 5961 state machine option
5. mention 6161 (reducing TIME-WAIT) 4. mention 6161 (reducing TIME-WAIT)
6. incorporate 6429 (ZWP/persist) 5. TOS material does not take DSCP changes into account
7. TOS material does not take DSCP changes into account 6. there is inconsistency between use of SYN_RCVD and SYNC-RECEIVED
8. there is inconsistency between use of SYN_RCVD and SYNC-RECEIVED
in diagrams and text in various places in diagrams and text in various places
9. make sure that clarifications in RFC 1011 are captured 7. make sure that clarifications in RFC 1011 are captured
TODO list of other potential changes, if there is TCPM consensus: TODO list of other potential changes, if there is TCPM consensus:
1. incorporate Fernando's new number-checking fixes (if past the 1. see draft-gont-tcpm-tcp-seccomp-prec
2. incorporate Fernando's new number-checking fixes (if past the
IESG in time) IESG in time)
2. look at Tony Sabatini suggestion for describing DO field 3. look at Tony Sabatini suggestion for describing DO field
3. clearly specify treatment of reserved bits (see TCPM thread on 4. clearly specify treatment of reserved bits (see TCPM thread on
EDO draft April 25, 2014) EDO draft April 25, 2014)
4. look at possible mention of draft-minshall-nagle (e.g. as in 5. look at possible mention of draft-minshall-nagle (e.g. as in
Linux) Linux)
5. per discussion with Joe Touch (TAPS list, 6/20/2015), the 6. 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
5. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. Existing IANA registries for This memo includes no request to IANA. Existing IANA registries for
TCP parameters are sufficient. TCP parameters are sufficient.
TODO: check whether entries pointing to 793 and other documents TODO: check whether entries pointing to 793 and other documents
obsoleted by this one should be updated to point to this one instead. obsoleted by this one should be updated to point to this one instead.
6. Security and Privacy Considerations 6. Security and Privacy Considerations
TODO TODO
See RFC 6093 [15] for discussion of security considerations related
See RFC 6093 [13] for discussion of security considerations related
to the urgent pointer field. to the urgent pointer field.
Editor's Note: Scott Brim mentioned that this should include a Editor's Note: Scott Brim mentioned that this should include a
PERPASS/privacy review. PERPASS/privacy review.
7. Acknowledgements 7. Acknowledgements
This document is largely a revision of RFC 793, which Jon Postel was This document is largely a revision of RFC 793, which Jon Postel was
the editor of. Due to his excellent work, it was able to last for the editor of. Due to his excellent work, it was able to last for
three decades before we felt the need to revise it. three decades before we felt the need to revise it.
skipping to change at page 85, line 16 skipping to change at page 88, line 42
This document includes content from errata that were reported by This document includes content from errata that were reported by
(listed chronologically): Yin Shuming, Bob Braden, Morris M. Keesan, (listed chronologically): Yin Shuming, Bob Braden, Morris M. Keesan,
Pei-chun Cheng, Constantin Hagemeier, Vishwas Manral, Mykyta Pei-chun Cheng, Constantin Hagemeier, Vishwas Manral, Mykyta
Yevstifeyev, EungJun Yi, Botong Huang. Yevstifeyev, EungJun Yi, Botong Huang.
8. References 8. References
8.1. Normative References 8.1. Normative References
[1] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [1] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[2] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>. <http://www.rfc-editor.org/info/rfc1191>.
[2] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [3] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>. 1996, <http://www.rfc-editor.org/info/rfc1981>.
[3] Bradner, S., "Key words for use in RFCs to Indicate [4] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[4] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", [5] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, DOI 10.17487/RFC2675, August 1999, RFC 2675, DOI 10.17487/RFC2675, August 1999,
<http://www.rfc-editor.org/info/rfc2675>. <http://www.rfc-editor.org/info/rfc2675>.
[5] Lahey, K., "TCP Problems with Path MTU Discovery", [6] Lahey, K., "TCP Problems with Path MTU Discovery",
RFC 2923, DOI 10.17487/RFC2923, September 2000, RFC 2923, DOI 10.17487/RFC2923, September 2000,
<http://www.rfc-editor.org/info/rfc2923>. <http://www.rfc-editor.org/info/rfc2923>.
[7] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011,
<http://www.rfc-editor.org/info/rfc6298>.
8.2. Informative References 8.2. Informative References
[6] Postel, J., "Transmission Control Protocol", STD 7, [8] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <http://www.rfc-editor.org/info/rfc793>.
[7] Nagle, J., "Congestion Control in IP/TCP Internetworks", [9] Nagle, J., "Congestion Control in IP/TCP Internetworks",
RFC 896, DOI 10.17487/RFC0896, January 1984, RFC 896, DOI 10.17487/RFC0896, January 1984,
<http://www.rfc-editor.org/info/rfc896>. <http://www.rfc-editor.org/info/rfc896>.
[8] Braden, R., Ed., "Requirements for Internet Hosts - [10] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <http://www.rfc-editor.org/info/rfc1122>.
[9] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [11] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>. <http://www.rfc-editor.org/info/rfc4821>.
[10] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. [12] Culley, P., Elzur, U., Recio, R., Bailey, S., and J.
Carrier, "Marker PDU Aligned Framing for TCP Carrier, "Marker PDU Aligned Framing for TCP
Specification", RFC 5044, DOI 10.17487/RFC5044, October Specification", RFC 5044, DOI 10.17487/RFC5044, October
2007, <http://www.rfc-editor.org/info/rfc5044>. 2007, <http://www.rfc-editor.org/info/rfc5044>.
[11] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [13] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<http://www.rfc-editor.org/info/rfc5681>. <http://www.rfc-editor.org/info/rfc5681>.
[12] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust [14] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795, Header Compression (ROHC) Framework", RFC 5795,
DOI 10.17487/RFC5795, March 2010, DOI 10.17487/RFC5795, March 2010,
<http://www.rfc-editor.org/info/rfc5795>. <http://www.rfc-editor.org/info/rfc5795>.
[13] Gont, F. and A. Yourtchenko, "On the Implementation of the [15] Gont, F. and A. Yourtchenko, "On the Implementation of the
TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093,
January 2011, <http://www.rfc-editor.org/info/rfc6093>. January 2011, <http://www.rfc-editor.org/info/rfc6093>.
[14] Gont, F. and S. Bellovin, "Defending against Sequence [16] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender
Clarification for Persist Condition", RFC 6429,
DOI 10.17487/RFC6429, December 2011,
<http://www.rfc-editor.org/info/rfc6429>.
[17] Gont, F. and S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
2012, <http://www.rfc-editor.org/info/rfc6528>. 2012, <http://www.rfc-editor.org/info/rfc6528>.
[15] Borman, D., "TCP Options and Maximum Segment Size (MSS)", [18] Borman, D., "TCP Options and Maximum Segment Size (MSS)",
RFC 6691, DOI 10.17487/RFC6691, July 2012, RFC 6691, DOI 10.17487/RFC6691, July 2012,
<http://www.rfc-editor.org/info/rfc6691>. <http://www.rfc-editor.org/info/rfc6691>.
[16] Borman, D., Braden, B., Jacobson, V., and R. [19] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance", Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014, RFC 7323, DOI 10.17487/RFC7323, September 2014,
<http://www.rfc-editor.org/info/rfc7323>. <http://www.rfc-editor.org/info/rfc7323>.
[17] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. [20] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
Zimmermann, "A Roadmap for Transmission Control Protocol Zimmermann, "A Roadmap for Transmission Control Protocol
(TCP) Specification Documents", RFC 7414, (TCP) Specification Documents", RFC 7414,
DOI 10.17487/RFC7414, February 2015, DOI 10.17487/RFC7414, February 2015,
<http://www.rfc-editor.org/info/rfc7414>. <http://www.rfc-editor.org/info/rfc7414>.
Appendix A. TCP Requirement Summary Appendix A. TCP Requirement Summary
This section is adapted from RFC 1122. This section is adapted from RFC 1122.
TODO: this needs to be seriously redone, to use 793bis section TODO: this needs to be seriously redone, to use 793bis section
 End of changes. 83 change blocks. 
134 lines changed or deleted 267 lines changed or added

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