RFC Errata
Found 8 records.
Status: Verified (4)
RFC 9293, "Transmission Control Protocol (TCP)", August 2022
Source of RFC: tcpm (wit)
Errata ID: 8167
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Christopher Williams
Date Reported: 2024-11-04
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-19
Section 3.10.7.3 says:
o A potential blind reset attack is described in RFC 5961 [9].
The mitigation described in that document has specific
applicability explained therein, and is not a substitute for
cryptographic protection (e.g., IPsec or TCP-AO). A TCP
implementation that supports the mitigation described in RFC
5961 SHOULD first check that the sequence number exactly
matches RCV.NXT prior to executing the action in the next
paragraph.
It should say:
[ The text is removed - see notes]
Notes:
This entire bullet is removed as RFC 5961 adds no rules to the handling
of RST segments in the SYN-SENT state.
See the discussion here (https://mailarchive.ietf.org/arch/msg/tcpm/Y5feX5f1YA00gCUyb4yP4iNfdXs/)
Errata ID: 8171
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Christopher Williams
Date Reported: 2024-11-06
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-18
Section Appendix B says:
+-----------------+---------+------+--------+-----+--------+------+
| * Dest Unreach | SHLD-25 | X | | | | |
| (0,1,5) => | | | | | | |
| inform ALP | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
It should say:
+-----------------+---------+------+--------+-----+--------+------+
| * Dest Unreach | SHLD-25 | | X | | | |
| (0,1,5) => | | | | | | |
| inform ALP | | | | | | |
+-----------------+---------+------+--------+-----+--------+------+
Notes:
This requirement has an X in the "MUST" column, but the X should be in the "SHOULD" column.
The relevant text for this requirement is "a TCP implementation ... SHOULD make the information available to the application (SHLD-25)."
Errata ID: 8126
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: zhihua.li
Date Reported: 2024-10-01
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-18
Section 3.3.1 says:
the sequence space labeled 3 in Figure 3
It should say:
the sequence space labeled 2 and 3 in Figure 3
Notes:
In Figure 3, the send window shoud be 2(sequence numbers of unacknowledged data) and 3(sequence numbers allowed for new data transmission).
Errata ID: 8710
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Noga H. Rotman
Date Reported: 2026-01-21
Verifier Name: G Fairhurst
Date Verified: 2026-02-11
Section 3.3.2, Fig. 5 says:
Figure 5: rcv RST (note 1) Note 1: The transition from SYN-RECEIVED to LISTEN on receiving a RST is conditional on having reached SYN-RECEIVED after a passive OPEN.
It should say:
Figure 5: rcv RST/SYN (note 1) Note 1: When a connection in SYN-RECEIVED was reached through a passive OPEN, the connection returns to LISTEN in two cases, as specified in Section 3.10.7.4: (1) when a RST is received, and (2) when a SYN is received.
Notes:
Rationale:
Section 3.10.7.4 specifies two cases in which a connection in SYN-RECEIVED, reached via a passive OPEN, returns to LISTEN: when a RST is received and when a SYN is received. Figure 5's edge label and Note 1 currently mention only the RST-based case. This change does not introduce new behavior; it aligns the label and Note 1 with the existing normative text.
Status: Reported (2)
RFC 9293, "Transmission Control Protocol (TCP)", August 2022
Source of RFC: tcpm (wit)
Errata ID: 8804
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Christopher Williams
Date Reported: 2026-03-04
Section 3.10.7.4 says:
- 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:
[Text is removed. See notes.]
Notes:
This paragraph is unnecessary because a segment arriving in the CLOSED, LISTEN, or SYN-SENT state is handled in sections 3.10.7.1, 3.10.7.2, or 3.10.7.3, respectively. This section (3.10.7.4) is for all other states besides those three.
Errata ID: 8805
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Christopher Williams
Date Reported: 2026-03-04
Section 3.10.7.4 says:
o FIN-WAIT-1 STATE
+ If our FIN has been ACKed (perhaps in this segment), then
enter TIME-WAIT, start the time-wait timer, turn off the
other timers; otherwise, enter the CLOSING state.
It should say:
o FIN-WAIT-1 STATE
+ Enter the CLOSING state.
Notes:
This original text is in the eighth step (check the FIN bit). In the fifth step (check the ACK field) if the state is FIN-WAIT-1 and "if the FIN segment is now acknowledged, then enter FIN-WAIT-2 and continue processing in that state."
So in the eighth step we know that our FIN cannot possibly be ACKed if we're still in the FIN-WAIT-1 state; if our FIN were ACKed then we would be in the FIN-WAIT-2 state instead.
Status: Rejected (2)
RFC 9293, "Transmission Control Protocol (TCP)", August 2022
Source of RFC: tcpm (wit)
Errata ID: 8654
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Denis Ovsienko
Date Reported: 2025-11-22
Rejected by: Gorry Fairhurst
Date Rejected: 2026-01-20
Section 3.1 says:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |C|E|U|A|P|R|S|F| | | Offset| Rsrvd |W|C|R|C|S|S|Y|I| Window | | | |R|E|G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [...] Reserved (Rsrvd): 4 bits
It should say:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data |R|R|R|R|C|E|U|A|P|R|S|F| | | Offset|4|5|6|7|W|C|R|C|S|S|Y|I| Window | | | | | | |R|E|G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [...] R4, R5, R6, R7: 1 bit each
Notes:
The packet diagram does not match the prose: this document in Section 6 "IANA Considerations" defines bits 4-7 as distinct bits rather than a single 4-bit field.
This definition as distinct bits is new to this document compared to the two previous TCP specifications (RFC 3168 and RFC 793), each of which defines the Reserved field of the TCP header as a single field, 4-bit and 6-bit respectively, and does not define any data structure for it. Likewise, RFC 3168 Section 6.1 "TCP" says: "This specification of the ECN Field leaves the Reserved field as a 4-bit field using bits 4-7."
This way, when the packet diagram shows the reserved part of the TCP header as a single field, it is consistent with the prose in RFC 3168 and RFC 793, but is an error in this document.
--VERIFIER NOTES--
This does not impact the functioning of the protocol, or ability to implement properly. Other RFCs might continue to update the field.
Errata ID: 8760
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Murat genc
Date Reported: 2026-02-14
Rejected by: G Fairhurst
Date Rejected: 2026-02-15
Section 3.6.1 says:
When a connection is closed actively, it MUST linger in the TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime) (MUST-13). However, it MAY accept a new SYN from the remote TCP endpoint to reopen the connection directly from TIME-WAIT state (MAY-2), if it: (1) assigns its initial sequence number for the new connection to be larger than the largest sequence number it used on the previous connection incarnation, and (2) returns to TIME-WAIT state if the SYN turns out to be an old duplicate. When the TCP Timestamp Options are available, an improved algorithm is described in [40] in order to support higher connection establishment rates. This algorithm for reducing TIME-WAIT is a Best Current Practice that SHOULD be implemented since Timestamp Options are commonly used, and using them to reduce TIME-WAIT provides benefits for busy Internet servers (SHLD-4).
It should say:
(1) uses the Timestamp-based algorithm described in [40] when reopening a connection directly from the TIME-WAIT state; and (2) returns to TIME-WAIT state if the SYN turns out to be an old duplicate. If TCP Timestamps are not available, the endpoint MUST NOT reopen the connection directly from the TIME-WAIT state.
Notes:
Rationale / Implementability:
Item (1) currently requires choosing an ISN “larger than the largest sequence number used on the previous connection incarnation.” On widely deployed systems (e.g., Linux), TCP does not maintain a per-connection persistent record of the “largest sequence number used” from the prior incarnation in a way that can be reliably applied to a subsequent connection reopened from TIME-WAIT. In practice, it may happen for a newly established connection to use an ISN that is smaller than the largest sequence number observed on a previous incarnation of the same 4-tuple, especially under rapid reconnect / port reuse and high-rate workloads.
Interoperability:
Many middleboxes (firewalls/load balancers/NAT devices) enforce sequence/window validity based on their own view of the prior flow and may drop segments they consider out-of-window or anomalous during/after fast reuse. This makes reopening directly from TIME-WAIT without a robust anti-duplicate mechanism prone to interoperability failures.
Proposed fix:
Replace the “largest sequence number” requirement with an explicit requirement to use the Timestamp-based Best Current Practice described in [40] (RFC 6191) when reopening directly from TIME-WAIT. If TCP Timestamps are not available, the endpoint MUST NOT reopen directly from TIME-WAIT and should follow the normal TIME-WAIT behavior (2xMSL).
--VERIFIER NOTES--
This proposed chnage is more than a correction and changes the mechanism. Such a change needs to be discussed in TCPM, and is more than permitted by an Errata,