Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane
draft-ietf-roll-useofrplinfo-43

Internet-Draft               RPL-data-plane                 January 2021

   +-----------+--------------+--------------+--------------+----------+
   |   Header  |      RAL     |     6LR_i    |     6LBR     | Internet |
   |           |      src     |              |              |    dst   |
   +-----------+--------------+--------------+--------------+----------+
   |   Added   | IPv6-in-IPv6 |      --      |      --      |    --    |
   |  headers  |     (RPI)    |              |              |          |
   +-----------+--------------+--------------+--------------+----------+
   |  Modified |      --      |              |      --      |    --    |
   |  headers  |              |     RPI      |              |          |
   +-----------+--------------+--------------+--------------+----------+
   |  Removed  |      --      |      --      | IPv6-in-IPv6 |    --    |
   |  headers  |              |              |     (RPI)    |          |
   +-----------+--------------+--------------+--------------+----------+
   | Untouched |      --      |      --      |      --      |    --    |
   |  headers  |              |              |              |          |
   +-----------+--------------+--------------+--------------+----------+

   Figure 28: Non-SM: Summary of the use of headers from RAL to Internet
                      with encapsulation to the root

8.2.2.  Non-SM: Example of Flow from Internet to RAL

   In this case the flow comprises:

   Internet --> root (6LBR) --> 6LR_i --> RAL dst (6LN)

   For example, a communication flow could be: Internet --> Node A
   (root) --> Node B --> Node D --> Node F (RAL)

   6LR_i represents the intermediate routers from source to destination,
   1 <= i <= n, where n is the total number of routers (6LR) that the
   packet goes through from 6LBR to destination (RAL).

   The 6LBR must add an RH3 header.  As the 6LBR will know the path and
   address of the target node, it can address the IPv6-in-IPv6 header to
   that node.  The 6LBR will zero the flow label upon entry in order to
   aid compression [RFC8138].

   The Figure 29 summarizes what headers are needed for this use case.

Robles, et al.            Expires July 14, 2021                [Page 43]
Internet-Draft               RPL-data-plane                 January 2021

   +-----------+----------+--------------+--------------+--------------+
   |   Header  | Internet |     6LBR     |     6LR_i    |      RAL     |
   |           |    src   |              |              |      dst     |
   +-----------+----------+--------------+--------------+--------------+
   |   Added   |    --    | IPv6-in-IPv6 |      --      |      --      |
   |  headers  |          |  (RH3, RPI)  |              |              |
   +-----------+----------+--------------+--------------+--------------+
   |  Modified |    --    |      --      | IPv6-in-IPv6 |      --      |
   |  headers  |          |              |  (RH3, RPI)  |              |
   +-----------+----------+--------------+--------------+--------------+
   |  Removed  |    --    |      --      |      --      | IPv6-in-IPv6 |
   |  headers  |          |              |              |  (RH3, RPI)  |
   +-----------+----------+--------------+--------------+--------------+
   | Untouched |    --    |      --      |      --      |      --      |
   |  headers  |          |              |              |              |
   +-----------+----------+--------------+--------------+--------------+

   Figure 29: Non-SM: Summary of the use of headers from Internet to RAL

8.2.3.  Non-SM: Example of Flow from RUL to Internet

   In this case the flow comprises:

   RUL (IPv6 src node) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet
   dst

   For example, a communication flow could be: Node G --> Node E -->
   Node B --> Node A --> Internet

   6LR_i represents the intermediate routers from source to destination,
   1 <= i <= n, where n is the total number of routers (6LRs) that the
   packet goes through from the source (RUL) to the 6LBR, e.g., 6LR_1
   (i=1).

   In this case the flow label is recommended to be zero in the RUL.  As
   the RUL parent adds RPL headers in the RUL packet, the first 6LR
   (6LR_1) will add an RPI inside a new IPv6-in-IPv6 header.  The IPv6-
   in-IPv6 header will be addressed to the root.  This case is identical
   to the storing-mode case (see Section 7.2.3).

   The Figure 30 shows the table that summarizes what headers are needed
   for this use case.

Robles, et al.            Expires July 14, 2021                [Page 44]
Internet-Draft               RPL-data-plane                 January 2021

   +---------+----+-------------+--------------+--------------+--------+
   |  Header |RUL |    6LR_1    |     6LR_i    |     6LBR     |Internet|
   |         |src |             |  [i=2,..,n]  |              |  dst   |
   |         |node|             |              |              |        |
   +---------+----+-------------+--------------+--------------+--------+
   |  Added  | -- |IP6-IP6(RPI) |      --      |      --      |   --   |
   | headers |    |             |              |              |        |
   +---------+----+-------------+--------------+--------------+--------+
   | Modified| -- |     --      |     RPI      |      --      |   --   |
   | headers |    |             |              |              |        |
   +---------+----+-------------+--------------+--------------+--------+
   | Removed | -- |     --      |      --      | IP6-IP6(RPI) |   --   |
   | headers |    |             |              |              |        |
   +---------+----+-------------+--------------+--------------+--------+
   |Untouched| -- |     --      |      --      |      --      |   --   |
   | headers |    |             |              |              |        |
   +---------+----+-------------+--------------+--------------+--------+

   Figure 30: Non-SM: Summary of the use of headers from RUL to Internet

