RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 10 records.

Status: Verified (3)

RFC 6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", March 2012

Source of RFC: roll (rtg)

Errata ID: 3580

Status: Verified
Type: Technical

Reported By: Tony Cheneau
Date Reported: 2013-04-04
Verifier Name: Adrian Farrel
Date Verified: 2013-04-10

Section 9.9.1 says:

   1.   Let C1 send a DAO containing a Target T with a Path Control
        10000000b.  Node N stores an entry associating 10000000b with
        the Path Control field for C1 and Target T.

   2.   Let C2 send a DAO containing a Target T with a Path Control
        00010000b.  Node N stores an entry associating 00010000b with
        the Path Control field for C1 and Target T.

   3.   Let C3 send a DAO containing a Target T with a Path Control
        00001100b.  Node N stores an entry associating 00001100b with
        the Path Control field for C1 and Target T.

It should say:

   1.   Let C1 send a DAO containing a Target T with a Path Control
        10000000b.  Node N stores an entry associating 10000000b with
        the Path Control field for C1 and Target T.

   2.   Let C2 send a DAO containing a Target T with a Path Control
        00010000b.  Node N stores an entry associating 00010000b with
        the Path Control field for C2 and Target T.

   3.   Let C3 send a DAO containing a Target T with a Path Control
        00001100b.  Node N stores an entry associating 00001100b with
        the Path Control field for C3 and Target T.

Notes:

Bullet 2 and 3 seem wrong. I believe "C1" should be replaced by "C2" in bullet 2 and "C1" should be replaced by "C3" in bullet 3.

This issue was initially reported by Federico Consoli on the ROLL WG mailing list.

Errata ID: 3287

Status: Verified
Type: Editorial

Reported By: Duong Nguyen
Date Reported: 2012-07-18
Verifier Name: Adrian Farrel
Date Verified: 2012-07-29

Section 6.5.1 says:

     127-255:  Rejection; the node sending the DAO-ACK is unwilling to
               act as a parent.

It should say:

     128-255:  Rejection; the node sending the DAO-ACK is unwilling to
               act as a parent.

Notes:

The status code range of "Rejection" overlaps with status code range of "Not an outright rejection".
The text in the body of the document makes it clear that the "Corrected Text" suggested here is what was intended.

Errata ID: 3895

Status: Verified
Type: Editorial

Reported By: Lei Mou
Date Reported: 2014-02-17
Verifier Name: Adrian Farrel
Date Verified: 2014-02-24

Section 9.8 says:

1.  The DODAG Parent Address subfield of a Transmit Information
    option MUST be empty.

5. ...

   When a storing node generates a DAO, it uses the stored state of DAOs
   it has received to produce a set of RPL Target options and their
   associated Transmit Information options.

It should say:

1.  The DODAG Parent Address subfield of a Transit Information
    option MUST be empty.

5. ...

   When a storing node generates a DAO, it uses the stored state of DAOs
   it has received to produce a set of RPL Target options and their
   associated Transit Information options.

Notes:

There is no "Transmit Information option", It should be Transit Information option.

Status: Reported (1)

RFC 6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", March 2012

Source of RFC: roll (rtg)

Errata ID: 4654

Status: Reported
Type: Editorial

Reported By: Michael Richardson
Date Reported: 2016-04-04

Section 2, 5.1, 6.3 says:

Section 2 defines DODAGID:

   DODAGID: A DODAGID is the identifier of a DODAG root.  The DODAGID is
         unique within the scope of a RPL Instance in the LLN.  The
         tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG.


It should say:

DODAGID: A DODAGID is the identifier of a DODAG root.  
  The DODAGID MUST be a reachable IPv6 address of the root node.
  The DODAG MUST be unique within the scope of a RPL Instance 
  in the LLN. The tuple (RPLInstanceID, DODAGID) uniquely 
  identifies a DODAG.


Notes:

section 5.1, and 6.3 also offered definitions of DODAGID, the above text summarizes those sections.

Status: Held for Document Update (6)

RFC 6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", March 2012

Source of RFC: roll (rtg)

Errata ID: 3311

Status: Held for Document Update
Type: Editorial

