RFC Errata
Found 47 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/
Status: Held for Document Update (24)
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: 1561
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Held for Document Update by: Wes Eddy
Section 3.2 says:
LAST-ACK - represents waiting for an acknowledgment of the
connection termination request previously sent to the remote TCP
(which includes an acknowledgment of its connection termination
request).
It should say:
LAST-ACK - represents waiting for an acknowledgment of the
connection termination request previously sent to the remote TCP
(The connection termination request sent to the remote TCP included
an acknowledgment of the connection termination request sent from
the remote TCP).
Notes:
It is unclear what 'which' and 'its' refers to.
Errata ID: 1565
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Held for Document Update by: Wes Eddy
Section 3.8 says:
TCP/Lower-Level Interface
Type of Service = Precedence: routine, Delay: normal, Throughput:
normal, Reliability: normal; or 00000000.
It should say:
TCP/Lower-Level Interface
Type of Service = Precedence, Delay: normal, Throughput:
normal, Reliability: normal; or XXX00000.
where XXX are the three bits determining precedence, e.g. 000
means routine.
Notes:
The precedence is given by the user.
Errata ID: 1569
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Held for Document Update by: Wesley Eddy
Section 2.4 says:
The TCP/internet interface provides calls to send and receive datagrams addressed to TCP modules in hosts anywhere in the internet system.
It should say:
The TCP/internet interface provides calls to send datagrams addressed to and receive datagrams addressed from TCP modules in hosts anywhere in the internet system.
Notes:
scnr
Errata ID: 1571
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Held for Document Update by: Wesley Eddy
Section 3.1 says:
Maximum Segment Size Option Data: 16 bits
If this option is present, then it communicates the maximum
receive segment size at the TCP which sends this segment.
This field must only be sent in the initial connection request
(i.e., in segments with the SYN control bit set). If this
option is not used, any segment size is allowed.
It should say:
Maximum Segment Size Option Data: 16 bits
If this option is present, then it communicates the maximum
receive segment size at the TCP which sends this segment.
This field may be sent in the initial connection request
(i.e., in segments with the SYN control bit set) and must not
be sent in other segments. If this option is not used, any
segment size is allowed.
Notes:
'must only' is ambiguous or even senseless.
Errata ID: 3300
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Botong Huang
Date Reported: 2012-07-30
Held for Document Update by: Wes Eddy
Date Held: 2012-09-13
Section 3.9 says:
SEGMENT ARRIVES
SYN-SENT STATE
If the ACK bit is set
If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset (unless
the RST bit is set, if so drop the segment and return)
<SEQ=SEG.ACK><CTL=RST>
and discard the segment. Return.
If SND.UNA =< SEG.ACK =< SND.NXT then the ACK is acceptable.
It should say:
SEGMENT ARRIVES
SYN-SENT STATE
If the ACK bit is set
If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset (unless
the RST bit is set, if so drop the segment and return)
<SEQ=SEG.ACK><CTL=RST>
and discard the segment. Return.
If SND.UNA < SEG.ACK =< SND.NXT then the ACK is acceptable.
Notes:
In SYN-SENT, SND.UNA == ISS, so the first line is contradictory to the last.
Verifier Notes:
This is being Held for Document Update rather than Verified because technically the algorithm is still correct, as the first check against ISS will fail and cause a reset to be generated. The second sentence that has an off-by-one error appears to be merely a paraphrasing.
In practice today, much code seems to be simplifying further and checking that SEG.ACK == SND.NXT, for stacks that are not sending data on the SYN, so I do not believe this text is leading to any significant issue with bugs or interoperability in the wild.
Errata ID: 3301
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Botong Huang
Date Reported: 2012-07-30
Held for Document Update by: Wes Eddy
Date Held: 2012-09-13
Section 3.9 says:
SEGMENT ARRIVES
Otherwise (Other States)
fifth check the ACK field
p71
if the ACK bit is on
SYN-RECEIVED STATE
If SND.UNA =< SEG.ACK =< SND.NXT then enter ESTABLISHED state
and continue processing.
If the segment acknowledgment is not acceptable, form a
reset segment,
<SEQ=SEG.ACK><CTL=RST>
and send it.
It should say:
SEGMENT ARRIVES
Otherwise (Other States)
fifth check the ACK field
p71
if the ACK bit is on
SYN-RECEIVED STATE
If SND.UNA < SEG.ACK =< SND.NXT then enter ESTABLISHED state
and continue processing.
If the segment acknowledgment is not acceptable, form a
reset segment,
<SEQ=SEG.ACK><CTL=RST>
and send it.
Notes:
In SYN-RECEIVE, SND.UNA == ISS. When the first ACK arrive with SEG.ACK == SND.UNA, it should be not accepted and thus transfer to ESTABLISHED state. This doesn't seem to be in rfc1122. Not sure if it is reported somewhere.
Verifier Note:
The side sending generating a packet that would erroneously check out would either be in error itself for generating the packet (not following the standard), or the packet would be extremely old (from a prior connection), and the responses should generate RSTs. Existing code seems to already be implementing this correctly, so I do not think there is an interoperability issue.
Errata ID: 3305
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Botong Huang
Date Reported: 2012-07-31
Held for Document Update by: Martin Stiemerling
Date Held: 2015-03-24
Section 3.9 says:
p70
SEGMENT ARRIVES
Otherwise,
first check sequence number
SYN-RECEIVED STATE
ESTABLISHED STATE
FIN-WAIT-1 STATE
FIN-WAIT-2 STATE
CLOSE-WAIT STATE
CLOSING STATE
LAST-ACK STATE
TIME-WAIT STATE
Segments are processed in sequence. Initial tests on arrival
are used to discard old duplicates, but further processing is
done in SEG.SEQ order. If a segment's contents straddle the
boundary between old and new, only the new parts should be
processed.
There are four cases for the acceptability test for an incoming
segment:
Segment Receive Test
Length Window
------- ------- -------------------------------------------
0 0 SEG.SEQ = RCV.NXT
0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
>0 0 not acceptable
>0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
It should say:
Added my Martin Stiemerling (TSV AD): A document update will address this problem and the TCPM working is expected to find a solution.
Notes:
Not sure how to correct it systemmatically, so I just present the problem.
If in SYN-RECEIVED state, and received a SYN-ACK packet with no data as:
SEG.SEQ = IRS
SEG.ACK = ISS + 1
However in SYN-RECEIVED state, RCV.NXT = IRS + 1, which means the SYN-ACK packet will fail on the second test above. The SYN-ACK packet will be dropped and a ACK packet is sent in reply. As a result, we lost the SYN part, but it is fine because we've already received SYN packet once. However, we also lost the ACK part which is supposed to be the ACK of our SYN. Thus we will never reach the ESTABLISH state.
Errata ID: 4785
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sanjeev Ranot
Date Reported: 2016-08-20
Held for Document Update by: Mirja Kühlewind
Date Held: 2016-09-01
Section 3.9 p. 72 says:
If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored.
It should say:
If the ACK is a duplicate (SEG.ACK =< SND.UNA), it can be ignored except when equality is met, then window should be updated. This can happen when there are segments in flight but the receiver shrinks its RCV.BUF to drop all of them and send an ACK carrying zero window update. Upon its arrival at the sending TCP, condition SND.UNA = SEG.ACK is met and we must update SND.WND <- 0. Then sender starts persist timer for sending zero-window probes [Ref. RFC 1122 Section 4.2.2.17, page 92]
Notes:
The condition is corrected as Duplicate ACK in
RFC 1122, Section 4.2.2.20 (g) p. 94. Accordingly old text must be
modified and new text should also be present to support the corrected
condition in RFC 793.
This is one case where duplicate acknowledgment cannot be ignored. i.e.
when SEG.ACK == SND.UNA and advertised window in the incoming ACK is 0
in which case sender needs to :
1. update window
2. start persist timer
3. send zero window probe segments.
Note:
Such ACKs should not be called as duplicates as it fails condition (e)
of definition of "DUPLICATE ACKNOWLEDGMENT" in Ref 5681 Section 2, pg 4
Errata ID: 2296
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: Wes Eddy
Section 3 says:
The security paramaters may be used even in a non-secure environment (the values would indicate unclassified data), thus hosts in non-secure environments must be prepared to receive the security parameters, though they need not send them.
It should say:
The security parameters may be used even in a non-secure environment (the values would indicate unclassified data), thus hosts in non-secure environments must be prepared to receive the security parameters, though they need not send them.
Notes:
s/paramaters/parameters/
Errata ID: 2297
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: Wes Eddy
Section 3.8 says:
Any lower level protocol will have to provide the source address,
destination address, and protocol fields, and some way to determine
the "TCP length", both to provide the functional equivlent service
of IP and to be used in the TCP checksum.
It should say:
Any lower level protocol will have to provide the source address,
destination address, and protocol fields, and some way to determine
the "TCP length", both to provide the functional equivalent service
of IP and to be used in the TCP checksum.
Notes:
s/equivlent/equivalent/
Errata ID: 2298
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2010-06-03
Held for Document Update by: Wes Eddy
Section Page 74 says:
Once the TCP takes responsibility for the data it advances RCV.NXT over the data accepted, and adjusts RCV.WND as apporopriate to the current buffer availability
It should say:
Once the TCP takes responsibility for the data it advances RCV.NXT over the data accepted, and adjusts RCV.WND as appropriate to the current buffer availability
Notes:
s/apporopriate/appropriate/
Errata ID: 2748
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-13
Held for Document Update by: Wes Eddy
Section 2.8 says:
2.8. Data Communication The data that flows on a connection may be thought of as a stream of octets. The sending user indicates in each SEND call whether the data in that call (and any preceeding calls) should be immediately pushed through to the receiving user by the setting of the PUSH flag.
It should say:
2.8. Data Communication The data that flows on a connection may be thought of as a stream of octets. The sending user indicates in each SEND call whether the data in that call (and any preceding calls) should be immediately pushed through to the receiving user by the setting of the PUSH flag.
Notes:
s/preceeding/preceding
Errata ID: 2749
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-03-13
Held for Document Update by: Wes Eddy
Section 3.2 says:
NOTE BENE: this diagram is only a summary and must not be taken as the total specification.
It should say:
NOTA BENE: this diagram is only a summary and must not be taken as the total specification.
Notes:
The Latin phrase is correctly written 'Nota bene', but not 'Note bene'.
Errata ID: 2934
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Held for Document Update by: Wes Eddy
Date Held: 2011-08-13
Section 3.4 says:
Reset Generation
3. If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or
unacceptible acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state.
If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and compartment,
and precedence requested for the connection,a reset is sent and
connection goes to the CLOSED state. The reset takes its sequence
number from the ACK field of the incoming segment.
It should say:
Reset Generation
3. If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or
unacceptable acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state.
If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and compartment,
and precedence requested for the connection, a reset is sent and
the connection goes to the CLOSED state. The reset takes its sequence
number from the ACK field of the incoming segment.
Notes:
Editorial errors:
1. Typo unacceptible -> unacceptable
2. wrong spacing and missing 'the'
Errata ID: 3213
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yi, EungJun
Date Reported: 2012-05-05
Held for Document Update by: Barry Leiba
Section 3.9 says:
Segments with higher begining sequence numbers may be held for later processing.
It should say:
Segments with higher beginning sequence numbers may be held for later processing.
Notes:
"begning" should be "beginning"
Errata ID: 4314
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna Rao DTV
Date Reported: 2015-03-26
Held for Document Update by: Martin Stiemerling
Date Held: 2015-04-14
Section 3.3 says:
Since the maximum segment lifetime in the net is not likely to exceed a few tens of seconds, this is deemed ample protection for foreseeable nets, even if data rates escalate to l0's of megabits/sec. At 100 megabits/sec, the cycle time is 5.4 minutes which may be a little short, but still within reason.
It should say:
Since the maximum segment lifetime in the net is not likely to exceed a few tens of seconds, this is deemed ample protection for foreseeable nets, even if data rates escalate to 10's of megabits/sec. At 100 megabits/sec, the cycle time is 5.4 minutes which may be a little short, but still within reason.
Notes:
s/l0/10
Errata ID: 4566
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Welzl
Date Reported: 2015-12-16
Held for Document Update by: Martin Stiemerling
Date Held: 2015-12-16
Section 3.9 says:
If the segment empties and carries an PUSH flag,
It should say:
If the segment empties and carries a PUSH flag,
Errata ID: 4580
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masoud Valizadeh
Date Reported: 2016-01-05
Held for Document Update by: Martin Stiemerling
Date Held: 2016-01-12
Section 2.7 says:
This exchange has been termed a three-way hand shake.
It should say:
This exchange has been termed a three-way handshake.
Errata ID: 6305
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Shuo Chen
Date Reported: 2020-10-12
Held for Document Update by: Martin Duke
Date Held: 2020-10-12
Section 3.9 Page 67 says:
fourth check the SYN bit
This step should be reached only if the ACK is ok, or there is
no ACK, and it the segment did not contain a RST.
It should say:
fourth check the SYN bit
This step should be reached only if the ACK is ok, or there is
no ACK, and the segment did not contain a RST.
Notes:
In the last sentence, the 'it' in 'and it the segment' is redundant.
Errata ID: 6222
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Charles Deng
Date Reported: 2020-07-06
Held for Document Update by: Martin Duke
Date Held: 2020-07-07
Section 3.4 says:
7. SYN-SENT <-- <SEQ=400><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
8. ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK> --> ESTABLISHED
Recovery from Old Duplicate SYN
Figure 9.
It should say:
7. ESTABLISHED <-- <SEQ=400><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
8. ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK> --> ESTABLISHED
Recovery from Old Duplicate SYN
Figure 9.
Notes:
To align with figure 7 in the same section, after TCP A get the SYN+ACK from TCP B, TCP A should enter ESTABLISHED state instead stay in SYN-SENT state.
Errata ID: 6281
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Merlin Büge
Date Reported: 2020-09-06
Held for Document Update by: Martin Duke
Date Held: 2020-10-12
Section 3.4 says:
At line 4, TCP A responds with an empty segment containing an ACK for TCP B's SYN; and in line 5, TCP A sends some data. Note that the sequence number of the segment in line 5 is the same as in line 4 because the ACK does not occupy sequence number space (if it did, we would wind up ACKing ACK's!).
It should say:
At line 4, TCP A responds with an empty segment containing an ACK for TCP B's SYN; and in line 5, TCP A sends some data. Note that the sequence number of the segment in line 5 is the same as in line 4 because the ACK does not occupy sequence number space (if it did, we would wind up ACKing ACKs!).
Notes:
last line: "ACK's" -> "ACKs"
Errata ID: 6282
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Merlin Büge
Date Reported: 2020-09-06
Held for Document Update by: Martin Duke
Date Held: 2020-10-12
Section 3.3 says:
To avoid confusion we must prevent segments from one incarnation of a
connection from being used while the same sequence numbers may still
be present in the network from an earlier incarnation. We want to
assure this, even if a TCP crashes and loses all knowledge of the
sequence numbers it has been using. When new connections are created,
an initial sequence number (ISN) generator is employed which selects a
new 32 bit ISN. The generator is bound to a (possibly fictitious) 32
bit clock whose low order bit is incremented roughly every 4
microseconds. Thus, the ISN cycles approximately every 4.55 hours.
Since we assume that segments will stay in the network no more than
the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55
hours we can reasonably assume that ISN's will be unique.
For each connection there is a send sequence number and a receive
sequence number. The initial send sequence number (ISS) is chosen by
the data sending TCP, and the initial receive sequence number (IRS) is
learned during the connection establishing procedure.
For a connection to be established or initialized, the two TCPs must
synchronize on each other's initial sequence numbers. This is done in
an exchange of connection establishing segments carrying a control bit
called "SYN" (for synchronize) and the initial sequence numbers. As a
shorthand, segments carrying the SYN bit are also called "SYNs".
Hence, the solution requires a suitable mechanism for picking an
initial sequence number and a slightly involved handshake to exchange
the ISN's.
The synchronization requires each side to send it's own initial
sequence number and to receive a confirmation of it in acknowledgment
from the other side. Each side must also receive the other side's
initial sequence number and send a confirming acknowledgment.
1) A --> B SYN my sequence number is X
2) A <-- B ACK your sequence number is X
3) A <-- B SYN my sequence number is Y
4) A --> B ACK your sequence number is Y
Because steps 2 and 3 can be combined in a single message this is
called the three way (or three message) handshake.
A three way handshake is necessary because sequence numbers are not
tied to a global clock in the network, and TCPs may have different
mechanisms for picking the ISN's. The receiver of the first SYN has
no way of knowing whether the segment was an old delayed one or not,
unless it remembers the last sequence number used on the connection
(which is not always possible), and so it must ask the sender to
verify this SYN. The three way handshake and the advantages of a
clock-driven scheme are discussed in [3].
It should say:
To avoid confusion we must prevent segments from one incarnation of a
connection from being used while the same sequence numbers may still
be present in the network from an earlier incarnation. We want to
assure this, even if a TCP crashes and loses all knowledge of the
sequence numbers it has been using. When new connections are created,
an initial sequence number (ISN) generator is employed which selects a
new 32 bit ISN. The generator is bound to a (possibly fictitious) 32
bit clock whose low order bit is incremented roughly every 4
microseconds. Thus, the ISN cycles approximately every 4.55 hours.
Since we assume that segments will stay in the network no more than
the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55
hours we can reasonably assume that ISNs will be unique.
For each connection there is a send sequence number and a receive
sequence number. The initial send sequence number (ISS) is chosen by
the data sending TCP, and the initial receive sequence number (IRS) is
learned during the connection establishing procedure.
For a connection to be established or initialized, the two TCPs must
synchronize on each other's initial sequence numbers. This is done in
an exchange of connection establishing segments carrying a control bit
called "SYN" (for synchronize) and the initial sequence numbers. As a
shorthand, segments carrying the SYN bit are also called "SYNs".
Hence, the solution requires a suitable mechanism for picking an
initial sequence number and a slightly involved handshake to exchange
the ISNs.
The synchronization requires each side to send it's own initial
sequence number and to receive a confirmation of it in acknowledgment
from the other side. Each side must also receive the other side's
initial sequence number and send a confirming acknowledgment.
1) A --> B SYN my sequence number is X
2) A <-- B ACK your sequence number is X
3) A <-- B SYN my sequence number is Y
4) A --> B ACK your sequence number is Y
Because steps 2 and 3 can be combined in a single message this is
called the three way (or three message) handshake.
A three way handshake is necessary because sequence numbers are not
tied to a global clock in the network, and TCPs may have different
mechanisms for picking the ISNs. The receiver of the first SYN has
no way of knowing whether the segment was an old delayed one or not,
unless it remembers the last sequence number used on the connection
(which is not always possible), and so it must ask the sender to
verify this SYN. The three way handshake and the advantages of a
clock-driven scheme are discussed in [3].
Notes:
The only change: s/ISN's/ISNs/g
"ISN's" has three matches in the whole RFC, all of them in this section, and all matches refer to the plural form of ISN.
ISN stands for "initial sequence number".
Sorry for all the bulk text.
Errata ID: 6476
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-12
Held for Document Update by: Martin Duke
Date Held: 2021-03-16
Section 3.8 says:
connection.Implementers may want to give the user control of
It should say:
connection. Implementers may want to give the user control of
Notes:
Missing space. 793bis is in progress and this text no longer exists.
Errata ID: 6477
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Panchenko
Date Reported: 2021-03-12
Held for Document Update by: Martin Duke
Date Held: 2021-03-16
Section GLOSSARY says:
unit of data transfered between a pair of TCP modules.
It should say:
unit of data transferred between a pair of TCP modules.
Notes:
Misspelled "transferred".
(text does not exist in ongoing 793bis)
Status: Rejected (12)
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: 784
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ian D. Allen
Date Reported: 2006-09-22
Rejected by: Lars Eggert
Date Rejected: 2008-12-06
Section 3.2 says:
+---------+ ---------\ active OPEN
| CLOSED | \ -----------
+---------+<---------\ \ create TCB
| ^ \ \ snd SYN
passive OPEN | | CLOSE \ \
------------ | | ---------- \ \
create TCB | | delete TCB \ \
V | \ \
+---------+ CLOSE | \
| LISTEN | ---------- | |
+---------+ delete TCB | |
rcv SYN | | SEND | |
----------- | | ------- | V
+---------+ snd SYN,ACK / \ snd SYN +---------+
| |<----------------- ------------------>| |
| SYN | rcv SYN | SYN |
| RCVD |<-----------------------------------------------| SENT |
| | snd ACK | |
| |------------------ -------------------| |
+---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+
| -------------- | | -----------
| x | | snd ACK
| V V
| CLOSE +---------+
| ------- | ESTAB |
| snd FIN +---------+
| CLOSE | | rcv FIN
V ------- | | -------
+---------+ snd FIN / \ snd ACK +---------+
| FIN |<----------------- ------------------>| CLOSE |
| WAIT-1 |------------------ | WAIT |
+---------+ rcv FIN \ +---------+
| rcv ACK of FIN ------- | CLOSE |
| -------------- snd ACK | ------- |
V x V snd FIN V
+---------+ +---------+ +---------+
|FINWAIT-2| | CLOSING | | LAST-ACK|
+---------+ +---------+ +---------+
| rcv ACK of FIN | rcv ACK of FIN |
| rcv FIN -------------- | Timeout=2MSL -------------- |
| ------- x V ------------ x V
\ snd ACK +---------+delete TCB +---------+
------------------------>|TIME WAIT|------------------>| CLOSED |
+---------+ +---------+
TCP Connection State Diagram
Figure 6.
It should say:
[not supplied]
Notes:
Compare with RFC 1122:
" 4.2.2.8 TCP Connection State Diagram: RFC-793 Section 3.2,
page 23
There are several problems with this diagram:
(a) The arrow from SYN-SENT to SYN-RCVD should be labeled
with "snd SYN,ACK", to agree with the text on page 68
and with Figure 8."
Either RFC1122 is wrong (in which case *it* needs an Errata entry), or
RFC793 is wrong, in which case *it* needs an Errata entry. They can't
both be right!
Because of the above protocol diagram change given in RFC1122 (and others
in the same section), RFC1122 should also be mentioned as "updating"
RFC793, and RFC793 should be documented as being "updated by" RFC1122.
from pending
--VERIFIER NOTES--
The RFC Editor has been instructed to indicate in their database and web pages that RFC1122 updates RFC0793. This errata has hence been addressed.
Errata ID: 1496
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Yin Shuming
Date Reported: 2008-08-27
Rejected by: Wes Eddy
Date Rejected: 2011-08-13
Section 3.9 says:
CLOSE CALL
CLOSE-WAIT STATE
Queue this request until all preceding SENDs have been segmentized;then send a FIN segment,enter CLOSING state.
CLOSING STATE
LAST-ACK STATE
TIME-WAIT STATE
Respond with "error: connection closing".
It should say:
CLOSE CALL
CLOSE-WAIT STATE
Queue this request until all preceding SENDs have been segmentized;then send a FIN segment,enter LAST-ACK state.
CLOSING STATE
LAST-ACK STATE
TIME-WAIT STATE
Respond with "error: connection closing".
Notes:
In Page 23,Figure 6."TCP Connection State Diagram",illustrates the state change from "CLOSE-WAIT" TO "LAST-ACK",together with the causing event "CLOSE".
--VERIFIER NOTES--
RFC 1122 updates RFC 793 and includes the changes noted in this errata already in section 4.2.2.20.
Errata ID: 1563
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Rejected by: Wes Eddy
Date Rejected: 2011-08-13
Section 3.4 says:
Reset Generation
3. If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or
unacceptible acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state.
If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and compartment,
and precedence requested for the connection,a reset is sent and
connection goes to the CLOSED state. The reset takes its sequence
number from the ACK field of the incoming segment.
It should say:
Reset Generation
3. If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or
unacceptable acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state.
If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and compartment,
and precedence requested for the connection, a reset is sent and
the connection goes to the CLOSED state.
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.
A SYN with a sequence number inside the receive window yields a
reset, too.
Notes:
Four errors, two editorial and two technical
1. Typo unacceptible -> unacceptable
2. wrong spacing and missing 'the'
3. The ACK bit should be set. But this check comes later. See page 71.
4. According to page 71 a SYN can cause a reset, too.
--VERIFIER NOTES--
I split the editorial corrections into another errata report and accepted them as "hold for document update". The technical corrections are being rejected due to RFC 1122 updating 793 and already including clarification on setting SEQ=0 and ACK=SEG.SEQ+SEG.LEN, as suggested by this errata submission.
Errata ID: 1566
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Rejected by: Wes Eddy
Date Rejected: 2011-08-13
Section 3.9 says:
OPEN Call
LISTEN STATE
Data associated with SEND may be sent with SYN segment or
queued for transmission after entering ESTABLISHED state. The
urgent bit if requested in the command must be sent with the data
segments sent as a result of this command.
It should say:
OPEN Call
LISTEN STATE
--delete this--
Notes:
This is an OPEN call. There is no data associated with a SEND.
BTW, What WND to set in the SYN segment? Set RCV.WND=1?
--VERIFIER NOTES--
This is "may" and does not produce incorrect protocol behavior, so there is no reason to remove it. This rejection was validated through consulting with the TCPM list.
Errata ID: 1567
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Rejected by: Wesley Eddy
Date Rejected: 2012-05-29
Section 3.9 says:
SEND Call
LISTEN STATE
If the foreign socket is specified, then change the connection
from passive to active, select an ISS. Send a SYN segment, set
SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT state. Data
associated with SEND may be sent with SYN segment or queued for
transmission after entering ESTABLISHED state. The urgent bit if
requested in the command must be sent with the data segments sent
as a result of this command. If there is no room to queue the
request, respond with "error: insufficient resources". If
Foreign socket was not specified, then return "error: foreign
socket unspecified".
It should say:
SEND Call
LISTEN STATE
If the foreign socket is specified, then change the connection
from passive to active, select an ISS. Send a SYN segment, set
SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT state. Data
associated with SEND may be sent with SYN segment or queued for
transmission after entering ESTABLISHED state. If data is sent with
the SYN segment, SND.NXT is advanced. The urgent bit if
requested in the command must be sent with the data segments sent
as a result of this command. If there is no room to queue the
request, respond with "error: insufficient resources". If
Foreign socket was not specified, then return "error: foreign
socket unspecified".
Notes:
If data is sent, SND.NXT has to be advanced.
But there are more problems.
What WND to set in the SYN segment? Set RCV.WND=1?
How much data may be put into the segment? There is no SND.WND yet.
What about PUSH? May the data be queued if a PUSH is given?
--VERIFIER NOTES--
As discussed on the TCPM Working Group mailing list in 2012:
According to the errata, there is some ambiguity in RFC 793 regarding data in SYNs.
This requires changes beyond the suggested errata text, and thus we believe
this issue should be done in a separate RFC.
Errata ID: 1568
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Rejected by: Wesley Eddy
Date Rejected: 2012-05-29
Section 3.9 says:
SEGMENT ARRIVES
If the state is LISTEN then
third check for a SYN
The connection
state should be changed to SYN-RECEIVED. Note that any other
incoming control or data (combined with SYN) will be processed
in the SYN-RECEIVED state, but processing of SYN and ACK should
not be repeated.
fourth other text or control
Any other control or text-bearing segment (not containing SYN)
must have an ACK and thus would be discarded by the ACK
processing. An incoming RST segment could not be valid, since
it could not have been sent in response to anything sent by this
incarnation of the connection. So you are unlikely to get here,
If the state is SYN-SENT then
first check the ACK bit
If SND.UNA =< SEG.ACK =< SND.NXT then the ACK is acceptable.
fourth check the SYN bit
This step should be reached only if the ACK is ok, or there is
no ACK, and it the segment did not contain a RST.
If the SYN bit is on and the security/compartment and precedence
are acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to
SEG.SEQ.
...
Data or controls which were queued for
transmission may be included.
fifth, if neither of the SYN or RST bits is set then drop the
segment and return.
Otherwise,
third check security and precedence
fifth check the ACK field,
SYN-RECEIVED STATE
If SND.UNA =< SEG.ACK =< SND.NXT then enter ESTABLISHED state
and continue processing.
If the segment acknowledgment is not acceptable, form a
reset segment,
<SEQ=SEG.ACK><CTL=RST>
and send it.
ESTABLISHED STATE
If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- SEG.ACK.
Any segments on the retransmission queue which are thereby
entirely acknowledged are removed. Users should receive
positive acknowledgments for buffers which have been SENT and
fully acknowledged (i.e., SEND buffer should be returned with
"ok" response). If the ACK is a duplicate
(SEG.ACK < SND.UNA), it can be ignored. If the ACK acks
something not yet sent (SEG.ACK > SND.NXT) then send an ACK,
drop the segment, and return.
If SND.UNA < SEG.ACK =< SND.NXT, the send window should be
updated. If (SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and
SND.WL2 =< SEG.ACK)), set SND.WND <- SEG.WND, set
SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.ACK.
eighth, check the FIN bit,
Do not process the FIN if the state is CLOSED, LISTEN or SYN-SENT
since the SEG.SEQ cannot be validated; drop the segment and
return.
It should say:
SEGMENT ARRIVES
If the state is LISTEN then
third check for a SYN
??? No idea. But the original does not work.
If there is data in the SYN, we have a problem. We have to be
ESTABLISHED to get a buffer. And in ESTABLISHED the segment will be
dropped, because it has the ACK bit off.
We need to allocate a buffer. It's just for one segment. And we have
to adapt the event handling for the user's RECEIVE call. ???
fourth other text or control
Any other control or text-bearing segment (not containing SYN)
must have an ACK and thus would be discarded by the ACK
processing. So you are unlikely to get here,
If the state is SYN-SENT then
first check the ACK bit
If SND.UNA < SEG.ACK =< SND.NXT then the ACK is acceptable.
fourth check the SYN bit
This step should be reached only if the ACK is ok, or there is
no ACK, and if the segment did not contain a RST.
If the SYN bit is on, RCV.NXT is set to SEG.SEQ+1, IRS is set to
SEG.SEQ.
...
Data or controls which were queued for
transmission may be included and SND.NXT advanced accordingly.
fifth, because neither of the SYN or RST bits is set, drop the
segment and return.
Otherwise,
third check security and precedence
Construct the RST in this way:
If there is an ACK
<SEQ=SEG.ACK><CTL=RST>
Otherwise
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
fifth check the ACK field,
SYN-RECEIVED STATE
If SND.UNA < SEG.ACK =< SND.NXT then enter ESTABLISHED state, set
SND.WND <- SEG.WND, SND.WL1 <- SEG.SEQ, SND.WL2 <- SEG.ACK,
and continue processing.
If the segment acknowledgment is not acceptable
(SEG.ACK =< ISS or SEG.ACK > SND.NXT), form a
reset segment,
<SEQ=SEG.ACK><CTL=RST>
and send it.
Drop the segment. Return.
ESTABLISHED STATE
If the ACK is a duplicate (SEG.ACK =< SND.UNA), it can be
ignored. If the ACK acks something not yet sent
(SEG.ACK > SND.NXT) then send an ACK, drop the segment, and
return.
If SND.UNA =< SEG.ACK =< SND.NXT, the send window should be
updated. If (SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and
SND.WL2 =< SEG.ACK)), set SND.WND <- SEG.WND, set
SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.ACK.
If SND.UNA < SEG.ACK =< SND.NXT, then set SND.UNA <- SEG.ACK.
Any segments on the retransmission queue which are thereby
entirely acknowledged are removed. Users should receive
positive acknowledgments for buffers which have been SENT and
fully acknowledged (i.e., SEND buffer should be returned with
"ok" response).
eighth, check the FIN bit,
--delete this--
Notes:
If the state is LISTEN then
fourth other text or control
Incoming RST are already thrown out. Don't diskuss about it here.
If the state is SYN-SENT then
first check the ACK bit
nearly the same as the correction in RFC-1122 4.2.2.20(g)
fourth check the SYN bit
typo it -> if
security/compartment and precedence are already checked. It is no mistake,
but it is superfluous and confusing.
don't forget to advance SND.NXT
fifth
No more testing is necessary. Superfluous testing is confusing.
Otherwise,
third check security and precedence
The ACK bit is not yet checked.
fifth check the ACK field
SYN-RECEIVED STATE
SND.UNA == ISS. SEG.ACK == ISS does not ack our SYN.
SND.WND <- SEG.WND etc is corrected by RFC-1122.
explanation of not acceptable acknowledgment is helpful
'Drop the segment. Return.' is missing, too.
ESTABLISHED STATE
Corrections of RFC-1122 are included.
What about SEG.ACK =< ISS? I reccomend to send an ACK, drop the segment
and return. When SND.NXT overpaces ISS, ISS has to be adjusted somehow,
e.g. ISS <- ISS xor 0x80000000.
The updating of SND.UNA must be in the end, because the comparisations
need the old value of SND.UNA.
eighth, check the FIN bit,
If you are here, you are not in those states.
--VERIFIER NOTES--
As discussed on the TCPM Working Group mailing list in 2012:
This errata combines several different suggestions. Some of them repeat updates of RFC 1122,
some are subtle minor hints, and in some cases the errata does not propose better phrasing.
The errata cannot be accepted in this form. It might be worth to consider individual aspects
separately.
Errata ID: 1570
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
Rejected by: Wesley Eddy
Date Rejected: 2012-05-29
Section 2.7 says:
There are two principal cases for matching the sockets in the local passive OPENs and an foreign active OPENs. In the first case, the local passive OPENs has fully specified the foreign socket. In this case, the match must be exact. In the second case, the local passive OPENs has left the foreign socket unspecified. In this case, any foreign socket is acceptable as long as the local sockets match.
It should say:
There are two principal cases for matching the sockets in the local passive OPENs and a foreign active OPEN. In the first case, there is exactly one local passive OPEN with matching local socket that has fully specified the foreign socket. In this case, the match must be exact. In the second case, there is exactly one local passive OPEN with matching local socket that has left the foreign socket unspecified. In this case, any foreign socket is acceptable.
Notes:
In this passage singular or plural make a big difference.
--VERIFIER NOTES--
As discussed on the TCPM Working Group mailing list in 2012:
We believe that the original text is not confusing and a change of the meaning is not required.
Errata ID: 2771
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-04-08
Rejected by: Wes Eddy
Date Rejected: 2011-08-13
Throughout the document, when it says:
Notes:
RFC 793 has no regulations whether it should obsolete RFC 761, which, however, is logically obvious. RFC 761 (http://tools.ietf.org/html/rfc761) is the previous version of RFC 793 and, if this errata report is verified, should be marked as obsoleted by RFC 793.
--VERIFIER NOTES--
This is not a technical matter, and should refer to the RFC metadata rather than the document.
Errata ID: 3602
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Dahai Jiang
Date Reported: 2013-04-21
Rejected by: Martin Stiemerling
Date Rejected: 2014-04-16
Section 3.4 says:
5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
7. ... <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
Simultaneous Connection Synchronization
Figure 8.
It should say:
5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
7. ... <SEQ=100><ACK=301><CTL=SYN,ACK> --> ESTABLISHED
Simultaneous Connection Synchronization
Figure 8.
Notes:
--VERIFIER NOTES--
See errata 573. Already done, thanks.
Errata ID: 3972
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Scheffenegger
Date Reported: 2014-04-23
Rejected by: Martin Stiemerling
Date Rejected: 2014-04-24
Section 3.1 says:
Reserved: 6 bits
Reserved for future use. Must be zero.
It should say:
Reserved: 6 bits
Reserved for future use. SHOULD be zero.
Notes:
RFC3168 specifies 2 additional bits (ECE and CWR), RFC3540 specifies one additional bit (NS). Even though RFC793 predates RFC2119, and section 2.10 states
" be conservative in what you do, be liberal in what you accept from others.", any
update to this RFC should adjust the wording apropriately.
--VERIFIER NOTES--
The text is correct, as is. For implementations implementing RFC 793 purely the have to set this to zero.
Errata ID: 4753
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Sanjeev Ranot
Date Reported: 2016-07-30
Rejected by: Mirja Kühlewind
Date Rejected: 2016-09-14
Section 1.5 says:
A pair of sockets uniquely identifies each connection. That is, a socket may be simultaneously used in multiple connections
It should say:
A pair of sockets uniquely identifies each connection. Sockets can be classified into client and server sockets. Typically a server socket may be simultaneously used in multiple connections.
Notes:
TCP is connection oriented therefore when we say "sockets used in multiple connections" it implies that the context is TCP. Considering their use in TCP, though a single client socket can be implemented in a way to multiplex it for connection with multiple server sockets and exchange different SYN segments but then its same what a server process listening for connections on server port does typically.
I feel classification of sockets here is vital to facilitate understand implicitly that in what use-case can a socket be typically multiplexed while still keeping generality of the statement.
--VERIFIER NOTES--
TCP sockets don't have a client/server concept therefore this clarification is inappropriate.
Errata ID: 7051
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Merlin Büge
Date Reported: 2022-07-28
Rejected by: Martin Duke
Date Rejected: 2022-09-22
Section 3.9 says:
This step should be reached only if the ACK is ok, or there is
no ACK, and it the segment did not contain a RST.
It should say:
This step should be reached only if the ACK is ok, or there is
no ACK, and if the segment did not contain a RST.
Notes:
Page 67: it -> if.
this document has been obsoleted.
--VERIFIER NOTES--