Subject: [Roll] suggested addition to draft-ietf-roll-efficient-npdao

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 Aug 2019 06:42:50 +0000

Dear all ;

I know it's late but I'd suggest an addition to draft-ietf-roll-efficient-npdao. There's a reserved field in the DCO.
My suggestion is to use it to transport RPL DAO-ACK status values as defined in RFC 6550. This way we can signal the reason of the DCO to the node.
This will become significant with the RPL-unaware leaves draft, so we can rebuild a NA(EARO) with a non-zero status based on a DCO.

Else the RUL draft will have to update efficient NP DAO, which does not look as good.

Any objection to this?

Pascal

   0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | RPLInstanceID |K|D|   Flags   |   Reserved    | DCOSequence   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                            DODAGID(optional)                  +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Option(s)...
     +-+-+-+-+-+-+-+-+

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Fri, 30 Aug 2019 07:03:54 +0000

The DCO could be initiated for regular route invalidation due to path changes or because of management decision. The status code can help understand the reason for initiating the DCO. I like the idea of this.

However, I don't know, procedurally, what it means to changing the draft at this stage.

The changes to draft would include new IANA considerations for the status field.

From: Roll [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 30 August 2019 14:43
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: [Roll] suggested addition to draft-ietf-roll-efficient-npdao

Dear all ;

Any objection to this?

Pascal

   0                   1                   2                   3

---

From: Peter van der Stok <[email-masked]>
Date: Fri, 30 Aug 2019 09:29:47 +0200

Hi Authors,

It is a bit late to change the approved draft.
It is in IANA editing; and you could write to IANA to apologize for a
late addition and see how far they are in the process.
BUT, worse,  how much text is needed to explain this addition?

Adding text to an approved document sounds like opening a can of worms
to me.

Peter

Rahul Arvind Jadhav schreef op 2019-08-30 09:03:

> FROM: Roll [mailto:[email-masked]] ON BEHALF OF Pascal Thubert (pthubert)
> SENT: 30 August 2019 14:43
> TO: Routing Over Low power and Lossy networks <[email-masked]>
> SUBJECT: [Roll] suggested addition to draft-ietf-roll-efficient-npdao 
> 
> Dear all ; 
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Ines Robles <[email-masked]>
Date: Fri, 30 Aug 2019 10:56:08 +0300

Hi,

Please note  that new IANA considerations and related new text  to a WG
approved document certainly needs WG approval again.

Ines and Peter

On Fri, Aug 30, 2019 at 10:30 AM Peter van der Stok <[email-masked]>
wrote:

> It is in IANA editing; and you could write to IANA to apologize for a late
> addition and see how far they are in the process.
> Adding text to an approved document sounds like opening a can of worms to
> me.
>
> Peter
>
> The DCO could be initiated for regular route invalidation due to path
> changes or because of management decision. The status code can help
> understand the reason for initiating the DCO. I like the idea of this.
>
>
>
> However, I don’t know, procedurally, what it means to changing the draft
> at this stage.
>
>
>
> *From:* Roll [mailto:[email-masked]] *On Behalf Of *Pascal Thubert
> (pthubert)
> *Sent:* 30 August 2019 14:43
> *To:* Routing Over Low power and Lossy networks <[email-masked]>
> *Subject:* [Roll] suggested addition to draft-ietf-roll-efficient-npdao
>
>
>
> Dear all ;
>
>
>
> I know it’s late but I’d suggest an addition to
> draft-ietf-roll-efficient-npdao. There’s a reserved field in the DCO.
>
> My suggestion is to use it to transport RPL DAO-ACK status values as
> defined in RFC 6550. This way we can signal the reason of the DCO to the
> node.
>
> This will become significant with the RPL-unaware leaves draft, so we can
> rebuild a NA(EARO) with a non-zero status based on a DCO.
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 Aug 2019 08:09:54 +0000

The registry does not exist so unless we decide to create it there is no IANA  change. Call it an omission in RFC 6550.

For that reason I have already added text in the next RUL to create the registry (in github). Let’s keep it in RUL to minimize the changes in NPDAO.

Minimal changes to NPDAO is to change the name “reserved” of the field in the drawing and add text saying same status field as in RPL DAO ACK.

If we really want new status values we may also add them in NPDAO and I’ll adapt RUL. But there is no absolute need to create the registry in NPDAO.

Regards,

Pascal

Le 30 août 2019 à 09:30, Peter van der Stok <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Authors,

It is a bit late to change the approved draft.
It is in IANA editing; and you could write to IANA to apologize for a late addition and see how far they are in the process.
BUT, worse,  how much text is needed to explain this addition?

Adding text to an approved document sounds like opening a can of worms to me.

Peter

However, I don’t know, procedurally, what it means to changing the draft at this stage.

From: Roll [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 30 August 2019 14:43
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Subject: [Roll] suggested addition to draft-ietf-roll-efficient-npdao

Dear all ;

I know it’s late but I’d suggest an addition to draft-ietf-roll-efficient-npdao. There’s a reserved field in the DCO.
My suggestion is to use it to transport RPL DAO-ACK status values as defined in RFC 6550. This way we can signal the reason of the DCO to the node.
This will become significant with the RPL-unaware leaves draft, so we can rebuild a NA(EARO) with a non-zero status based on a DCO.

Any objection to this?

Pascal

   0                   1                   2                   3

_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Fri, 30 Aug 2019 08:31:20 +0000

If we really want new status values we may also add them in NPDAO and I’ll adapt RUL. But there is no absolute need to create the registry in NPDAO.
[RJ] The status field values of DAO-ACK/DCO-ACK are not what we require to be sent in DCO… What we want is a Reason field and not a Status field in the DCO.. Hence I believe that there are changes required for IANA. We can take a shortcut and keep the field same as Status, but it seems like a hack to me.

Peter

Dear all ;

Any objection to this?

Pascal

   0                   1                   2                   3

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 Aug 2019 08:50:08 +0000

Hum;

The term “status” may be abused, but it practice it means more than a state. It is more like a return code.
RUL uses the “Status values” from 6LoWPAN ND and transports them on DCO.
E.g., the backbone router uses “removed” to indicate that another BBR now owns the address.
In a 6TiSCH network that would mean in another RPL DODAG, so the address in this DODAG needs to be cleaned up. DCO is the way to do that. So the expectation is a DCO with a status code ‘removed’ as well.
The 6lo chairs asked me to remove text on RPL from the BBR so the above is still nuspecified, we’ll do that once the BBR has shipped.

If you look at the values in RUL right now they are exactly the sort of thing you’re talking about; current IANA section of RUL has the following:

    +---------+--------------------------------------+----------------+
    |  Value  |               Meaning                | Defining Spec  |
    +---------+--------------------------------------+----------------+
    |    0    |        Unqualified acceptance        |    RFC6550     |
    |         |                                      |                |
    |  1-127  |      Reserved for Warning Codes      |    RFC6550     |
    |         |                                      |                |
    |   128   |          Duplicate Address           |    This RFC    |
    |         |                                      |                |
    |   129   |            Out of Storage            |    This RFC    |
    |         |                                      |                |
    |   130   |                Moved                 |    This RFC    |
    |         |                                      |                |
    |   131   |               Removed                |    This RFC    |
    |         |                                      |                |
    |   132   |         Validation Requested         |    This RFC    |
    |         |                                      |                |
    |   133   |       Duplicate Source Address       |    This RFC    |
    |         |                                      |                |
    |   134   |        Invalid Source Address        |    This RFC    |
    |         |                                      |                |
    |   135   |   Address topologically incorrect    |    This RFC    |
    |         |                                      |                |
    |   136   |       6LBR Registry saturated        |    This RFC    |
    |         |                                      |                |
    |   137   |          Validation Failed           |    This RFC    |
    |         |                                      |                |
    | 138-192 | Reserved for 6LoWPAN ND code mapping |    This RFC    |
    |         |                                      |                |
    | 193-255 |  Reserved for other Rejection Codes  |    RFC6550     |
    +---------+--------------------------------------+----------------+

All the best,

Pascal

From: Roll <[email-masked]> On Behalf Of Rahul Arvind Jadhav
Sent: vendredi 30 août 2019 10:31
To: Routing Over Low power and Lossy networks <[email-masked]>; [email-masked]
Subject: Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao

Peter

Dear all ;

Any objection to this?

Pascal

   0                   1                   2                   3

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 30 Aug 2019 06:52:44 -0700

Hi!

I haven’t looked at the implications/details…but, at first glance, I think
we would need more than some changes in the IANA section…probably also
explanations, maybe security considerations on the new field, etc..

The document is currently being Edited by the RFC Editor.  The only time we
can’t stop the process is once the publication is complete…so there is time
if that is what we want to do.  I think we should pause the process, have
the discussion and then go back and see that the effect is.  IOW, the
discussion may end up in no/minor changes which we could make at this point
in the process…or it could result in bigger changes where some of the
process may have to be rerun (from WGLC to IETF LC, etc..).  Please don’t
let this last part scare anyone away from doing what may be the right
thing: even if there is process, it is probably lighter than a brand new
document. :-)

Unless I hear otherwise in the next few hours, I will ask the RFC Editor to
pause editing before my end of day.  I realize that no one who has
participated in this thread so far is based in the US (my timezone), but
the RFC Editor staff is, and Monday is a holiday, so I rather pause now
than wait until Tuesday.  With any luck this conversation can be settled
over the weekend and we’ll be ready to do then. :-)

