Subject: [Roll] rplinfo

From: peter van der Stok <[email-masked]>
Date: Tue, 18 Jul 2017 10:52:33 +0200

Hi all,

I had a quick look through the RPLinfo document.
The text has considerably improved since the last 2 versions. For me 
less reasoning was needed to understand what was going on. I did not 
check all the individual tables. I appreciated the larger security 
considerations section.
The considerations about the effect of RPI on non RPL aware nodes has 
been clarified.
Below some of my comments (typos and other comments mixed); hope they 
help

Peter

_____________________________________________________________________________________________________

Page 4; this document clarifIES
section 2 ; RPL-not-capable : …..which DOES not…
section 2, rpl-not-capable; how can this node be a leaf of a DODAG. It 
can be a neighbour of a DODAG node but not a leaf in my understanding
section 3.1 I don’t understand the following text “This ensures that a 
packet that
    leaves the RPL domain of an LLN (or that leaves the LLN entirely)
    will not be discarded when it contains the [RFC6553] RPL Hop-by-Hop
    option known as RPI.”
How can a change to an RPL option field have a consequence for a 
not-RPL-aware node? The only thing a change to the option field can do 
is that the treatment by rpl-aware and not-aware nodes is the same.
Page 6; We propose -> the document proposes.
Section 4 page 7, A “new” ICMP message, propose to remove “new”
Page 7, “or an in non-storing” suggest to remove “an”
Figures 5 and 6 are referenced as figures 1 and 2
Figure 2(6) In my understanding Raf 6LN are leaves of the DODAG and ~RAF 
6LN are not leaves but are part of the lowpan network to which the DODAG 
nodes belong as well. Using the concept of lowpan network (LLN) and 
subset that forms a DODAG may help the explanation.
Also the term “RPL Domain” is used; is that equivalent to DODAG? Suggest 
to use only one term and explain it.
Section 5 “This document also describe” -> describes
Section 5 “hte LLN” ->the
Section 5 “We describe also how is the communication inside of the LLN” 
-> We also describe the communication inside the LLN
(I stop noting typos from here)
Page 11: “leaves the LLN entirely” what does that mean? LLN is not well 
defined
Page 11: “   NOTE: There is some possible security risk when the RPI 
information
    is released to the Internet.  At this point this is a theoretical
    situation.”
Suggest to remove this phrase and add this point to security 
considerations

page 11: “be placed is placed” twice placed
Page 12 “so an IPsec AH security header can be
    applied across these headers, but it can not secure the values which
    mutate.”
  Not sure that I understand. I read: You can encrypt the header but not 
some of the values. Is that meant? How does the encryption algorithm 
know which values not to touch?

Section 6 first sentence “inside the LLN” is that inside the DODAG?
Page 13: Figure 6? Is unreadable.
Section 6.1.1 “1 <= i >= n” <= n (and at other places)
Why is the row “Re-added headers” necessary in the table? In all tables 
that I checked no node re-adds headers.
Section 11, “RPL root” -> DODAG root ?

-- 
Peter van der Stok

---

From: Ines Robles <[email-masked]>
Date: Tue, 18 Jul 2017 10:59:17 +0200

Thank you Peter,

