[Roll] changing the RPL RPI Option Type --- new version of useofrplinfo

[Michael Richardson <[e-mail]>]

I've been through an editorial pass of useofrplinfo.  The result is the -03
version of the document, which you can see diffs at:
        https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-useofrplinfo-02&url2=draft-ietf-roll-useofrplinfo-03

I think that I want to change all of the "not-RPL-aware" to "non-RPL-aware".
I shortened some of the column names in the tables so they would fit better,
and I split up the storing/non-storing table so that it would be easier to
read.  Now I wonder why I wrote "Raf" rather than "Ral".

Please see the summary in new section 7.

The thing I wanted to bring out is how much work the storing mode of RPL has
to do in order to deal with the Option Type being 0x63 rather than 0x43.
Here is the table.
"Raf"  ==     RPL Aware Router.
"!Raf" == non-RPL Aware Router.

   +---------------+--------------+--------------+----------+----------+
   | Use Case      | RPI (RFC     | RH3 (RFC     | IP-in-IP | IPIP dst |
   |               | 6553)        | 6554)        |          |          |
   +---------------+--------------+--------------+----------+----------+
   | Raf to root   | Yes          | No           | No       | --       |
   | root to Raf   | Yes          | No           | No       | --       |
   | root to ~Raf  | Yes          | No           | Yes      | hop   *  |
   | ~Raf to root  | Yes          | No           | Yes      | root     |
   | Raf to Int    | Yes          | No           | Yes      | root     |
   | Int to Raf    | Yes          | No           | Yes      | raf   *1 |
   | ~Raf to Int   | Yes          | No           | Yes      | root     |
   | Int to ~Raf   | Yes          | No           | Yes      | hop   *1 |
   | Raf to Raf    | Yes          | No           | No       | --    *2 |
   | Raf to ~Raf   | Yes          | No           | Yes      | hop   *2 |
   | ~Raf to Raf   | Yes          | No           | Yes      | dst   *2 |
   | ~Raf to ~Raf  | Yes          | No           | Yes      | hop   *2 |
   +---------------+--------------+--------------+----------+----------+

If an RPL LLN can be sure that there are no 6lowpan-only nodes, then it can
regularly avoid IPIP headers except for traffic entering or leaving the LLN.
Traffic entering the LLN is obvious to the 6LBR, so that part is easy.

Traffic leaving the LLN can usually be determine by comparing the destination
address to that of the prefix found in the DIO's PIO.  Traffic not matching
is going out the Internet and requires an IPIP header towards the 6LBR, which
will remove the RPI header on the way out.

If the RPL LLN is *not* certain that there are no 6lowpan-only nodes (%),
then nodes have no way of knowing if they are in the two situations marked
*1, or *2.  As such, they essentially have to send *ALL* traffic in the LLN
with *hop-by-hop* IPIP headers, as the RPI might have to be removed at any
point in the forwarding.  These hop-by-hop IPIP headers do *NOTHING* to help
steer ICMP messages back to the correct originating node unless each router
keeps state about each encapsulation/decapsulation it has done.

Note that the "always do hop-by-hop IPIP" solution does *not* work in the
non-storing case. Section 7.2 mentions this.

If we make the RPI Option Type 0x43, then all the cases marked "to ~Raf"
devolve into the cases marked "to Raf", and we can use RPI everywhere.
A change to the 6lowpan specification to say that Option Type 0x63 MUST be
recognized (and discarded by end hosts) would also work if there was still
value elsewhere.  We are about to have a flag day for 6lowpan hosts when it
comes to compressing these artifacts anyway.

I could redo useofrpl with the assumption that the Option Type was 0x43 and
show the resulting difference.


(%) - in RPL non-storing mode we actually get a signal to the 6LBR root that
    there are non-RPL nodes in the LLN.  We could create such a signal for
    storing mode.  In the storing mode case, this signal would have to be
    rebroadcast from the root to tell all nodes to go into hop-by-hop mode.
    As such the nodes would now have two code paths and all the problems of
    both.  Seems like a stupid thing to do.

Note that we do not have the same problems in non-storing mode because all
traffic goes through the root, and the root knows the entire topology, and
can figure out how to address the IPIP headers so that they the RPI is
removed before the leaf.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-