[Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-leaf

[Michael Richardson <[e-mail]>]

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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-