RFC Errata
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: 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.