8.2.4.  Non-SM: Example of Flow from Internet to RUL

   In this case the flow comprises:

   Internet src --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)

   For example, a communication flow could be: Internet --> Node A
   (root) --> Node B --> Node E --> Node G

   6LR_i represents the intermediate routers from source to destination,
   1 <= i <= n, where n is the total number of routers (6LR) that the
   packet goes through from 6LBR to RUL.

   The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header.  The
   6LBR will know the path, and will recognize that the final node is
   not a RPL capable node as it will have received the connectivity DAO
   from the nearest 6LR.  The 6LBR can therefore make the IPv6-in-IPv6
   header destination be the last 6LR.  The 6LBR will set to zero the
   flow label upon entry in order to aid compression [RFC8138].

   The Figure 31 shows the table that summarizes what headers are needed
   for this use case.

Robles, et al.            Expires July 14, 2021                [Page 45]
Internet-Draft               RPL-data-plane                 January 2021

  +----------+--------+------------------+-----------+-----------+-----+
  |  Header  |Internet|       6LBR       |   6LR_i   |   6LR_n   | RUL |
  |          |   src  |                  |           |           | dst |
  +----------+--------+------------------+-----------+-----------+-----+
  |  Added   |   --   | IP6-IP6(RH3,RPI) |     --    |     --    |  -- |
  | headers  |        |                  |           |           |     |
  +----------+--------+------------------+-----------+-----------+-----+
  | Modified |   --   |        --        |  IP6-IP6  |     --    |  -- |
  | headers  |        |                  | (RH3,RPI) |           |     |
  +----------+--------+------------------+-----------+-----------+-----+
  | Removed  |   --   |        --        |     --    |  IP6-IP6  |  -- |
  | headers  |        |                  |           | (RH3,RPI) |     |
  +----------+--------+------------------+-----------+-----------+-----+
  |Untouched |   --   |        --        |     --    |     --    |  -- |
  | headers  |        |                  |           |           |     |
  +----------+--------+------------------+-----------+-----------+-----+

     Figure 31: Non-SM: Summary of the use of headers from Internet to
                                   RUL.

8.3.  Non-SM: Interaction between leaves

   In this section is described the communication flow in Non Storing
   Mode (Non-SM) between,

      RAL to RAL

      RAL to RUL

      RUL to RAL

      RUL to RUL

8.3.1.  Non-SM: Example of Flow from RAL to RAL

   In this case the flow comprises:

   RAL src --> 6LR_ia --> root (6LBR) --> 6LR_id --> RAL dst

   For example, a communication flow could be: Node F (RAL src)--> Node
   D --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL
   dst)

   6LR_ia represents the intermediate routers from source to the root, 1
   <= ia <= n, where n is the total number of routers (6LR) that the
   packet goes through from RAL to the root.

Robles, et al.            Expires July 14, 2021                [Page 46]
Internet-Draft               RPL-data-plane                 January 2021

   6LR_id represents the intermediate routers from the root to the
   destination, 1 <= id <= m, where m is the total number of the
   intermediate routers (6LR).

   This case involves only nodes in same RPL domain.  The originating
   node will add an RPI to the original packet, and send the packet
   upwards.

   The originating node may put the RPI (RPI1) into an IPv6-in-IPv6
   header addressed to the root, so that the 6LBR can remove that
   header.  If it does not, then the RPI1 is forwarded down from the
   root in the inner header to no avail.

   The 6LBR will need to insert an RH3 header, which requires that it
   add an IPv6-in-IPv6 header.  It removes the RPI(RPI1), as it was
   contained in an IPv6-in-IPv6 header addressed to it.  Otherwise,
   there may be an RPI buried inside the inner IP header, which should
   get ignored.  The root inserts an RPI (RPI2) alongside the RH3.

   Networks that use the RPL P2P extension [RFC6997] are essentially
   non-storing DODAGs and fall into this scenario or scenario
   Section 8.1.2, with the originating node acting as 6LBR.

   The Figure 32 shows the table that summarizes what headers are needed
   for this use case when encapsulation to the root takes place.

   The Figure 33 shows the table that summarizes what headers are needed
   for this use case when there is no encapsulation to the root.  Note
   that in the Modified headers row, going up in each 6LR_ia only the
   RPI1 is changed.  Going down, in each 6LR_id the IPv6 header is
   swapped with the RH3 so both are changed alongside with the RPI2.