ticket 183 was created to track this. [
https://trac.ietf.org/trac/roll/ticket/183#ticket]

Cheers,

Ines.

2017-07-18 10:52 GMT+02:00 peter van der Stok <[email-masked]>:

> The text has considerably improved since the last 2 versions. For me less
> reasoning was needed to understand what was going on. I did not check all
> the individual tables. I appreciated the larger security considerations
> section.
> The considerations about the effect of RPI on non RPL aware nodes has been
> clarified.
> Below some of my comments (typos and other comments mixed); hope they help
>
> Peter
>
> ____________________________________________________________
> _________________________________________
>
> section 2, rpl-not-capable; how can this node be a leaf of a DODAG. It can
> be a neighbour of a DODAG node but not a leaf in my understanding
> not-RPL-aware node? The only thing a change to the option field can do is
> that the treatment by rpl-aware and not-aware nodes is the same.
> nodes belong as well. Using the concept of lowpan network (LLN) and subset
> that forms a DODAG may help the explanation.
> Section 5 “We describe also how is the communication inside of the LLN” ->
> We also describe the communication inside the LLN
> Suggest to remove this phrase and add this point to security considerations
>
> some of the values. Is that meant? How does the encryption algorithm know
> which values not to touch?
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Ines Robles <[email-masked]>
Date: Tue, 18 Jul 2017 13:15:10 +0200

Thank you Peter for your suggestions/corrections.

Please find some comments bellow.

> be a neighbour of a DODAG node but not a leaf in my understanding

I understand that we can have it. Please someone correct me if I am wrong.

RFC 6550 (pag. 110) mentions that a RPL-Leaf-Node-only:

 - A leaf node (only) does not ever participate as a RPL router.

 - Support of a particular MOP encoding is not required

 - Support of a particular OF is not required.

 -  A leaf node does not generally issue DIO messages,

 - it may issue DAO and DIS messages.  A leaf node accepts DIO messages
though it generally ignores DAO and DIS messages  (not applied in our case)

> that the treatment by rpl-aware and not-aware nodes is the same.

The RPI is carried within the IPv6 Hop-by-Hop header. Processing of the
Hop-by-Hop Options header (by IPv6 intermediate nodes) is now optional, but
if nodes (not-rpl-aware) are configured to process the header, and if such
nodes encounter an option with the first two bits set to 01 (RPI), they
will drop the packet.

> that forms a DODAG may help the explanation.

Ok, This is related with a previous comment above.

> to use only one term and explain it.

Ok, thanks, we are going to clarify those terms in text. In Figure 2 we are
using the meaning for RPL domain, not equivalent to DODAG:

RPL Domain: A collection of RPL routers under the control of a single
      administration.  The boundaries of routing domains are defined by
      network management by setting some links to be exterior, or inter-
      domain, links. [RFC 7102]

Destination-Oriented DAG (DODAG): A DAG rooted at a single
         destination, i.e., at a single DAG root (the DODAG root) with
         no outgoing edges.[RFC 6550]

> Page 11: “leaves the LLN entirely” what does that mean? LLN is not well

Ok, we will explain that better.

>From Figure 5, it means e.g. go out of the RPL domain, in this case go to
the Internet.

> Suggest to remove this phrase and add this point to security considerations

Ok,

> some of the values. Is that meant?

Yes.

How does the encryption algorithm know which values not to touch?

Have to check this.

> Section 6 first sentence “inside the LLN” is that inside the DODAG?

I would say here, inside the RPL Domain.

Ok, we will add more clarification here.

> Section 11, “RPL root” -> DODAG root ?

We will check it.

Thank you again.

Ines.

---

From: peter van der Stok <[email-masked]>
Date: Tue, 18 Jul 2017 13:23:39 +0200

>> section 2, rpl-not-capable; how can this node be a leaf of a DODAG.
>> It can be a neighbour of a DODAG node but not a leaf in my
>> understanding
> 
>  - it may issue DAO and DIS messages.  A leaf node accepts DIO
> messages though it generally ignores DAO and DIS messages  (not
> applied in our case)
> 

A leaf node accepts DIO messages and is thus RPL-aware in my 
understanding;

Peter

---

From: Ines Robles <[email-masked]>
Date: Tue, 18 Jul 2017 13:32:28 +0200

Yes, agree.

So, could we have a case where the leaf nodes do not accept DIO Messages
like in the use cases?

Maybe we should define the features with more detail of a
not-RPL-aware-leaf in the document.

2017-07-18 13:23 GMT+02:00 peter van der Stok <[email-masked]>:

> A leaf node accepts DIO messages and is thus RPL-aware in my understanding;
>
> Peter
>

---

From: peter van der Stok <[email-masked]>
Date: Tue, 18 Jul 2017 13:48:34 +0200

Hi Ines,

my suggestion:
There is a LLN of connected nodes with IPv6 addresses and paths between 
them
A subset of these nodes is RPL aware.
These RPL aware nodes form a DODAG.
The non RPL aware nodes are not part of the DODAG and cannot be leaves 
of the DODAG
However, communication is possible between a rpl-aware node and a 
non-rpl-aware node via link-local addresses at least.

Peter

Ines  Robles schreef op 2017-07-18 13:32:
> Yes, agree.
> 
> So, could we have a case where the leaf nodes do not accept DIO
> Messages like in the use cases?
>

---

From: Ines Robles <[email-masked]>
Date: Tue, 18 Jul 2017 14:53:06 +0200

Yes.  a non RPL aware node is not part of a DODAG.

We should add more clarification in the text, so far we have:

 RPL-not-capable: It is a device which do not implement RPL, thus we can
   say that the device is not-RPL-aware.  Please note that the device
   can be found inside the LLN.  In this document a not-RPL-aware node
   which is a leaf of a DODAG is called not-RPL-aware-leaf.

Could be changed to:

 RPL-not-capable: It is a device which does not implement RPL,
 thus, we can say that the device is not-RPL-aware.
 Please, note that the device can be found inside the LLN.
 In ths document, a not-RPL-aware node is connected to a 6LR in a
"leaf position"
 ( note that the device does not belong to a DODAG).
 The device uses Router-Advertisements, 6LowPAN DAR/DAC and
   efficient-ND only to participate in the network
 This type of node is called a not-RPL-aware-leaf.

What do you think?

Thanks,

Ines

2017-07-18 13:48 GMT+02:00 peter van der Stok <[email-masked]>:

> The non RPL aware nodes are not part of the DODAG and cannot be leaves of
> the DODAG

---

From: peter van der Stok <[email-masked]>
Date: Tue, 18 Jul 2017 14:58:51 +0200

Yes, better, removes my confusion.

Ines  Robles schreef op 2017-07-18 14:53:
>> There is a LLN of connected nodes with IPv6 addresses and paths
>> between them
>> The non RPL aware nodes are not part of the DODAG and cannot be
>> leaves of the DODAG

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Jul 2017 09:26:20 +0200

> A leaf node accepts DIO messages and is thus RPL-aware in my

There are two definitions perhaps.  RFC6550 says situations in which
an RPL-aware node MUST join as a leaf node because it does not speak the
correct MOP, or other situations.  But, it doesn't actually say what
it means to be a leaf node.

A leaf node is a node that join using Router Advertisements only.
A leaf node is what we normally have called a "host".  Only in the
situation where it was an incompatible 6550 implementation would
the leaf understand RPI.  There are potentially many leaf nodes that
would join a LLN via RA, etc.

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

---

From: peter van der Stok <[email-masked]>
Date: Fri, 21 Jul 2017 10:15:01 +0200

> would join a LLN via RA, etc.

IMO it is good to make that clear in the document and explain the 
difference between RA leaves and DODAG leaves

Peter

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Jul 2017 11:18:58 +0200

peter van der Stok <[email-masked]> wrote:
    >> an RPL-aware node MUST join as a leaf node because it does not speak
    >> the correct MOP, or other situations.  But, it doesn't actually say
    >> what it means to be a leaf node.
    >>
    >> A leaf node is a node that join using Router Advertisements only.  A
    >> leaf node is what we normally have called a "host".  Only in the
    >> situation where it was an incompatible 6550 implementation would the
    >> leaf understand RPI.  There are potentially many leaf nodes that would
    >> join a LLN via RA, etc.

    > difference between RA leaves and DODAG leaves

But, when an RPL aware node is forced into a leaf position (due to
incompatibility), it does so using RAs, etc. so it really has no effect
on the considerations.  A storing-mode only RPL node, upon encountering
a non-storing mode DODAG, might join as a leaf, but might *not* understand
RH3 headers.

So rather than explain that there is a difference, I think we should just
explain that they are leaves.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: peter van der Stok <[email-masked]>
Date: Fri, 21 Jul 2017 11:23:02 +0200

> explain that they are leaves.
The document makes a difference between raf and ~raf.
Explaining they are leaves in the 2 protocols (ND and RPL) is then the 
solution?

Peter