Re: [Roll] WGLC on draft-ietf-roll-unaware-leaves-13

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

Many thanks Rahul!

I hope all is going right for you and your family; 

Let's see below, I need more precisions from you:

> 1. The draft requires that the first registration (EDAR/EDAC) is directly
> handshaked with the 6LBR but all the subsequent refreshes using DAO/DAO-
> ACK goes through the Root which in turn generates anonymous EDAR/EDAC
> handshaked with the 6LBR.
> **Can't we have the 6LR simply use DAO always to Root which generates the
> EDAR(with ROVR)/EDAC to 6LBR?** This would simplify the handling of 6LR.

Here is why: The 6LR does the traditional DAD and ensures that the address is not a duplicate before it injects it in RPL. 

On paper DAD is really a special operation that allows the address in the network. Using the address before DAD is against IPv6 and prone to attacks. 


E.g., if we skip that step, and RPL is not aware of the new ROVR field, then in storing mode the duplicate will take over the path as the DAO progresses upwards, and that's not desirable security-wise. When the Root comes back with a NPDAO, it's too late. At the moment, we do not change RPL to process the ROVR. Hopefully in the future we'll do more.

Arguably in non-storing we could do it because the flow is nested and the root can check with the 6LBR before it updates its state. That would be an even deeper integration of RPL and ND. Is that more useful than dangerous?

> With the updated target option it is now possible to send ROVR in target
> option in a backward-compatible fashion. The root is anyways handling the
> anonymous EDAR/EDAC and thus has all the required handling needed to
> proxy non-anonymous EDAR/EDAC. Also, the de-registration is also handled
> through Root which means Root also has to proxy non-anonymous
> EDAR/EDAC in that case? The de-registration case is not clarified in the Figures
> 7,8,9.

You're right we should add text on the deactivation of the state.

If the root cannot do non-anonymous then the state will stay as is in the 6LBR if an anonymous EDAR comes in with lifetime 0. The idea is really to add the ROVR to the DAO.

I will:
1) add figures for flows with lifetime=0
2) add text in the 6LBR section that indicates that a lifetime 0 is ignored in an anonymous EDAR. This is implicit already
" 
  an anonymous message can only increase the lifetime and/or increment the TID of an existing state at the 6LBR.
"
3) There is no mandate for using the ROVR in the target option. It is a SHOULD, should it be a MUST?


> 
> 2. The document introduces the term RAN for any RPL aware node which can
> act as a parent node for the RUL. But in the document, subsequently, the term
> 6LR is used to depict the parent node with which the RUL attaches. Wondering
> why? Isn't RAN the appropriate term to be used?
> 

This is by reference to RFC 8505, to echo what happens there. Wouldn't the use of RAN blur things?


> 3. Section 9.2.2: "If a 6LR receives a valid NS(EARO) message with the "R" flag
> reset and a Registration Lifetime that is not 0, and the 6LR was redistributing
> the Registered Address due to previous NS(EARO) messages with the flag set,
> then it MUST stop injecting the address."
> In this case, should the 6LR also evict the corresponding NCE?

The NCE does not depend on the "R" flag. The flag controls the redistribution into RPL only.

> 
> 4. Section 9.2.3: "the Registration Lifetime is adapted from the Path Lifetime
> in the TIO by converting the Lifetime Units used in RPL into units of 60
> seconds used in the 6LoWPAN ND messages;"
> The unit of lifetime for RPL is not a multiple of 60sec like that of 6lo ND. Thus
> it is possible that absolute conversion is not possible in some cases. I guess
> the implementation should round-up in this case?

Yes, I can add "rounded up to the upper value". Is that OK?


> 
> 5. Section 5 ... "anonymous message can only increase the lifetime"
> ... It should be "anonymous message can only update the lifetime"

I really meant that in terms of configuration, it can only increase the duration of the lifetime parameter but not reduce it, e.g., to 0. A lifetime value of less than the current value will trigger a restart of the current value.

That behavior on an anonymous can really be discussed. Think that anyone could send it, what change can we allow it to cause?

> 
> 6. Section 9.1 ... "On the first Address Registration, illustrated in Figure 5 and
> Figure 8" ... Figure 8 currently does not show first address registration.
> 

Oups fig 8 it was repurposed, because it was too obvious. Fixed in github. The paragraph becomes

"
   On the first Address Registration, illustrated in Figure 5 for RPL
   Non-Storing Mode, the Extended Duplicate Address exchange takes place
   as prescribed by [RFC8505].  Any combination of the logical functions
   of 6LR, Root and 6LBR might be collapsed in a single node.
"
> 7. Nits:
> Sec 9.2.2 "that is sends in response" -> "that is sent in response"
Actually I meant "it sends" : )

> Sec 10: "unicast to each if the interested children" -> "unicast to each of the
> interested children"


> Sec 10: "Layer-2 acknoledgement" -> "Layer-2 acknowledgement"   

> Sec 11: " whereby the it is possible to validate" ->  "whereby it is possible to
> validate"
> Sec 12.4: "DAO-ACK and RCO" -> "DAO-ACK and DCO"

> Appendix A: " Follows the RPI-6LoRH and then the IP-in-IP 6LoRH." -> Need to
> be rephrased

Wasn't that high poetry? Changed to

   The SRH-6LoRHs are followed by RPI-6LoRH and then the IP-in-IP 6LoRH.
   When the IP-in-IP 6LoRH is removed, all the 6LoRH Headers that
   precede it are also removed.

Many thanks again Rahul, waiting for your advice on the issues raised.

Be safe

Pascal