RFC Errata
Found 11 records.
Status: Verified (11)
RFC 793, "Transmission Control Protocol", September 1981
Note: This RFC has been obsoleted by RFC 9293
Note: This RFC has been updated by RFC 1122, RFC 3168, RFC 6093, RFC 6528
Source of RFC: LegacyArea Assignment: tsv
Errata ID: 573
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Braden
Date Reported: 2007-02-22
A number of details in RFC 793 were corrected, modified, or clarified in RFC 1122. Familiarity with RFC 1122 and more recent TCP documents is imperative before any implementation of RFC 793 is attempted.
TCP Feature RFC 793 Ref See RFC 1122 Section Received PUSH bit Section 2.8 4.2.2.2 Urgent Pointer Section 3.1 4.2.2.4 TCP state diagram Section 3.2, p.23 4.2.2.8 Simultaneous Open Section 3.4, Fig 8 4.2.2.10 Retransmission Timeout Section 3.7 4.2.2.15, 4.2.3.1 Event Processing Section 3.9 4.2.2.20
Errata ID: 1562
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Verifier Name: Wes Eddy
Date Verified: 2011-08-13
Section 3.3 says:
Remember that each segment is bound to as many consecutive sequence numbers as there are octets of data in the segment. ... the numbers occupied by a segment are "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 segment,
It should say:
Remember that each segment is bound to as many consecutive sequence numbers as there are octets of data and SYN or FIN flags in the segment. ... the numbers occupied by a segment are "busy" or "in use" until MSL seconds have passed, upon crashing a block of space-time is occupied by the octets and SYN or FIN flags of the last emitted segment,
Notes:
I changed this text to specifically include the SYN and FIN bits, rather than the previous errata wording which was unclear since other control flags are not part of the sequence space, based on discussion on the TCPM mailing list which indicated that the prior wording was confusing.
Errata ID: 1564
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Verifier Name: Wes Eddy
Date Verified: 2011-08-13
Section 3.7 says:
When the sender creates a segment and transmits it the sender advances SND.NXT. When the receiver accepts a segment it advances RCV.NXT and sends an acknowledgment. When the data sender receives an acknowledgment it advances SND.UNA. The extent to which 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 length of the data in the segment. Note that once in the ESTABLISHED state all segments must carry current acknowledgment information.
It should say:
When the sender creates a segment and transmits it the sender advances SND.NXT. When the receiver accepts a segment it advances RCV.NXT and sends an acknowledgment. When the data sender receives an acknowledgment it advances SND.UNA. The extent to which 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 length of the data and SYN or FIN flags in the segment. Note that once in the ESTABLISHED state all segments must carry current acknowledgment information.
Notes:
SYN and FIN are counted, too
Errata ID: 1572
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Verifier Name: Wes Eddy
Date Verified: 2011-08-13
Section 3.4 says:
If the incoming segment has an ACK field, the reset takes its 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 of the sequence number and segment length of the incoming segment.
It should say:
If the incoming segment has the ACK bit set, the reset takes its 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 of the sequence number and segment length of the incoming segment.
Notes:
Every segment has an ACK field.
Errata ID: 572
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Section 2.1 says:
The format of data blocks exchanged within the a network will generally not be of concern to us.
It should say:
The format of data blocks exchanged within the network will generally not be of concern to us.
Notes:
from pending
Errata ID: 574
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yin Shuming
Date Reported: 2005-05-22
In Section 3.7, page 43, it says:
If the the user signals a push function then the
data must be sent even if it is a small segment.
It should say:
If the user signals a push function then the
data must be sent even if it is a small segment.
Errata ID: 575
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Morris M. Keesan
Date Reported: 2003-10-29
Section 2.7 says:
If there are several pending passive OPENs (recorded in TCBs) with the
same local socket, an foreign active OPEN ...
It should say:
If there are several pending passive OPENs (recorded in TCBs) with
the same local socket, a foreign active OPEN ...
Errata ID: 700
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Section 3.7 says:
One procedure for determining a retransmission time out is given here as an illustration.
It should say:
One procedure for determining a retransmission timeout is given here as an illustration.
Notes:
from pending
Errata ID: 701
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Section 3.8 says:
since it will be specified in detail by the specification of the lowel level protocol.
It should say:
since it will be specified in detail by the specification of the lower level protocol.
Notes:
from pending
Errata ID: 1283
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pei-chun Cheng
Date Reported: 2008-01-14
Verifier Name: Lars Eggert
Date Verified: 2009-02-16
Section 3.3 says:
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
time" specification. Hosts which prefer to avoid waiting are
willing to risk possible confusion of old and new packets at a given
destination may choose not to wait for the "quite time".
Implementors may provide TCP users with the ability to select on a
connection by connection basis whether to wait after a crash, or may
informally implement the "quite time" for all connections.
Obviously, even where a user selects to "wait," this is not
necessary after the host has been "up" for at least MSL seconds.
It should say:
One way to deal with this problem is to deliberately delay emitting
segments for one MSL after recovery from a crash- this is the "quiet
time" specification. Hosts which prefer to avoid waiting are
willing to risk possible confusion of old and new packets at a given
destination may choose not to wait for the "quiet time".
Implementors may provide TCP users with the ability to select on a
connection by connection basis whether to wait after a crash, or may
informally implement the "quiet time" for all connections.
Obviously, even where a user selects to "wait," this is not
necessary after the host has been "up" for at least MSL seconds.
Notes:
"quite time" should be "quiet time"
Errata ID: 6775
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eugene Adell
Date Reported: 2021-12-05
Verifier Name: RFC Editor
Date Verified: 2021-12-06
Section 3.3 says:
Note that when the receive window is zero no segments should be acceptable except ACK segments. Thus, it is be possible for a TCP to maintain a zero receive window while transmitting data and receiving ACKs. However, even when the receive window is zero, a TCP must process the RST and URG fields of all incoming segments.
It should say:
Note that when the receive window is zero no segments should be acceptable except ACK segments. Thus, it is possible for a TCP to maintain a zero receive window while transmitting data and receiving ACKs. However, even when the receive window is zero, a TCP must process the RST and URG fields of all incoming segments.
Notes:
s/it is be/it is/