Subject: Re: [Roll] Add ROVR in DAO?

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 Aug 2019 09:43:16 +0000

Dear all

As noted below, and discussed at the WG meeting at IETF 105, it would be good to convey the ROVR field in the DAO, so if the Root and the 6LBR are different entities then the root can build a full EDAR as opposed to the dummy one.
It will also help make RPL more secure in the future. So I'm calling to confirm the discussion in Montreal and if there is no opposition I'll go ahead and propose a new option that can be placed with the DAO to transport a ROVR.
We'll also need something in the configuration option to trigger its use.

Comments and any hint on how to do that right are welcome.

All the best;

Pascal

From: Roll <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: mercredi 24 juillet 2019 23:54
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: [Roll] Add ROVR in DAO?

Dear all

The only change I foresee in the unaware leaves draft is the addition of the RFC 8505 ROVR from the ND EARO into the DAO. After that I'd feel ready to call for WGLC.

The proposed change enables to build a full EDAR message at the root, and avoids the weird processing of the keep-alive EDAR (see https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-02#section-7.4)
If we do it now we can forget that weird format (all ones ROVR) and never code for it. This may also be useful when we work on securing the DAO using the AP ND proof of ownership all the way to the root..

Please let me know if there's disagreement to make that change

All the best

Pascal

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Fri, 23 Aug 2019 14:34:05 +0000

Hi Pascal,

As I understand the proposal is to:

1.       Remove the ROVR generation on the 6LBR on behalf of the 6LN.

2.       Use the ROVR from NS(EARO) directly in the DAO.

3.       This would eliminate Keep-Alive EDAR/EDAC during initial/first registration.

4.       This would eliminate the need for root node to set all ones in the ROVR field of keep-alive EDAR.
This seems optimal.
But there is one downside if the DAO is used for such purpose; Adding a 64-bit ROVR field in DAO would mean that in storing MOP all the parents maintain the ROVR field in their routing table. This is an immense overhead, since it impacts the routing entry size even if the RPL network needs to support just a single RUL.

Another question I have is,... In the Figure 2, EDAR is sent to 6LBR and DAO is sent to the Root. As I understand the DODAGID in the DIO will be the global IPv6 address of the Root (and not 6LBR) and thus DAO can be addressed to the Root. But how does 6LR get the address of the 6LBR to send the EDAR? (assuming in this case the Root and 6LBR are different network entities). Also it would be better to differentiate Root and 6LBR in the terminology section.

Regards,
Rahul

From: Roll [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 23 August 2019 17:43
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] Add ROVR in DAO?

Dear all

As noted below, and discussed at the WG meeting at IETF 105, it would be good to convey the ROVR field in the DAO, so if the Root and the 6LBR are different entities then the root can build a full EDAR as opposed to the dummy one.
It will also help make RPL more secure in the future.. So I'm calling to confirm the discussion in Montreal and if there is no opposition I'll go ahead and propose a new option that can be placed with the DAO to transport a ROVR.
We'll also need something in the configuration option to trigger its use.

All the best;

Pascal

From: Roll <[email-masked]<mailto:[email-masked]>> On Behalf Of Pascal Thubert (pthubert)
Sent: mercredi 24 juillet 2019 23:54
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Subject: [Roll] Add ROVR in DAO?

Dear all

The proposed change enables to build a full EDAR message at the root, and avoids the weird processing of the keep-alive EDAR (see https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-02#section-7.4)
If we do it now we can forget that weird format (all ones ROVR) and never code for it. This may also be useful when we work on securing the DAO using the AP ND proof of ownership all the way to the root...

All the best

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 Aug 2019 14:55:42 +0000

Hello Rahul and all

Please see below

?    Not that. The ROVR is never generated by the 6LBR

  1.  Use the ROVR from NS(EARO) directly in the DAO.
  2.  This would eliminate Keep-Alive EDAR/EDAC during initial/first registration.

?    Actually we keep it in the first because it happens before RPL and provides DAD. But yes for all the subsequent.

  1.  This would eliminate the need for root node to set all ones in the ROVR field of keep-alive EDAR.

?    Exactly

This seems optimal.

?    So far

?    Yes. It is an additional 64 to 512 bits which limits the size of the routing table. Immense is a use case dependent thing. The value will increase if we use it to secure the DAO state.

?    In a network with legacy devices, the flows in draft-ietf-roll-unaware-leaves-02 will have to be supported. I take your mail as a hint that they are here to stay in case we cannot afford to store the ROVR.

?    That's 6LoWPAN ND. It happens before RPL, and even if there is no ROLL. See https://tools.ietf.org/html/rfc6775#section-4.3

All the best;

Pascal

Dear all

As noted below, and discussed at the WG meeting at IETF 105, it would be good to convey the ROVR field in the DAO, so if the Root and the 6LBR are different entities then the root can build a full EDAR as opposed to the dummy one.
It will also help make RPL more secure in the future... So I'm calling to confirm the discussion in Montreal and if there is no opposition I'll go ahead and propose a new option that can be placed with the DAO to transport a ROVR.
We'll also need something in the configuration option to trigger its use.

All the best;

Pascal

Dear all

The proposed change enables to build a full EDAR message at the root, and avoids the weird processing of the keep-alive EDAR (see https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-02#section-7.4)
If we do it now we can forget that weird format (all ones ROVR) and never code for it. This may also be useful when we work on securing the DAO using the AP ND proof of ownership all the way to the root....

All the best

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Aug 2019 16:53:07 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > As noted below, and discussed at the WG meeting at IETF 105, it would be good
    > to convey the ROVR field in the DAO, so if the Root and the 6LBR are
    > different entities then the root can build a full EDAR as opposed to the
    > dummy one.

    > It will also help make RPL more secure in the future.. So I’m calling to
    > confirm the discussion in Montreal and if there is no opposition I’ll go
    > ahead and propose a new option that can be placed with the DAO to transport a
    > ROVR.

So, this will be used by unware-leaves?
    EARO(ROVR) -> 6LR
                  6LR ---DAO(ROVR)---> 6LBR

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Aug 2019 20:40:18 -0400

> But there is one downside if the DAO is used for such purpose; Adding a
    > 64-bit ROVR field in DAO would mean that in storing MOP all the parents
    > maintain the ROVR field in their routing table. This is an immense
    > overhead, since it impacts the routing entry size even if the RPL
    > network needs to support just a single RUL.

So, ideally, the RUL or 6LR would send some keepalives with the ROVR directly
to the 6LBR even in storing mode.  Maybe not in DAOs.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 26 Aug 2019 08:55:22 +0000

Hello Michael

>                   6LR ---DAO(ROVR)---> 6LBR

Yes, more like this
 6LN -> EARO(ROVR) -> 6L
                   6LR ---DAO(ROVR)---> Root 
                                    Root ---DAR(ROVR)---> 6LBR

Note that I do not know how to avoid keeping what we have in unaware leaves today, that is the flow from the 6LR without a ROVR, and the problem is as usual backward compatibility.
We have to chose between yet another flag day / configuration bit approach or to live with the keep alive as already described with no ROVR as an option.
There's also the problem of knowing whether the 6LBR supports the keep alive with no ROVR. That will need to be signaled.

Suggestions welcome!

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 26 Aug 2019 09:24:49 +0000

> -----Original Message-----
> From: Roll <[email-masked]> On Behalf Of Michael Richardson
> Sent: samedi 24 août 2019 02:40

Well, that's what we want to avoid, 2 keep alive messages all the way across the LLN when one could suffice.
In that case I'd rather live with a DAR with no ROVR the duplication of efforts.

All the best,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Aug 2019 12:31:36 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > Note that I do not know how to avoid keeping what we have in unaware
    > leaves today, that is the flow from the 6LR without a ROVR, and the
    > problem is as usual backward compatibility.

I'll need to spend some time with some flows in front of me to understand the conflict.
unaware leaves is not done, and not deployed, so can we just change it now
then?
It's a bit of a mirky swirl of time sequence diagrams for me right now.

    > We have to chose between yet another flag day / configuration bit
    > approach or to live with the keep alive as already described with no
    > ROVR as an option.

    > There's also the problem of knowing whether the 6LBR supports the keep
    > alive with no ROVR. That will need to be signaled.

I feel there is a combinatorics of options here, and not a lot of ability to
communicate them to RULs.   Let's get the end point well described, and
figure out if there are in fact way points in the middle which are worth
while describing?