RFC Errata
Found 10 records.
Status: Verified (4)
RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP", September 2001
Note: This RFC has been updated by RFC 4301, RFC 6040, RFC 8311
Source of RFC: tsvwg (wit)
Errata ID: 3639
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Scheffenegger
Date Reported: 2013-06-05
Verifier Name: Martin Stiemerling
Date Verified: 2015-04-17
Section 6.1 / 6.1.3 says:
Section 6.1 says: * The receiver receives the packet with the CE codepoint set, and sets the ECN-Echo flag in its next TCP ACK sent to the sender. [...] * The sender sets the CWR flag in the TCP header of the next packet sent to the receiver to acknowledge its receipt of and reaction to the ECN-Echo flag. Section 6.1.3 says: When TCP receives a CE data packet at the destination end-system, the TCP data receiver sets the ECN-Echo flag in the TCP header of the subsequent ACK packet. [...] The TCP receiver uses the CWR flag received from the TCP sender to determine when to stop setting the ECN-Echo flag.
It should say:
Section 6.1.3 should say: The TCP receiver uses the CWR flag received from the TCP sender to determine when to stop setting the ECN-Echo flag. This check has to be performed before checking if the received segment is CE marked.
Notes:
The ordering of the text in the bullet points in section 6.1, and the text in section 6.1.3 can led to inappropriate implementations. At least Section 6.1.3 should be strict about the handling of CE-marked CWR-segments.
If CE is checked first, and ECE set, and thereafter CWR used to disable ECE, a CE-marked CWR segment will not result in the sending of an additional window of ECEs.
All derivatives of BSD used to
First, set ECE because of CE
Second, reset ECE because of CWR
However, the "authorative" NS2 sample code, the TBIT tool, Windows, Solaris and Linux would
First, reset ECE because of CWR
Second, set ECE because of CE
The latter approach seems to be the sensible one, and it was quickly fixed:
http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039450.html
Errata ID: 2307
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-06-21
Verifier Name: Lars Eggert
Date Verified: 2010-06-29
Section 6.1 says:
This proposal specifies two new flags in the Reserved field of the TCP header. The TCP mechanism for negotiating ECN-Capability uses the ECN-Echo (ECE) flag in the TCP header. Bit 9 in the Reserved field of the TCP header is designated as the ECN-Echo flag. The location of the 6-bit Reserved field in the TCP header is shown in Figure 4 of RFC 793 [RFC793] (and is reproduced below for completeness). This specification of the ECN Field leaves the Reserved field as a 4-bit field using bits 4-7.
It should say:
This proposal specifies two new flags in the Reserved field of the TCP header. The TCP mechanism for negotiating ECN-Capability uses the ECN-Echo (ECE) flag in the TCP header. Bit 9 in the Reserved field of the TCP header is designated as the ECN-Echo flag. The location of the 6-bit Reserved field in the TCP header is shown in Figure 3 of RFC 793 [RFC793] (and is reproduced below for completeness). This specification of the ECN Field leaves the Reserved field as a 4-bit field using bits 4-7.
Notes:
Incorrect reference to Figure 4 of RFC 793
Errata ID: 2660
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bob Briscoe
Date Reported: 2010-12-04
Verifier Name: Lars Eggert
Date Verified: 2011-02-03
Section header block says:
Updates: 2474, 2401, 793
It should say:
Updates: 2474, 2401, 2003, 793
Notes:
RFC 3168 updates RFC 2003 but does not indicate this in its header block.
Specifically, Section 9 of RFC 3168 defines processing of the ECN field for Encapsulated Packets. This updates RFC 2003, which specified "IP Encapsulation within IP" at a time before the ECN field was defined.
Errata ID: 5966
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Richard Scheffenegger
Date Reported: 2020-01-26
Verifier Name: Martin Duke
Date Verified: 2020-04-20
Section 6.1 says:
Section 6.1 states: * The sender sets the CWR flag in the TCP header of the next packet sent to the receiver to acknowledge its receipt of and reaction to the ECN-Echo flag. section 6.1.2 clarifies: We ensure that the "Congestion Window Reduced" information is reliably delivered to the TCP receiver. This comes about from the fact that if the new data packet carrying the CWR flag is dropped, then the TCP sender will have to again reduce its congestion window, and send another new data packet with the CWR flag set. Thus, the CWR bit in the TCP header SHOULD NOT be set on retransmitted packets. When the TCP data sender is ready to set the CWR bit after reducing the congestion window, it SHOULD set the CWR bit only on the first new data packet that it transmits.
It should say:
Section 6.1 should say: * The sender sets the CWR flag in the TCP header of the next new data packet sent to the receiver to acknowledge its receipt of and reaction to the ECN-Echo flag.
Notes:
Discrepancies in the above text lead to poorly interoperating implementations. In NetBSD (and derived implementationd), the "SHOULD set CWR on new data" was used liberal in setting CWR on the very next packet to be sent, regardless of type. While at the same time the Linux implementation performed very stingent tests on the receiver side, if the sender was complying with the "SHOULD" like a "MUST". In request-response session with frequently changing data direction, this leads to a collapse of the congestion window, as the *BSD side will continue to interpret the still latched ECE flag as an indication of another RTT of congestion.
== Reviewer note: The original report recommended a requirement that TCP receivers MUST process CWR on any packet, data or otherwise. While this would be helpful to interoperate implementations that are incorrect due to this erratum, it is a slight change in the intent of the document.
Status: Held for Document Update (2)
RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP", September 2001
Note: This RFC has been updated by RFC 4301, RFC 6040, RFC 8311
Source of RFC: tsvwg (wit)
Errata ID: 2316
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-06-29
Held for Document Update by: Lars Eggert
Section 15 says:
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2409, November 1998.
It should say:
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
Notes:
Incorrect reference to RFC 2409
Errata ID: 4754
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bob Briscoe
Date Reported: 2016-07-31
Held for Document Update by: Mirja Kühlewind
Date Held: 2020-03-04
Section Header block says:
Updates: 2474, 2401, 2003, 793
It should say:
Updates: 2474, 2401, 2003, 2473, 793
Notes:
RFC 3168 updates RFC 2473 but does not indicate this in its header block.
Specifically, Section 9 of RFC 3168 defined processing of the ECN field for Encapsulated Packets, which updated section 6.4 of RFC 2473, where the creation of the "IPv6 Tunnel Packet Traffic Class" was specified. RFC3168 also updated the decapsulation behaviour of the ECN field in an IPv6 tunnel header, which had not been specified in RFC2473.
Note 1: As well as tagging RFC3168 with this erratum, RFC2473 needs to be tagged (in the RFC index and associated tools outputs) to indicate that it is updated by RFC3168.
Note 2: Originally, the "Updates:" header of RFC3168 did not contain "2003", which was added as a result of Errata ID 2660.
Note 3: The first sentence of section 9.1 in RFC3168 should also be modified as follows:
Original text:
The encapsulation of IP packet headers in tunnels is used in many
places, including IPsec and IP in IP [RFC2003].
Corrected text:
The encapsulation of IP packet headers in tunnels is used in many
places, including IPsec and IP in IP [RFC2003, 2473].
Comment:
Nowadays RFC2473 would be a normative reference, but RFC3168 pre-dated the categorisation of references into normative and informative.
Note 4: Section 9 of RFC3168 has since been updated by RFC6040. Nonetheless, that is already correctly identified in RFC6040.
This reported errata has be moved to "Held for Document Update". While the reported problem is correct and needs to be addressed, it is not just an errata but a larger oversight at publication time.
Status: Rejected (4)
RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP", September 2001
Note: This RFC has been updated by RFC 4301, RFC 6040, RFC 8311
Source of RFC: tsvwg (wit)
Errata ID: 3680
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mirja Kühlewind
Date Reported: 2013-07-12
Rejected by: Martin Stiemerling
Date Rejected: 2015-04-17
Section 6.1.1. says:
If the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECN codepoint to not-ECT, and the TCP receiver ignores the CE codepoint in the received packet.
It should say:
If the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECN codepoint to not-ECT.
Notes:
The receiver should not ignore any CE codepoint.
--VERIFIER NOTES--
This is not an editorial fix or technical clarification, but proposes to change the processing of ECN. Please go ahead and write a draft that works towards updating RFC 3168.
Errata ID: 6494
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Joe Touch
Date Reported: 2021-03-24
Rejected by: Martin Duke
Date Rejected: 2021-03-24
Section Header says:
Updates: 2474, 2401, 793
It should say:
Updates: 2474, 2401, 793, 791
Notes:
This is the first standards-track RFC to assign the two unused bits of the IP TOS byte to ECN. Granted it was suggested in RFC2481, but that was experimental and unable to update RFC791 because it would create a downref.
--VERIFIER NOTES--
As several have pointed out on the list, 2474 itself updates 791, so someone following 791 through the tree of its updates will consider 3168.
Errata ID: 3636
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mirja Kühlewind
Date Reported: 2013-06-04
Rejected by: Martin Stiemerling
Date Rejected: 2013-07-11
Section 6.1.1. says:
If the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECN codepoint to not-ECT, and the TCP receiver ignores the CE codepoint in the received packet.
It should say:
If the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECN codepoint to not-ECT.
Notes:
CE should not be set on not-ECT capable packets. If this happens anyway, the CE codepoint would overwrite the ECT codepoint. Thus there is no way for the receiver to know it should ignore the CE codepoint; the sentence is therefore nonsensical.
--VERIFIER NOTES--
See discussions in the tsvwg (http://www.ietf.org/mail-archive/web/tsvwg/current/msg11989.html)
Errata ID: 4997
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: C. M. Heard
Date Reported: 2017-04-17
Rejected by: Martin Duke
Date Rejected: 2020-04-20
Section Header says:
Updates: 2474, 2401, 793
It should say:
Updates: 2474, 2460, 2401, 793
Notes:
RFC 3168 updates RFC 2460 but does not indicate this in its header block.
Specifically, Section 5.3 of RFC 3168 requires that the ECN field of a reassembled IPv6 datagram be calculated from the ECN fields of all of the fragments, rather than simply copying it from the initial fragment as specified in RFC 2460.
There are other missing Updates: fields; see e.g. Erratum 2660.
--VERIFIER NOTES--
This is a borderline case, as RFC 2474 already changes the semantics of this field and is correctly listed in the Updates field. Anyway, this would be "Hold for Document Update", but RFC 2460 has already been updated with RFC 8200.