Re: [Roll] Erik Kline's Discuss on draft-ietf-roll-useofrplinfo-42: (with DISCUSS and COMMENT)

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Erik

Many thanks for your review!

My 2 cents:

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> [ section 12 ]
> 
> * Ignoring an invalid RH3 header by the end host (I'm assuming this
>   means that segments left > 0) doesn't specify whether the packet
>   should be processed (ignore the RH) or the whole packet should be
>   ignored.
> 
>   I might recommend instead referring to RFC 6554 S4.2 for how to handle
>   RH3's if the node is also a RPL-aware router and say it MUST drop the
>   packet if segments left is non-zero and it's not a RPL-aware router.

On the one hand, this spec applies to RPL routers so implicitly it can dictate what a RAN does but not what a RPL unaware node does.

On the other hand, RFC 8200 has:
"
   If, while processing a received packet, a node encounters a Routing
   header with an unrecognized Routing Type value, the required behavior
   of the node depends on the value of the Segments Left field, as
   follows:

      If Segments Left is zero, the node must ignore the Routing header
      and proceed to process the next header in the packet, whose type
      is identified by the Next Header field in the Routing header.

      If Segments Left is non-zero, the node must discard the packet and
      send an ICMP Parameter Problem, Code 0, message to the packet's
      Source Address, pointing to the unrecognized Routing Type.
"

So maybe for RPL Unaware Nodes, we do node need to be normative, just mention the above as the generic protection for all RHs?



>   Related: I'd also recommend:
> 
>   "It should just be noted that an incoming RH3 must be fully consumed, or
>    very carefully inspected."
> 
>   ->
> 
>   "It should just be noted that an incoming RH3 MUST be fully consumed."
> 

By consumed we mean segment left == 0; would you have a better term? 

On the side of this discuss and for consistency, draft-ietf-roll-unaware-leaves says:

"
                                                                [USEofRPLinfo] expects the
   RUL to support the basic "IPv6 Node Requirements" [RFC8504].  In
   particular the RUL is expected to ignore the RPL artifacts that are
   either consumed or not applicable to a host.

"

Based on your comments  I changed that text in -27 to 

"
                                                                       [USEofRPLinfo] expects the
   RUL to support the basic "IPv6 Node Requirements" [RFC8504] and in
   particular the mandates in Sections 4.2 and 4.4 of [RFC8200].  As
   such, the RUL is expected to ignore the RPL artifacts that may be
   left over, either an SRH with zero Segments Left or a RPL Option in
   the Hop-by-Hop Header, which can be skipped when not recognized, see
   Section 5."

draft-ietf-roll-unaware-leaves also indicates:

"
5.4.  Support of the Routing Header

   A RUL is expected to process an unknown Routing Header Type as
   prescribed by section 4.4 of [RFC8200].  This implies that the Source
   Routing Header with a Routing Type of 3 [RFC6554] is ignored when the
   Segments Left is zero.
"


> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [ section 8.1.3 ]
> 
> * I'm confused by the use of "consumed" here.  Is the final RH3 entry
>   RUL's address?  I guess you could say RH penultimate hop "consumes"
>   the header because the ultimate destination address is put in the
>   header DA field.  Seems a bit odd though.
> 
>   I assume 6LR_n gets RUL's address from the last segment in RH3.
> 
>   "Consumed" means segments left == 0, I guess?  I suppose should have
>   picked up on this terminology when it was first used in Section 2.
>   Maybe clarify what it means in that section (2)?
> 

That would be good, I thought "consumed" was more common than it usually appears to be, at least in the RFCs.

Keep safe;

Pascal