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

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

Hello Rahul:

I ended up doing multiple changes for your review so I published a 14 to help you validate them:

Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-14


Continuing below:

> > 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?
> 
> [RJ] I get the proposition now. I guess, it's better to leave the initial EDAR/EDAC
> flow separate in all cases as specified in the draft.

Ack and agreed. No action.

> Another thing is the retry policy. EDAR/EDAC is sent multi hops away and the
> loss probability is too high in our networks. It would be great if implementers
> have some idea on what basis and how many times to retry if the EDAC is not
> received. Wondering if this is covered in other drafts, and I skimmed through
> 8505 without finding anything.


Good point! This is really inherited from RFC 6775 that stipulates:
"

8.2.6.  Recovering from Failures

   If there is no response from a 6LBR after RETRANS_TIMER [RFC4861],
   then the 6LR would retransmit the DAR to the 6LBR up to
   MAX_UNICAST_SOLICIT [RFC4861] times.  After this, the 6LR SHOULD
   respond to the host with an ARO Status of zero.

"
Note that the default RFC4861 values are usually not appropriate from deep inside a mesh.

Action add the last sentence in the text below:
"

3.3.  RFC 8505 Extended DAR/DAC

   [RFC8505] updates the periodic DAR/DAC exchange that takes place
   between the 6LR and the 6LBR using Extended DAR/DAC messages which
   can carry a ROVR field of variable size.  The exchange is triggered
   by an NS(EARO) message and is intended to create, refresh and delete
   the corresponding state in the 6LBR for a lifetime that is indicated
   by the 6LN.  It is protected by the ARQ mechanism specified in 8.2.6
   of [RFC6775], though in an LLN, a duration longer than the
   RETRANS_TIMER [RFC4861] of 1 second may be necessary to cover the
   Turn Around Trip delay from the 6LR to the 6LBR.
".

> Ideally, a 6LR should make itself available for RULs only once it has itself joined
> the network.

By which you mean "reachable through RPL" I guess. 

Having completed the join process (fig 5 of https://tools.ietf.org/html/draft-ietf-6tisch-architecture-28#section-4.2.1) is usually what people mean by joined.

I understand that you mean that beyond fig 7, you also ascertained that the 6LR's address is reachable though RPL. And I agree from the points you made earlier that we are lacking a reachability test.

Note that a successful EDAR/EDAC exchange on behalf of the RUL is such a proof. But it happens a bit late, the 6LR would waste a lot of energy retrying EDARs if it is not effectively reachable. We can probably do better. Ready when you are, but that's a different scope.

> In case of storing mode, we know from our experience, this is not
> easy to ascertain (i.e., DAO-ACK does not mean that end to end path is estd). But
> I guess, the worst case is that EDAC will be lost and will be retried. But not sure
> who does the retry, the RUL or the 6LR itself?

Both retries are defined. The RUL will retry the NS(EARO) on its own time in case that is what was lost, also per RFC 6775. RFC 6775 is not specific about the retry, so it is inherited from the NS process in RFC 4861. 
"
   The response to an address registration might not be immediate, since
   in route-over configurations the 6LR might perform Duplicate Address
   Detection against the 6LBR.  A host retransmits the Address
   Registration Option until it is acknowledged by the receipt of an
   Address Registration Option.

"
Certainly the timer on the RUL must be longer than that in the 6LR, but anyway there's no limit to the number of retries.

No action.

> 
> Also, the draft should make it clear that the 6LR should attempt the DAO for the
> RUL only when the initial registration is successful. Not doing this would possibly
> result in DAO for RUL reaching before initial EDAR to the root causing problems
> (DAO reaching before would mean the generation of anonymous EDAR and
> since 6LBR will not have an entry it would answer "Removed" which in turn
> would be used as Status in DAO-ACK)

The text already has:
"
   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.

   When successful, the flow creates a Neighbor Cache Entry (NCE) in the
   6LR, and the 6LR injects the Registered Address in RPL using DAO/DAO-
   ACK exchanges all the way to the RPL DODAG Root.  The protocol does
   not carry a specific information that the Extended Duplicate Address
   messages were already exchanged, so the Root proxies them anyway.

"
And in section in 9.2.2
"
  Also as prescribed by [RFC8505], the 6LR generates an EDAR message
   upon reception of a valid NS(EARO) message for the Address
   Registration of a new IPv6 Address by a 6LN and for the termination
   of a registration (lifetime of 0).

   If the initial EDAR/EDAC exchange succeeds, then the 6LR installs an
   NCE for the registration lifetime.

"

If the exchange fails, we're in RFC 6775/8505 land, the registration is rejected with status 1 'duplicate'.
To clarify I'm adding the second sentence below:
"
   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].  If the exchange fails, the 6LR returns
   an NA message with a negative status to the 6LN, the NCE is not
   created and the address is not injected in RPL.
