draft-ietf-tcpm-rfc793bis-05.txt   draft-ietf-tcpm-rfc793bis-06.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, 6429, 6528, March 28, 2017 Obsoletes: 793, 879, 6093, 6429, 6528, July 17, 2017
6691 (if approved) 6691 (if approved)
Updates: 1122 (if approved) Updates: 5961, 1122 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 29, 2017 Expires: January 18, 2018
Transmission Control Protocol Specification Transmission Control Protocol Specification
draft-ietf-tcpm-rfc793bis-05 draft-ietf-tcpm-rfc793bis-06
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, as well as 879, 6093, 6429, 6528,
all actual RFCs when finished). and 6691. It updates RFC 1122, and should be considered as a
replacement for the portions of that document dealing with TCP
requirements. It updates RFC 5961 due to a small clarification in
reset handling while in the SYN-RECEIVED state. (TODO: double-check
this list for 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 [4]. document are to be interpreted as described in RFC 2119 [4].
skipping to change at page 2, line 4 skipping to change at page 2, line 9
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 September 29, 2017.
This Internet-Draft will expire on January 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 48 skipping to change at page 3, line 5
3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 15 3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 15
3.4. Establishing a connection . . . . . . . . . . . . . . . . 21 3.4. Establishing a connection . . . . . . . . . . . . . . . . 21
3.4.1. Remote Address Validation . . . . . . . . . . . . . . 28 3.4.1. Remote Address Validation . . . . . . . . . . . . . . 28
3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 28 3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 28
3.5.1. Half-Closed Connections . . . . . . . . . . . . . . . 31 3.5.1. Half-Closed Connections . . . . . . . . . . . . . . . 31
3.6. Precedence and Security . . . . . . . . . . . . . . . . . 31 3.6. Precedence and Security . . . . . . . . . . . . . . . . . 31
3.7. Segmentation . . . . . . . . . . . . . . . . . . . . . . 32 3.7. Segmentation . . . . . . . . . . . . . . . . . . . . . . 32
3.7.1. Maximum Segment Size Option . . . . . . . . . . . . . 33 3.7.1. Maximum Segment Size Option . . . . . . . . . . . . . 33
3.7.2. Path MTU Discovery . . . . . . . . . . . . . . . . . 34 3.7.2. Path MTU Discovery . . . . . . . . . . . . . . . . . 35
3.7.3. Interfaces with Variable MTU Values . . . . . . . . . 35 3.7.3. Interfaces with Variable MTU Values . . . . . . . . . 35
3.7.4. Nagle Algorithm . . . . . . . . . . . . . . . . . . . 35 3.7.4. Nagle Algorithm . . . . . . . . . . . . . . . . . . . 36
3.7.5. IPv6 Jumbograms . . . . . . . . . . . . . . . . . . . 36 3.7.5. IPv6 Jumbograms . . . . . . . . . . . . . . . . . . . 36
3.8. Data Communication . . . . . . . . . . . . . . . . . . . 36 3.8. Data Communication . . . . . . . . . . . . . . . . . . . 36
3.8.1. Retransmission Timeout . . . . . . . . . . . . . . . 37 3.8.1. Retransmission Timeout . . . . . . . . . . . . . . . 37
3.8.2. TCP Congestion Control . . . . . . . . . . . . . . . 37 3.8.2. TCP Congestion Control . . . . . . . . . . . . . . . 37
3.8.3. TCP Connection Failures . . . . . . . . . . . . . . . 37 3.8.3. TCP Connection Failures . . . . . . . . . . . . . . . 38
3.8.4. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . 38 3.8.4. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . 39
3.8.5. The Communication of Urgent Information . . . . . . . 39 3.8.5. The Communication of Urgent Information . . . . . . . 39
3.8.6. Managing the Window . . . . . . . . . . . . . . . . . 40 3.8.6. Managing the Window . . . . . . . . . . . . . . . . . 40
3.9. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 44 3.9. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 44
3.9.1. User/TCP Interface . . . . . . . . . . . . . . . . . 44 3.9.1. User/TCP Interface . . . . . . . . . . . . . . . . . 45
3.9.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 52 3.9.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 53
3.10. Event Processing . . . . . . . . . . . . . . . . . . . . 54 3.10. Event Processing . . . . . . . . . . . . . . . . . . . . 55
3.11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 79 3.11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 80
4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 84 4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 86
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 90
6. Security and Privacy Considerations . . . . . . . . . . . . . 89 6. Security and Privacy Considerations . . . . . . . . . . . . . 90
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.1. Normative References . . . . . . . . . . . . . . . . . . 89 8.1. Normative References . . . . . . . . . . . . . . . . . . 91
8.2. Informative References . . . . . . . . . . . . . . . . . 90 8.2. Informative References . . . . . . . . . . . . . . . . . 92
Appendix A. TCP Requirement Summary . . . . . . . . . . . . . . 92 Appendix A. Other Implementation Notes . . . . . . . . . . . . . 93
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 95 Appendix B. TCP Requirement Summary . . . . . . . . . . . . . . 94
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 97
1. Purpose and Scope 1. Purpose and Scope
In 1981, RFC 793 [10] was released, documenting the Transmission In 1981, RFC 793 [12] was released, documenting the Transmission
Control Protocol (TCP), and replacing earlier specifications for TCP Control Protocol (TCP), and replacing earlier specifications for TCP
that had been published in the past. that had been published in the past.
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 [23]. Over time, a combined to serve as the specification for TCP [27]. 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 37 skipping to change at page 4, line 43
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" [23] provides a more extensive guide to the RFCs The "TCP Roadmap" [27] 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. [16]) is a TCP requirement, but is a complex congestion control (e.g. [18]) 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 [22], but these are not include the high-performance extensions in [26], 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.
TEMPORARY EDITOR'S NOTE: the current revision of this document does TEMPORARY EDITOR'S NOTE: the current revision of this document does
not yet collect all of the changes that will be in the final version. 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 (IP) header carries several information fields, including the source
destination host addresses [1]. A TCP header follows the internet and destination host addresses [1] [5]. A TCP header follows the
header, supplying information specific to the TCP protocol. This internet header, supplying information specific to the TCP protocol.
division allows for the existence of host level protocols other than This division allows for the existence of host level protocols other
TCP. (Editorial TODO - this last sentence makes sense in 793 than TCP. (Editorial TODO - this last sentence makes sense in 793
context, but may be a candidate to remove here? ... additionally, context, but may be a candidate to remove here? ... additionally,
Section 2 of 793 is not includeed here, but some parts may be useful, Section 2 of 793 is not includeed here, but some parts may be useful,
to quickly define basic concepts of ports, bytestream service, etc. to quickly define basic concepts of ports, bytestream service, etc.
at high-level before delving into protocol details?) 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 |
skipping to change at page 7, line 10 skipping to change at page 7, line 10
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.
Rsrvd - Reserved: 4 bits Rsrvd - Reserved: 4 bits
Reserved for future use. Must be zero. Reserved for future use. Must be zero in generated segments and
must be ignored in received segments. TODO -- no RFC reference for
this sentence ... do we want this change or should we keep the
prior 793 description which is only "Must be zero." ... need to
discuss on TCPM list
Control Bits: 8 bits (from left to right): Control Bits: 8 bits (from left to right):
CWR: Congestion Window Reduced (see [7]) CWR: Congestion Window Reduced (see [9])
ECE: ECN-Echo (see [7]) ECE: ECN-Echo (see [9])
URG: Urgent Pointer field significant URG: Urgent Pointer field significant
ACK: Acknowledgment field significant ACK: Acknowledgment field significant
PSH: Push Function PSH: Push Function
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
skipping to change at page 7, line 45 skipping to change at page 7, line 49
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.
The checksum also covers a 96 bit pseudo header conceptually The checksum also covers a pseudo header conceptually prefixed to
prefixed to the TCP header. This pseudo header contains the Source the TCP header. The pseudo header is 96 bits for IPv4 and 320 bits
for IPv6. For IPv4, 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 IPv4 and is transferred across the TCP/
across the TCP/Network interface in the arguments or results of Network interface in the arguments or results of calls by the TCP
calls by the TCP on the IP. (TODO: this is IPv4-specific, need to on the IP.
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
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.
For IPv6, the pseudo header is contained in section 8.1 of RFC 2460
[5], and contains the IPv6 Source Address and Destination Address,
an Upper Layer Packet Length (a 32-bit value otherwise equivalent
to TCP Length in the IPv4 pseudo header), three bytes of zero-
padding, and a Next Header value (differing from the IPv6 header
value in the case of extension headers present in between IPv6 and
TCP).
The TCP checksum is never optional. The sender MUST generate it The TCP checksum is never optional. The sender MUST generate it
and the receiver MUST check 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.
skipping to change at page 9, line 5 skipping to change at page 9, line 15
Case 2: An octet of option-kind, an octet of option-length, and Case 2: An octet of option-kind, an octet of option-length, and
the actual option-data octets. the actual option-data octets.
The option-length counts the two octets of option-kind and option- The option-length counts the two octets of option-kind and option-
length as well as the option-data octets. length as well as the option-data octets.
Note that the list of options may be shorter than the data offset Note that the list of options may be shorter than the data offset
field might imply. The content of the header beyond the End-of- field might imply. The content of the header beyond the End-of-
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): The list of all currently defined options is managed by IANA [29],
and each option is defined in other RFCs, as indicated there. That
set includes experimental options that can be extended to support
multiple concurrent uses [25].
A given TCP implementation can support any currently defined
options, but the following options MUST be supported (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 10, line 16 skipping to change at page 10, line 31
+--------+--------+---------+--------+ +--------+--------+---------+--------+
|00000010|00000100| max seg size | |00000010|00000100| max seg size |
+--------+--------+---------+--------+ +--------+--------+---------+--------+
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 value is limited by the IP reassembly limit. This field may be
segments with the SYN control bit set) and must not be sent in sent in the initial connection request (i.e., in segments with
other segments. If this option is not used, any segment size is the SYN control bit set) and must not be sent in other segments.
allowed. A more complete description of this option is in If this option is not used, any segment size is allowed. A more
Section 3.7.1. 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 13, line 43 skipping to change at page 13, line 43
A TCP connection progresses from one state to another in response to A TCP connection progresses from one state to another in response to
events. The events are the user calls, OPEN, SEND, RECEIVE, CLOSE, events. The events are the user calls, OPEN, SEND, RECEIVE, CLOSE,
ABORT, and STATUS; the incoming segments, particularly those ABORT, and STATUS; the incoming segments, particularly those
containing the SYN, ACK, RST and FIN flags; and timeouts. containing the SYN, ACK, RST and FIN flags; and timeouts.
The state diagram in Figure 4 illustrates only state changes, The state diagram in Figure 4 illustrates only state changes,
together with the causing events and resulting actions, but addresses together with the causing events and resulting actions, but addresses
neither error conditions nor actions which are not connected with neither error conditions nor actions which are not connected with
state changes. In a later section, more detail is offered with state changes. In a later section, more detail is offered with
respect to the reaction of the TCP to events. respect to the reaction of the TCP to events. Some state names are
abbreviated or hyphenated differently in the diagram from how they
appear elsewhere in the document.
NOTA BENE: this diagram is only a summary and must not be taken as NOTA BENE: This diagram is only a summary and must not be taken as
the total specification. the total specification. Many details are not included.
+---------+ ---------\ active OPEN +---------+ ---------\ active OPEN
| CLOSED | \ ----------- | CLOSED | \ -----------
+---------+<---------\ \ create TCB +---------+<---------\ \ create TCB
| ^ \ \ snd SYN | ^ \ \ snd SYN
passive OPEN | | CLOSE \ \ passive OPEN | | CLOSE \ \
------------ | | ---------- \ \ ------------ | | ---------- \ \
create TCB | | delete TCB \ \ create TCB | | delete TCB \ \
V | \ \ V | \ \
rcv RST (note 1) +---------+ CLOSE | \ rcv RST (note 1) +---------+ CLOSE | \
-------------------->| LISTEN | ---------- | | -------------------->| LISTEN | ---------- | |
/ +---------+ delete TCB | | / +---------+ delete TCB | |
/ rcv SYN | | SEND | | / rcv SYN | | SEND | |
/ ----------- | | ------- | V / ----------- | | ------- | V
+--------+ snd SYN,ACK / \ snd SYN +--------+ +--------+ snd SYN,ACK / \ snd SYN +--------+
| |<----------------- ------------------>| | | |<----------------- ------------------>| |
| SYN | rcv SYN | SYN | | SYN | rcv SYN | SYN |
| RCVD |<-----------------------------------------------| SENT | | RCVD |<-----------------------------------------------| SENT |
| | snd SYN,ACK | | | | snd SYN,ACK | |
| |------------------ -------------------| | | |------------------ -------------------| |
+--------+ rcv ACK of SYN \ / rcv SYN,ACK +--------+ +--------+ rcv ACK of SYN \ / rcv SYN,ACK +--------+
| -------------- | | ----------- | -------------- | | -----------
| x | | snd ACK | x | | snd ACK
| V V | V V
| CLOSE +---------+ | CLOSE +---------+
| ------- | ESTAB | | ------- | ESTAB |
| snd FIN +---------+ | snd FIN +---------+
| CLOSE | | rcv FIN | CLOSE | | rcv FIN
V ------- | | ------- V ------- | | -------
+---------+ snd FIN / \ snd ACK +---------+ +---------+ snd FIN / \ snd ACK +---------+
| FIN |<----------------- ------------------>| CLOSE | | FIN |<----------------- ------------------>| CLOSE |
| WAIT-1 |------------------ | WAIT | | WAIT-1 |------------------ | WAIT |
+---------+ rcv FIN \ +---------+ +---------+ rcv FIN \ +---------+
| rcv ACK of FIN ------- | CLOSE | | rcv ACK of FIN ------- | CLOSE |
| -------------- snd ACK | ------- | | -------------- snd ACK | ------- |
V x V snd FIN V V x V snd FIN V
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
|FINWAIT-2| | CLOSING | | LAST-ACK| |FINWAIT-2| | CLOSING | | LAST-ACK|
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| rcv ACK of FIN | rcv ACK of FIN | | rcv ACK of FIN | rcv ACK of FIN |
| rcv FIN -------------- | Timeout=2MSL -------------- | | rcv FIN -------------- | Timeout=2MSL -------------- |
| ------- x V ------------ x V | ------- x V ------------ x V
\ snd ACK +---------+delete TCB +---------+ \ snd ACK +---------+delete TCB +---------+
------------------------>|TIME WAIT|------------------>| CLOSED | ------------------------>|TIME WAIT|------------------>| CLOSED |
+---------+ +---------+ +---------+ +---------+
note 1: The transition from SYN-RCVD to LISTEN on receiving a RST is note 1: The transition from SYN-RECEIVED to LISTEN on receiving a RST is
conditional on having reached SYN-RCVD after a passive open. conditional on having reached SYN-RECEIVED after a passive open.
note 2: An unshown transition exists from FIN-WAIT-1 to TIME-WAIT if note 2: An unshown transition exists from FIN-WAIT-1 to TIME-WAIT if
a FIN is received and the local FIN is also acknowledged. a FIN is received and the local FIN is also acknowledged.
TCP Connection State Diagram
TCP Connection State Diagram
Figure 4 Figure 4
3.3. Sequence Numbers 3.3. Sequence Numbers
A fundamental notion in the design is that every octet of data sent A fundamental notion in the design is that every octet of data sent
over a TCP connection has a sequence number. Since every octet is over a TCP connection has a sequence number. Since every octet is
sequenced, each of them can be acknowledged. The acknowledgment sequenced, each of them can be acknowledged. The acknowledgment
mechanism employed is cumulative so that an acknowledgment of mechanism employed is cumulative so that an acknowledgment of
sequence number X indicates that all octets up to but not including X sequence number X indicates that all octets up to but not including X
have been received. This mechanism allows for straight-forward have been received. This mechanism allows for straight-forward
skipping to change at page 18, line 33 skipping to change at page 18, line 38
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 [20]. and management of the secret key data, please see Section 3 of [23].
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 23, line 38 skipping to change at page 23, line 41
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. A TCP MUST support simultaneous open attempts.
Note that a TCP implementation MUST keep track of whether a Note that a TCP implementation MUST keep track of whether a
connection has reached SYN_RCVD state as the result of a passive OPEN connection has reached SYN-RECEIVED state as the result of a passive
or an active OPEN. 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 28, line 41 skipping to change at page 28, line 41
3.4.1. Remote Address Validation 3.4.1. Remote Address Validation
TODO - figure out if this section would fit better elsewhere, for TODO - figure out if this section would fit better elsewhere, for
instance in the more detailed description of the OPEN call later on 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 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). invalid remote IP address (e.g., a broadcast or multicast address).
An incoming SYN with an invalid source address must be ignored either 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 [12]). by TCP or by the IP layer (see Section 3.2.1.3 of [14]).
A TCP implementation MUST silently discard an incoming SYN segment A TCP implementation MUST silently discard an incoming SYN segment
that is addressed to a broadcast or multicast address. 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
skipping to change at page 31, line 38 skipping to change at page 31, line 38
(1) assigns its initial sequence number for the new connection to (1) assigns its initial sequence number for the new connection to
be larger than the largest sequence number it used on the previous be larger than the largest sequence number it used on the previous
connection incarnation, and connection incarnation, and
(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
TODO - talk to TCPM about what to do about precedence and security
compartment throughout the document ... security compartment material
for IPv4 may be fine nearly as-is, but precedence was a subset of
what DSCP includes and it's not clear that running code actually does
what 793 says about precedence anyways, especially since now as a
DSCP it doesn't make sense to do greater-than comparisons on, nor to
reset connections if it changes.
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) [1]. 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.
skipping to change at page 32, line 26 skipping to change at page 32, line 34
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 [14], there are performance optimizations possible when the MPA [16], 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 39 skipping to change at page 33, line 47
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 - 60) 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, the EMTU_R [14])
size permitted by the IP layer: and the largest transmission size permitted by the IP layer (EMTU_S
[14]):
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 34, line 25 skipping to change at page 34, line 32
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
[21] discusses this in greater detail. [24] 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 at the IP layer). TCP obtains MMS_R
the IP layer; see the generic call GET_MAXSIZES in Section 3.4 of RFC and MMS_S from the IP layer; see the generic call GET_MAXSIZES in
1122. Section 3.4 of RFC 1122. These are defined in terms of their IP MTU
equivalents, EMTU_R and EMTU_S [14].
When TCP is used in a situation where either the IP or TCP headers When TCP is used in a situation where either the IP or TCP headers
are not fixed, the sender must reduce the amount of TCP data in any are not fixed, the sender must reduce the amount of TCP data in any
given packet by the number of octets used by the IP and TCP options. given packet by the number of octets used by the IP and TCP options.
This has been a point of confusion historically, as explained in RFC This has been a point of confusion historically, as explained in RFC
6691, Section 3.1. 6691, Section 3.1.
3.7.2. Path MTU Discovery 3.7.2. Path MTU Discovery
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. Both PMTUD and PLPMTUD help TCP choose segment sizes that
avoid both on-path (for IPv4) and source fragmentation (IPv4 and
IPv6).
PMTUD for IPv4 [2] or IPv6 [3] 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. It relies both on avoiding source
implementation with PMTUD are described in RFC 2923 in order to deal fragmentation and setting the IPv4 DF (don't fragment) flag, the
with problems experienced in practice [6]. PLPMTUD [13] is a latter to inhibit on-path fragmentation. It relies on ICMP errors
Standards Track improvement to PMTUD that relaxes the requirement for from routers along the path, whenever a segment is too large to
ICMP support across a path, and improves performance in cases where traverse a link. Several adjustments to a TCP implementation with
ICMP is not consistently conveyed. The mechanisms in all four of PMTUD are described in RFC 2923 in order to deal with problems
these RFCs are recommended to be included in TCP implementations. experienced in practice [8]. PLPMTUD [15] is a Standards Track
improvement to PMTUD that relaxes the requirement for ICMP support
across a path, and improves performance in cases where ICMP is not
consistently conveyed, but still tries to avoid source fragmentation.
The mechanisms in all four of 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) [17]. It is compression, e.g., RObust Header Compression (ROHC) [19]. 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 [11] and was The "Nagle algorithm" was described in RFC 896 [13] and was
recommended in RFC 1122 [12] for mitigation of an early problem of recommended in RFC 1122 [14] for mitigation of an early problem of
too many small packets being generated. It has been implemented in too many small packets being generated. It has been implemented in
most 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 [16]. Start algorithm [18].
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 [5] defines that an MSS value of 65,535 option can convey. RFC 2675 [7] defines that an MSS value of 65,535
bytes is to be treated as infinity, and Path MTU Discovery [3] 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.
skipping to change at page 37, line 11 skipping to change at page 37, line 26
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
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 (RTO) must be dynamically determined. retransmission timeout (RTO) must be dynamically determined.
The RTO MUST be computed according to the algorithm in [8], including The RTO MUST be computed according to the algorithm in [10],
Karn's algorithm for taking RTT samples. including Karn's algorithm for taking RTT samples.
RFC 793 contains an early example procedure for computing the RTO. RFC 793 contains an early example procedure for computing the RTO.
This was then replaced by the algorithm described in RFC 1122, and This was then replaced by the algorithm described in RFC 1122, and
subsequently updated in RFC 2988, and then again in RFC 6298. subsequently updated in RFC 2988, and then again in RFC 6298.
If a retransmitted packet is identical to the original packet (which If a retransmitted packet is identical to the original packet (which
implies not only that the data boundaries have not changed, but also implies not only that the data boundaries have not changed, but also
that the window and acknowledgment fields of the header have not that the window and acknowledgment fields of the header have not
changed), then the same IP Identification field MAY be used (see changed), then the same IP Identification field MAY be used (see
Section 3.2.1.5 of RFC 1122). Section 3.2.1.5 of RFC 1122).
skipping to change at page 37, line 36 skipping to change at page 37, line 51
RFC 1122 required implementation of Van Jacobson's congestion control RFC 1122 required implementation of Van Jacobson's congestion control
algorithm combining slow start with congestion avoidance. RFC 2581 algorithm combining slow start with congestion avoidance. RFC 2581
provided IETF Standards Track description of this, along with fast provided IETF Standards Track description of this, along with fast
retransmit and fast recovery. RFC 5681 is the current description of retransmit and fast recovery. RFC 5681 is the current description of
these algorithms and is the current standard for TCP congestion these algorithms and is the current standard for TCP congestion
control. control.
A TCP MUST implement RFC 5681. A TCP MUST implement RFC 5681.
Explicit Congestion Notification (ECN) was defined in RFC 3168 and is Explicit Congestion Notification (ECN) was defined in RFC 3168 and is
an IETF Standards Track enhancement that has many benefits [24]. an IETF Standards Track enhancement that has many benefits [28].
A TCP SHOULD implement ECN as described in RFC 3168. A TCP SHOULD implement ECN as described in RFC 3168.
3.8.3. TCP Connection Failures 3.8.3. TCP Connection Failures
Excessive retransmission of the same segment by TCP indicates some Excessive retransmission of the same segment by TCP indicates some
failure of the remote host or the Internet path. This failure may be 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 of short or long duration. The following procedure MUST be used to
handle excessive retransmissions of data segments: handle excessive retransmissions of data segments:
(a) There are two thresholds R1 and R2 measuring the amount of (a) There are two thresholds R1 and R2 measuring the amount of
retransmission that has occurred for the same segment. R1 and R2 retransmission that has occurred for the same segment. R1 and R2
might be measured in time units or as a count of retransmissions. might be measured in time units or as a count of retransmissions.
(b) When the number of transmissions of the same segment reaches (b) When the number of transmissions of the same segment reaches
or exceeds threshold R1, pass negative advice (see [12] or exceeds threshold R1, pass negative advice (see [14]
Section 3.3.1.4) to the IP layer, to trigger dead-gateway Section 3.3.1.4) to the IP layer, to trigger dead-gateway
diagnosis. diagnosis.
(c) When the number of transmissions of the same segment reaches a (c) When the number of transmissions of the same segment reaches a
threshold R2 greater than R1, close the connection. threshold R2 greater than R1, close the connection.
(d) An application MUST be able to set the value for R2 for a (d) An application MUST be able to set the value for R2 for a
particular connection. For example, an interactive application particular connection. For example, an interactive application
might set R2 to "infinity," giving the user control over when to might set R2 to "infinity," giving the user control over when to
disconnect. disconnect.
skipping to change at page 39, line 17 skipping to change at page 39, line 32
An implementation SHOULD send a keep-alive segment with no data; An implementation SHOULD send a keep-alive segment with no data;
however, it MAY be configurable to send a keep-alive segment however, it MAY be configurable to send a keep-alive segment
containing one garbage octet, for compatibility with erroneous TCP containing one garbage octet, for compatibility with erroneous TCP
implementations. implementations.
3.8.5. The Communication of Urgent Information 3.8.5. 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 [18]. urgent mechanism. Details can be found in RFC 6093 [21].
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 39, line 44 skipping to change at page 40, line 10
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. [12] A TCP MUST support a sequence of urgent data of any length. [14]
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. [12] whether or not more urgent data remains to be read. [14]
3.8.6. Managing the Window 3.8.6. 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
skipping to change at page 41, line 27 skipping to change at page 41, line 40
(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. This enables TCP to function in scenarios connection to stay open. This enables TCP to function in scenarios
such as the "printer ran out of paper" situation described in such as the "printer ran out of paper" situation described in
Section 4.2.2.17 of RFC1122. The behavior is subject to the Section 4.2.2.17 of RFC1122. The behavior is subject to the
implementation's resource management concerns, as noted in [19]. implementation's resource management concerns, as noted in [22].
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.6.2. Silly Window Syndrome Avoidance 3.8.6.2. Silly Window Syndrome Avoidance
The "Silly Window Syndrome" (SWS) is a stable pattern of small The "Silly Window Syndrome" (SWS) is a stable pattern of small
incremental window movements resulting in extremely poor TCP incremental window movements resulting in extremely poor TCP
performance. Algorithms to avoid SWS are described below for both performance. Algorithms to avoid SWS are described below for both
skipping to change at page 48, line 7 skipping to change at page 48, line 24
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 [18] due to New applications SHOULD NOT set the URGENT flag [21] 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 52, line 7 skipping to change at page 52, line 25
Flush Flush
Some TCP implementations have included a FLUSH call, which will Some TCP implementations have included a FLUSH call, which will
empty the TCP send queue of any data for which the user has 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 issued SEND calls but which is still to the right of the
current send window. That is, it flushes as much queued send current send window. That is, it flushes as much queued send
data as possible without losing sequence number data as possible without losing sequence number
synchronization. synchronization.
Set TOS Set Differentiated Services Field (IPv4 TOS or IPv6 Traffic Class)
The application layer MUST be able to specify the Type-of- The application layer MUST be able to specify the
Service (TOS) for segments that are sent on a connection. It Differentiated Services field for segments that are sent on a
connection. The Differentiated Services field includes the
6-bit Differentiated Services Code Point (DSCP) value. It is
not required, but the application SHOULD be able to change the not required, but the application SHOULD be able to change the
TOS during the connection lifetime. TCP SHOULD pass the Differentiated Services field during the connection lifetime.
current TOS value without change to the IP layer, when it sends TCP SHOULD pass the current Differentiated Services field value
segments on the connection. without change to the IP layer, when it sends segments on the
connection.
The TOS will be specified independently in each direction on The Differentiated Services field will be specified
the connection, so that the receiver application will specify independently in each direction on the connection, so that the
the TOS used for ACK segments. receiver application will specify the Differentiated Services
field used for ACK segments.
TCP MAY pass the most recently received TOS up to the TCP MAY pass the most recently received Differentiated Services
application. field 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 52, line 45 skipping to change at page 53, line 19
Local Connection Name Always Local Connection Name Always
Response String Always Response String Always
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. The two current standard
internetwork system where the lower level module is the Internet Internet Protocol (IP) versions layered below TCP are IPv4 [1] and
Protocol (IP) [1]. IPv6 [5].
If the lower level protocol is IP it provides arguments for a type of If the lower level protocol is IPv4 it provides arguments for a type
service and for a time to live. TCP uses the following settings for of service (used within the Differentiated Services field) and for a
these parameters: time to live. TCP uses the following settings for 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. TODO - this is pretty much wrong with regard
to DiffServ, I think we should just say that the user can specify
diffserv field (superset of DSCP) and leave it at that, but will
check with TCPM
Time to Live (TTL): The TTL value used to send TCP segments MUST Time to Live (TTL): The TTL value used to send TCP segments MUST
be configurable. be configurable.
Note that RFC 793 specified one minute (60 seconds) as a Note that RFC 793 specified one minute (60 seconds) as a
constant for the TTL, because the assumed maximum segment constant for the TTL, because the assumed maximum segment
lifetime was two minutes. This was intended to explicitly ask lifetime was two minutes. This was intended to explicitly ask
that a segment be destroyed if it cannot be delivered by the that a segment be destroyed if it cannot be delivered by the
internet system within one minute. RFC 1122 changed this internet system within one minute. RFC 1122 changed this
specification to require that the TTL be configurable. specification to require that the TTL be configurable.
skipping to change at page 54, line 14 skipping to change at page 54, line 35
3.9.2.2. ICMP Messages 3.9.2.2. ICMP Messages
TCP MUST act on an ICMP error message passed up from the IP layer, TCP MUST act on an ICMP error message passed up from the IP layer,
directing it to the connection that created the error. The necessary directing it to the connection that created the error. The necessary
demultiplexing information can be found in the IP header contained demultiplexing information can be found in the IP header contained
within the ICMP message. within the ICMP message.
This applies to ICMPv6 in addition to IPv4 ICMP. This applies to ICMPv6 in addition to IPv4 ICMP.
[15] contains discussion of specific ICMP and ICMPv6 messages [17] contains discussion of specific ICMP and ICMPv6 messages
classified as either "soft" or "hard" errors that may bear different classified as either "soft" or "hard" errors that may bear different
responses. Treatment for classes of ICMP messages is described responses. Treatment for classes of ICMP messages is described
below: below:
Source Quench Source Quench
TCP MUST silently discard any received ICMP Source Quench messages. TCP MUST silently discard any received ICMP Source Quench messages.
See [9] for discussion. See [11] for discussion.
Soft Errors Soft Errors
For ICMP these include: Destination Unreachable -- codes 0, 1, 5, For ICMP these include: Destination Unreachable -- codes 0, 1, 5,
Time Exceeded -- codes 0, 1, and Parameter Problem. Time Exceeded -- codes 0, 1, and Parameter Problem.
For ICMPv6 these include: Destination Unreachable -- codes 0 and 3, For ICMPv6 these include: Destination Unreachable -- codes 0 and 3,
Time Exceeded -- codes 0, 1, and Parameter Problem -- codes 0, 1, 2 Time Exceeded -- codes 0, 1, and Parameter Problem -- codes 0, 1, 2
Since these Unreachable messages indicate soft error conditions, Since these Unreachable messages indicate soft error conditions,
TCP MUST NOT abort the connection, and it SHOULD make the TCP MUST NOT abort the connection, and it SHOULD make the
information available to the application. information available to the application.
Hard Errors Hard Errors
For ICMP these include Destination Unreachable -- codes 2-4"> For ICMP these include Destination Unreachable -- codes 2-4">
These are hard error conditions, so TCP SHOULD abort the These are hard error conditions, so TCP SHOULD abort the
connection. [15] notes that some implementations do not abort connection. [17] notes that some implementations do not abort
connections when an ICMP hard error is received for a connection connections when an ICMP hard error is received for a connection
that is in any of the synchronized states. that is in any of the synchronized states.
Note that [15] section 4 describes widespread implementation behavior Note that [17] section 4 describes widespread implementation behavior
that treats soft errors as hard errors during connection that treats soft errors as hard errors during connection
establishment. establishment.
3.10. Event Processing 3.10. Event Processing
The processing depicted in this section is an example of one possible The processing depicted in this section is an example of one possible
implementation. Other implementations may have slightly different implementation. Other implementations may have slightly different
processing sequences, but they should differ from those in this processing sequences, but they should differ from those in this
section only in detail, not in substance. section only in detail, not in substance.
skipping to change at page 68, line 16 skipping to change at page 68, line 16
acceptable. (TODO: in processing Errata ID 3300, it was acceptable. (TODO: in processing Errata ID 3300, it was
noted that some stacks in the wild that do not send data noted that some stacks in the wild that do not send data
on the SYN are just checking that SEG.ACK == SND.NXT ... on the SYN are just checking that SEG.ACK == SND.NXT ...
think about whether anything should be said about that think about whether anything should be said about that
here) here)
second check the RST bit second check the RST bit
If the RST bit is set If the RST bit is set
A potential blind reset attack is described in RFC 5961
[20], with the mitigation that a TCP implementation
SHOULD first check that the sequence number exactly
matches RCV.NXT prior to executing the action in the next
paragraph.
If the ACK was acceptable then signal the user "error: If the ACK was acceptable then signal the user "error:
connection reset", drop the segment, enter CLOSED state, connection reset", drop the segment, enter CLOSED state,
delete TCB, and return. Otherwise (no ACK) drop the delete TCB, and return. Otherwise (no ACK) drop the
segment and return. segment and return.
third check the security and precedence third check the security and precedence
If the security/compartment in the segment does not exactly If the security/compartment in the segment does not exactly
match the security/compartment in the TCB, send a reset match the security/compartment in the TCB, send a reset
skipping to change at page 71, line 17 skipping to change at page 71, line 26
In general, the processing of received segments MUST be In general, the processing of received segments MUST be
implemented to aggregate ACK segments whenever possible. implemented to aggregate ACK segments whenever possible.
For example, if the TCP is processing a series of queued For example, if the TCP is processing a series of queued
segments, it MUST process them all before sending any ACK segments, it MUST process them all before sending any ACK
segments. (TODO - see if there's a better place for this segments. (TODO - see if there's a better place for this
paragraph - taken from RFC1122) paragraph - taken from RFC1122)
second check the RST bit, second check the RST bit,
RFC 5961 section 3 describes a potential blind reset attack
and optional mitigation approach that SHOULD be implemented.
For stacks implementing RFC 5961, the three checks below
apply, otherwise processesing for these states is indicated
further below.
1) If the RST bit is set and the sequence number is
outside the current receive window, silently drop the
segment.
2) If the RST bit is set and the sequence number exactly
matches the next expected sequence number (RCV.NXT), then
TCP MUST reset the connection in the manner prescribed
below according to the connection state.
3) If the RST bit is set and the sequence number does not
exactly match the next expected sequence value, yet is
within the current receive window, TCP MUST send an
acknowledgement (challenge ACK):
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the challenge ACK, TCP MUST drop the
unacceptable segment and stop processing the incoming
packet further. Note that RFC 5961 and Errata ID 4772
contain additional considerations for ACK throttling in
an implementation.
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
with an active OPEN (i.e., came from SYN-SENT state) with an active OPEN (i.e., came from SYN-SENT state)
then the connection was refused, signal the user then the connection was refused, signal the user
skipping to change at page 72, line 34 skipping to change at page 73, line 22
Enter the CLOSED state, delete the TCB, and return. Enter the CLOSED state, delete the TCB, and return.
Note this check is placed following the sequence check to Note this check is placed following the sequence check to
prevent a segment from an old connection between these ports prevent a segment from an old connection between these ports
with a different security or precedence from causing an with a different security or precedence from causing an
abort of the current connection. abort of the current connection.
fourth, check the SYN bit, fourth, check the SYN bit,
SYN-RECEIVED SYN-RECEIVED
If the connection was initiated with a passive OPEN, then
return this connection to the LISTEN state and return.
Otherwise, handle per the directions for synchronized
states below.
ESTABLISHED STATE ESTABLISHED STATE
FIN-WAIT STATE-1 FIN-WAIT STATE-1
FIN-WAIT STATE-2 FIN-WAIT STATE-2
CLOSE-WAIT STATE CLOSE-WAIT STATE
CLOSING STATE CLOSING STATE
LAST-ACK STATE LAST-ACK STATE
TIME-WAIT STATE TIME-WAIT STATE
TODO: need to incorporate RFC 1122 4.2.2.20(e) here If the SYN bit is set in these synchronized states, it
may be either an error where the connection should be
reset, or the result of an attack attempt, as described
in RFC 5961 [20]. RFC 5961 provides a mitigation that
SHOULD be implemented, though there are alternatives (see
Section 6). RFC 5961 recommends that in these
synchronized states, if the SYN bit is set, irrespective
of the sequence number, TCP MUST send a "challenge ACK"
to the remote peer:
If the SYN is in the window it is an error, send a reset, <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgement, TCP MUST drop the
unacceptable segment and stop processing further. Note
that RFC 5961 and Errata ID 4772 contain additional ACK
throttling notes for an implementation.
For implementations that do not follow RFC 5961, the
original RFC 793 behavior follows in this paragraph. If
the SYN is in the window it is an error, send a reset,
any outstanding RECEIVEs and SEND should receive "reset" any outstanding RECEIVEs and SEND should receive "reset"
responses, all segment queues should be flushed, the user responses, all segment queues should be flushed, the user
should also receive an unsolicited general "connection should also receive an unsolicited general "connection
reset" signal, enter the CLOSED state, delete the TCB, reset" signal, enter the CLOSED state, delete the TCB,
and return. and return.
If the SYN is not in the window this step would not be If the SYN is not in the window this step would not be
reached and an ack would have been sent in the first step reached and an ack would have been sent in the first step
(sequence number check). (sequence number check).
fifth check the ACK field, fifth check the ACK field,
if the ACK bit is off drop the segment and return if the ACK bit is off drop the segment and return
if the ACK bit is on if the ACK bit is on
RFC 5961 section 5 describes a potential blind data
injection attack, and mitigation that implementations MAY
choose to include. TCP stacks that implement RFC 5961
MUST add an input check that the ACK value is acceptable
only if it is in the range of ((SND.UNA - MAX.SND.WND) =<
SEG.ACK =< SND.NXT). All incoming segments whose ACK
value doesn't satisfy the above condition MUST be
discarded and an ACK sent back. The new state variable
MAX.SND.WND is defined as the largest window that the
local sender has ever received from its peer (subject to
window scaling) or may be hard-coded to a maximum
permissible window value. When the ACK value is
acceptable, the processing per-state below applies:
SYN-RECEIVED STATE SYN-RECEIVED STATE
If SND.UNA < SEG.ACK =< SND.NXT then enter ESTABLISHED If SND.UNA < SEG.ACK =< SND.NXT then enter ESTABLISHED
state and continue processing with variables below set state and continue processing with variables below set
to: to:
SND.WND <- SEG.WND SND.WND <- SEG.WND
SND.WL1 <- SEG.SEQ SND.WL1 <- SEG.SEQ
SND.WL2 <- SEG.ACK SND.WL2 <- SEG.ACK
skipping to change at page 84, line 28 skipping to change at page 85, line 28
the state of a connection. the state of a connection.
TCB.PRC TCB.PRC
The precedence of the connection. The precedence of the connection.
TCP TCP
Transmission Control Protocol: A host-to-host protocol for Transmission Control Protocol: A host-to-host protocol for
reliable communication in internetwork environments. reliable communication in internetwork environments.
TOS TOS
Type of Service, an Internet Protocol field. Type of Service, an IPv4 field, that currently carries the
Differentiated Services field [6] containing the
Differentiated Services Code Point (DSCP) value and two
unused bits.
Type of Service Type of Service
An Internet Protocol field which indicates the type of An Internet Protocol field which indicates the type of
service for this internet fragment. service for this internet fragment.
URG URG
A control bit (urgent), occupying no sequence space, used to A control bit (urgent), occupying no sequence space, used to
indicate that the receiving user should be notified to do indicate that the receiving user should be notified to do
urgent processing as long as there is data to be consumed urgent processing as long as there is data to be consumed
with sequence numbers less than the value indicated in the with sequence numbers less than the value indicated in the
skipping to change at page 88, line 20 skipping to change at page 89, line 22
Acknowledging Queued Segments, and Remote Address Validation. RTO Acknowledging Queued Segments, and Remote Address Validation. RTO
computation is referenced from RFC 6298 rather than RFC 1122. computation is referenced from RFC 6298 rather than RFC 1122.
The -05 revision includes the requirement to implement TCP congestion The -05 revision includes the requirement to implement TCP congestion
control with recommendation to implemente ECN, the RFC 6633 update to control with recommendation to implemente ECN, the RFC 6633 update to
1122, which changed the requirement on responding to source quench 1122, which changed the requirement on responding to source quench
ICMP messages, and discussion of ICMP (and ICMPv6) soft and hard ICMP messages, and discussion of ICMP (and ICMPv6) soft and hard
errors per RFC 5461 (ICMPv6 handling for TCP doesn't seem to be errors per RFC 5461 (ICMPv6 handling for TCP doesn't seem to be
mentioned elsewhere in standards track). mentioned elsewhere in standards track).
The -06 revision includes an appendix on "Other Implementation Notes"
to capture widely-deployed fundamental features that are not
contained in the RFC series yet. It also added mention of RFC 6994
and the IANA TCP parameters registry as a reference. It includes
references to RFC 5961 in appropriate places. The references to TOS
were changed to DiffServ field, based on reflecting RFC 2474 as well
as the IPv6 presence of traffic class (carrying DiffServ field)
rather than TOS.
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. mention 5961 state machine option 1. mention 6161 (reducing TIME-WAIT)
2. mention 6161 (reducing TIME-WAIT) 2. clarify data on SYN from Michael Welzl
3. TOS material does not take DSCP changes into account
4. there is inconsistency between use of SYN_RCVD and SYNC-RECEIVED
in diagrams and text in various places
5. make sure that clarifications in RFC 1011 are captured
TODO list of other potential changes, if there is TCPM consensus: Some other suggested changes that will not be incorporated in this
793 update unless TCPM consensus changes with regard to scope are:
1. see draft-gont-tcpm-tcp-seccomp-prec 1. look at Tony Sabatini suggestion for describing DO field
2. incorporate Fernando's new number-checking fixes (if past the 2. clearly specify treatment of reserved bits (see TCPM thread on
IESG in time) EDO draft April 25, 2014) -- TODO - an attempt at this is
3. look at Tony Sabatini suggestion for describing DO field actually in -06, but needs to be confirmed by TCPM explicitly
4. clearly specify treatment of reserved bits (see TCPM thread on since there is no RFC reference
EDO draft April 25, 2014) 3. per discussion with Joe Touch (TAPS list, 6/20/2015), the
5. look at possible mention of draft-minshall-nagle (e.g. as in
Linux)
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 [18] for discussion of security considerations related See RFC 6093 [21] 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 89, line 36 skipping to change at page 90, line 44
Michael Scharf Michael Scharf
Yoshifumi Nishida Yoshifumi Nishida
Pasi Sarolahti Pasi Sarolahti
During early discussion of this work on the TCPM mailing list, and at During early discussion of this work on the TCPM mailing list, and at
the IETF 88 meeting in Vancouver, helpful comments, critiques, and the IETF 88 meeting in Vancouver, helpful comments, critiques, and
reviews were received from (listed alphebetically): David Borman, reviews were received from (listed alphebetically): David Borman,
Yuchung Cheng, Martin Duke, Kevin Lahey, Kevin Mason, Matt Mathis, Yuchung Cheng, Martin Duke, Kevin Lahey, Kevin Mason, Matt Mathis,
Hagen Paul Pfeifer, Anthony Sabatini, Joe Touch, Reji Varghese, Lloyd Hagen Paul Pfeifer, Anthony Sabatini, Joe Touch, Reji Varghese, Lloyd
Wood, and Alex Zimmermann. Wood, and Alex Zimmermann. Joe Touch provided help in clarifying the
description of segment size parameters and PMTUD/PLPMTUD
recommendations.
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
skipping to change at page 90, line 18 skipping to change at page 91, line 26
[3] 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>.
[4] 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>.
[5] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[6] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>.
[7] 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>.
[6] Lahey, K., "TCP Problems with Path MTU Discovery", [8] 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] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [9] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>. <http://www.rfc-editor.org/info/rfc3168>.
[8] Paxson, V., Allman, M., Chu, J., and M. Sargent, [10] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, DOI 10.17487/RFC6298, June 2011,
<http://www.rfc-editor.org/info/rfc6298>. <http://www.rfc-editor.org/info/rfc6298>.
[9] Gont, F., "Deprecation of ICMP Source Quench Messages", [11] Gont, F., "Deprecation of ICMP Source Quench Messages",
RFC 6633, DOI 10.17487/RFC6633, May 2012, RFC 6633, DOI 10.17487/RFC6633, May 2012,
<http://www.rfc-editor.org/info/rfc6633>. <http://www.rfc-editor.org/info/rfc6633>.
8.2. Informative References 8.2. Informative References
[10] Postel, J., "Transmission Control Protocol", STD 7, [12] 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>.
[11] Nagle, J., "Congestion Control in IP/TCP Internetworks", [13] 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>.
[12] Braden, R., Ed., "Requirements for Internet Hosts - [14] 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>.
[13] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [15] 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>.
[14] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. [16] 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>.
[15] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, [17] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
DOI 10.17487/RFC5461, February 2009, DOI 10.17487/RFC5461, February 2009,
<http://www.rfc-editor.org/info/rfc5461>. <http://www.rfc-editor.org/info/rfc5461>.
[16] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [18] 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>.
[17] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust [19] 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>.
[18] Gont, F. and A. Yourtchenko, "On the Implementation of the [20] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961,
DOI 10.17487/RFC5961, August 2010,
<http://www.rfc-editor.org/info/rfc5961>.
[21] 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>.
[19] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender [22] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender
Clarification for Persist Condition", RFC 6429, Clarification for Persist Condition", RFC 6429,
DOI 10.17487/RFC6429, December 2011, DOI 10.17487/RFC6429, December 2011,
<http://www.rfc-editor.org/info/rfc6429>. <http://www.rfc-editor.org/info/rfc6429>.
[20] Gont, F. and S. Bellovin, "Defending against Sequence [23] 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>.
[21] Borman, D., "TCP Options and Maximum Segment Size (MSS)", [24] 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>.
[22] Borman, D., Braden, B., Jacobson, V., and R. [25] Touch, J., "Shared Use of Experimental TCP Options",
RFC 6994, DOI 10.17487/RFC6994, August 2013,
<http://www.rfc-editor.org/info/rfc6994>.
[26] 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>.
[23] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. [27] 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>.
[24] Fairhurst, G. and M. Welzl, "The Benefits of Using [28] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087, Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017, DOI 10.17487/RFC8087, March 2017,
<http://www.rfc-editor.org/info/rfc8087>. <http://www.rfc-editor.org/info/rfc8087>.
Appendix A. TCP Requirement Summary [29] IANA, "Transmission Control Protocol (TCP) Parameters,
https://www.iana.org/assignments/tcp-parameters/tcp-
parameters.xhtml", 2017.
Appendix A. Other Implementation Notes
TODO - mention draft-gont-tcpm-tcp-seccomp-prec - per IETF 99 TCPM
discussion
TODO - mention draft-gont-tcpm-tcp-seq-validation - per IETF 99 TCPM
discussion
TODO - mention the draft-minshall Nagle variation that is in Linux -
suggested by Yuchung Cheng
TODO - mention the low watermark function that is in Linux -
suggested by Michael Welzl
Appendix B. 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
recommendations. recommendations.
skipping to change at page 93, line 41 skipping to change at page 95, line 37
TCP Checksums | | | | | | | TCP Checksums | | | | | | |
Sender compute checksum |4.2.2.7 |x| | | | | Sender compute checksum |4.2.2.7 |x| | | | |
Receiver check checksum |4.2.2.7 |x| | | | | Receiver check checksum |4.2.2.7 |x| | | | |
| | | | | | | | | | | | | |
ISN Selection | | | | | | | ISN Selection | | | | | | |
Include a clock-driven ISN generator component |4.2.2.9 |x| | | | | Include a clock-driven ISN generator component |4.2.2.9 |x| | | | |
Secure ISN generator with a PRF component | N/A | |x| | | | Secure ISN generator with a PRF component | N/A | |x| | | |
| | | | | | | | | | | | | |
Opening Connections | | | | | | | Opening Connections | | | | | | |
Support simultaneous open attempts |4.2.2.10|x| | | | | Support simultaneous open attempts |4.2.2.10|x| | | | |
SYN-RCVD remembers last state |4.2.2.11|x| | | | | SYN-RECEIVED remembers last state |4.2.2.11|x| | | | |
Passive Open call interfere with others |4.2.2.18| | | | |x| Passive Open call interfere with others |4.2.2.18| | | | |x|
Function: simultan. LISTENs for same port |4.2.2.18|x| | | | | Function: simultan. LISTENs for same port |4.2.2.18|x| | | | |
Ask IP for src address for SYN if necc. |4.2.3.7 |x| | | | | Ask IP for src address for SYN if necc. |4.2.3.7 |x| | | | |
Otherwise, use local addr of conn. |4.2.3.7 |x| | | | | Otherwise, use local addr of conn. |4.2.3.7 |x| | | | |
OPEN to broadcast/multicast IP Address |4.2.3.14| | | | |x| OPEN to broadcast/multicast IP Address |4.2.3.14| | | | |x|
Silently discard seg to bcast/mcast addr |4.2.3.14|x| | | | | Silently discard seg to bcast/mcast addr |4.2.3.14|x| | | | |
| | | | | | | | | | | | | |
Closing Connections | | | | | | | Closing Connections | | | | | | |
RST can contain data |4.2.2.12| |x| | | | RST can contain data |4.2.2.12| |x| | | |
Inform application of aborted conn |4.2.2.13|x| | | | | Inform application of aborted conn |4.2.2.13|x| | | | |
skipping to change at page 95, line 29 skipping to change at page 97, line 24
Param Problem => tell ALP, don't abort |4.2.3.9 | |x| | | | Param Problem => tell ALP, don't abort |4.2.3.9 | |x| | | |
| | | | | | | | | | | | | |
Address Validation | | | | | | | Address Validation | | | | | | |
Reject OPEN call to invalid IP address |4.2.3.10|x| | | | | Reject OPEN call to invalid IP address |4.2.3.10|x| | | | |
Reject SYN from invalid IP address |4.2.3.10|x| | | | | Reject SYN from invalid IP address |4.2.3.10|x| | | | |
Silently discard SYN to bcast/mcast addr |4.2.3.10|x| | | | | Silently discard SYN to bcast/mcast addr |4.2.3.10|x| | | | |
| | | | | | | | | | | | | |
TCP/ALP Interface Services | | | | | | | TCP/ALP Interface Services | | | | | | |
Error Report mechanism |4.2.4.1 |x| | | | | Error Report mechanism |4.2.4.1 |x| | | | |
ALP can disable Error Report Routine |4.2.4.1 | |x| | | | ALP can disable Error Report Routine |4.2.4.1 | |x| | | |
ALP can specify TOS for sending |4.2.4.2 |x| | | | | ALP can specify DiffServ field for sending |4.2.4.2 |x| | | | |
Passed unchanged to IP |4.2.4.2 | |x| | | | Passed unchanged to IP |4.2.4.2 | |x| | | |
ALP can change TOS during connection |4.2.4.2 | |x| | | | ALP can change DiffServ field during connection|4.2.4.2 | |x| | | |
Pass received TOS up to ALP |4.2.4.2 | | |x| | | Pass received DiffServ field up to ALP |4.2.4.2 | | |x| | |
FLUSH call |4.2.4.3 | | |x| | | FLUSH call |4.2.4.3 | | |x| | |
Optional local IP addr parm. in OPEN |4.2.4.4 |x| | | | | Optional local IP addr parm. in OPEN |4.2.4.4 |x| | | | |
-------------------------------------------------|--------|-|-|-|-|-|-- -------------------------------------------------|--------|-|-|-|-|-|--
FOOTNOTES: (1) "ALP" means Application-Layer program. FOOTNOTES: (1) "ALP" means Application-Layer program.
Author's Address Author's Address
Wesley M. Eddy (editor) Wesley M. Eddy (editor)
MTI Systems MTI Systems
 End of changes. 103 change blocks. 
207 lines changed or deleted 369 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/