Robles, et al.            Expires July 14, 2021                [Page 47]
Internet-Draft               RPL-data-plane                 January 2021

   +---------+-------+----------+------------+----------+------------+
   |  Header | RAL   |   6LR_ia |    6LBR    | 6LR_id   |     RAL    |
   |         | src   |          |            |          |     dst    |
   +---------+-------+----------+------------+----------+------------+
   |  Added  |IP6-IP6|          |  IP6-IP6   |  --      |     --     |
   | headers |(RPI1) |   --     |(RH3-> RAL, |          |            |
   |         |       |          |   RPI2)    |          |            |
   +---------+-------+----------+------------+----------+------------+
   | Modified|  --   |          |    --      | IP6-IP6  |    --      |
   | headers |       |   RPI1   |            |(RH3,RPI2)|            |
   +---------+-------+----------+------------+----------+------------+
   | Removed |    -- |    --    |   IP6-IP6  |  --      |  IP6-IP6   |
   | headers |       |          |   (RPI1)   |          |   (RH3,    |
   |         |       |          |            |          |   RPI2)    |
   +---------+-------+----------+------------+----------+------------+
   |Untouched|    -- |    --    |    --      |  --      |    --      |
   | headers |       |          |            |          |            |
   +---------+-------+----------+------------+----------+------------+

   Figure 32: Non-SM: Summary of the Use of Headers from RAL to RAL with
                        encapsulation to the root.

   +-----------+------+--------+---------+---------+---------+
   |   Header  |  RAL | 6LR_ia |   6LBR  |  6LR_id |   RAL   |
   +-----------+------+--------+---------+---------+---------+
   |  Inserted | RPI1 |   --   | IP6-IP6 |    --   |    --   |
   |  headers  |      |        |  (RH3,  |         |         |
   |           |      |        |   RPI2) |         |         |
   +-----------+------+--------+---------+---------+---------+
   |  Modified |  --  |  RPI1  |    --   | IP6-IP6 |    --   |
   |  headers  |      |        |         |  (RH3,  |         |
   |           |      |        |         |   RPI2) |         |
   +-----------+------+--------+---------+---------+---------+
   |  Removed  |  --  |   --   |    --   |    --   | IP6-IP6 |
   |  headers  |      |        |         |         |  (RH3,  |
   |           |      |        |         |         |   RPI2) |
   |           |      |        |         |         |         |
   +-----------+------+--------+---------+---------+---------+
   | Untouched |  --  |   --   |   RPI1  |   RPI1  |   RPI1  |
   |  headers  |      |        |         |         |(Ignored)|
   +-----------+------+--------+---------+---------+---------+

     Figure 33: Non-SM: Summary of the Use of Headers from RAL to RAL
                    without encapsulation to the root.

Robles, et al.            Expires July 14, 2021                [Page 48]
Internet-Draft               RPL-data-plane                 January 2021

8.3.2.  Non-SM: Example of Flow from RAL to RUL

   In this case the flow comprises:

   RAL --> 6LR_ia --> root (6LBR) --> 6LR_id --> RUL (IPv6 dst node)

   For example, a communication flow could be: Node F (RAL) --> Node D
   --> Node B --> Node A (root) --> Node B --> Node E --> Node G (RUL)

   6LR_ia represents the intermediate routers from source to the root, 1
   <= ia <= n, where n is the total number of intermediate routers (6LR)

   6LR_id represents the intermediate routers from the root to the
   destination, 1 <= id <= m, where m is the total number of the
   intermediate routers (6LRs).

   As in the previous case, the RAL (6LN) may insert an RPI (RPI1)
   header which must be in an IPv6-in-IPv6 header addressed to the root
   so that the 6LBR can remove this RPI.  The 6LBR will then insert an
   RH3 inside a new IPv6-in-IPv6 header addressed to the last 6LR_id
   (6LR_id = m) alongside the insertion of RPI2.

   If the originating node does not put the RPI (RPI1) into an IPv6-in-
   IPv6 header addressed to the root.  Then, the RPI1 is forwarded down
   from the root in the inner header to no avail.

   The Figure 34 shows the table that summarizes what headers are needed
   for this use case when encapsulation to the root takes place.  The
   Figure 35 shows the table that summarizes what headers are needed for
   this use case when no encapsulation to the root takes place.

Robles, et al.            Expires July 14, 2021                [Page 49]
Internet-Draft               RPL-data-plane                 January 2021

  +-----------+---------+---------+---------+---------+---------+------+
  |   Header  |   RAL   |  6LR_ia |   6LBR  |  6LR_id |  6LR_m  | RUL  |
  |           |   src   |         |         |         |         | dst  |
  |           |   node  |         |         |         |         | node |
  +-----------+---------+---------+---------+---------+---------+------+
  |   Added   | IP6-IP6 |         | IP6-IP6 |    --   |    --   |  --  |
  |  headers  |  (RPI1) | --      |  (RH3,  |         |         |      |
  |           |         |         |   RPI2) |         |         |      |
  +-----------+---------+---------+---------+---------+---------+------+
  |  Modified |    --   |         |    --   | IP6-IP6 |         |  --  |
  |  headers  |         |  RPI1   |         |  (RH3,  |  --     |      |
  |           |         |         |         |   RPI2) |         |      |
  +-----------+---------+---------+---------+---------+---------+------+
  |  Removed  |    --   |    --   | IP6-IP6 |    --   | IP6-IP6 |  --  |
  |  headers  |         |         |  (RPI1) |         |  (RH3,  |      |
  |           |         |         |         |         |   RPI2) |      |
  +-----------+---------+---------+---------+---------+---------+------+
  | Untouched |    --   |    --   |    --   |    --   |    --   |  --  |
  |  headers  |         |         |         |         |         |      |
  +-----------+---------+---------+---------+---------+---------+------+

   Figure 34: Non-SM: Summary of the use of headers from RAL to RUL with
                        encapsulation to the root.

   +-----------+------+--------+---------+---------+---------+---------+
   |   Header  |  RAL | 6LR_ia |   6LBR  |  6LR_id |  6LR_n  |   RUL   |
   |           |  src |        |         |         |         |   dst   |
   |           | node |        |         |         |         |   node  |
   +-----------+------+--------+---------+---------+---------+---------+
   |  Inserted | RPI1 |   --   | IP6-IP6 |    --   |    --   |    --   |
   |  headers  |      |        |  (RH3,  |         |         |         |
   |           |      |        |   RPI2) |         |         |         |
   +-----------+------+--------+---------+---------+---------+---------+
   |  Modified |  --  |  RPI1  |    --   | IP6-IP6 |    --   |    --   |
   |  headers  |      |        |         |  (RH3,  |         |         |
   |           |      |        |         |   RPI2) |         |         |
   +-----------+------+--------+---------+---------+---------+---------+
   |  Removed  |  --  |   --   |    --   |    --   | IP6-IP6 |    --   |
   |  headers  |      |        |         |         |  (RH3,  |         |
   |           |      |        |         |         |   RPI2) |         |
   +-----------+------+--------+---------+---------+---------+---------+
   | Untouched |  --  |   --   |   RPI1  |   RPI1  |   RPI1  |   RPI1  |
   |  headers  |      |        |         |         |         |(Ignored)|
   +-----------+------+--------+---------+---------+---------+---------+

     Figure 35: Non-SM: Summary of the use of headers from RAL to RUL
                    without encapsulation to the root.