Reported By: Duong Nguyen
Date Reported: 2012-08-08
Held for Document Update by: Adrian Farrel

Section 6.7.10 says:

   R:    1-bit router address flag.  When set, it indicates that the
         Prefix field contains a complete IPv6 address assigned to the
         sending router that can be used as parent in a target option.

It should say:

   R:    1-bit router address flag.  When set, it indicates that the
         Prefix field contains a complete IPv6 address assigned to the
         sending router that can be used as parent in a transit option.

Notes:

parent address is carried in transit option, not target option.

Errata ID: 3581

Status: Held for Document Update
Type: Editorial

Reported By: Tony Cheneau
Date Reported: 2013-04-04
Held for Document Update by: Adrian Farrel

Section 6.4.3 says:

   A special case of the DAO message, termed a No-Path, is used in
   Storing mode to clear Downward routing state that has been
   provisioned through DAO operation.  The No-Path carries a Target
   option and an associated Transit Information option with a lifetime
   of 0x00000000 to indicate a loss of reachability to that Target.

It should say:

   A special case of the DAO message, termed a No-Path, is used in
   Storing mode to clear Downward routing state that has been
   provisioned through DAO operation.  The No-Path carries a Target
   option and an associated Transit Information option with a lifetime
   of 0x00 to indicate a loss of reachability to that Target.

Notes:

The Path Lifetime field of the Transit Information option is a 8-bit field. Using 0x00000000 here would indicate a 32 bits encoding and is misleading.

Errata ID: 4219

Status: Held for Document Update
Type: Editorial

Reported By: Michael Richardson
Date Reported: 2015-01-05
Held for Document Update by: Adrian Farrel
Date Held: 2015-01-06

Section 1.0 says:

This document specifies the IPv6 Routing Protocol for LLNs (RPL).
Note that although RPL was specified according to the requirements
set forth in the aforementioned requirement documents, its use is in
no way limited to these applications.

It should say:

This document specifies the IPv6 Routing Protocol for LLNs (RPL).  
The acronym RPL is used extensively in other documents and in 
other acronyms,and it is pronounced "ripple". As such, it is 
appropriate to write "a RPL root" as if the acronym was pronounced, 
rather than "an RPL root" if the letters were spelt out "arr peee ell".

Note that although RPL was specified according to the requirements
set forth in the aforementioned requirement documents, its use is in
no way limited to these applications.

Notes:

Pronunciation of RPL
Newcomers to the IoT space do not know what "ripple" is.
This is recorded as errata so that it does not get lost on 6550bis.

Errata ID: 4457

Status: Held for Document Update
Type: Editorial

Reported By: Dominique Barthel
Date Reported: 2015-08-27
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-15

Section 20.9 says:

in title of section (one instance) and text (two instances)
"DODAG Informational Solicitation"

It should say:

"DODAG Information Solicitation"

Notes:

DIS is defined in Section 2 (Terminology) as "DODAG Information Solicitation".
This acronym is expanded consistently throughout the RFC but in this section.

=== Alvaro Retana ===
Note that this error affects the name of the IANA registry as well. A future revision of this document should request an update to that name as well.

Errata ID: 4458

Status: Held for Document Update
Type: Editorial

Reported By: Dominique Barthel
Date Reported: 2015-08-27
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-15

Section 20.10 says:

No bit is currently defined for the DIS (DODAG Informational
Solicitation) Flags.

It should say:

No bit is currently defined for the DIO (DODAG Information
Object) Flags.

Notes:

This is obviously an erroneous copy-paste from section 20.9

Errata ID: 4618

Status: Held for Document Update
Type: Editorial

Reported By: Yasuyuki Tanaka
Date Reported: 2016-02-13
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-15

Section 6.7.6 says:

Reserved: 7-bit unused field.  The field MUST be initialized to zero
         by the sender and MUST be ignored by the receiver.

It should say:

Reserved: 8-bit unused field.  The field MUST be initialized to zero
         by the sender and MUST be ignored by the receiver.

Notes:

The error is clear, but it should not affect implementations.

Report New Errata



Search RFCs
Advanced Search
×