RFC Errata
Found 8 records.
Status: Verified (3)
RFC 3931, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", March 2005
Note: This RFC has been updated by RFC 5641
Source of RFC: l2tpext (int)
Errata ID: 210
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ming Deng
Date Reported: 2007-05-09
Section 3 says:
SSHTRESH
It should say:
SSTHRESH
Notes:
Occurs 3 times.
from pending.
Errata ID: 1433
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Puiu
Date Reported: 2008-05-30
Verifier Name: Brian Haberman
Date Verified: 2012-05-09
Section 4.5 says:
The LCCE then checks the Cookie field in the data packet against the Cookie value received in the Assigned Cookie AVP during session establishment.
It should say:
The LCCE then checks the Cookie field in the data packet against the Cookie value sent in the Assigned Cookie AVP during session establishment.
Notes:
Section 5.4.4 contradicts this directly ("All data messages sent to a peer MUST use the Assigned Cookie sent by the peer in this AVP"), and seems consistent with the rest of the 'assigned ...' fields.
Errata ID: 211
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carlos Pignataro
Date Reported: 2005-10-31
Section 5.4.5 says:
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 32.
It should say:
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 24.
Notes:
Status: Held for Document Update (4)
RFC 3931, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", March 2005
Note: This RFC has been updated by RFC 5641
Source of RFC: l2tpext (int)
Errata ID: 3766
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Chaz Granholm
Date Reported: 2013-10-26
Held for Document Update by: Brian Haberman
Date Held: 2013-10-29
Section 8.2.3 says:
Further, it is far easier to change a compromised L2TPv3 Cookie than a compromised IP address," and a cryptographically random [RFC1750] value is far less likely to be discovered by brute-force attacks compared to an IP address.
It should say:
Further, it is far easier to change a compromised L2TPv3 Cookie than a compromised IP address, and a cryptographically random [RFC1750] value is far less likely to be discovered by brute-force attacks compared to an IP address.
Notes:
Erroneous quotation mark.
Errata ID: 6273
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Casper van Eersel
Date Reported: 2020-09-02
Held for Document Update by: Eric Vyncke
Date Held: 2020-09-03
Section 4.3 says:
See Section 5.4.3 for details on calculation of the Message Digest and construction of the Control Message Authentication Nonce and Message Digest AVPs.
It should say:
See Section 5.4.1 for details on calculation of the Message Digest and construction of the Control Message Authentication Nonce and Message Digest AVPs.
Notes:
The explanation of the (HMAC etc.) details is given in 5.4.1, not 5.4.3.
--- Reviewer / AD note ---
While the errata is correct, it does not impact implementation and is not really confusing so the status of 'verified' for IETF steam is not the right state.
Errata ID: 6274
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Casper van Eersel
Date Reported: 2020-09-02
Held for Document Update by: Eric Vyncke
Date Held: 2020-09-03
Section 4.3 says:
The integrity check is calculated as in Section 5.4.3, with an empty zero-length shared secret, local nonce, and remote nonce.
It should say:
The integrity check is calculated as in Section 5.4.1, with an empty zero-length shared secret, local nonce, and remote nonce.
Notes:
The calculation is covered in section 5.4.1.
--- Review AD note ---
While the errata is correct, it does not impact implementation and is not really confusing so the status of 'verified' for IETF steam is not the right state.
Errata ID: 6275
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Casper van Eersel
Date Reported: 2020-09-02
Held for Document Update by: Eric Vyncke
Date Held: 2020-09-03
Section 6.5 says:
See Section 4.2 for a description of the keepalive mechanism.
It should say:
See Section 4.4 for a description of the keepalive mechanism.
Notes:
Incorrect reference to section 4.2.
--- Reviewer / AD note ---
While the errata is correct, it does not impact implementation and is not really confusing so the status of 'verified' for IETF steam is not the right state.
Status: Rejected (1)
RFC 3931, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", March 2005
Note: This RFC has been updated by RFC 5641
Source of RFC: l2tpext (int)
Errata ID: 2766
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Teco Boot
Date Reported: 2011-04-04
Rejected by: Brian Haberman
Date Rejected: 2012-05-09
Section 4.1.4 says:
An LCCE MAY fragment a packet before encapsulating it in L2TP. For example, if an IPv4 packet arrives at an LCCE from a Remote System that, after encapsulation with its associated framing, L2TP, and IP, does not fit in the available path MTU towards its LCCE peer, the local LCCE may perform IPv4 fragmentation on the packet before tunnel encapsulation.
It should say:
An LCCE MAY fragment a packet before encapsulating it in L2TP. For example, if an IPv4 packet with DF=0 arrives at an LCCE from a Remote System that, after encapsulation with its associated framing, L2TP, and IP, does not fit in the available path MTU towards its LCCE peer, the local LCCE may perform IPv4 fragmentation on the packet before tunnel encapsulation.
Notes:
Following RFC 791, IPv4 packets with the DF flag set shall not fragment such packets. RFC 3931 shall not make a precedent for fragmenting IPv4 packets with DF=1.
--VERIFIER NOTES--
The original text uses MAY so it does not mandate fragmentation behavior.