Robles, et al.            Expires July 14, 2021                [Page 50]
Internet-Draft               RPL-data-plane                 January 2021

8.3.3.  Non-SM: Example of Flow from RUL to RAL

   In this case the flow comprises:

   RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id
   --> RAL dst (6LN)

   For example, a communication flow could be: Node G (RUL)--> Node E
   --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL)

   6LR_ia represents the intermediate routers from source to the root, 1
   <= ia <= n, where n is the total number of intermediate routers (6LR)

   6LR_id represents the intermediate routers from the root to the
   destination, 1 <= id <= m, where m is the total number of the
   intermediate routers (6LR).

   In this scenario the RPI (RPI1) is added by the first 6LR (6LR_1)
   inside an IPv6-in-IPv6 header addressed to the root.  The 6LBR will
   remove this RPI, and add its own IPv6-in-IPv6 header containing an
   RH3 header and an RPI (RPI2).

   The Figure 36 shows the table that summarizes what headers are needed
   for this use case.

   +----------+------+---------+---------+---------+---------+---------+
   |  Header  | RUL  |  6LR_1  |  6LR_ia |   6LBR  |  6LR_id |   RAL   |
   |          | src  |         |         |         |         |   dst   |
   |          | node |         |         |         |         |   node  |
   +----------+------+---------+---------+---------+---------+---------+
   |  Added   |  --  | IP6-IP6 |    --   | IP6-IP6 |    --   |    --   |
   | headers  |      |  (RPI1) |         |  (RH3,  |         |         |
   |          |      |         |         |   RPI2) |         |         |
   +----------+------+---------+---------+---------+---------+---------+
   | Modified |  --  |         |         |    --   | IP6-IP6 |    --   |
   | headers  |      |  --     |  RPI1   |         |  (RH3,  |         |
   |          |      |         |         |         |   RPI2) |         |
   +----------+------+---------+---------+---------+---------+---------+
   | Removed  |  --  |         |    --   | IP6-IP6 |    --   | IP6-IP6 |
   | headers  |      | --      |         |  (RPI1) |         |  (RH3,  |
   |          |      |         |         |         |         |   RPI2) |
   +----------+------+---------+---------+---------+---------+---------+
   |Untouched |  --  | --      |    --   |    --   |    --   |    --   |
   | headers  |      |         |         |         |         |         |
   +----------+------+---------+---------+---------+---------+---------+

     Figure 36: Non-SM: Summary of the use of headers from RUL to RAL.

Robles, et al.            Expires July 14, 2021                [Page 51]
Internet-Draft               RPL-data-plane                 January 2021

8.3.4.  Non-SM: Example of Flow from RUL to RUL

   In this case the flow comprises:

   RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id
   --> RUL (IPv6 dst node)

   For example, a communication flow could be: Node G --> Node E -->
   Node B --> Node A (root) --> Node C --> Node J

   6LR_ia represents the intermediate routers from source to the root, 1
   <= ia <= n, where n is the total number of intermediate routers (6LR)

   6LR_id represents the intermediate routers from the root to the
   destination, 1 <= id <= m, where m is the total number of the
   intermediate routers (6LR).

   This scenario is the combination of the previous two cases.

   The Figure 37 shows the table that summarizes what headers are needed
   for this use case.

   +---------+------+-------+-------+---------+-------+---------+------+
   |  Header | RUL  | 6LR_1 | 6LR_ia|   6LBR  |6LR_id |  6LR_m  | RUL  |
   |         | src  |       |       |         |       |         | dst  |
   |         | node |       |       |         |       |         | node |
   +---------+------+-------+-------+---------+-------+---------+------+
   |  Added  |  --  |IP6-IP6|  --   | IP6-IP6 |  --   |    --   |  --  |
   | headers |      | (RPI1)|       |  (RH3,  |       |         |      |
   |         |      |       |       |   RPI2) |       |         |      |
   +---------+------+-------+-------+---------+-------+---------+------+
   | Modified|  --  |  --   |       |    --   |IP6-IP6|    --   |  --  |
   | headers |      |       |  RPI1 |         | (RH3, |         |      |
   |         |      |       |       |         |  RPI2)|         |      |
   +---------+------+-------+-------+---------+-------+---------+------+
   | Removed |  --  |  --   |  --   | IP6-IP6 |  --   | IP6-IP6 |  --  |
   | headers |      |       |       |  (RPI1) |       |  (RH3,  |      |
   |         |      |       |       |         |       |   RPI2) |      |
   +---------+------+-------+-------+---------+-------+---------+------+
   |Untouched|  --  |  --   |  --   |    --   |  --   |    --   |  --  |
   | headers |      |       |       |         |       |         |      |
   +---------+------+-------+-------+---------+-------+---------+------+

     Figure 37: Non-SM: Summary of the use of headers from RUL to RUL

