Subject: [Roll] useofrplinfo-07

From: "Turner, Randy" <[email-masked]>
Date: Tue, 2 Aug 2016 20:22:43 +0000

Hi All,

In section 5, “Storing Mode”, first paragraph, there is a sentence that says “the sender cannot determine whether the destination is RPL-capable and thus would need an IP-in-IP header.”  The last sentence in this paragraph says "the sender can determine if the destination is inside the LLN by looking if the destination address is matched by the DIO’s PIO option.”

This implies that “RPL-capable” does not mean “inside the LLN”, is this implication correct ?

Thanks!
Randy

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Aug 2016 21:44:07 -0400

Turner, Randy <[email-masked]> wrote:
    > In section 5, “Storing Mode”, first paragraph, there is a sentence that
    > says “the sender cannot determine whether the destination is
    > RPL-capable and thus would need an IP-in-IP header.”  The last sentence
    > in this paragraph says "the sender can determine if the destination is
    > inside the LLN by looking if the destination address is matched by the
    > DIO’s PIO option.”

    > This implies that “RPL-capable” does not mean “inside the LLN”, is this

I don't think so.
There may well be some editing that has to happen, since 2460bis assumption.
Maybe you can contribute some text to fix this so that it makes sense to you?

One can be inside the LLN, but be RPL-incapable. (a "leaf" or "IPv6 host")

One assumes that nodes outside the LLN are RPL-incapable, and one can
tell this buy looking seeing if the destination address matches the PIO.

{Clearly, with a 6BBR, one can have RPL nodes outside the local LLN
which are RPL-capable, but we can't tell that}

(or more to the point, before -07, routers would drop packets with RPL
artifacts on them. Starting at -07 we assume that RPI is okay, but RH3 is not)

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

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 3 Aug 2016 02:01:50 +0000

Hi Michael,

thanks for the reply  - comments below

R.

> On Aug 2, 2016, at 6:44 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Yes I understand that, post-plenary, some docs may be in flux due to 2460bis resolution, I
could probably suggest/submit something that works the way I believe is the intent.

> 
> One can be inside the LLN, but be RPL-incapable. (a "leaf" or "IPv6 host”)

Yes, the draft recognizes the RPL-incapable leaf

> which are RPL-capable, but we can't tell that}

Right, anything outside the DODAG/instance would probably have a different PIO prefix so comparing prefixes
is no guarantee the destination is not “RPL-capable”.
So “RPL-capable” might not be the right term to use — “outside the LLN”  might work,  in this case I’m inferring that the LLN is the local DODAG/instance

> artifacts on them. Starting at -07 we assume that RPI is okay, but RH3 is not)

Right, I understand that some 2460bis proposals would make life easier, but the discussion on hop-by-hop headers
and how they are handled is still undecided, or at least that was my takeaway from the plenary….is this right?

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

---

From: Ines Robles <[email-masked]>
Date: Mon, 8 Aug 2016 15:28:38 +0300

Hi,

2016-08-03 5:01 GMT+03:00 Turner, Randy <[email-masked]>:

> So “RPL-capable” might not be the right term to use — “outside the LLN”
> might work,  in this case I’m inferring that the LLN is the local
> DODAG/instance
>

What about to add this in the terminology section:

        RPL-node: It is device which implements RPL, thus we can say that
the device is RPL-capable or RPL-aware.
Please note that the device can be found inside the LLN or outside LLN.
In this document a RPL-node which is a leaf is called RPL-aware-leaf.

        RPL-not-capable: It is 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 this document a not-RPL-node which is a leaf is called
not-RPL-aware-leaf.

> and how they are handled is still undecided, or at least that was my
> takeaway from the plenary….is this right?
>

I understood from 6man that this paragraph is going to be kept:

"NOTE: While [RFC2460 <https://tools.ietf.org/html/rfc2460>] required that
all nodes must examine and

   process the Hop-by-Hop Options header, it is now expected that nodes
   along a packet's delivery path only examine and process the Hop-by-
   Hop Options header if explicitly configured to do so."

Thanks,

Ines.