Re: [Roll] [Technical Errata Reported] RFC9008 (7543)

[Mathis Marion <[e-mail]>]

On 13/01/2024 19:20, Michael Richardson wrote:
 > Yeah, the fix for errata is wrong, and I think is due to a 
mis-understanding.
 > Mathis, thank you for reporting this, and I'm interested to know your
 > thoughts about this document, as it was a *$%(#@$ to write turning 
from one a
 > 1-week effort to produce a 3 page document into the 3-year 2700 line 
behemoth.
 >

For a bit of context, I am working on Wi-SUN, which uses the non-storing
mode of RPL. I have contacted Pascal Thubert for a couple technical
questions during the past year as I was confused by some RPL concepts.
One issue that Wi-SUN has is that it was specified before RFC 9008 and
consequently made some decisions that clash with the vision exposed in
RFC 9008. Recent incentives to introduce references to this RFC in the
Wi-SUN specification were unfortunately rejected by the Wi-SUN Alliance,
supposedly for backward compatibility reasons (I do not know all the
details).

Regarding this very errata, Pascal suggested that I publish it as a
result from one of our discussions. Now it is possible that I came to
the wrong conclusion, the errata was not reviewed until now. So one of
the starting point was my confusion with this bit from RFC 6550 section
11.2:

    SenderRank: 16-bit field set to zero by the source and to
          DAGRank(rank) by a router that forwards inside the RPL network.

To me there is no reason to set the rank to 0 at the source. Pascal
explained to me that this was written this way to allow RUL devices to
insert the RPI option without having a rank. However it seems that for
RAN, there is no reason to set this field to 0. Moreover, RFC 6550 never
states that SenderRank=0 must be treated specifically as meaning
"unspecified". In fact I was even more confused by the fact that this is
defined in section 17:

    BASE_RANK: This is the Rank for a virtual root that might be used to
          coordinate multiple roots.  BASE_RANK has a value of 0.

 > Assuming that I have the context correct, from section 6:
 >
 > }   As the Rank information in the RPI artifact is changed at each hop,
 > }   it will typically be zero when it arrives at the DODAG root.  The
 > }   DODAG root MUST force it to zero when passing the packet out to the
 > }   Internet.  The Internet will therefore not see any SenderRank
 > }   information.
 >
 > We might clarify things in this way:
 >
 > }   As the Rank information in the RPI artifact is changed at each hop,
 > +   for traffic originating within the DODAG,
 > }   it will typically be zero when it arrives at the DODAG root.  The
 > }   DODAG root MUST force it to zero when passing the packet out to the
 > }   Internet.  The Internet will therefore not see any SenderRank
 > }   information.
 >
 > While we have cases in the document dealing with traffic coming from the
 > Internet, in all those cases, a new RPI has to be added.  We never 
reuse (or
 > trust) any RPI (or RH3) that happens to be on the traffic from the 
"outside".
 > (We imagine some cases where traffic is from a trusted "inside" node, but
 > above the DODAG root, but which is a virtual part of the DODAG, but those
 > cases are not real today, and it's not _Internet_, but rather _Intranet_)
 >

I now agree that packets coming from Internet are basically never going
to contain an RPI option when arriving at the DODAG root, so we can
remove my note "The packet comes from Internet (and has an RPI)".

Now regarding the text edit, I maintain what I wrote as I think this 
note is correct: "The typical case is rather a packet that arrives at 
the DODAG root from a child node forwarding a packet, in which case 
SenderRank is set to DAGRank(rank) > 0.". Tell me if you believe this is 
wrong.

 > Not sure what means for errata processing.
 >
 >
 > --
 > Michael Richardson <[e-mail]>, Sandelman Software Works
 >  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*