Robles, et al.            Expires July 14, 2021                [Page 52]
Internet-Draft               RPL-data-plane                 January 2021

9.  Operational Considerations of supporting RUL-leaves

   Roughly half of the situations described in this document involve
   leaf ("host") nodes that do not speak RPL.  These nodes fall into two
   further categories: ones that drop a packet that have RPI or RH3
   headers, and ones that continue to process a packet that has RPI and/
   or RH3 headers.

   [RFC8200] provides for new rules that suggest that nodes that have
   not been configured (explicitly) to examine Hop-by-Hop headers,
   should ignore those headers, and continue processing the packet.
   Despite this, and despite the switch from 0x63 to 0x23, there may be
   nodes that are pre-RFC8200, or simply intolerant.  Those nodes will
   drop packets that continue to have RPL artifacts in them.  In
   general, such nodes can not be easily supported in RPL LLNs.

   There are some specific cases where it is possible to remove the RPL
   artifacts prior to forwarding the packet to the leaf host.  The
   critical thing is that the artifacts have been inserted by the RPL
   root inside an IPv6-in-IPv6 header, and that the header has been
   addressed to the 6LR immediately prior to the leaf node.  In that
   case, in the process of removing the IPv6-in-IPv6 header, the
   artifacts can also be removed.

   The above case occurs whenever traffic originates from the outside
   the LLN (the "Internet" cases above), and non-storing mode is used.
   In non-storing mode, the RPL root knows the exact topology (as it
   must create the RH3 header) and therefore knows which 6LR is prior to
   the leaf.  For example, in Figure 6, Node E is the 6LR prior to leaf
   Node G, or Node C is the 6LR prior to leaf Node J.

   Traffic originating from the RPL root (such as when the data
   collection system is co-located on the RPL root), does not require an
   IPv6-in-IPv6 header (in storing or non-storing mode), as the packet
   is originating at the root, and the root can insert the RPI and RH3
   headers directly into the packet, as it is formed.  Such a packet is
   slightly smaller, but only can be sent to nodes (whether RPL aware or
   not), that will tolerate the RPL artifacts.

   An operator that finds itself with a high amount of traffic from the
   RPL root to RPL-not-aware-leaves, will have to do IPv6-in-IPv6
   encapsulation if the leaf is not tolerant of the RPL artifacts.  Such
   an operator could otherwise omit this unnecessary header if it was
   certain of the properties of the leaf.

   As storing mode can not know the final path of the traffic,
   intolerant (that drop packets with RPL artifacts) leaf nodes can not
   be supported.

Robles, et al.            Expires July 14, 2021                [Page 53]
Internet-Draft               RPL-data-plane                 January 2021

10.  Operational considerations of introducing 0x23

   This section describes the operational considerations of introducing
   the new RPI Option Type of 0x23.

   During bootstrapping the node gets the DIO with the information of
   RPI Option Type, indicating the new RPI in the DODAG Configuration
   option Flag.  The DODAG root is in charge to configure the current
   network to the new value, through DIO messages and when all the nodes
   are set with the new value.  The DODAG should change to a new DODAG
   version.  In case of rebooting, the node does not remember the RPI
   Option Type.  Thus, the DIO is sent with a flag indicating the new
   RPI Option Type.

   The DODAG Configuration option is contained in a RPL DIO message,
   which contains a unique DTSN counter.  The leaf nodes respond to this
   message with DAO messages containing the same DTSN.  This is a normal
   part of RPL routing; the RPL root therefore knows when the updated
   DODAG Configuration option has been seen by all nodes.

   Before the migration happens, all the RPL-aware nodes should support
   both values .  The migration procedure is triggered when the DIO is
   sent with the flag indicating the new RPI Option Type.  Namely, it
   remains at 0x63 until it is sure that the network is capable of 0x23,
   then it abruptly changes to 0x23.  The 0x23 RPI Option allows to send
   packets to not-RPL nodes.  The not-RPL nodes should ignore the option
   and continue processing the packets.

   As mentioned previously, indicating the new RPI in the DODAG
   Configuration option flag is a way to avoid the flag day (abrupt
   changeover) in a network using 0x63 as the RPI Option Type value.  It
   is suggested that RPL implementations accept both 0x63 and 0x23 RPI
   Option type values when processing the header to enable
   interoperability.

11.  IANA Considerations

11.1.  Option Type in RPL Option

   This document updates the registration made in [RFC6553] Destination
   Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in
   Figure 38.

Robles, et al.            Expires July 14, 2021                [Page 54]
Internet-Draft               RPL-data-plane                 January 2021

   +-------+-------------------+------------------------+---------- -+
   |  Hex  |    Binary Value   |       Description      | Reference  |
   + Value +-------------------+                        +            +
   |       | act | chg |  rest |                        |            |
   +-------+-----+-----+-------+------------------------+------------+
   |  0x23 |  00 |  1  | 00011 |       RPL Option       |[RFCXXXX](*)|
   +-------+-----+-----+-------+------------------------+------------+
   |  0x63 |  01 |  1  | 00011 | RPL Option(DEPRECATED) | [RFC6553]  |
   |       |     |     |       |                        |[RFCXXXX](*)|
   +-------+-----+-----+-------+------------------------+------------+

     Figure 38: Option Type in RPL Option.(*)represents this document

   DODAG Configuration option is updated as follows (Figure 39):

                 +------------+-----------------+---------------+
                 | Bit number |   Description   |   Reference   |
                 +------------+-----------------+---------------+
                 |      3     | RPI 0x23 enable | This document |
                 +------------+-----------------+---------------+

   Figure 39: DODAG Configuration option Flag to indicate the RPI-flag-
                                   day.

