errata logo graphic

Found 34 records.

Status: Verified (10)

RFC0793, "Transmission Control Protocol", September 1981

Source of RFC: Legacy
Area Assignment: tsv

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 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

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

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

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

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"


Status: Reported (1)

RFC0793, "Transmission Control Protocol", September 1981

Source of RFC: Legacy
Area Assignment: tsv

Errata ID: 3305

Status: Reported
Type: Technical

Reported By: Botong Huang
Date Reported: 2012-07-31

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

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.


Status: Held for Document Update (13)

RFC0793, "Transmission Control Protocol", September 1981

Source of RFC: Legacy
Area Assignment: tsv

Errata ID: 1561

Status: Held for Document Update
Type: Technical

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

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

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

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

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

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: 2296

Status: Held for Document Update
Type: Editorial

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

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

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

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

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

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

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"


Status: Rejected (10)

RFC0793, "Transmission Control Protocol", September 1981

Source of RFC: Legacy
Area Assignment: tsv

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.


Errata ID: 1496

Status: Rejected
Type: Technical

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

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

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

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

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

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

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

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

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.


Report New Errata