RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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, RFC 9601

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, RFC 9601

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, RFC 9601

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.

Report New Errata



Advanced Search