"

> 
> >
> > > 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
> [RJ] Thanks

See the figure and new text in Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-14 

> > 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.
> > "
> [RJ] Making it explicit will help.

Added the last sentence in
"
   6.  Upon receiving an NS message with an EARO and the "R" flag set,
       the 6LR SHOULD inject the Registered Address in RPL by sending a
       DAO message on behalf of the 6LN.  If the Registration Lifetime
       was 0, the effect is to remove the route and then the NCE; this
       also causes the Root as a proxy to send and EDAR/EDAC to the
       6LBR with a Lifetime of 0.
"



OK will do that



> 
> > 3) There is no mandate for using the ROVR in the target option. It is a SHOULD,
> should it be a MUST?
> 
> [RJ] The ROVR will be a MUST only when a DAO for RUL is sent with a lifetime of
> zero by the 6LR. If this is what you mean then yes, I think it should be a MUST.

There will still be the case of a legacy node, to the Root will have to cope with no ROVR.
The text did not MUST on the termination because there is a proposed alternative of doing the EDAR exchange there. 

SHOULD we MUST it all the time? 

It is also useful to control the 6LBR, e.g., reduce the lifetime. 
It is mostly protecting the future for more zerotrust security using the ROVR in RPL. We can work on that rapidly once the RUL work is complete. The cost is the extra bytes obviously.


> 
> >
> >
> > >
> > > 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?
> 
> [RJ] Yep it would blur when you read it in context to 8505. The only reason why
> I brought this up is that without been routing-aware the 6LR cant handle things
> on behalf of RUL. We will just let this be as it is.
> 

Cool, no change there then


> >
> >
> > > 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.
> 
> [RJ] ok. Is there any scenario where RUL will reset 'R' flag subsequently after
> setting it? I am wondering if 6LR should invalidate the path when it gets 'R' flag is
> reset.

If the RUL does not want to use that 6LR anymore but say another one. But it still wants to keep the state in the 6LR in case it switches back, or for packets in flight.

> 
> >
> > >
> > > 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?
> 
> [RJ] Yep

Will do


> 
> >
> >
> > >
> > > 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?
> 
> [RJ]  thought it is possible for intermediate 6LRs to generate DAO on behalf of
> RUL without any direct trigger from the RUL. In this case, the lifetime will be a
> lower non-zero value.

True, and the router has the ROVR so it can reduce the lifetime. If that 6LR is an attacker, since it is on, it can do anything, changing the lifetime is only one out of many possibilities. What we want to prevent here is that other nodes not on-path may alter the path. This reduces the perimeter of attacks.


> > > 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?
> [RJ] Indeed it was and like any other high poetry, I couldn't understand a thing!
> :-)

Arfffff!!!

> 
> 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.
> >
> [RJ] Great, Thanks.

There's the MUST on each DAO that's still open, otherwise I believe I covered it all in 14.

Please let me know!

Many thanks, Rahul 😊

Keep safe;

Pascal