11.2.  Change to the DODAG Configuration Options Flags registry

   This document requests IANA to change the name of the "DODAG
   Configuration Option Flags" registry to "DODAG Configuration Option
   Flags for MOP 0..6".

   This document requests to be mentioned as a reference for this
   change.

11.3.  Change MOP value 7 to Reserved

   This document requests the changing the registration status of value
   7 in the Mode of Operation registry from Unassigned to Reserved.
   This change is in support of future work.

   This document requests to be mentioned as a reference for this entry
   in the registry.

Robles, et al.            Expires July 14, 2021                [Page 55]
Internet-Draft               RPL-data-plane                 January 2021

12.  Security Considerations

   The security considerations covered in [RFC6553] and [RFC6554] apply
   when the packets are in the RPL Domain.

   The IPv6-in-IPv6 mechanism described in this document is much more
   limited than the general mechanism described in [RFC2473].  The
   willingness of each node in the LLN to decapsulate packets and
   forward them could be exploited by nodes to disguise the origin of an
   attack.

   While a typical LLN may be a very poor origin for attack traffic (as
   the networks tend to be very slow, and the nodes often have very low
   duty cycles), given enough nodes, LLNs could still have a significant
   impact, particularly if the attack is targeting another LLN.
   Additionally, some uses of RPL involve large backbone ISP scale
   equipment [I-D.ietf-anima-autonomic-control-plane], which may be
   equipped with multiple 100Gb/s interfaces.

   Blocking or careful filtering of IPv6-in-IPv6 traffic entering the
   LLN as described above will make sure that any attack that is mounted
   must originate from compromised nodes within the LLN.  The use of
   BCP38 [BCP38] filtering at the RPL root on egress traffic will both
   alert the operator to the existence of the attack, as well as drop
   the attack traffic.  As the RPL network is typically numbered from a
   single prefix, which is itself assigned by RPL, BCP38 filtering
   involves a single prefix comparison and should be trivial to
   automatically configure.

   There are some scenarios where IPv6-in-IPv6 traffic should be allowed
   to pass through the RPL root, such as the IPv6-in-IPv6 mediated
   communications between a new Pledge and the Join Registrar/
   Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra]
   and [I-D.ietf-6tisch-dtsecurity-zerotouch-join].  This is the case
   for the RPL root to do careful filtering: it occurs only when the
   Join Coordinator is not co-located inside the RPL root.

   With the above precautions, an attack using IPv6-in-IPv6 tunnels can
   only be by a node within the LLN on another node within the LLN.
   Such an attack could, of course, be done directly.  An attack of this
   kind is meaningful only if the source addresses are either fake or if
   the point is to amplify return traffic.  Such an attack, could also
   be done without the use of IPv6-in-IPv6 headers using forged source
   addresses.  If the attack requires bi-directional communication, then
   IPv6-in-IPv6 provides no advantages.

   Whenever IPv6-in-IPv6 headers are being proposed, there is a concern
   about creating security issues.  In the Security Considerations

Robles, et al.            Expires July 14, 2021                [Page 56]
Internet-Draft               RPL-data-plane                 January 2021

   section of [RFC2473], it was suggested that tunnel entry and exit
   points can be secured by securing the IPv6 path between them.  This
   recommendation is not practical for RPL networks.  [RFC5406] goes
   into some detail on what additional details would be needed in order
   to "Use IPsec".  Use of ESP would prevent [RFC8138] compression
   (compression must occur before encryption), and [RFC8138] compression
   is lossy in a way that prevents use of AH.  These are minor issues.
   The major issue is how to establish trust enough such that IKEv2
   could be used.  This would require a system of certificates to be
   present in every single node, including any Internet nodes that might
   need to communicate with the LLN.  Thus, using IPsec requires a
   global PKI in the general case.

   More significantly, the use of IPsec tunnels to protect the IPv6-in-
   IPv6 headers would in the general case scale with the square of the
   number of nodes.  This is a lot of resource for a constrained nodes
   on a constrained network.  In the end, the IPsec tunnels would be
   providing only BCP38-like origin authentication!  That is, IPsec
   provides a transitive guarantee to the tunnel exit point that the
   tunnel entry point did BCP38 on traffic going in.  Just doing origin
   filtering per BCP 38 at the entry and exit of the LLN provides a
   similar level of security without all the scaling and trust problems
   related to IPv6 tunnels as discussed in RFC 2473.  IPsec is not
   recommended.

   An LLN with hostile nodes within it would not be protected against
   impersonation with the LLN by entry/exit filtering.

   The RH3 header usage described here can be abused in equivalent ways
   (to disguise the origin of traffic and attack other nodes) with an
   IPv6-in-IPv6 header to add the needed RH3 header.  As such, the
   attacker's RH3 header will not be seen by the network until it
   reaches the end host, which will decapsulate it.  An end-host should
   be suspicious about an RH3 header which has additional hops which
   have not yet been processed, and SHOULD ignore such a second RH3
   header.

   In addition, the LLN will likely use [RFC8138] to compress the IPv6-
   in-IPv6 and RH3 headers.  As such, the compressor at the RPL-root
   will see the second RH3 header and MAY choose to discard the packet
   if the RH3 header has not been completely consumed.  A consumed
   (inert) RH3 header could be present in a packet that flows from one
   LLN, crosses the Internet, and enters another LLN.  As per the
   discussion in this document, such headers do not need to be removed.
   However, there is no case described in this document where an RH3 is
   inserted in a non-storing network on traffic that is leaving the LLN,
   but this document should not preclude such a future innovation.  It
   should just be noted that an incoming RH3 must be fully consumed, or

