|
|
|
|
Found 21 records.
Source of RFC: Legacy
Errata ID: 573
Status: Verified
Type: Technical
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 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: 572
Status: Verified
Type: Editorial
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
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
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
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
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
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"
Source of RFC: Legacy
Errata ID: 1496
Status: Reported
Type: Technical
Reported By: Yin Shuming
Date Reported: 2008-08-27
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".
Errata ID: 1561
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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: 1562
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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 implicitly included control 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 implicitly included control flags of the last emitted segment,
Errata ID: 1563
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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 unacceptibla -> 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.
Errata ID: 1564
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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 imlicitly included control 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: 1565
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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: 1566
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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?
Errata ID: 1567
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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?
Errata ID: 1568
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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.
Errata ID: 1569
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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: 1570
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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.
Errata ID: 1571
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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: 1572
Status: Reported
Type: Technical
Reported By: Constantin Hagemeier
Date Reported: 2008-10-11
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.
Source of RFC: Legacy
Errata ID: 784
Status: Rejected
Type: Technical
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.