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

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.

Report New Errata