Robles, et al.            Expires July 14, 2021                [Page 57]
Internet-Draft               RPL-data-plane                 January 2021

   very carefully inspected to match a policy that applies to this
   network and is correctly processed by the leaves.

   The RPI, if permitted to enter the LLN, could be used by an attacker
   to change the priority of a packet by selecting a different
   RPLInstanceID, perhaps one with a higher energy cost, for instance.
   It could also be that not all nodes are reachable in an LLN using the
   default RPLInstanceID, but a change of RPLInstanceID would permit an
   attacker to bypass such filtering.  Like the RH3, an RPI is to be
   inserted by the RPL root on traffic entering the LLN by first
   inserting an IPv6-in-IPv6 header.  The attacker's RPI therefore will
   not be seen by the network.  Upon reaching the destination node the
   RPI has no further meaning and is just skipped; the presence of a
   second RPI will have no meaning to the end node as the packet has
   already been identified as being at it's final destination.

   For traffic leaving a RUL, if the RUL adds an opaque RPI then the 6LR
   as a RPL border router SHOULD rewrite the RPI to indicate the
   selected Instance and set the flags.  This is done in order to avoid:
   1) The leaf is an external router that passes a packet that it did
   not generate and that carries an unrelated RPI and 2) The leaf is an
   attacker or presents misconfiguration and tries to inject traffic in
   a protected instance.  Also, this applies in the case where the leaf
   is aware of the RPL instance and passes a correct RPI; the 6LR needs
   a configuration that allows that leaf to inject in that instance.

   The RH3 and RPIs could be abused by an attacker inside of the network
   to route packets on non-obvious ways, perhaps eluding observation.
   This usage appears consistent with a normal operation of [RFC6997]
   and can not be restricted at all.  This is a feature, not a bug.

   [RFC7416] deals with many other threats to LLNs not directly related
   to the use of IPv6-in-IPv6 headers, and this document does not change
   that analysis.

   Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an
   attack on another part of the LLN, while disguising the origin of the
   attack.  The mechanism can even be abused to make it appear that the
   attack is coming from outside the LLN, and unless countered, this
   could be used to mount a Distributed Denial Of Service attack upon
   nodes elsewhere in the Internet.  See [DDOS-KREBS] for an example of
   such attacks already seen in the real world.

   If an attack comes from inside of LLN, it can be alleviated with SAVI
   (Source Address Validation Improvement) using [RFC8505] with
   [I-D.ietf-6lo-ap-nd].  The attacker will not be able to source
   traffic with an address that is not registered, and the registration
   process checks for topological correctness.  Notice that there is an

Robles, et al.            Expires July 14, 2021                [Page 58]
Internet-Draft               RPL-data-plane                 January 2021

   L2 authentication in most of the cases.  If an attack comes from
   outside LLN IPv6-in- IPv6 can be used to hide inner routing headers,
   but by construction, the RH3 can typically only address nodes within
   the LLN.  That is, an RH3 with a CmprI less than 8 , should be
   considered an attack (see RFC6554, section 3).

   Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic
   through the RPL root to perform this attack.  To counter, the RPL
   root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the
   simpler solution), or it SHOULD walk the IP header extension chain
   until it can inspect the upper-layer-payload as described in
   [RFC7045].  In particular, the RPL root SHOULD do [BCP38] processing
   on the source addresses of all IP headers that it examines in both
   directions.

   Note: there are some situations where a prefix will spread across
   multiple LLNs via mechanisms such as the one described in
   [I-D.ietf-6lo-backbone-router].  In this case the BCP38 filtering
   needs to take this into account, either by exchanging detailed
   routing information on each LLN, or by moving the BCP38 filtering
   further towards the Internet, so that the details of the multiple
   LLNs do not matter.

13.  Acknowledgments

   This work is done thanks to the grant given by the StandICT.eu
   project.

   A special BIG thanks to C.  M.  Heard for the help with the
   Section 4.  Much of the redaction in that section is based on his
   comments.

   Additionally, the authors would like to acknowledge the review,
   feedback, and comments of (alphabetical order): Dominique Barthel,
   Robert Cragie, Simon Duquennoy, Ralph Droms, Cenk Guendogan, Rahul
   Jadhav, Benjamin Kaduk, Matthias Kovatsch, Gustavo Mercado,
   Subramanian Moonesamy, Marcela Orbiscay, Charlie Perkins, Cristian
   Perez, Alvaro Retana, Peter van der Stok, Xavier Vilajosana, Eric
   Vyncke and Thomas Watteyne.

14.  References

14.1.  Normative References

   [BCP38]    Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <https://www.rfc-editor.org/info/bcp38>.

