< draft-eddy-rfc793bis-01.txt   draft-eddy-rfc793bis-02.txt >
Internet Engineering Task Force W. Eddy Internet Engineering Task Force W. Eddy, Ed.
Internet-Draft MTI Systems Internet-Draft MTI Systems
Obsoletes: 793 (if approved) March 20, 2014 Obsoletes: 793 (if approved) March 27, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: September 21, 2014 Expires: September 28, 2014
Transmission Control Protocol Specification Transmission Control Protocol Specification
draft-eddy-rfc793bis-01 draft-eddy-rfc793bis-02
Abstract Abstract
This document specifies the Internet's Transmission Control Protocol This document specifies the Internet's Transmission Control Protocol
(TCP). TCP is an important transport layer protocol in the Internet (TCP). TCP is an important transport layer protocol in the Internet
stack, and has continuously evolved over decades of use and growth of stack, and has continuously evolved over decades of use and growth of
the Internet. Over this time, a number of changes have been made to the Internet. Over this time, a number of changes have been made to
TCP as it was specified in RFC 793, though these have only been TCP as it was specified in RFC 793, though these have only been
documented in a piecemeal fashion. This document collects and brings documented in a piecemeal fashion. This document collects and brings
those changes together with the protocol specification from RFC 793. those changes together with the protocol specification from RFC 793.
This document obsoletes RFC 793 and several other RFCs (TODO: list This document obsoletes RFC 793 and several other RFCs (TODO: list
actual RFCs). all actual RFCs when finished).
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.
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 [1]. document are to be interpreted as described in RFC 2119 [1].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 45 skipping to change at page 1, line 48
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 21, 2014. This Internet-Draft will expire on September 28, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 36 skipping to change at page 2, line 36
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 1. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Functional Specification . . . . . . . . . . . . . . . . . . 4 3. Functional Specification . . . . . . . . . . . . . . . . . . 5
3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 14 3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 13
3.4. Establishing a connection . . . . . . . . . . . . . . . . 20 3.4. Establishing a connection . . . . . . . . . . . . . . . . 19
3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 27 3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 26
3.6. Precedence and Security . . . . . . . . . . . . . . . . . 29 3.6. Precedence and Security . . . . . . . . . . . . . . . . . 28
3.7. Data Communication . . . . . . . . . . . . . . . . . . . 30 3.7. Data Communication . . . . . . . . . . . . . . . . . . . 29
3.8. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 34 3.8. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 33
3.8.1. User/TCP Interface . . . . . . . . . . . . . . . . . 34 3.8.1. User/TCP Interface . . . . . . . . . . . . . . . . . 33
3.8.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 40 3.8.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 40
3.9. Event Processing . . . . . . . . . . . . . . . . . . . . 41 3.9. Event Processing . . . . . . . . . . . . . . . . . . . . 40
3.10. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 64 3.10. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 63
4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 69 4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 68
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
6. Security Considerations . . . . . . . . . . . . . . . . . . . 71 6. Security and Privacy Considerations . . . . . . . . . . . . . 70
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.1. Normative References . . . . . . . . . . . . . . . . . . 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 71
8.2. Informative References . . . . . . . . . . . . . . . . . 71 8.2. Informative References . . . . . . . . . . . . . . . . . 71
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 72
1. Purpose and Scope 1. Purpose and Scope
In 1983, RFC 793 [2] was released, documenting the Transmission In 1981, RFC 793 [2] 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 that time, TCP has been implemented many times, and has been Since that time, TCP has been implemented many times, and has been
used as a transport protocol for numerous applications on the used as a transport protocol for numerous applications on the
Internet. 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 [3]. Over time, combined to serve as the specification for TCP [3]. Over time, a
errata have been identified on RFC 793, as well as deficiencies in number of errata have been identified on RFC 793, as well as
security, performance, and other aspects. A number of enhancements deficiencies in security, performance, and other aspects. A number
has grown and been documented separately. of enhancements has grown and been documented separately. These were
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
have not been attempted to include in this document. This is a have not been attempted to include in this document. This is a
concious choice, as this base specification can be used with multiple conscious choice, as this base specification can be used with
additional algorithms that are developed and incorporated separately, multiple additional algorithms that are developed and incorporated
but all TCP implementations need to implement this specification as a separately, but all TCP implementations need to implement this
common basis in order to interoperate. As some additional TCP specification as a common basis in order to interoperate. As some
features have become quite complicated themselves (e.g. advanced loss additional TCP features have become quite complicated themselves
recovery and congestion control), future companion documents may (e.g. advanced loss recovery and congestion control), future
attempt to similarly bring these together. companion documents may attempt to similarly bring these together.
In addition to the protocol specification that descibes the TCP In addition to the protocol specification that descibes the TCP
segment format, generation, and processing rules that are to be segment format, generation, and processing rules that are to be
implemented in code, RFC 793 and other updates also contain implemented in code, RFC 793 and other updates also contain
informative and descriptive text for human readers to understand informative and descriptive text for human readers to understand
aspects of the protocol design and operation. This document does not aspects of the protocol design and operation. This document does not
attempt to alter or update those parts of RFC 793, and is focused attempt to alter or update this informative text, and is focused only
only on updating the normative protocol specification. We preserve on updating the normative protocol specification. We preserve
references to the documentation containing the important explanations references to the documentation containing the important explanations
and rationale, where appropriate. and rationale, where appropriate.
This document is intended to be useful both in checking existing TCP This document is intended to be useful both in checking existing TCP
implementations for conformance, as well as in writing new implementations for conformance, as well as in writing new
implementations. implementations.
2. Introduction 2. Introduction
RFC 793 contains a discussion of the TCP design goals and provides RFC 793 contains a discussion of the TCP design goals and provides
examples of its operation, including examples of connection examples of its operation, including examples of connection
establishment, closing connections, and retransmitting packets to establishment, closing connections, and retransmitting packets to
repair losses. repair losses.
This document describes the 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.
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 reference.
***Please do not use this revision as a basis for any work or
reference.***
TODO: describe the subsequent structure of the document to-be (e.g. TODO: describe the subsequent structure of the document to-be (e.g.
will it follow the newtcp BSD implementation?), and mention that a will it follow the newtcp BSD implementation?), and mention that a
list of changes from RFC 793 will be kept in the final section list of changes from RFC 793 will be kept in the final section
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 roughly: The set of content changes planned for future revisions is roughly:
-00 was a proposal for the scope of the document and description -00 was a proposal for the scope of the document and description
of the need for an update to RFC 793 of the need for an update to RFC 793
-01 incorporated the RFC 793 section 3 content with no additional -01 incorporated the RFC 793 section 3 content with no additional
changes into XML2RFC format for easy tracking of the changes changes into XML2RFC format for easy tracking of the changes
between RFC 793 and future revisions of the document between RFC 793 and future revisions of the document
-02 is planned to incorporate the verified errata on RFC 793 -02 incorporates the verified errata on RFC 793 as of March 20,
2014
-03 and beyond are intended to incorporate changes from other RFCs -03 and beyond are intended to incorporate changes from other RFCs
that updated 793 that updated 793
3. Functional Specification 3. Functional Specification
3.1. Header Format 3.1. Header Format
TCP segments are sent as internet datagrams. The Internet Protocol TCP segments are sent as internet datagrams. The Internet Protocol
header carries several information fields, including the source and header carries several information fields, including the source and
skipping to change at page 6, line 46 skipping to change at page 7, line 4
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 96 bit pseudo header conceptually
prefixed to the TCP header. This pseudo header contains the Source prefixed to the TCP header. This pseudo header contains the Source
Address, the Destination Address, the Protocol, and TCP length. Address, the Destination Address, the Protocol, and TCP length.
This gives the TCP protection against misrouted segments. This This gives the TCP protection against misrouted segments. This
information is carried in the Internet Protocol and is transferred information is carried in the Internet Protocol and is transferred
across the TCP/Network interface in the arguments or results of across the TCP/Network interface in the arguments or results of
calls by the TCP on the IP. calls by the TCP on the IP.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| 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.
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 last octet in a
the urgent data. This field is only be interpreted in segments sequence of urgent data. This field is only be interpreted in
with the URG control bit set. segments with the URG control bit set. EDITOR'S NOTE: TODO need to
incorporate RFC 6093 here.
Options: variable Options: variable
Options may occupy space at the end of the TCP header and are a Options may occupy space at the end of the TCP header and are a
multiple of 8 bits in length. All options are included in the multiple of 8 bits in length. All options are included in the
checksum. An option may begin on any octet boundary. There are checksum. An option may begin on any octet boundary. There are
two cases for the format of an option: two cases for the format of an option:
Case 1: A single octet of option-kind. Case 1: A single octet of option-kind.
skipping to change at page 8, line 48 skipping to change at page 9, line 4
not begin on a word boundary. not begin on a word boundary.
Maximum Segment Size Maximum Segment Size
+--------+--------+---------+--------+ +--------+--------+---------+--------+
|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 must only be sent in the initial connection request (i.e., field may be sent in the initial connection request (i.e., in
in segments with the SYN control bit set). If this option is segments with the SYN control bit set) and must not be sent in
not used, any segment size is allowed. other segments. If this option is not used, any segment size is
allowed.
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 11, line 41 skipping to change at page 11, line 41
request from the remote TCP. request from the remote TCP.
CLOSE-WAIT - represents waiting for a connection termination CLOSE-WAIT - represents waiting for a connection termination
request from the local user. request from the local user.
CLOSING - represents waiting for a connection termination request CLOSING - represents waiting for a connection termination request
acknowledgment from the remote TCP. acknowledgment from the remote TCP.
LAST-ACK - represents waiting for an acknowledgment of the LAST-ACK - represents waiting for an acknowledgment of the
connection termination request previously sent to the remote TCP connection termination request previously sent to the remote TCP
(which includes an acknowledgment of its connection termination (this termination request sent to the remote TCP already included
request). an acknowledgment of the termination request sent from the remote
TCP).
TIME-WAIT - represents waiting for enough time to pass to be sure TIME-WAIT - represents waiting for enough time to pass to be sure
the remote TCP received the acknowledgment of its connection the remote TCP received the acknowledgment of its connection
termination request. termination request.
CLOSED - represents no connection state at all. CLOSED - represents no connection state at all.
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.
NOTE 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.
+---------+ ---------\ 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 | \ \
+---------+ 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 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 ------- | | -------
skipping to change at page 13, line 50 skipping to change at page 13, line 13
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
|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
conditional on having reached SYN-RCVD after a passive open.
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.
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
skipping to change at page 18, line 41 skipping to change at page 18, line 12
duplicate detection and sequencing algorithm in the TCP protocol duplicate detection and sequencing algorithm in the TCP protocol
relies on the unique binding of segment data to sequence space to the relies on the unique binding of segment data to sequence space to the
extent that sequence numbers will not cycle through all 2**32 values extent that sequence numbers will not cycle through all 2**32 values
before the segment data bound to those sequence numbers has been before the segment data bound to those sequence numbers has been
delivered and acknowledged by the receiver and all duplicate copies delivered and acknowledged by the receiver and all duplicate copies
of the segments have "drained" from the internet. Without such an of the segments have "drained" from the internet. Without such an
assumption, two distinct TCP segments could conceivably be assigned assumption, two distinct TCP segments could conceivably be assigned
the same or overlapping sequence numbers, causing confusion at the the same or overlapping sequence numbers, causing confusion at the
receiver as to which data is new and which is old. Remember that receiver as to which data is new and which is old. Remember that
each segment is bound to as many consecutive sequence numbers as each segment is bound to as many consecutive sequence numbers as
there are octets of data in the segment. there are octets of data and SYN or FIN flags in the segment.
Under normal conditions, TCPs keep track of the next sequence number Under normal conditions, TCPs keep track of the next sequence number
to emit and the oldest awaiting acknowledgment so as to avoid to emit and the oldest awaiting acknowledgment so as to avoid
mistakenly using a sequence number over before its first use has been mistakenly using a sequence number over before its first use has been
acknowledged. This alone does not guarantee that old duplicate data acknowledged. This alone does not guarantee that old duplicate data
is drained from the net, so the sequence space has been made very is drained from the net, so the sequence space has been made very
large to reduce the probability that a wandering duplicate will cause large to reduce the probability that a wandering duplicate will cause
trouble upon arrival. At 2 megabits/sec. it takes 4.5 hours to use trouble upon arrival. At 2 megabits/sec. it takes 4.5 hours to use
up 2**32 octets of sequence space. Since the maximum segment up 2**32 octets of sequence space. Since the maximum segment
lifetime in the net is not likely to exceed a few tens of seconds, lifetime in the net is not likely to exceed a few tens of seconds,
skipping to change at page 19, line 46 skipping to change at page 19, line 17
connection! If the recovery occurs quickly enough, any old connection! If the recovery occurs quickly enough, any old
duplicates in the net bearing sequence numbers in the neighborhood of duplicates in the net bearing sequence numbers in the neighborhood of
S1 may arrive and be treated as new packets by the receiver of the S1 may arrive and be treated as new packets by the receiver of the
new incarnation of the connection. new incarnation of the connection.
The problem is that the recovering host may not know for how long it The problem is that the recovering host may not know for how long it
crashed nor does it know whether there are still old duplicates in crashed nor does it know whether there are still old duplicates in
the system from earlier connection incarnations. the system from earlier connection incarnations.
One way to deal with this problem is to deliberately delay emitting One way to deal with this problem is to deliberately delay emitting
segments for one MSL after recovery from a crash- this is the "quite segments for one MSL after recovery from a crash- this is the "quiet
time" specification. Hosts which prefer to avoid waiting are willing time" specification. Hosts which prefer to avoid waiting are willing
to risk possible confusion of old and new packets at a given to risk possible confusion of old and new packets at a given
destination may choose not to wait for the "quite time". destination may choose not to wait for the "quite time".
Implementors may provide TCP users with the ability to select on a Implementors may provide TCP users with the ability to select on a
connection by connection basis whether to wait after a crash, or may connection by connection basis whether to wait after a crash, or may
informally implement the "quite time" for all connections. informally implement the "quite time" for all connections.
Obviously, even where a user selects to "wait," this is not necessary Obviously, even where a user selects to "wait," this is not necessary
after the host has been "up" for at least MSL seconds. after the host has been "up" for at least MSL seconds.
To summarize: every segment emitted occupies one or more sequence To summarize: every segment emitted occupies one or more sequence
numbers in the sequence space, the numbers occupied by a segment are numbers in the sequence space, the numbers occupied by a segment are
"busy" or "in use" until MSL seconds have passed, upon crashing a "busy" or "in use" until MSL seconds have passed, upon crashing a
block of space-time is occupied by the octets of the last emitted block of space-time is occupied by the octets and SYN or FIN flags of
segment, if a new connection is started too soon and uses any of the the last emitted segment, if a new connection is started too soon and
sequence numbers in the space-time footprint of the last segment of uses any of the sequence numbers in the space-time footprint of the
the previous connection incarnation, there is a potential sequence last segment of the previous connection incarnation, there is a
number overlap area which could cause confusion at the receiver. potential sequence number overlap area which could cause confusion at
the receiver.
3.4. Establishing a connection 3.4. Establishing a connection
The "three-way handshake" is the procedure used to establish a The "three-way handshake" is the procedure used to establish a
connection. This procedure normally is initiated by one TCP and connection. This procedure normally is initiated by one TCP and
responded to by another TCP. The procedure also works if two TCP responded to by another TCP. The procedure also works if two TCP
simultaneously initiate the procedure. When simultaneous attempt simultaneously initiate the procedure. When simultaneous attempt
occurs, each TCP receives a "SYN" segment which carries no occurs, each TCP receives a "SYN" segment which carries no
acknowledgment after it has sent a "SYN". Of course, the arrival of acknowledgment after it has sent a "SYN". Of course, the arrival of
an old duplicate "SYN" segment can potentially make it appear, to the an old duplicate "SYN" segment can potentially make it appear, to the
skipping to change at page 22, line 19 skipping to change at page 21, line 25
2. SYN-SENT --> <SEQ=100><CTL=SYN> ... 2. SYN-SENT --> <SEQ=100><CTL=SYN> ...
3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT 3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT
4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED 4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ... 5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED 6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
7. ... <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED 7. ... <SEQ=100><ACK=301><CTL=SYN,ACK> --> ESTABLISHED
Simultaneous Connection Synchronization Simultaneous Connection Synchronization
Figure 6 Figure 6
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.
skipping to change at page 26, line 15 skipping to change at page 25, line 15
arrives which apparently is not intended for the current connection. arrives which apparently is not intended for the current connection.
A reset must not be sent if it is not clear that this is the case. A reset must not be sent if it is not clear that this is the case.
There are three groups of states: There are three groups of states:
1. If the connection does not exist (CLOSED) then a reset is sent 1. If the connection does not exist (CLOSED) then a reset is sent
in response to any incoming segment except another reset. In in response to any incoming segment except another reset. In
particular, SYNs addressed to a non-existent connection are particular, SYNs addressed to a non-existent connection are
rejected by this means. rejected by this means.
If the incoming segment has an ACK field, the reset takes its If the incoming segment has the ACK bit set, the reset takes its
sequence number from the ACK field of the segment, otherwise the sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment. of the sequence number and segment length of the incoming segment.
The connection remains in the CLOSED state. The connection remains in the CLOSED state.
2. If the connection is in any non-synchronized state (LISTEN, 2. If the connection is in any non-synchronized state (LISTEN,
SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges
something not yet sent (the segment carries an unacceptable ACK), something not yet sent (the segment carries an unacceptable ACK),
or if an incoming segment has a security level or compartment or if an incoming segment has a security level or compartment
which does not exactly match the level and compartment requested which does not exactly match the level and compartment requested
skipping to change at page 26, line 50 skipping to change at page 25, line 50
If the incoming segment has an ACK field, the reset takes its If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment. of the sequence number and segment length of the incoming segment.
The connection remains in the same state. The connection remains in the same state.
3. If the connection is in a synchronized state (ESTABLISHED, 3. If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or any unacceptable segment (out of window sequence number or
unacceptible acknowledgment number) must elicit only an empty unacceptable acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state. to be received, and the connection remains in the same state.
If an incoming segment has a security level, or compartment, or If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and precedence which does not exactly match the level, and
compartment, and precedence requested for the connection,a reset compartment, and precedence requested for the connection,a reset
is sent and connection goes to the CLOSED state. The reset takes is sent and the connection goes to the CLOSED state. The reset
its sequence number from the ACK field of the incoming segment. takes its sequence number from the ACK field of the incoming
segment.
Reset Processing Reset Processing
In all states except SYN-SENT, all reset (RST) segments are validated In all states except SYN-SENT, all reset (RST) segments are validated
by checking their SEQ-fields. A reset is valid if its sequence by checking their SEQ-fields. A reset is valid if its sequence
number is in the window. In the SYN-SENT state (a RST received in number is in the window. In the SYN-SENT state (a RST received in
response to an initial SYN), the RST is acceptable if the ACK field response to an initial SYN), the RST is acceptable if the ACK field
acknowledges the SYN. acknowledges the SYN.
The receiver of a RST first validates it, then changes state. If the The receiver of a RST first validates it, then changes state. If the
skipping to change at page 30, line 21 skipping to change at page 29, line 21
A connection attempt with mismatched security/compartment values or a A connection attempt with mismatched security/compartment values or a
lower precedence value must be rejected by sending a reset. lower precedence value must be rejected by sending a reset.
Rejecting a connection due to too low a precedence only occurs after Rejecting a connection due to too low a precedence only occurs after
an acknowledgment of the SYN has been received. an acknowledgment of the SYN has been received.
Note that TCP modules which operate only at the default value of Note that TCP modules which operate only at the default value of
precedence will still have to check the precedence of incoming precedence will still have to check the precedence of incoming
segments and possibly raise the precedence level they use on the segments and possibly raise the precedence level they use on the
connection. connection.
The security paramaters may be used even in a non-secure environment The security parameters may be used even in a non-secure environment
(the values would indicate unclassified data), thus hosts in non- (the values would indicate unclassified data), thus hosts in non-
secure environments must be prepared to receive the security secure environments must be prepared to receive the security
parameters, though they need not send them. parameters, though they need not send them.
3.7. Data Communication 3.7. 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.
skipping to change at page 30, line 50 skipping to change at page 29, line 50
data keeps track of the oldest unacknowledged sequence number in the data keeps track of the oldest unacknowledged sequence number in the
variable SND.UNA. If the data flow is momentarily idle and all data variable SND.UNA. If the data flow is momentarily idle and all data
sent has been acknowledged then the three variables will be equal. sent has been acknowledged then the three variables will be equal.
When the sender creates a segment and transmits it the sender When the sender creates a segment and transmits it the sender
advances SND.NXT. When the receiver accepts a segment it advances advances SND.NXT. When the receiver accepts a segment it advances
RCV.NXT and sends an acknowledgment. When the data sender receives RCV.NXT and sends an acknowledgment. When the data sender receives
an acknowledgment it advances SND.UNA. The extent to which the an acknowledgment it advances SND.UNA. The extent to which the
values of these variables differ is a measure of the delay in the values of these variables differ is a measure of the delay in the
communication. The amount by which the variables are advanced is the communication. The amount by which the variables are advanced is the
length of the data in the segment. Note that once in the ESTABLISHED length of the data and SYN or FIN flags in the segment. Note that
state all segments must carry current acknowledgment information. once in the ESTABLISHED state all segments must carry current
acknowledgment information.
The CLOSE user call implies a push function, as does the FIN control The CLOSE user call implies a push function, as does the FIN control
flag in an incoming segment. flag in an incoming segment.
Retransmission Timeout Retransmission Timeout
NOTE: TODO this needs to be updated in light of 1122 4.2.2.15 and
errata 573; this will be done as part of RFC 1122 incorporation into
this document.
Because of the variability of the networks that compose an Because of the variability of the networks that compose an
internetwork system and the wide range of uses of TCP connections the internetwork system and the wide range of uses of TCP connections the
retransmission timeout must be dynamically determined. One procedure retransmission timeout must be dynamically determined. One procedure
for determining a retransmission time out is given here as an for determining a retransmission timeout is given here as an
illustration. illustration.
An Example Retransmission Timeout Procedure An Example Retransmission Timeout Procedure
Measure the elapsed time between sending a data octet with a Measure the elapsed time between sending a data octet with a
particular sequence number and receiving an acknowledgment that particular sequence number and receiving an acknowledgment that
covers that sequence number (segments sent do not have to match covers that sequence number (segments sent do not have to match
segments received). This measured elapsed time is the Round Trip segments received). This measured elapsed time is the Round Trip
Time (RTT). Next compute a Smoothed Round Trip Time (SRTT) as: Time (RTT). Next compute a Smoothed Round Trip Time (SRTT) as:
skipping to change at page 33, line 32 skipping to change at page 32, line 34
many small segments when better performance is achieved using many small segments when better performance is achieved using
fewer large segments. fewer large segments.
One suggestion for avoiding small windows is for the receiver to One suggestion for avoiding small windows is for the receiver to
defer updating a window until the additional allocation is at defer updating a window until the additional allocation is at
least X percent of the maximum allocation possible for the least X percent of the maximum allocation possible for the
connection (where X might be 20 to 40). connection (where X might be 20 to 40).
Another suggestion is for the sender to avoid sending small Another suggestion is for the sender to avoid sending small
segments by waiting until the window is large enough before segments by waiting until the window is large enough before
sending data. If the the user signals a push function then the sending data. If the user signals a push function then the data
data must be sent even if it is a small segment. must be sent even if it is a small segment.
Note that the acknowledgments should not be delayed or unnecessary Note that the acknowledgments should not be delayed or unnecessary
retransmissions will result. One strategy would be to send an retransmissions will result. One strategy would be to send an
acknowledgment when a small segment arrives (with out updating the acknowledgment when a small segment arrives (with out updating the
window information), and then to send another acknowledgment with window information), and then to send another acknowledgment with
new window information when the window is larger. new window information when the window is larger.
The segment sent to probe a zero window may also begin a break up The segment sent to probe a zero window may also begin a break up
of transmitted data into smaller and smaller segments. If a of transmitted data into smaller and smaller segments. If a
segment containing a single data octet sent to probe a zero window segment containing a single data octet sent to probe a zero window
skipping to change at page 34, line 16 skipping to change at page 33, line 18
actively attempt to combine small window allocations into larger actively attempt to combine small window allocations into larger
windows, since the mechanisms for managing the window tend to lead windows, since the mechanisms for managing the window tend to lead
to many small windows in the simplest minded implementations. to many small windows in the simplest minded implementations.
3.8. Interfaces 3.8. Interfaces
There are of course two interfaces of concern: the user/TCP interface There are of course two interfaces of concern: the user/TCP interface
and the TCP/lower-level interface. We have a fairly elaborate model and the TCP/lower-level interface. We have a fairly elaborate model
of the user/TCP interface, but the interface to the lower level of the user/TCP interface, but the interface to the lower level
protocol module is left unspecified here, since it will be specified protocol module is left unspecified here, since it will be specified
in detail by the specification of the lowel level protocol. For the in detail by the specification of the lower level protocol. For the
case that the lower level is IP we note some of the parameter values case that the lower level is IP we note some of the parameter values
that TCPs might use. that TCPs might use.
3.8.1. User/TCP Interface 3.8.1. User/TCP Interface
The following functional description of user commands to the TCP is, The following functional description of user commands to the TCP is,
at best, fictional, since every operating system will have different at best, fictional, since every operating system will have different
facilities. Consequently, we must warn readers that different TCP facilities. Consequently, we must warn readers that different TCP
implementations may have different user interfaces. However, all implementations may have different user interfaces. However, all
TCPs must provide a certain minimum set of services to guarantee that TCPs must provide a certain minimum set of services to guarantee that
skipping to change at page 38, line 38 skipping to change at page 37, line 41
a PUSH is seen before the buffer is filled the buffer will be a PUSH is seen before the buffer is filled the buffer will be
returned partially filled and PUSH indicated. returned partially filled and PUSH indicated.
If there is urgent data the user will have been informed as If there is urgent data the user will have been informed as
soon as it arrived via a TCP-to-user signal. The receiving soon as it arrived via a TCP-to-user signal. The receiving
user should thus be in "urgent mode". If the URGENT flag is user should thus be in "urgent mode". If the URGENT flag is
on, additional urgent data remains. If the URGENT flag is off, on, additional urgent data remains. If the URGENT flag is off,
this call to RECEIVE has returned all the urgent data, and the this call to RECEIVE has returned all the urgent data, and the
user may now leave "urgent mode". Note that data following the user may now leave "urgent mode". Note that data following the
urgent pointer (non-urgent data) cannot be delivered to the urgent pointer (non-urgent data) cannot be delivered to the
user in the same buffer with preceeding urgent data unless the user in the same buffer with preceding urgent data unless the
boundary is clearly marked for the user. boundary is clearly marked for the user.
To distinguish among several outstanding RECEIVEs and to take To distinguish among several outstanding RECEIVEs and to take
care of the case that a buffer is not completely filled, the care of the case that a buffer is not completely filled, the
return code is accompanied by both a buffer pointer and a byte return code is accompanied by both a buffer pointer and a byte
count indicating the actual length of the data received. count indicating the actual length of the data received.
Alternative implementations of RECEIVE might have the TCP Alternative implementations of RECEIVE might have the TCP
allocate buffer storage, or the TCP might share a ring buffer allocate buffer storage, or the TCP might share a ring buffer
with the user. with the user.
skipping to change at page 41, line 9 skipping to change at page 40, line 16
The TCP calls on a lower level protocol module to actually send and The TCP calls on a lower level protocol module to actually send and
receive information over a network. One case is that of the ARPA receive information over a network. One case is that of the ARPA
internetwork system where the lower level module is the Internet internetwork system where the lower level module is the Internet
Protocol (IP) [2]. Protocol (IP) [2].
If the lower level protocol is IP it provides arguments for a type of If the lower level protocol is IP it provides arguments for a type of
service and for a time to live. TCP uses the following settings for service and for a time to live. TCP uses the following settings for
these parameters: these parameters:
Type of Service = Precedence: routine, Delay: normal, Throughput: Type of Service = Precedence: given by user, Delay: normal,
normal, Reliability: normal; or 00000000. Throughput: normal, Reliability: normal; or binary XXX00000, where
XXX are the three bits determining precedence, e.g. 000 means
routine precedence.
Time to Live = one minute, or 00111100. Time to Live = one minute, or 00111100.
Note that the assumed maximum segment lifetime is two minutes. Note that the assumed maximum segment lifetime is two minutes.
Here we explicitly ask that a segment be destroyed if it cannot Here we explicitly ask that a segment be destroyed if it cannot
be delivered by the internet system within one minute. be delivered by the internet system within one minute.
If the lower level is IP (or other protocol that provides this If the lower level is IP (or other protocol that provides this
feature) and source routing is used, the interface must allow the feature) and source routing is used, the interface must allow the
route information to be communicated. This is especially important route information to be communicated. This is especially important
so that the source and destination addresses used in the TCP checksum so that the source and destination addresses used in the TCP checksum
be the originating source and ultimate destination. It is also be the originating source and ultimate destination. It is also
important to preserve the return route to answer connection requests. important to preserve the return route to answer connection requests.
Any lower level protocol will have to provide the source address, Any lower level protocol will have to provide the source address,
destination address, and protocol fields, and some way to determine destination address, and protocol fields, and some way to determine
the "TCP length", both to provide the functional equivlent service of the "TCP length", both to provide the functional equivalent service
IP and to be used in the TCP checksum. of IP and to be used in the TCP checksum.
3.9. Event Processing 3.9. 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.
The activity of the TCP can be characterized as responding to events. The activity of the TCP can be characterized as responding to events.
The events that occur can be cast into three categories: user calls, The events that occur can be cast into three categories: user calls,
skipping to change at page 48, line 48 skipping to change at page 47, line 48
FIN-WAIT-2 STATE FIN-WAIT-2 STATE
Strictly speaking, this is an error and should receive a Strictly speaking, this is an error and should receive a
"error: connection closing" response. An "ok" response would "error: connection closing" response. An "ok" response would
be acceptable, too, as long as a second FIN is not emitted (the be acceptable, too, as long as a second FIN is not emitted (the
first FIN may be retransmitted though). first FIN may be retransmitted though).
CLOSE-WAIT STATE CLOSE-WAIT STATE
Queue this request until all preceding SENDs have been Queue this request until all preceding SENDs have been
segmentized; then send a FIN segment, enter CLOSING state. segmentized; then send a FIN segment, enter LAST-ACK state.
CLOSING STATE CLOSING STATE
LAST-ACK STATE LAST-ACK STATE
TIME-WAIT STATE TIME-WAIT STATE
Respond with "error: connection closing". Respond with "error: connection closing".
ABORT Call ABORT Call
CLOSED STATE (i.e., TCB does not exist) CLOSED STATE (i.e., TCB does not exist)
skipping to change at page 52, line 50 skipping to change at page 51, line 50
Return. Return.
third check for a SYN third check for a SYN
If the SYN bit is set, check the security. If the security/ If the SYN bit is set, check the security. If the security/
compartment on the incoming segment does not exactly match compartment on the incoming segment does not exactly match
the security/compartment in the TCB then send a reset and the security/compartment in the TCB then send a reset and
return. return.
<SEQ=SEG.ACK><CTL=RST> <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
If the SEG.PRC is greater than the TCB.PRC then if allowed If the SEG.PRC is greater than the TCB.PRC then if allowed
by the user and the system set TCB.PRC<-SEG.PRC, if not by the user and the system set TCB.PRC<-SEG.PRC, if not
allowed send a reset and return. allowed send a reset and return.
<SEQ=SEG.ACK><CTL=RST> <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
If the SEG.PRC is less than the TCB.PRC then continue. If the SEG.PRC is less than the TCB.PRC then continue.
Set RCV.NXT to SEG.SEQ+1, IRS is set to SEG.SEQ and any Set RCV.NXT to SEG.SEQ+1, IRS is set to SEG.SEQ and any
other control or text should be queued for processing later. other control or text should be queued for processing later.
ISS should be selected and a SYN segment sent of the form: ISS should be selected and a SYN segment sent of the form:
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK> <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
SND.NXT is set to ISS+1 and SND.UNA to ISS. The connection SND.NXT is set to ISS+1 and SND.UNA to ISS. The connection
skipping to change at page 54, line 5 skipping to change at page 53, line 5
If the ACK bit is set If the ACK bit is set
If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset
(unless the RST bit is set, if so drop the segment and (unless the RST bit is set, if so drop the segment and
return) return)
<SEQ=SEG.ACK><CTL=RST> <SEQ=SEG.ACK><CTL=RST>
and discard the segment. Return. and discard the segment. Return.
If SND.UNA =< SEG.ACK =< SND.NXT then the ACK is If SND.UNA < SEG.ACK =< SND.NXT then the ACK is
acceptable. acceptable. (TODO: in processing Errata ID 3300, it was
noted that some stacks in the wild that do not send data
on the SYN are just checking that SEG.ACK == SND.NXT ...
think about whether anything should be said about that
here)
second check the RST bit second check the RST bit
If the RST bit is set If the RST bit is set
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.
skipping to change at page 55, line 28 skipping to change at page 54, line 33
and send it. Data or controls which were queued for and send it. Data or controls which were queued for
transmission may be included. If there are other controls transmission may be included. If there are other controls
or text in the segment then continue processing at the sixth or text in the segment then continue processing at the sixth
step below where the URG bit is checked, otherwise return. step below where the URG bit is checked, otherwise return.
Otherwise enter SYN-RECEIVED, form a SYN,ACK segment Otherwise enter SYN-RECEIVED, form a SYN,ACK segment
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK> <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
and send it. If there are other controls or text in the and send it. Set the variables:
segment, queue them for processing after the ESTABLISHED
state has been reached, return. SND.WND <- SEG.WND
SND.WL1 <- SEG.SEQ
SND.WL2 <- SEG.ACK
If there are other controls or text in the segment, queue
them for processing after the ESTABLISHED state has been
reached, return.
fifth, if neither of the SYN or RST bits is set then drop the fifth, if neither of the SYN or RST bits is set then drop the
segment and return. segment and return.
Otherwise, Otherwise,
first check sequence number first check sequence number
SYN-RECEIVED STATE SYN-RECEIVED STATE
ESTABLISHED STATE ESTABLISHED STATE
skipping to change at page 56, line 42 skipping to change at page 56, line 5
After sending the acknowledgment, drop the unacceptable After sending the acknowledgment, drop the unacceptable
segment and return. segment and return.
In the following it is assumed that the segment is the In the following it is assumed that the segment is the
idealized segment that begins at RCV.NXT and does not exceed idealized segment that begins at RCV.NXT and does not exceed
the window. One could tailor actual segments to fit this the window. One could tailor actual segments to fit this
assumption by trimming off any portions that lie outside the assumption by trimming off any portions that lie outside the
window (including SYN and FIN), and only processing further window (including SYN and FIN), and only processing further
if the segment then begins at RCV.NXT. Segments with higher if the segment then begins at RCV.NXT. Segments with higher
begining sequence numbers may be held for later processing. beginning sequence numbers should be held for later
processing.
second check the RST bit, second check the RST bit,
SYN-RECEIVED STATE SYN-RECEIVED STATE
If the RST bit is set If the RST bit is set
If this connection was initiated with a passive OPEN If this connection was initiated with a passive OPEN
(i.e., came from the LISTEN state), then return this (i.e., came from the LISTEN state), then return this
connection to LISTEN state and return. The user need connection to LISTEN state and return. The user need
not be informed. If this connection was initiated not be informed. If this connection was initiated
with an active OPEN (i.e., came from SYN-SENT state) with an active OPEN (i.e., came from SYN-SENT state)
then the connection was refused, signal the user then the connection was refused, signal the user
"connection refused". In either case, all segments on "connection refused". In either case, all segments on
the retransmission queue should be removed. And in the retransmission queue should be removed. And in
the active OPEN case, enter the CLOSED state and the active OPEN case, enter the CLOSED state and
delete the TCB, and return. delete the TCB, and return.
skipping to change at page 57, line 41 skipping to change at page 57, line 5
delete the TCB, and return. delete the TCB, and return.
third check security and precedence third check security and precedence
SYN-RECEIVED SYN-RECEIVED
If the security/compartment and precedence in the segment If the security/compartment and precedence in the segment
do not exactly match the security/compartment and do not exactly match the security/compartment and
precedence in the TCB then send a reset, and return. precedence in the TCB then send a reset, and return.
ESTABLISHED STATE ESTABLISHED
FIN-WAIT-1
FIN-WAIT-2
CLOSE-WAIT
CLOSING
LAST-ACK
TIME-WAIT
If the security/compartment and precedence in the segment If the security/compartment and precedence in the segment
do not exactly match the security/compartment and do not exactly match the security/compartment and
precedence in the TCB then send a reset, any outstanding precedence in the TCB then send a reset, any outstanding
RECEIVEs and SEND should receive "reset" responses. All RECEIVEs and SEND should receive "reset" responses. All
segment queues should be flushed. Users should also segment queues should be flushed. Users should also
receive an unsolicited general "connection reset" signal. receive an unsolicited general "connection reset" signal.
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
skipping to change at page 58, line 21 skipping to change at page 57, line 37
SYN-RECEIVED SYN-RECEIVED
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 is in the window it is an error, send a reset, 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).
skipping to change at page 58, line 35 skipping to change at page 58, line 4
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
SYN-RECEIVED STATE SYN-RECEIVED STATE
If SND.UNA =< SEG.ACK =< SND.NXT then enter If SND.UNA < SEG.ACK =< SND.NXT then enter ESTABLISHED
ESTABLISHED state and continue processing. state and continue processing with variables below set
to:
SND.WND <- SEG.WND
SND.WL1 <- SEG.SEQ
SND.WL2 <- SEG.ACK
If the segment acknowledgment is not acceptable, If the segment acknowledgment is not acceptable,
form a reset segment, form a reset segment,
<SEQ=SEG.ACK><CTL=RST> <SEQ=SEG.ACK><CTL=RST>
and send it. and send it.
ESTABLISHED STATE ESTABLISHED STATE
If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <-
SEG.ACK. Any segments on the retransmission queue SEG.ACK. Any segments on the retransmission queue
which are thereby entirely acknowledged are removed. which are thereby entirely acknowledged are removed.
Users should receive positive acknowledgments for Users should receive positive acknowledgments for
buffers which have been SENT and fully acknowledged buffers which have been SENT and fully acknowledged
(i.e., SEND buffer should be returned with "ok" (i.e., SEND buffer should be returned with "ok"
response). If the ACK is a duplicate (SEG.ACK < response). If the ACK is a duplicate (SEG.ACK =<
SND.UNA), it can be ignored. If the ACK acks SND.UNA), it can be ignored. If the ACK acks
something not yet sent (SEG.ACK > SND.NXT) then send something not yet sent (SEG.ACK > SND.NXT) then send
an ACK, drop the segment, and return. an ACK, drop the segment, and return.
If SND.UNA < SEG.ACK =< SND.NXT, the send window If SND.UNA =< SEG.ACK =< SND.NXT, the send window
should be updated. If (SND.WL1 < SEG.SEQ or (SND.WL1 should be updated. If (SND.WL1 < SEG.SEQ or (SND.WL1
= SEG.SEQ and SND.WL2 =< SEG.ACK)), set SND.WND <- = SEG.SEQ and SND.WL2 =< SEG.ACK)), set SND.WND <-
SEG.WND, set SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.WND, set SND.WL1 <- SEG.SEQ, and set SND.WL2 <-
SEG.ACK. SEG.ACK.
Note that SND.WND is an offset from SND.UNA, that Note that SND.WND is an offset from SND.UNA, that
SND.WL1 records the sequence number of the last SND.WL1 records the sequence number of the last
segment used to update SND.WND, and that SND.WL2 segment used to update SND.WND, and that SND.WL2
records the acknowledgment number of the last segment records the acknowledgment number of the last segment
used to update SND.WND. The check here prevents using used to update SND.WND. The check here prevents using
skipping to change at page 61, line 7 skipping to change at page 60, line 30
or the segment is empty. If the segment empties and or the segment is empty. If the segment empties and
carries an PUSH flag, then the user is informed, when the carries an PUSH flag, then the user is informed, when the
buffer is returned, that a PUSH has been received. buffer is returned, that a PUSH has been received.
When the TCP takes responsibility for delivering the data When the TCP takes responsibility for delivering the data
to the user it must also acknowledge the receipt of the to the user it must also acknowledge the receipt of the
data. data.
Once the TCP takes responsibility for the data it Once the TCP takes responsibility for the data it
advances RCV.NXT over the data accepted, and adjusts advances RCV.NXT over the data accepted, and adjusts
RCV.WND as apporopriate to the current buffer RCV.WND as appropriate to the current buffer
availability. The total of RCV.NXT and RCV.WND should availability. The total of RCV.NXT and RCV.WND should
not be reduced. not be reduced.
Please note the window management suggestions in section Please note the window management suggestions in section
3.7. 3.7.
Send an acknowledgment of the form: Send an acknowledgment of the form:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
skipping to change at page 69, line 51 skipping to change at page 68, line 51
urgent pointer urgent pointer
A control field meaningful only when the URG bit is on. This A control field meaningful only when the URG bit is on. This
field communicates the value of the urgent pointer which field communicates the value of the urgent pointer which
indicates the data octet associated with the sending user's indicates the data octet associated with the sending user's
urgent call. urgent call.
4. Changes from RFC 793 4. Changes from RFC 793
TODO: this entire section will need to be edited and condensed before TODO: this entire section will need to be edited and condensed before
the document is finalized. It currently represents a plan for future the document is finalized. It currently represents a plan for future
updates. updates mixed with notes on what changes have already been completed.
The -00 version of this document was merely a proposal and rough plan It should likely be an appendix, and in the final RFC, only the
for updating RFC 793. changes should be listed, and not what particular revision of the I-D
they were made within.
The -00 revision of this document was merely a proposal and rough
plan for updating RFC 793.
The -01 revision of this document incorporates the content of RFC 793 The -01 revision of this document incorporates the content of RFC 793
Section 3 titled "FUNCTIONAL SPECIFICATION". Other content from RFC Section 3 titled "FUNCTIONAL SPECIFICATION". Other content from RFC
793 has not been incorporated. The -01 revision of this document 793 has not been incorporated. The -01 revision of this document
makes some minor formatting changes to the RFC 793 content in order makes some minor formatting changes to the RFC 793 content in order
to convert the content into XML2RFC format and account for left-out to convert the content into XML2RFC format and account for left-out
parts of RFC 793. For instance, figure numbering differs and some parts of RFC 793. For instance, figure numbering differs and some
indentation is not exactly the same. indentation is not exactly the same.
TODO: Incomplete list of changes - these need to be added to and made The -02 revision of this document incorporates errata that have been
more specific, as the document proceeds: verified:
1. incorporate the accepted errata
2. incorporate 1122 additions
3. point to major additional docs like 1323bis and 5681
4. incorporate relevant parts of 3168 (ECN) Errata ID 573: Reported by Bob Braden (note: This errata basically
is just a reminder that RFC 1122 updates 793. Some of the
associated changes are left pending to a separate revision that
incorporates 1122. Bob's mention of PUSH in 793 section 2.8 was
not applicable here because that section was not part of the
"functional specification" and the note on the urgent pointer will
be revised when changes to account for RFC 6093 are incorporated.
Also the 1122 text on the retransmission timeout also has been
updated by subsequent RFCs, so the change here deviates from Bob's
suggestion to apply the 1122 text.)
Errata ID 574: Reported by Yin Shuming
Errata ID 700: Reported by Yin Shuming
Errata ID 701: Reported by Yin Shuming
Errata ID 1283: Reported by Pei-chun Cheng
Errata ID 1561: Reported by Constantin Hagemeier
Errata ID 1562: Reported by Constantin Hagemeier
Errata ID 1564: Reported by Constantin Hagemeier
Errata ID 1565: Reported by Constantin Hagemeier
Errata ID 1571: Reported by Constantin Hagemeier
Errata ID 1572: Reported by Constantin Hagemeier
Errata ID 2296: Reported by Vishwas Manral
Errata ID 2297: Reported by Vishwas Manral
Errata ID 2298: Reported by Vishwas Manral
Errata ID 2748: Reported by Mykyta Yevstifeyev
Errata ID 2749: Reported by Mykyta Yevstifeyev
Errata ID 2934: Reported by Constantin Hagemeier
Errata ID 3213: Reported by EugnJun Yi
Errata ID 3300: Reported by Botong Huang
Errata ID 3301: Reported by Botong Huang
Note: Some verified errata were not used in this update, as they
relate to sections of RFC 793 elided from this document. These
include Errata ID 572, 575, and 1569.
Note: Errata ID 3602 was not applied in this revision as it is
duplicative of the 1122 corrections.
There is an errata 3305 currently reported that need to be
verified, held, or rejected by the ADs; it is addressing the same
issue as draft-gont-tcpm-tcp-seq-validation and was not attempted
to be applied to this document.
5. incorporate 6093 (urgent pointer) Not related to RFC 793 content, this revision also makes small tweaks
to the introductory text, fixes indentation of the pseudoheader
diagram, and notes that the Security Considerations should also
include privacy, when this section is written.
6. incorporate 6528 (sequence number) TODO: Incomplete list of planned changes - these need to be added to
and made more specific, as the document proceeds:
7. incorporate Fernando's new number-checking fixes (if past the 1. incorporate 1122 additions
2. point to major additional docs like 1323bis and 5681
3. incorporate relevant parts of 3168 (ECN)
4. incorporate 6093 (urgent pointer)
5. incorporate 6528 (sequence number)
6. incorporate Fernando's new number-checking fixes (if past the
IESG in time) IESG in time)
7. point to PMTUD?
8. point to PMTUD? 8. point to 5461 (soft errors)
9. mention 5961 state machine option
9. point to 5461 (soft errors) 10. mention 6161 (reducing TIME-WAIT)
11. incorporate 6429 (ZWP/persist)
10. mention 5961 state machine option 12. incorporate 6691 (MSS)
11. mention 6161 (reducing TIME-WAIT)
12. incorporate 6429 (ZWP/persist)
13. incorporate 6691 (MSS)
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 Considerations 6. Security and Privacy Considerations
TODO TODO
Editor's Note: Scott Brim mentioned that this should include a
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.
Andre Oppermann was a contributor and helped to edit the first Andre Oppermann was a contributor and helped to edit the first
revision of this document. revision of this document.
We are thankful for the assistance of the IETF TCPM working group We are thankful for the assistance of the IETF TCPM working group
skipping to change at page 71, line 31 skipping to change at page 71, line 27
Michael Scharf Michael Scharf
Yoshifumi Nishida Yoshifumi Nishida
Pasi Sarolahti Pasi Sarolahti
On the TCPM mailing list, and at the IETF 88 meeting in Vancouver, On the TCPM mailing list, and at the IETF 88 meeting in Vancouver,
helpful comments, critiques, and reviews were received from (listed helpful comments, critiques, and reviews were received from (listed
alphebetically): David Borman, Yuchung Cheng, Martin Duke, Kevin alphebetically): David Borman, Yuchung Cheng, Martin Duke, Kevin
Lahey, Kevin Mason, Matt Mathis, Hagen Paul Pfeifer, Anthony Lahey, Kevin Mason, Matt Mathis, Hagen Paul Pfeifer, Anthony
Sabatini, Joe Touch, Reji Varghese, Lloyd Wood, and Alex Zimmermann. Sabatini, Joe Touch, Reji Varghese, Lloyd Wood, and Alex Zimmermann.
This document includes content from errata that were reported by
(listed chronologically): Yin Shuming, Bob Braden, Morris M. Keesan,
Pei-chun Cheng, Constantin Hagemeier, Vishwas Manral, Mykyta
Yevstifeyev, EungJun Yi, Botong Huang.
8. References 8. References
8.1. Normative References 8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate [1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC [2] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[3] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. [3] 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", draft-ietf-tcpm-tcp- (TCP) Specification Documents", draft-ietf-tcpm-tcp-
rfc4614bis-00 (work in progress), August 2013. rfc4614bis-00 (work in progress), August 2013.
Author's Address Author's Address
Wesley M. Eddy
Wesley M. Eddy (editor)
MTI Systems MTI Systems
US US
Email: wes@mti-systems.com Email: wes@mti-systems.com
 End of changes. 71 change blocks. 
129 lines changed or deleted 225 lines changed or added

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