RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Reported (1)

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

Source of RFC: 6man (int)

Errata ID: 4807

Status: Reported
Type: Technical

Reported By: Tim Chown
Date Reported: 2016-09-20

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:

I noticed in cross-checking that RFC6564 refers to [IANA_IP_PARAM], or http://www.iana.org/assignments/ip-parameters/ip-parameters.xhtml, while 2460-bis refers to [IANA-PN], or https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml for the possible Next Header values in the Uniform IPv6 EH defined in RFC6564, and described in Section 4.8 of 2460-bis. So looks like an errata needed?

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

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



Search RFCs
Advanced Search
×