Thanks!!

Alvaro.

On August 30, 2019 at 4:50:43 AM, Pascal Thubert (pthubert) (
[email-masked]) wrote:

Hum;

The term “status” may be abused, but it practice it means more than a
state. It is more like a return code.

E.g., the backbone router uses “removed” to indicate that another BBR now
owns the address.

In a 6TiSCH network that would mean in another RPL DODAG, so the address in
this DODAG needs to be cleaned up. DCO is the way to do that. So the
expectation is a DCO with a status code ‘removed’ as well.

The 6lo chairs asked me to remove text on RPL from the BBR so the above is
still nuspecified, we’ll do that once the BBR has shipped.

If you look at the values in RUL right now they are exactly the sort of
thing you’re talking about; current IANA section of RUL has the following:

    |         |                                      |                |

    |         |                                      |                |

    |         |                                      |                |

    |         |                                      |                |

    |         |                                      |                |

    |         |                                      |                |

    |         |                                      |                |

    |         |                                      |                |

    |         |                                      |                |

    |         |                                      |                |

    |         |                                      |                |

    |         |                                      |                |

    |         |                                      |                |

All the best,

Pascal

*From:* Roll <[email-masked]> *On Behalf Of *Rahul Arvind Jadhav
*Sent:* vendredi 30 août 2019 10:31
*To:* Routing Over Low power and Lossy networks <[email-masked]>;
[email-masked]
*Subject:* Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao

Minimal changes to NPDAO is to change the name “reserved” of the field in
the drawing and add text saying same status field as in RPL DAO ACK.

If we really want new status values we may also add them in NPDAO and I’ll
adapt RUL. But there is no absolute need to create the registry in NPDAO.

[RJ] The status field values of DAO-ACK/DCO-ACK are not what we require to
be sent in DCO… What we want is a Reason field and not a Status field in
the DCO.. Hence I believe that there are changes required for IANA. We can
take a shortcut and keep the field same as Status, but it seems like a hack
to me.

Le 30 août 2019 à 09:30, Peter van der Stok <[email-masked]> a écrit :

Hi Authors,

Peter

However, I don’t know, procedurally, what it means to changing the draft at
this stage.

The changes to draft would include new IANA considerations for the status
field.

*From:* Roll [mailto:[email-masked] <[email-masked]>] *On
Behalf Of *Pascal Thubert (pthubert)
*Sent:* 30 August 2019 14:43
*To:* Routing Over Low power and Lossy networks <[email-masked]>
*Subject:* [Roll] suggested addition to draft-ietf-roll-efficient-npdao

Dear all ;

Else the RUL draft will have to update efficient NP DAO, which does not
look as good.

Any objection to this?

Pascal

   0                   1                   2                   3

     |                                                               |

     +                                                               +

     |                                                               |

     +                            DODAGID(optional)                  +

     |                                                               |

     +                                                               +

     |                                                               |

     |   Option(s)...

     +-+-+-+-+-+-+-+-+

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 Aug 2019 14:19:59 +0000