Robles, et al.            Expires July 14, 2021                [Page 59]
Internet-Draft               RPL-data-plane                 January 2021

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6040]  Briscoe, B., "Tunnelling of Explicit Congestion
              Notification", RFC 6040, DOI 10.17487/RFC6040, November
              2010, <https://www.rfc-editor.org/info/rfc6040>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <https://www.rfc-editor.org/info/rfc6282>.

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

   [RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
              Power and Lossy Networks (RPL) Option for Carrying RPL
              Information in Data-Plane Datagrams", RFC 6553,
              DOI 10.17487/RFC6553, March 2012,
              <https://www.rfc-editor.org/info/rfc6553>.

   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
              Routing Header for Source Routes with the Routing Protocol
              for Low-Power and Lossy Networks (RPL)", RFC 6554,
              DOI 10.17487/RFC6554, March 2012,
              <https://www.rfc-editor.org/info/rfc6554>.

   [RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
              of IPv6 Extension Headers", RFC 7045,
              DOI 10.17487/RFC7045, December 2013,
              <https://www.rfc-editor.org/info/rfc7045>.

   [RFC8025]  Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
              RFC 8025, DOI 10.17487/RFC8025, November 2016,
              <https://www.rfc-editor.org/info/rfc8025>.

   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
              "IPv6 over Low-Power Wireless Personal Area Network
              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
              April 2017, <https://www.rfc-editor.org/info/rfc8138>.

Robles, et al.            Expires July 14, 2021                [Page 60]
Internet-Draft               RPL-data-plane                 January 2021

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

14.2.  Informative References

   [DDOS-KREBS]
              Goodin, D., "Record-breaking DDoS reportedly delivered by
              >145k hacked cameras", September 2016,
              <http://arstechnica.com/security/2016/09/botnet-of-145k-
              cameras-reportedly-deliver-internets-biggest-ddos-ever/>.

   [I-D.ietf-6lo-ap-nd]
              Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
              "Address Protected Neighbor Discovery for Low-power and
              Lossy Networks", draft-ietf-6lo-ap-nd-23 (work in
              progress), April 2020.

   [I-D.ietf-6lo-backbone-router]
              Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
              Backbone Router", draft-ietf-6lo-backbone-router-20 (work
              in progress), March 2020.

   [I-D.ietf-6tisch-dtsecurity-zerotouch-join]
              Richardson, M., "6tisch Zero-Touch Secure Join protocol",
              draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in
              progress), July 2019.

   [I-D.ietf-anima-autonomic-control-plane]
              Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
              Control Plane (ACP)", draft-ietf-anima-autonomic-control-
              plane-30 (work in progress), October 2020.

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-45 (work in progress), November 2020.

   [I-D.ietf-intarea-tunnels]
              Touch, J. and M. Townsley, "IP Tunnels in the Internet
              Architecture", draft-ietf-intarea-tunnels-10 (work in
              progress), September 2019.

Robles, et al.            Expires July 14, 2021                [Page 61]
Internet-Draft               RPL-data-plane                 January 2021

   [I-D.ietf-roll-unaware-leaves]
              Thubert, P. and M. Richardson, "Routing for RPL Leaves",
              draft-ietf-roll-unaware-leaves-28 (work in progress),
              December 2020.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <https://www.rfc-editor.org/info/rfc2460>.

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
              December 1998, <https://www.rfc-editor.org/info/rfc2473>.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", STD 89,
              RFC 4443, DOI 10.17487/RFC4443, March 2006,
              <https://www.rfc-editor.org/info/rfc4443>.

   [RFC5406]  Bellovin, S., "Guidelines for Specifying the Use of IPsec
              Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406,
              February 2009, <https://www.rfc-editor.org/info/rfc5406>.

   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
              "IPv6 Flow Label Specification", RFC 6437,
              DOI 10.17487/RFC6437, November 2011,
              <https://www.rfc-editor.org/info/rfc6437>.

   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,
              <https://www.rfc-editor.org/info/rfc6775>.

   [RFC6997]  Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
              J. Martocci, "Reactive Discovery of Point-to-Point Routes
              in Low-Power and Lossy Networks", RFC 6997,
              DOI 10.17487/RFC6997, August 2013,
              <https://www.rfc-editor.org/info/rfc6997>.

   [RFC7102]  Vasseur, JP., "Terms Used in Routing for Low-Power and
              Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
              2014, <https://www.rfc-editor.org/info/rfc7102>.

Robles, et al.            Expires July 14, 2021                [Page 62]
Internet-Draft               RPL-data-plane                 January 2021

   [RFC7416]  Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
              and M. Richardson, Ed., "A Security Threat Analysis for
              the Routing Protocol for Low-Power and Lossy Networks
              (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
              <https://www.rfc-editor.org/info/rfc7416>.

   [RFC8180]  Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
              IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
              Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
              May 2017, <https://www.rfc-editor.org/info/rfc8180>.

   [RFC8504]  Chown, T., Loughney, J., and T. Winters, "IPv6 Node
              Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
              January 2019, <https://www.rfc-editor.org/info/rfc8504>.

   [RFC8505]  Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
              Perkins, "Registration Extensions for IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Neighbor
              Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
              <https://www.rfc-editor.org/info/rfc8505>.

Authors' Addresses

   Maria Ines Robles
   Universidad Tecno. Nac.(UTN)-FRM, Argentina/ Aalto University Finland

   Email: mariainesrobles@gmail.com

   Michael C. Richardson
   Sandelman Software Works
   470 Dawson Avenue
   Ottawa, ON  K1Z 5V7
   CA

   Email: mcr+ietf@sandelman.ca
   URI:   http://www.sandelman.ca/mcr/

   Pascal Thubert
   Cisco Systems, Inc
   Building D
   45 Allee des Ormes - BP1200
   MOUGINS - Sophia Antipolis  06254
   FRANCE

   Phone: +33 497 23 26 34
   Email: pthubert@cisco.com

Robles, et al.            Expires July 14, 2021                [Page 63]