draft-ietf-tcpm-rfc793bis-00.txt   draft-ietf-tcpm-rfc793bis-01.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 June 19, 2015 Obsoletes: 793, 879, 6093, 6528, 6691 September 21, 2015
(if approved) (if approved)
Updates: 1122 (if approved) Updates: 1122 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: December 21, 2015 Expires: March 24, 2016
Transmission Control Protocol Specification Transmission Control Protocol Specification
draft-ietf-tcpm-rfc793bis-00 draft-ietf-tcpm-rfc793bis-01
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 4 skipping to change at page 2, line 4
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 December 21, 2015. This Internet-Draft will expire on March 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 40 skipping to change at page 2, line 40
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 . . . . . . . . . . . . . . . . . . 4 3. Functional Specification . . . . . . . . . . . . . . . . . . 4
3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 13 3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 14
3.4. Establishing a connection . . . . . . . . . . . . . . . . 20 3.4. Establishing a connection . . . . . . . . . . . . . . . . 20
3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 27 3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 27
3.6. Precedence and Security . . . . . . . . . . . . . . . . . 29 3.5.1. Half-Closed Connections . . . . . . . . . . . . . . . 30
3.7. Segmentation . . . . . . . . . . . . . . . . . . . . . . 30 3.6. Precedence and Security . . . . . . . . . . . . . . . . . 30
3.7.1. Maximum Segment Size Option . . . . . . . . . . . . . 31 3.7. Segmentation . . . . . . . . . . . . . . . . . . . . . . 31
3.7.1. Maximum Segment Size Option . . . . . . . . . . . . . 32
3.7.2. Path MTU Discovery . . . . . . . . . . . . . . . . . 33 3.7.2. Path MTU Discovery . . . . . . . . . . . . . . . . . 33
3.7.3. Interfaces with Variable MSS Values . . . . . . . . . 33 3.7.3. Interfaces with Variable MTU Values . . . . . . . . . 34
3.7.4. Nagle Algorithm . . . . . . . . . . . . . . . . . . . 34 3.7.4. Nagle Algorithm . . . . . . . . . . . . . . . . . . . 34
3.7.5. IPv6 Jumbograms . . . . . . . . . . . . . . . . . . . 34 3.7.5. IPv6 Jumbograms . . . . . . . . . . . . . . . . . . . 35
3.8. Data Communication . . . . . . . . . . . . . . . . . . . 34 3.8. Data Communication . . . . . . . . . . . . . . . . . . . 35
3.9. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 38 3.9. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 39
3.9.1. User/TCP Interface . . . . . . . . . . . . . . . . . 38 3.9.1. User/TCP Interface . . . . . . . . . . . . . . . . . 39
3.9.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 45 3.9.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 47
3.10. Event Processing . . . . . . . . . . . . . . . . . . . . 46 3.10. Event Processing . . . . . . . . . . . . . . . . . . . . 47
3.11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 69 3.11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 71
4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 74 4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 76
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80
6. Security and Privacy Considerations . . . . . . . . . . . . . 77 6. Security and Privacy Considerations . . . . . . . . . . . . . 80
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 80
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 81
8.1. Normative References . . . . . . . . . . . . . . . . . . 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 81
8.2. Informative References . . . . . . . . . . . . . . . . . 79 8.2. Informative References . . . . . . . . . . . . . . . . . 81
Appendix A. TCP Requirement Summary . . . . . . . . . . . . . . 79 Appendix A. TCP Requirement Summary . . . . . . . . . . . . . . 82
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 86
1. Purpose and Scope 1. Purpose and Scope
In 1981, RFC 793 [6] was released, documenting the Transmission In 1981, RFC 793 [6] 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.
skipping to change at page 6, line 11 skipping to change at page 6, line 14
If the ACK control bit is set this field contains the value of the If the ACK control bit is set this field contains the value of the
next sequence number the sender of the segment is expecting to next sequence number the sender of the segment is expecting to
receive. Once a connection is established this is always sent. receive. Once a connection is established this is always sent.
Data Offset: 4 bits Data Offset: 4 bits
The number of 32 bit words in the TCP Header. This indicates where The number of 32 bit words in the TCP Header. This indicates where
the data begins. The TCP header (even one including options) is an the data begins. The TCP header (even one including options) is an
integral number of 32 bits long. integral number of 32 bits long.
Reserved: 6 bits Reserved: 4 bits
Reserved for future use. Must be zero. Reserved for future use. Must be zero.
Control Bits: 6 bits (from left to right): Control Bits: 8 bits (from left to right):
CWR: Congestion Window Reduced
ECE: ECN-Echo
URG: Urgent Pointer field significant URG: Urgent Pointer field significant
ACK: Acknowledgment field significant ACK: Acknowledgment field significant
PSH: Push Function PSH: Push Function
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.
The window size MUST be treated as an unsigned number, or else
large window sizes will appear like negative windows and TCP will
now work. It is RECOMMENDED that implementations will reserve
32-bit fields for the send and receive window sizes in the
connection record and do all window computations with 32 bits.
Checksum: 16 bits Checksum: 16 bits
The checksum field is the 16 bit one's complement of the one's The checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words in the header and text. If a complement sum of all 16 bit words in the header and text. If a
segment contains an odd number of header and text octets to be segment contains an odd number of header and text octets to be
checksummed, the last octet is padded on the right with zeros to checksummed, the last octet is padded on the right with zeros to
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.
skipping to change at page 7, line 18 skipping to change at page 7, line 26
| 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
octets (this is not an explicitly transmitted quantity, but is octets (this is not an explicitly transmitted quantity, but is
computed), and it does not count the 12 octets of the pseudo computed), and it does not count the 12 octets of the pseudo
header. header.
The TCP checksum is never optional. The sender MUST generate it
and the receiver MUST check it.
Urgent Pointer: 16 bits Urgent Pointer: 16 bits
This field communicates the current value of the urgent pointer as This field communicates the current value of the urgent pointer as
a positive offset from the sequence number in this segment. The a positive offset from the sequence number in this segment. The
urgent pointer points to the sequence number of the octet following urgent pointer points to the sequence number of the octet following
the urgent data. This field is only be interpreted in segments the urgent data. This field is only be interpreted in segments
with the URG control bit set. with the URG control bit set.
Options: variable Options: variable
skipping to change at page 8, line 5 skipping to change at page 8, line 17
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.
A TCP MUST be able to receive a TCP option in any segment. A TCP A TCP MUST be able to receive a TCP option in any segment.
MUST ignore without error any TCP option it does not implement, A TCP MUST ignore without error any TCP option it does not
assuming that the option has a length field (all TCP options except implement, assuming that the option has a length field (all TCP
End of option list and No-Operation have length fields). TCP MUST options except End of option list and No-Operation have length
be prepared to handle an illegal option length (e.g., zero) without fields). TCP MUST be prepared to handle an illegal option length
crashing; a suggested procedure is to reset the connection and log (e.g., zero) without crashing; a suggested procedure is to reset
the reason. the connection and log the reason.
Specific Option Definitions Specific Option Definitions
End of Option List End of Option List
+--------+ +--------+
|00000000| |00000000|
+--------+ +--------+
Kind=0 Kind=0
skipping to change at page 9, line 7 skipping to change at page 9, line 19
+--------+--------+---------+--------+ +--------+--------+---------+--------+
Kind=2 Length=4 Kind=2 Length=4
Maximum Segment Size Option Data: 16 bits Maximum Segment Size Option Data: 16 bits
If this option is present, then it communicates the maximum If this option is present, then it communicates the maximum
receive segment size at the TCP which sends this segment. This receive segment size at the TCP which sends this segment. This
field may be sent in the initial connection request (i.e., in field may be sent in the initial connection request (i.e., in
segments with the SYN control bit set) and must not be sent in segments with the SYN control bit set) and must not be sent in
other segments. If this option is not used, any segment size is other segments. If this option is not used, any segment size is
allowed. allowed. A more complete description of this option is in
Section 3.7.1.
Padding: variable Padding: variable
The TCP header padding is used to ensure that the TCP header ends The TCP header padding is used to ensure that the TCP header ends
and data begins on a 32 bit boundary. The padding is composed of and data begins on a 32 bit boundary. The padding is composed of
zeros. zeros.
3.2. Terminology 3.2. Terminology
Before we can discuss very much about the operation of the TCP we Before we can discuss very much about the operation of the TCP we
skipping to change at page 16, line 35 skipping to change at page 17, line 17
created, an initial sequence number (ISN) generator is employed which created, an initial sequence number (ISN) generator is employed which
selects a new 32 bit ISN. There are security issues that result if selects a new 32 bit ISN. There are security issues that result if
an off-path attacker is able to predict or guess ISN values. an off-path attacker is able to predict or guess ISN values.
The recommended ISN generator is based on the combination of a The recommended ISN generator is based on the combination of a
(possibly fictitious) 32 bit clock whose low order bit is incremented (possibly fictitious) 32 bit clock whose low order bit is incremented
roughly every 4 microseconds, and a pseudorandom hash function (PRF). roughly every 4 microseconds, and a pseudorandom hash function (PRF).
The clock component is intended to insure that with a Maximum Segment The clock component is intended to insure that with a Maximum Segment
Lifetime (MSL), generated ISNs will be unique, since it cycles Lifetime (MSL), generated ISNs will be unique, since it cycles
approximately every 4.55 hours, which is much longer than the MSL. approximately every 4.55 hours, which is much longer than the MSL.
This recommended algorithm is further described in RFC 1948 and
builds on the basic clock-driven algorithm from RFC 793.
TCP SHOULD generate its Initial Sequence Numbers with the expression: A TCP MUST use a clock-driven selection of initial sequence numbers,
and SHOULD generate its Initial Sequence Numbers with the expression:
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
skipping to change at page 22, line 25 skipping to change at page 22, line 35
5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ... 5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED 6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
7. ... <SEQ=100><ACK=301><CTL=SYN,ACK> --> ESTABLISHED 7. ... <SEQ=100><ACK=301><CTL=SYN,ACK> --> ESTABLISHED
Simultaneous Connection Synchronization Simultaneous Connection Synchronization
Figure 6 Figure 6
A TCP MUST support simultaneous open attempts.
Note that a TCP implementation MUST keep track of whether a
connection has reached SYN_RCVD state as the result of a passive OPEN
or an active OPEN.
The principle reason for the three-way handshake is to prevent old The principle reason for the three-way handshake is to prevent old
duplicate connection initiations from causing confusion. To deal duplicate connection initiations from causing confusion. To deal
with this, a special control message, reset, has been devised. If with this, a special control message, reset, has been devised. If
the receiving TCP is in a non-synchronized state (i.e., SYN-SENT, the receiving TCP is in a non-synchronized state (i.e., SYN-SENT,
SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset. SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset.
If the TCP is in one of the synchronized states (ESTABLISHED, FIN- If the TCP is in one of the synchronized states (ESTABLISHED, FIN-
WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it
aborts the connection and informs its user. We discuss this latter aborts the connection and informs its user. We discuss this latter
case under "half-open" connections below. case under "half-open" connections below.
skipping to change at page 27, line 30 skipping to change at page 27, line 30
acknowledges the SYN. acknowledges the SYN.
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.
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 29, line 47 skipping to change at page 29, line 47
... <SEQ=101><ACK=301><CTL=ACK> --> ... <SEQ=101><ACK=301><CTL=ACK> -->
4. TIME-WAIT TIME-WAIT 4. TIME-WAIT TIME-WAIT
(2 MSL) (2 MSL) (2 MSL) (2 MSL)
CLOSED CLOSED CLOSED CLOSED
Simultaneous Close Sequence Simultaneous Close Sequence
Figure 12 Figure 12
A TCP connection may terminate in two ways: (1) the normal TCP close
sequence using a FIN handshake, and (2) an "abort" in which one or
more RST segments are sent and the connection state is immediately
discarded. If a TCP connection is closed by the remote site, the
local application MUST be informed whether it closed normally or was
aborted.
3.5.1. Half-Closed Connections
The normal TCP close sequence delivers buffered data reliably in both
directions. Since the two directions of a TCP connection are closed
independently, it is possible for a connection to be "half closed,"
i.e., closed in only one direction, and a host is permitted to
continue sending data in the open direction on a half-closed
connection.
A host MAY implement a "half-duplex" TCP close sequence, so that an
application that has called CLOSE cannot continue to read data from
the connection. If such a host issues a CLOSE call while received
data is still pending in TCP, or if new data is received after CLOSE
is called, its TCP SHOULD send a RST to show that data was lost.
When a connection is closed actively, it MUST linger in TIME-WAIT
state for a time 2xMSL (Maximum Segment Lifetime). However, it MAY
accept a new SYN from the remote TCP to reopen the connection
directly from TIME-WAIT state, if it:
(1) assigns its initial sequence number for the new connection to
be larger than the largest sequence number it used on the previous
connection incarnation, and
(2) returns to TIME-WAIT state if the SYN turns out to be an old
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) [2]. 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,
skipping to change at page 31, line 44 skipping to change at page 32, line 34
3.7.1. Maximum Segment Size Option 3.7.1. Maximum Segment Size Option
TCP MUST implement both sending and receiving the MSS option. TCP MUST implement both sending and receiving the MSS option.
TCP SHOULD send an MSS option in every SYN segment when its receive TCP SHOULD send an MSS option in every SYN segment when its receive
MSS differs from the default 536 for IPv4 or 1220 for IPv6, and MAY MSS differs from the default 536 for IPv4 or 1220 for IPv6, and MAY
send it always. send it always.
If an MSS option is not received at connection setup, TCP MUST assume If an MSS option is not received at connection setup, TCP MUST assume
a default send MSS of 536 (576-40) for IPv4 or 1220 (1280 - 40) for a default send MSS of 536 (576-40) for IPv4 or 1220 (1280 - 60) for
IPv6. IPv6.
The maximum size of a segment that TCP really sends, the "effective The maximum size of a segment that TCP really sends, the "effective
send MSS," MUST be the smaller of the send MSS (which reflects the send MSS," MUST be the smaller of the send MSS (which reflects the
available reassembly buffer size at the remote host) and the largest available reassembly buffer size at the remote host) and the largest
size permitted by the IP layer: size permitted by the IP layer:
Eff.snd.MSS = Eff.snd.MSS =
min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize
where: where:
o SendMSS is the MSS value received from the remote host, or the o SendMSS is the MSS value received from the remote host, or the
default 536 for IPv4 or 1220 for IPv6, if no MSS option is default 536 for IPv4 or 1220 for IPv6, if no MSS option is
received. received.
o MMS_S is the maximum size for a transport-layer message that TCP o MMS_S is the maximum size for a transport-layer message that TCP
may send. may send.
skipping to change at page 33, line 34 skipping to change at page 34, line 24
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 MSS 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) [12]. 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.
skipping to change at page 39, line 39 skipping to change at page 40, line 26
(a) general information about a connection (e.g., interrupts, (a) general information about a connection (e.g., interrupts,
remote close, binding of unspecified foreign socket). remote close, binding of unspecified foreign socket).
(b) replies to specific user commands indicating success or (b) replies to specific user commands indicating success or
various types of failure. various types of failure.
Open Open
Format: OPEN (local port, foreign socket, active/passive [, Format: OPEN (local port, foreign socket, active/passive [,
timeout] [, precedence] [, security/compartment] [, options]) timeout] [, precedence] [, security/compartment] [local IP
-> local connection name address,] [, options]) -> local connection name
We assume that the local TCP is aware of the identity of the We assume that the local TCP is aware of the identity of the
processes it serves and will check the authority of the process processes it serves and will check the authority of the process
to use the connection specified. Depending upon the to use the connection specified. Depending upon the
implementation of the TCP, the local network and TCP implementation of the TCP, the local network and TCP
identifiers for the source address will either be supplied by identifiers for the source address will either be supplied by
the TCP or the lower level protocol (e.g., IP). These the TCP or the lower level protocol (e.g., IP). These
considerations are the result of concern about security, to the considerations are the result of concern about security, to the
extent that no TCP be able to masquerade as another one, and so extent that no TCP be able to masquerade as another one, and so
on. Similarly, no process can masquerade as another without on. Similarly, no process can masquerade as another without
skipping to change at page 40, line 49 skipping to change at page 41, line 36
this precedence negotiation. For example, the user might be this precedence negotiation. For example, the user might be
allowed to specify that the precedence must be exactly matched, allowed to specify that the precedence must be exactly matched,
or that any attempt to raise the precedence be confirmed by the or that any attempt to raise the precedence be confirmed by the
user. user.
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
allow the specification of the local IP address. This enables
applications that need to select the local IP address used when
multihoming is present.
A passive OPEN call with a specified "local IP address"
parameter will await an incoming connection request to that
address. If the parameter is unspecified, a passive OPEN will
await an incoming connection request to any local IP address,
and then bind the local IP address of the connection to the
particular address that is used.
For an active OPEN call, a specified "local IP address"
parameter will be used for opening the connection. If the
parameter is unspecified, the TCP will choose an appropriate
local IP address (see RFC 1122 section 3.3.4.2).
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, 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. 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
skipping to change at page 45, line 4 skipping to change at page 46, line 8
Depending on the state of the connection, or on the Depending on the state of the connection, or on the
implementation itself, some of this information may not be implementation itself, some of this information may not be
available or meaningful. If the calling process is not available or meaningful. If the calling process is not
authorized to use this connection, an error is returned. This authorized to use this connection, an error is returned. This
prevents unauthorized processes from gaining information about prevents unauthorized processes from gaining information about
a connection. a connection.
Abort Abort
Format: ABORT (local connection name) Format: ABORT (local connection name)
This command causes all pending SENDs and RECEIVES to be This command causes all pending SENDs and RECEIVES to be
aborted, the TCB to be removed, and a special RESET message to aborted, the TCB to be removed, and a special RESET message to
be sent to the TCP on the other side of the connection. be sent to the TCP on the other side of the connection.
Depending on the implementation, users may receive abort Depending on the implementation, users may receive abort
indications for each outstanding SEND or RECEIVE, or may simply indications for each outstanding SEND or RECEIVE, or may simply
receive an ABORT-acknowledgment. receive an ABORT-acknowledgment.
Flush
Some TCP implementations have included a FLUSH call, which will
empty the TCP send queue of any data for which the user has
issued SEND calls but which is still to the right of the
current send window. That is, it flushes as much queued send
data as possible without losing sequence number
synchronization.
Set TOS
The application layer MUST be able to specify the Type-of-
Service (TOS) for segments that are sent on a connection. It
not required, but the application SHOULD be able to change the
TOS during the connection lifetime. TCP SHOULD pass the
current TOS value without change to the IP layer, when it sends
segments on the connection.
The TOS will be specified independently in each direction on
the connection, so that the receiver application will specify
the TOS used for ACK segments.
TCP MAY pass the most recently received TOS up to the
application.
TCP-to-User Messages TCP-to-User Messages
It is assumed that the operating system environment provides a It is assumed that the operating system environment provides a
means for the TCP to asynchronously signal the user program. means for the TCP to asynchronously signal the user program.
When the TCP does signal a user program, certain information is When the TCP does signal a user program, certain information is
passed to the user. Often in the specification the information passed to the user. Often in the specification the information
will be an error message. In other cases there will be will be an error message. In other cases there will be
information relating to the completion of processing a SEND or information relating to the completion of processing a SEND or
RECEIVE or other user call. RECEIVE or other user call.
skipping to change at page 77, line 14 skipping to change at page 79, line 14
The -05 revision of draft-eddy-rfc793bis incorporates MSS The -05 revision of draft-eddy-rfc793bis incorporates MSS
requirements and definitions from RFC 879, 1122, and 6691, as well as requirements and definitions from RFC 879, 1122, and 6691, as well as
option-handling requirements from RFC 1122. option-handling requirements from RFC 1122.
The -00 revision of draft-ietf-tcpm-rfc793bis incorporates several The -00 revision of draft-ietf-tcpm-rfc793bis incorporates several
additional clarifications and updates to the section on segmentation, additional clarifications and updates to the section on segmentation,
many of which are based on feedback from Joe Touch improving from the many of which are based on feedback from Joe Touch improving from the
initial text on this in the previous revision. initial text on this in the previous revision.
The -01 revision incorporates the change to Reserved bits due to ECN,
as well as many other changes that come from RFC 1122.
TODO: Incomplete list of other planned changes - these can be added TODO: Incomplete list of other planned changes - these can be added
to and made more specific, as the document proceeds: to and made more specific, as the document proceeds:
1. incorporate all other 1122 additions 1. incorporate all other 1122 additions (sections on Data
Communication, Retransmission Timeout, Managing the Window,
Probing Zero Windows, Passive OPEN Calls, Time to Live, Event
Processing, Acknowledging Queued Segments, Retransmission
Timeout Calculation, When to Send an ACK Segment, When to Send a
Window Update, When to Send Data, TCP Connection Failures, TCP
Keep-Alives, TCP Multihoming, IP options, ICMP messages, remote
address validation)
2. point to major additional docs like 1323bis and 5681 2. point to major additional docs like 1323bis and 5681
3. incorporate relevant parts of 3168 (ECN) 3. incorporate relevant parts of 3168 (ECN) - beyond just
indicating the names of the 2 bits already done
4. incorporate Fernando's new number-checking fixes (if past the 4. incorporate Fernando's new number-checking fixes (if past the
IESG in time) IESG in time)
5. point to 5461 (soft errors) 5. point to 5461 (soft errors)
6. mention 5961 state machine option 6. mention 5961 state machine option
7. mention 6161 (reducing TIME-WAIT) 7. mention 6161 (reducing TIME-WAIT)
8. incorporate 6429 (ZWP/persist) 8. incorporate 6429 (ZWP/persist)
9. look at Tony Sabatini suggestion for describing DO field 9. look at Tony Sabatini suggestion for describing DO field
10. clearly specify treatment of reserved bits (see TCPM thread on 10. clearly specify treatment of reserved bits (see TCPM thread on
EDO draft April 25, 2014) EDO draft April 25, 2014)
11. look at possible mention of draft-minshall-nagle (e.g. as in 11. look at possible mention of draft-minshall-nagle (e.g. as in
Linux) Linux)
12. make sure that clarifications in RFC 1011 are captured 12. make sure that clarifications in RFC 1011 are captured
13. per TCPM discussion, discussion of checking reserved bits may 13. per TCPM discussion, discussion of checking reserved bits may
need to be altered from 793 need to be altered from 793
14. per discussion with Joe Touch (TAPS list, 6/20/2015), the
description of the API could be revisited
15. there is inconsistency between use of SYN_RCVD and SYNC-RECEIVED
in diagrams and text in various places
16. TOS material does not take DSCP changes into account
17. discuss with working group whether to include anything like
section 4.2.3.12 of 1122 (on "efficiency" ... basically
implementation advice), maybe similar to 2525 in handling for
this document. also 4.2.3.11 on "TCP Traffic Patterns"
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
skipping to change at page 78, line 38 skipping to change at page 81, line 10
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] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>.
[2] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [2] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>.
[3] Bradner, S., "Key words for use in RFCs to Indicate [3] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[4] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", [4] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999. RFC 2675, DOI 10.17487/RFC2675, August 1999,
<http://www.rfc-editor.org/info/rfc2675>.
[5] Lahey, K., "TCP Problems with Path MTU Discovery", RFC [5] Lahey, K., "TCP Problems with Path MTU Discovery",
2923, September 2000. RFC 2923, DOI 10.17487/RFC2923, September 2000,
<http://www.rfc-editor.org/info/rfc2923>.
8.2. Informative References 8.2. Informative References
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC [6] Postel, J., "Transmission Control Protocol", STD 7,
793, September 1981. RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[7] Nagle, J., "Congestion control in IP/TCP internetworks", [7] Nagle, J., "Congestion Control in IP/TCP Internetworks",
RFC 896, January 1984. RFC 896, DOI 10.17487/RFC0896, January 1984,
<http://www.rfc-editor.org/info/rfc896>.
[8] Braden, R., "Requirements for Internet Hosts - [8] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[9] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [9] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>.
[10] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. [10] 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, October 2007. Specification", RFC 5044, DOI 10.17487/RFC5044, October
2007, <http://www.rfc-editor.org/info/rfc5044>.
[11] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [11] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<http://www.rfc-editor.org/info/rfc5681>.
[12] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust [12] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795, March Header Compression (ROHC) Framework", RFC 5795,
2010. DOI 10.17487/RFC5795, March 2010,
<http://www.rfc-editor.org/info/rfc5795>.
[13] Gont, F. and A. Yourtchenko, "On the Implementation of the [13] Gont, F. and A. Yourtchenko, "On the Implementation of the
TCP Urgent Mechanism", RFC 6093, January 2011. TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093,
January 2011, <http://www.rfc-editor.org/info/rfc6093>.
[14] Gont, F. and S. Bellovin, "Defending against Sequence [14] Gont, F. and S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, February 2012. Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
2012, <http://www.rfc-editor.org/info/rfc6528>.
[15] Borman, D., "TCP Options and Maximum Segment Size (MSS)", [15] Borman, D., "TCP Options and Maximum Segment Size (MSS)",
RFC 6691, July 2012. RFC 6691, DOI 10.17487/RFC6691, July 2012,
<http://www.rfc-editor.org/info/rfc6691>.
[16] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. [16] 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, February 2015. (TCP) Specification Documents", RFC 7414,
DOI 10.17487/RFC7414, February 2015,
<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
numbers instead of 1122 ones, the RFC1122 heading should be removed, numbers instead of 1122 ones, the RFC1122 heading should be removed,
and all 1122 requirements need to be reflected in 793bis text. and all 1122 requirements need to be reflected in 793bis text.
TODO: NOTE that PMTUD+PLPMTUD is not included in this table of TODO: NOTE that PMTUD+PLPMTUD is not included in this table of
 End of changes. 48 change blocks. 
63 lines changed or deleted 205 lines changed or added

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