Subject: Re: [Roll] [roll] #173 (useofrplinfo): Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf

From: "roll issue tracker" <[email-masked]>
Date: Fri, 19 Feb 2016 12:53:50 -0000

#173: Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf

Comment (by [email-masked]):

 Pascal said: “Yes

 We have to define the support for the non RPL leaf. This needs a different
 draft.

 My expectation is that the draft would indicate that the non RPL leaf is
 known by the 6LR through 6LowPAN ND with 6BBr extension (for the sequence
 number).

 IMHO, whether in storing or not storing, it would be good that the 6LR
 injects a DAO with self as transit with the external (E) bit set and the
 leaf address as target. So the other nodes know. So that in non-storing
 the root terminated the RH3 at the last router.

 Routing will take the packet back to that 6LR. The 6LR should strip the
 6LoRH, which is easy in the compressed format.

 But stripping is illegal unless there’s an IP in IP. So the problem is
 really the IP conformance. One way to solve that is to say that there is
 an implicit IP in IP from link local to link local in front of any 6LoRH.”

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  [email-masked]          |  [email-masked]
     Type:  defect                   |      Status:  new
 Priority:  major                    |   Milestone:
Component:  useofrplinfo             |     Version:
 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <https://tools.ietf.org/wg/roll/trac/ticket/173#comment:1>
roll <https://tools.ietf.org/wg/roll/>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 21 Feb 2016 22:51:55 -0500

At the interim meeting last fall, we came across two problems for which we have
no clear recommendation, and which we think needs some protocol work.

The situation is described in ticket 173, and in section 5.10 of useofrplinfo.

Consider the packet flow:
   6LN --> 6LR1 --> common parent (6LR2) --> 6LR3 --> not-RPL-aware 6LN

In storing mode the packet goes up to the common parent (which may be below
the root) via typically a default route, and then follows the hop-by-hop down
the tree.  An RPI header needs to be inserted by the 6LN.

In section 5.9 (Flow from RPL-aware-leaf to RPL-aware-leaf), an IPIP is not
necessary, since the receiving node is RPL aware, it can remove the RPI.

In this case, however, the end-node is not RPI aware, so the 6LR3 needs to
remove the RPI.  In order for that to happen, the IPIP header needs to be
addressed to 6LR3, but 6LN doesn't have any idea what 6LR3's address.

here are two possible ways to deal with this issue:

1) Pascal has pointed out that we can use an IPIP header on a hop-by-hop
   basis, using either link-local addresses, or even GUA addresses, but
   each IPIP header needs to be added/removed at each hop.

2) If the definition of the RPI was changed so that it isn't a
   "discard if not recognized" type.  This change is an incompatible
   on-the-wire change, and would represent a flag day.
   However, this change could perhaps be done with the updated 6LoRH
   compression work, as that is also an incompatible on-the-wire
   change for which we presently have no way to signal.

3) These proposals are not mutually exclusive: we could do both.

I'm not looking for "yes, I like proposal X", but rather I'm looking for
replies of the form of "I can not live with proposal X because Y"

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 22 Feb 2016 10:19:53 -0500

Michael Richardson <[email-masked]> wrote:
    > In section 5.9 (Flow from RPL-aware-leaf to RPL-aware-leaf), an IPIP is
    > not necessary, since the receiving node is RPL aware, it can remove the
    > RPI.

    > In this case, however, the end-node is not RPI aware, so the 6LR3 needs
    > to remove the RPI.  In order for that to happen, the IPIP header needs
    > to be addressed to 6LR3, but 6LN doesn't have any idea what 6LR3's
    > address.

I wanted to add that the sending node has no way of knowing if it is
in situation 5.9 or situation 5.10, so absent some signaling that there are
no non-RPL aware nodes in the DAG, then sending nodes must assume that the
receiver is not-RPI aware.

An additional possible protocol action might be to signal in the DIOs that
that the RPL network is entirely RPL-aware.  This would/could get negated by
DAOs having a bit so indicate if each target address is RPI aware (i.e. if it
was learned from ND or via DAO).

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Feb 2016 06:45:55 +0000

For completeness, Michael, 

The change Nb2 reverses a decision that makes sure that if a packet with an HbH header / RPI escapes the RPL domain, it is immediately discarded. This impact has to be weighted.

Cheers,

Pascal

> -----Original Message-----
> From: Roll [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: lundi 22 février 2016 04:52
> To: [email-masked]
> Subject: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-leaf
> 
> 
> At the interim meeting last fall, we came across two problems for which we
> have no clear recommendation, and which we think needs some protocol
> work.
> 
> In storing mode the packet goes up to the common parent (which may be
> below the root) via typically a default route, and then follows the hop-by-
> hop down the tree.  An RPI header needs to be inserted by the 6LN.
> 
> I'm not looking for "yes, I like proposal X", but rather I'm looking for replies
> of the form of "I can not live with proposal X because Y"
> 
> --

---

From: Simon Duquennoy <[email-masked]>
Date: Tue, 23 Feb 2016 18:39:53 +0100

Michael, Pascal,

I think we need at least #1 in order for the problem to be solved not only
in a 6LoRH context.
Having both #1 and #2 is even more appealing, for more simplicity in the
6LoRH case.

Thanks,
Simon

On Tue, Feb 23, 2016 at 7:45 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> The change Nb2 reverses a decision that makes sure that if a packet with
> an HbH header / RPI escapes the RPL domain, it is immediately discarded.
> This impact has to be weighted.
>
> Cheers,
>
> Pascal
>
>
> not
> to
> replies
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Feb 2016 09:41:19 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > The change Nb2 reverses a decision that makes sure that if a packet
    > with an HbH header / RPI escapes the RPL domain, it is immediately
    > discarded. This impact has to be weighted.

It would only be discarded if the receiving machine does not speak RPL/RPI.
If by chance, it does understand that header, then would not discard it by
2460 rule.  It could be configured to drop packets with RPI in them.

So the protection isn't that great in my opinion, while the cost is pretty
significant.   But, I agree that it's a concern.

We have the opportunity in 6LoRH to effectively make other incompatible
changes since deploying 6LoRH will be an incompatible change.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 29 Feb 2016 13:35:38 +0000

Agreed, Michael.

Pascal

> Sent: jeudi 25 février 2016 15:41
> To: Routing Over Low power and Lossy networks <[email-masked]>
> Subject: Re: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-
> leaf
> 
>