RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Held for Document Update (1)

RFC 6564, "A Uniform Format for IPv6 Extension Headers", April 2012

Source of RFC: 6man (int)

Errata ID: 4807
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Tim Chown
Date Reported: 2016-09-20
Held for Document Update by: Suresh Krishnan
Date Held: 2017-01-29

Section 4 and 9 says:

In Section 4:

Next Header          8-bit selector.  Identifies the type of header
                        immediately following the extension header.
                        Uses the same values as the IPv4 Protocol field
                        [IANA_IP_PARAM].

In Section 9:

[IANA_IP_PARAM] IANA, "IP Parameters",
                   <http://www.iana.org/assignments/ip-parameters>.

It should say:

In Section 4:

Next Header          8-bit selector.  Identifies the type of header
                        immediately following the extension header.
                        Uses the same values as the IPv4 Protocol field
                        [IANA-PN].

In Section 9:

[IANA-PN]  "Assigned Internet Protocol Numbers",
              <https://www.iana.org/assignments/protocol-numbers/
              protocol-numbers.xhtml>.

Notes:

This is being handled in the 2460bis work.

Status: Rejected (1)

RFC 6564, "A Uniform Format for IPv6 Extension Headers", April 2012

Source of RFC: 6man (int)

Errata ID: 4423
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Fernando Gont
Date Reported: 2015-07-20
Rejected by: Brian Haberman
Date Rejected: 2015-09-15

Section 5 says:

   Any IPv6 extension headers defined in the future, keeping in mind the
   restrictions specified in Section 3 and also the restrictions
   specified in [RFC2460], MUST use the consistent format defined in
   Figure 1.  This minimizes breakage in intermediate nodes that examine
   these extension headers.

It should say:

There's a bug in the logic of this document. Essentially:

   A key problem with the Uniform Format for IPv6 Extension Headers
   [RFC6564] lies in that both IPv6 Extension Headers and Transport
   Protocols share the same namespace ("Next Header" registry/
   namespace).  Thus, given an "unknown Next Header value", it is
   impossible to tell whether the aforementioned value refers to an IPv6
   Extension Header that employs the aforementioned uniform format, or
   an "unknown" upper-layer protocol (e.g. an "unknown" transport
   protocol).  That is, while [RFC6564] specifies the syntax for the
   Uniform Format for IPv6 Extension Headers, but it does not provide a
   mechanism for a node to identify whether the aforementioned format is
   being employed in the first place.

This problem is discussed in: draft-gont-6man-rfc6564bis.

Notes:

The problem is not specifically with Section 5, but rather with the logic in the document.
--VERIFIER NOTES--
The changes proposed go beyond the level of an erratum. The issue should be discussed within the 6MAN working group and a revision of 6564 published if there is consensus to do so.

Report New Errata



Advanced Search