RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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: Legacy
Area 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: Legacy
Area 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: Legacy
Area 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--

Report New Errata



Advanced Search