Hello Alvaro

The proposal does not change the behavior of the NPDAO but adds information about why the NPDAO is sent. Are you concerned by attacks like a cover channel? We could have one sentence on that but I’m unclear how to protect against it.

In the future status values that modify the behavior of NPDAO may be introduced. But for now we’d be looking at a very minimalistic change where the reserved field carries a RPL status that does not affect the behavior of the nodes.
The hope would be that it does not affect the reviews that were already done.

Regards,

Pascal

Le 30 août 2019 à 15:53, Alvaro Retana <[email-masked]<mailto:[email-masked]>> a écrit :

Hi!

I haven’t looked at the implications/details…but, at first glance, I think we would need more than some changes in the IANA section…probably also explanations, maybe security considerations on the new field, etc..

The document is currently being Edited by the RFC Editor.  The only time we can’t stop the process is once the publication is complete…so there is time if that is what we want to do.  I think we should pause the process, have the discussion and then go back and see that the effect is.  IOW, the discussion may end up in no/minor changes which we could make at this point in the process…or it could result in bigger changes where some of the process may have to be rerun (from WGLC to IETF LC, etc..).  Please don’t let this last part scare anyone away from doing what may be the right thing: even if there is process, it is probably lighter than a brand new document. :-)

Unless I hear otherwise in the next few hours, I will ask the RFC Editor to pause editing before my end of day.  I realize that no one who has participated in this thread so far is based in the US (my timezone), but the RFC Editor staff is, and Monday is a holiday, so I rather pause now than wait until Tuesday.  With any luck this conversation can be settled over the weekend and we’ll be ready to do then. :-)

Thanks!!

Alvaro.

On August 30, 2019 at 4:50:43 AM, Pascal Thubert (pthubert) ([email-masked]<mailto:[email-masked]>) wrote:
Hum;

All the best,

Pascal

From: Roll <[email-masked]<mailto:[email-masked]>> On Behalf Of Rahul Arvind Jadhav
Sent: vendredi 30 août 2019 10:31
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao

Peter

Dear all ;

Any objection to this?

Pascal

   0                   1                   2                   3

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 30 Aug 2019 11:13:12 -0700

On August 30, 2019 at 10:20:05 AM, Pascal Thubert (pthubert) (
[email-masked]) wrote:

Pascal:

The proposal does not change the behavior of the NPDAO but adds information
about why the NPDAO is sent. Are you concerned by attacks like a cover
channel? We could have one sentence on that but I’m unclear how to protect
against it.

I haven’t thought about it too long…but, yes, that could be one thing.  Not
having a mitigation is ok, as  long as a potential vulnerability is
explained.

In the future status values that modify the behavior of NPDAO may be
introduced. But for now we’d be looking at a very minimalistic change where
the reserved field carries a RPL status that does not affect the behavior
of the nodes.
The hope would be that it does not affect the reviews that were already
done.

I hope so too…but would have to see the scope of any change first.

For now, I will ask the RFC Editor to pause processing.

Thanks!

Alvaro.