[Roll] AD Review of draft-ietf-roll-useofrplinfo-23

[Alvaro Retana <[e-mail]>]

Dear authors:

I have (finally!) finished reading this document.  Thanks for all the work
and time put into working out all the details.

I have several concerns.  I'm listing some of the Major (and document-wide)
ones up front.  I also put more comments and questions inline below.

(1) [major] Where is the specification of the data-plane behavior?

This document does a couple of things: it Updates several other RFCs, and
presents a list of *example* flows where the expected behavior is
illustrated.  The Updates are mostly about the new RPI value (0x23), but
not about the behavior of the nodes.

Most of the examples are worded such that they describe actions
(encapsulate, remove, etc.)...and some even include rfc2119 Normative
Keywords.  But they are called examples!  So...my questions are: is the
behavior illustrated in §6 and §7 intended to be Normative?  IOW, do these
sections include both examples and specify the behavior expected in the
LLN?  Is the behavior already specified somewhere else (and this document
is just illustrating)?  [I am asking that last question just-in-case,
because the Introduction says that "this document clarifies what is the
correct and the incorrect behaviour."]

§8 seems to attempt to summarize "observations about the cases", but (if it
is intended to be *the* Normative text about the behavior) it is general
and short.

[Some of my comments below ask about Normative language... Please take
those in context with the answers here.]


(2) [major] Operational Considerations

Non-storing mode networks don't need the change to 0x23 (§8.2)...but making
the change creates a flag day, and even then, implementations should still
process both values (§3.1).  I would really like to see text about the
operational considerations of introducing 0x23.  It concerns me that a
significant change that most[*] networks don't need is being introduced.
Please take a look at rfc5706 (Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions), specially §2.

[*] Most deployed networks work in non-storing mode, right?


(3) [minor] >= ??

There are several (25!) instances of text like this:

   6LR_i are the intermediate routers from source to destination.  In
   this case, "1 <= i >= n", n is the number of routers (6LR) that the
   packet go through from source (6LN) to destination (6LBR).

Maybe it's just me, but I don't understand why (or how!) i could ever be >=
n.  The text says that i are the "intermediate routers from source to
destination", while n is "the number of routers...from source (6LN) to
destination (6LBR)".  Isn't that the same thing?  What am I missing?


(4) Style nit: the document uses "we"...a third person style would be
preferable.  For example: s/In this section we are going to
describe.../This section describes...


I will wait for the major points to be addressed before starting the IETF
LC.

Thanks!!

Alvaro.



[Note: the numbers came from the idnits output.]

...
10              When to use RFC 6553, 6554 and IPv6-in-IPv6
11                    draft-ietf-roll-useofrplinfo-23

[minor] Can we come up with a more descriptive tittle?  Also, the
"shorthand" version ("Useof6553") could be improved.


...
130 1.  Introduction
...
156   The related document A Routing Header Dispatch for 6LoWPAN (6LoRH)
157   [RFC8138] defines a method to compress RPL Option information and
158   Routing Header type 3 [RFC6554], an efficient IP-in-IP technique, and
159   use cases proposed for the [Second6TischPlugtest] involving 6loRH.

[nit] I'm having trouble parsing this last paragraph.  It sounds like
rfc8138 (also) defines the use cases, but I don't remember seeing anything
like that in there.  Is that what you meant?

[nit] I think the Introduction would benefit from an overview of the
document; something like "section X talks about abc, section Y presents
examples, etc.".

161 2.  Terminology and Requirements Language

163   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
164   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
165   document are to be interpreted as described in RFC 2119 [RFC2119].

[major] Please use the RFC8174 template.

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

[nit] RPL-capable is not used anywhere else.

...
180   pledge: a new device which seeks admission to a network. (from
181   [I-D.ietf-anima-bootstrapping-keyinfra])

183   Join Registrar and Coordinator (JRC): a device which brings new nodes
184   (pledges) into a network. (from
185   [I-D.ietf-anima-bootstrapping-keyinfra])

[minor] Do these two terms need to be defined in this document?  They are
only used once, and with a reference to
I-D.ietf-anima-bootstrapping-keyinfra next to them.  Also, and more
important, the definition here doesn't match the one in that other draft.
Please take out the definitions and just make reference later on...

187   Flag day: A "flag day" is a procedure in which the network, or a part
188   of it, is changed during a planned outage, or suddenly, causing an
189   outage while the network recovers [RFC4192]

[nit] rfc4192 seems like an odd place to pull a reference to "flag day" --
specially as it is being defined as "a procedure" and not the effect it
causes, which seems to be how it is used in the text: "creates a flag day",
"will experience a flag day", "avoid a flag day".  This is not a big issue
-- if it was up to me, I would either make my own definition, or just not
define it at all: I think it is a well known term...

191 2.1.  hop-by-hop IPv6-in-IPv6 headers

193   The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header
194   that originates from a node to an adjacent node, using the addresses
195   (usually the GUA or ULA, but could use the link-local addresses) of
196   each node.  If the packet must traverse multiple hops, then it must
197   be decapsulated at each hop, and then re-encapsulated again in a
198   similar fashion.

[minor] That term is not used anywhere...but "hop-by-hop IP-in-IP" is.

IPv6-in-IPv6 and IP-in-IP are used interchangeably throughout the
document.  This use is not wrong, but it is inconsistent.  Adding a note
about it (even though it may be obvious to many readers that the terms
refer to the same thing) would be nice...being consistent even nicer.

Later on, "IPIP" is also used...


[nit] Why is this definition in its own sub-section?

200 3.  Updates to RFC6553, RFC6550 and RFC 8138

202 3.1.  Updates to RFC 6553

...
209   [RFC6553] states as showed below, that in the Option Type field of
210   the RPL Option header, the two high order bits MUST be set to '01'
211   and the third bit is equal to '1'.  The first two bits indicate that
212   the IPv6 node MUST discard the packet if it doesn't recognize the
213   option type, and the third bit indicates that the Option Data may
214   change en route.  The remaining bits serve as the option type.

s/showed/shown

[major] The 2 MUSTs used above are used paraphrasing rfc6553, and don't
define Normative behavior in this document.  Please either use a direct
quote, or use non-normative language.

...
223   Recent changes in [RFC8200] (section 4, page 8), states: "it is now
224   expected that nodes along a packet's delivery path only examine and
225   process the Hop-by-Hop Options header if explicitly configured to do
226   so".  Processing of the Hop-by-Hop Options header (by IPv6
227   intermediate nodes) is now optional, but if they are configured to
228   process the header, and if such nodes encounter an option with the
229   first two bits set to 01, they will drop the packet (if they conform
230   to [RFC8200]).  Host systems should do the same, irrespective of the
231   configuration.

[minor] The description above seems to be missing "...if the option is not
recognized".

233   Based on That, if an IPv6 (intermediate) node (RPL-not-capable)
234   receives a packet with an RPL Option, it should ignore the HBH RPL
235   option (skip over this option and continue processing the header).

s/That/that

...
266   When forwarding packets, implementations SHOULD use the same value as
267   it was received (This is required because, RPI type code can not be
268   changed by [RFC8200]).  It allows to the network to be incrementally
269   upgraded, and for the DODAG root to know which parts of the network
270   are upgraded.

[major] There seems to be a contradiction above: "SHOULD use the same
value...this is required..."   If required by rfc8200, why not use MUST?

272   When originating new packets, implementations SHOULD have an option
273   to determine which value to originate with, this option is controlled
274   by the DIO option described below.

[minor] §3.3 defines the option...but it doesn't explicitly say what the
receivers should do with it.  It may be obvious, but it should be explicit
for completeness.

[major] It seems to me that the paragraph above may be out of place,
doesn't say much, may be wrong...or maybe all 3.  The text says that the
originating value is controlled by the option in §3.3 (again, but that
section doesn't explicitly say what should be done)...but it also says
(with the SHOULD) that an implementation may have valid reasons to not pay
attention to the option -- what are those??


...
281 3.2.  Updates to RFC 8138

283   RPI-6LoRH header provides a compressed form for the RPL RPI
284   [RFC8138].  It should be considered when the Option Type in RPL
285   Option is decompressed, should take the value of 0x23 instead of
286   0x63.

[major] AFAICT, the compression specified in rfc8138 doesn't include the
RPI option type...but the use of the 6LoRH Type 5 implies the RPI.  If I
got that right, then how would the decompressing node know which RPI type
was in use when first compressed?  Given that both types may be used in a
network (§3.1), how would one know unless the 6LoRH type was also changed?
Or are you suggesting that the decompression should always use 0x23?  In
any case, I think that stronger language might be needed.


288 3.3.  Updates to RFC 6550: Indicating the new RPI in the DODAG
289      Configuration Option Flag.

291   In order to avoid a flag day caused by lack of interoperation between
292   new RPI (0x23) and old RPI (0x63) nodes, when there is a mix of new
293   nodes and old nodes, the new nodes may be put into a compatibility
294   mode until all of the old nodes are replaced or upgraded.

296   This can be done via a DODAG Configuration Option flag which will
297   propogate through the network.  Failure to receive this information
298   will cause new nodes to remain in compatibility mode, and originate
299   traffic with the old-RPI (0x63) value.

s/propogate/propagate

[major] "compatibility mode"

What is "compatibility mode"?  Initially I thought that it was maybe the
ability of new nodes to use both RPI values...but the end of the second
paragraph suggests using only 0x63.

The text suggests that "compatibility mode" can be enabled via "via a DODAG
Configuration Option flag" -- that flag is not defined anywhere...but
"failure to receive this information will cause new nodes to remain in
compatibility mode".  So...would it be enabled using a flag, or is it the
default?

Why wouldn't the default be the new RPI?  I can see how most of the
networks will support the old RPI, but that will eventually be the
exception...

301   As stated in [RFC6550] the DODAG Configuration option is present in
302   DIO messages.  The DODAG Configuration option distributes
303   configuration information.  It is generally static, and does not
304   change within the DODAG.  This information is configured at the DODAG
305   root and distributed throughout the DODAG with the DODAG
306   Configuration option.  Nodes other than the DODAG root do not modify
307   this information when propagating the DODAG Configuration option.

309   The DODAG Configuration Option has a Flags field which is modified by
310   this document.  Currently, the DODAG Configuration Option in
311   [RFC6550] is as follows. .

313   Flags: The 4-bits remaining unused in the Flags field are reserved
314   for flags.  The field MUST be initialized to zero by the sender and
315   MUST be ignored by the receiver.

317 0                       1                    2                     3
318 +-----------------+---------------------------------------------------+
319 |  Type = 0x04    |  Opt Length = 14| Flags  | A | PCS| DIOIntDoubl.  |
320 +---------------------------------------------------------------------+
321 | DIOIntMin.      |  DIORedund.     |  MaxRankIncrease                |
322 +-----------------+---------------------------------------------------+
323 |  MinHopRankIncrease               |            OCP                  |
324 +-----------------+---------------------------------------------------+
325 |Reserved         | Def. Lifetime   |         Lifetime Unit           |
326 +-----------------+-----------------+---------------------------------+

328                   Figure 3: DODAG Configuration Option.

[minor] Suggestion: instead of copying (and not quoting the Normative
language) the text from rfc6550 above, just indicate what the Update is:
"the unused bits MUST...".  Also, I think that Figure 3 is not needed.


...
342   In case of rebooting, the node does not remember the flag.  Thus, the
343   DIO is sent with flag indicating the new RPI value.

[minor] By "the node", which node are you referring to?  The root?  If it
doesn't remember, it means that it needs to be configured -- how does that
happen?  Why isn't the configuration persistent at the root?

345 4.  Sample/reference topology

347   A RPL network in general is composed of a 6LBR (6LoWPAN Border
348   Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN
349   (6LoWPAN Node) as leaf logically organized in a DODAG structure.
350   (Destination Oriented Directed Acyclic Graph).

[minor] The 6BBR doesn't appear in the Figure.

[nit] BTW, it might be better to put the topology diagram right after this
first paragraph.

[nit] The DODAG expansion should be on first use.

352   RPL defines the RPL Control messages (control plane), a new ICMPv6
353   [RFC4443]  message with Type 155.  DIS (DODAG Information
354   Solicitation), DIO (DODAG Information Object) and DAO (Destination
355   Advertisement Object) messages are all RPL Control messages but with
356   different Code values.  A RPL Stack is showed in Figure 5.

[minor] Not exactly sure what this paragraph has to do with the reference
topology (yet), but (same comment as above) it might be good to put the
figure right after the text.

s/showed/shown


...
428                    Figure 6: A reference RPL Topology.

430   Figure 2 shows the reference RPL Topology for this document.  The
431   letters above the nodes are there so that they may be referenced in
432   subsequent sections.  In the figure, 6LR represents a full router
433   node.  The 6LN is a RPL aware router, or host.

s/Figure 2/Figure 6

[minor] The 6LN is defined in the first paragraph as a node (not a
router).  BTW, what is the difference between a "full router" and (just) a
"router" (6LR vs 6LN)?

[minor] 6LN is characterized above as "RPL aware", but (below) the "Raf"
mark is also used for that -- so it seems that "~Raf 6LN" would be a
"not-RPL aware leaf...RPL aware router, or host".

Some terminology clean up is needed.

435   But, the 6LN leaves (Raf - "RPL aware leaf"-) marked as (F, H and I)
436   are RPL nodes with no children hosts.

[minor] Is there a relevance to the "children hosts" existing?  Can it be
concluded that ~Raf nodes have children hosts?


...
446 5.  Use cases
...
507   This means that when the no-drop RPI option code 0x23 is used, a
508   packet that leaves the RPL domain of an LLN (or that leaves the LLN
509   entirely) will not be discarded when it contains the [RFC6553] RPL
510   Hop-by-Hop option known as RPI.  Thus, the RPI Hop-by-Hop option MAY
511   be left in place even if the end host does not understand it.

[minor] If the last RPL-aware node knows that the host doesn't understand
the RPI, why would it not remove it (if it can)?  IOW, I understand how it
causes no harm (leading to the optional behavior above), but just because
it can be done doesn't mean that it should.  Are there cases where it can
be used for something?

If the RPI can't be removed because the border is not the destination, then
the MAY above is insignificant: no one can strip it, so there's no real
option.

513   NOTE: There is some possible security risk when the RPI information
514   is released to the Internet.  At this point this is a theoretical
515   situation; no clear attack has been described.  At worst, it is clear
516   that the RPI option would waste some network bandwidth when it
517   escapes.  This is traded off against the savings in the LLN by not
518   having to encapsulate the packet in order to remove the artifact.

[major] AFAICT, leaking the RPI means leaking the RPLInstanceID and the
SenderRank.  The Security Considerations already mentions what an attacker
could do if it knows the RPLInstanceID...but it doesn't say anything about
the SenderRank.

I'm thinking that the SenderRank may help an attacker to have an idea of
the topology of the LLN, right?  I don't know what an attacker can do with
that information, but the fact that could be used for that (and it could be
a privacy issue) should be mentioned in the Security Considerations section.

...
526   A corollory is that an SHR3 or RPI Option can only be removed by an
527   intermediate router if it is placed in an encapsulating IPv6 Header,
528   which is addressed TO the intermediate router.  When it does so, the
529   whole encapsulating header must be removed.  (A replacement may be
530   added).  This sometimes can result in outer IP headers being
531   addressed to the next hop router using link-local addresses.

s/corollory/corollary


...
541   RPI should be present in every single RPL data packet.  There is one
542   exception in non-storing mode: when a packet is going down from the
543   root.  In a downward non-storing mode, the entire route is written,
544   so there can be no loops by construction, nor any confusion about
545   which forwarding table to use (as the root has already made all
546   routing decisions).  However, there are still cases, such as in
547   6tisch, where the instanceID portion of the RPI header may still be
548   needed to pick an appropriate priority or channel at each hop.

[major] So...does that mean: in all cases, except downward non-storing mode
if 6tisch is not used, the RPI SHOULD be present?  Note that some of the
examples in §7 actually say that the RPI is optional...

550   In the tables present in this document, the term "RPL aware leaf" is
551   has been shortened to "Raf", and "not-RPL aware leaf" has been
552   shortened to "~Raf" to make the table fit in available space.

s/is has been/has been

[nit] There's some repetition; Raf, for example, was already introduced
earlier in this section.

...
557 6.  Storing mode

559   In storing mode (fully stateful), the sender can determine if the
560   destination is inside the LLN by looking if the destination address
561   is matched by the DIO's PIO option.

[nit] Please expand PIO...

563   The following table itemizes which headers are needed in the
564   following scenarios, and indicates if the IP-in-IP header must be
565   inserted on a hop-by-hop basis, or when it can target the destination
566   node directly.  There are these possible situations: hop-by-hop
567   necessary (indicated by "hop"), or destination address possible
568   (indicated by "dst").  In all cases hop by hop MAY be used.

[major] Should there be something else Normative in this paragraph?  Maybe
a MUST to indicate the need for "hop", as in "the IP-in-IP header MUST be
inserted on a hop-by-hop basis"?

[minor] I'm confused by the nomenclature.  The description above seems to
indicate that "hop" and "dst" are mutually exclusive...but the table shows
a column with a title using "dst" and specific rows containing "hop".  What
does that mean?

570   In cases where no IP-in-IP header is needed, the column is left
571   blank.

[minor] In Figure 7, there are "blank" columns (containing "--"), but there
are also entries that say "No".  Are they meant to indicate the same thing?

573   In all cases the RPI headers are needed, since it identifies
574   inconsistencies (loops) in the routing topology.  In all cases the
575   RH3 is not needed because we do not indicate the route in storing
576   mode.

578   In each case, 6LR_i are the intermediate routers from source to
579   destination.  "1 <= i >= n", n is the number of routers (6LR) that
580   the packet go through from source (6LN) to destination.

582   The leaf can be a router 6LR or a host, both indicated as 6LN (see
583   Figure 6).

585   +---------------------+--------------+----------+--------------+
586   | Interaction between |   Use Case   | IP-in-IP | IP-in-IP dst |
587   +---------------------+--------------+----------+--------------+
588   |                     |  Raf to root |    No    |      --      |
589   +                     +--------------+----------+--------------+
590   |     Leaf - Root     |  root to Raf |    No    |      --      |
591   +                     +--------------+----------+--------------+
592   |                     | root to ~Raf |    No    |      --      |
593   +                     +--------------+----------+--------------+
594   |                     | ~Raf to root |    Yes   |     root     |
595   +---------------------+--------------+----------+--------------+
596   |                     |  Raf to Int  |    No    |      --      |
597   +                     +--------------+----------+--------------+
598   |   Leaf - Internet   |  Int to Raf  |   Yes    |      Raf     |
599   +                     +--------------+----------+--------------+
600   |                     |  ~Raf to Int |    Yes   |     root     |
601   +                     +--------------+----------+--------------+
602   |                     |  Int to ~Raf |    Yes   |      hop     |
603   +---------------------+--------------+----------+--------------+
604   |                     |  Raf to Raf  |    No    |      --      |
605   +                     +--------------+----------+--------------+
606   |                     |  Raf to ~Raf |    No    |      --      |
607   +     Leaf - Leaf     +--------------+----------+--------------+
608   |                     |  ~Raf to Raf |    Yes   |      dst     |
609   +                     +--------------+----------+--------------+
610   |                     | ~Raf to ~Raf |    Yes   |      hop     |
611   +---------------------+--------------+----------+--------------+

613             Figure 7: IP-in-IP encapsulation in Storing mode.

...
726 6.1.4.  SM: Example of Flow from not-RPL-aware-leaf to root

728   In this case the flow comprises:

730   not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR)

732   For example, a communication flow could be: Node G --> Node E -->
733   Node B --> Node A root(6LBR)

735   When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E),
736   the 6LR_1 will insert a RPI header, encapsuladed in a IPv6-in-IPv6
737   header.  The IPv6-in-IPv6 header can be addressed to the next hop
738   (Node B), or to the root (Node A).  The root removes the header and
739   processes the packet.

[minor] The table below doesn't reflect the case where the IPv6-in-IPv6
header is addressed to the next hop.

741   +------------+------+---------------+---------------+---------------+
742   | Header     | IPv6 | 6LR_1         | 6LR_i         | 6LBR          |
743   +------------+------+---------------+---------------+---------------+
744   | Inserted   | --   | IP-in-IP(RPI) | --            | --            |
745   | headers    |      |               |               |               |
746   | Removed    | --   | --            | --            | IP-in-IP(RPI) |
747   | headers    |      |               |               |               |
748   | Re-added   | --   | --            | --            | --            |
749   | headers    |      |               |               |               |
750   | Modified   | --   | --            | IP-in-IP(RPI) | --            |
751   | headers    |      |               |               |               |
752   | Untouched  | --   | --            | --            | --            |
753   | headers    |      |               |               |               |
754   +------------+------+---------------+---------------+---------------+

756     Storing: Summary of the use of headers from not-RPL-aware-leaf to
757                                   root

...
772 6.2.1.  SM: Example of Flow from RPL-aware-leaf to Internet

774   RPL information from RFC 6553 MAY go out to Internet as it will be
775   ignored by nodes which have not been configured to be RPI aware.

[major] The "MAY" (Normative) is out of place as the sentence above is
stating a fact, not specifying a behavior. s/MAY/may

...
835 6.2.3.  SM: Example of Flow from not-RPL-aware-leaf to Internet

837   In this case the flow comprises:

839   not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) -->
840   Internet

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

845   The 6LR_1 (i=1) node will add an IP-in-IP(RPI) header addressed
846   either to the root, or hop-by-hop such that the root can remove the
847   RPI header before passing upwards.  The IP-in-IP addressed to the
848   root cause less processing overhead.  On the other hand, with hop-by-
849   hop the intermediate routers can check the routing tables for a
850   better routing path, thus it could be more efficient and faster.
851   Implementation should decide wich approach to take.

s/wich/which

[minor] The hop-by-hop option is not reflected in the table.


853   The originating node will ideally leave the IPv6 flow label as zero
854   so that the packet can be better compressed through the LLN.  The
855   6LBR will set the flow label of the packet to a non-zero value when
856   sending to the Internet.

858   +---------+-----+-------------+-------------+-------------+---------+
859   | Header  | IPv | 6LR_1       | 6LR_i       | 6LBR        | Interne |
860   |         | 6   |             | [i=2,..,n]_ |             | t       |
861   +---------+-----+-------------+-------------+-------------+---------+
862   | Inserte | --  | IP-in-      | --          | --          | --      |
863   | d       |     | IP(RPI)     |             |             |         |
864   | headers |     |             |             |             |         |
865   | Removed | --  | --          | --          | IP-in-      | --      |
866   | headers |     |             |             | IP(RPI)     |         |
867   | Re-     | --  | --          | --          | --          | --      |
868   | added   |     |             |             |             |         |
869   | headers |     |             |             |             |         |
870   | Modifie | --  | --          | IP-in-      | --          | --      |
871   | d       |     |             | IP(RPI)     |             |         |
872   | headers |     |             |             |             |         |
873   | Untouch | --  | --          | --          | --          | --      |
874   | ed      |     |             |             |             |         |
875   | headers |     |             |             |             |         |
876   +---------+-----+-------------+-------------+-------------+---------+

878     Storing: Summary of the use of headers from not-RPL-aware-leaf to
879                                 Internet

881 6.2.4.  SM: Example of Flow from Internet to non-RPL-aware-leaf

883   In this case the flow comprises:

885   Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)

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

890   The 6LBR will have to add an RPI header within an IP-in-IP header.
891   The IP-in-IP is addressed to the not-RPL-aware-leaf, leaving the RPI
892   inside.

[minor] The table below seems to be missing the not-RPL-aware-leaf removing
the IP-in-IP header.

894   Note that there is a requirement that the final node be able to
895   remove one or more IP-in-IP headers which are all addressed to it,
896   mentioned in [I-D.thubert-roll-unaware-leaves] :

898   "RPL data packets are often encapsulated using IP in IP.  The 6LN
899   MUST be able to decapsulate a packet when it is the destination of
900   the outer header and process correctly the inner header."

[major] I realize that we're not reviewing I-D.thubert-roll-unaware-leaves
at this point, but how can a requirement be placed on a not-RPL-aware-leaf
if, by definition, it is not aware of RPL??   ...and I don't think we can
assume it is aware of any other requirement...

If this document depends on the requirement in
I-D.thubert-roll-unaware-leaves, then the reference should be Normative (it
is now listed as Informative).

...
935 6.3.1.  SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf
...
959   It is assume that the two nodes are in the same RPL Domain (that they
960   share the same DODAG root).  At the common parent (Node B), the
961   direction of RPI is changed (from increasing to decreasing the rank).

s/assume/assumed


...
1079 6.3.4.  SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware-
1080        leaf
...
1102   The 6LR_1 (Node E) receives the packet from the the IPv6 node (Node
1103   G) and inserts the RPI header (RPIa), encapsulated in an IPv6-in-IPv6
1104   header.  The IPv6-in-IPv6 header is addressed to the final
1105   destination.

[minor] As in 6.2.4, which node removes the IP-in-IP header?  For
completion, it seems like the table is missing the fact that the "IPv6 dst"
node ignores the RPI.

1107   +----------+-----+-------------+--------------+--------------+------+
1108   | Header   | IPv | 6LR_1       | 6LR_ia       | 6LR_m        | IPv6 |
1109   |          | 6   |             |              |              | dst  |
1110   |          | src |             |              |              |      |
1111   +----------+-----+-------------+--------------+--------------+------+
1112   | Inserted | --  | IP-in-      | --           | --           | --   |
1113   | headers  |     | IP(RPI)     |              |              |      |
1114   | Removed  | --  | --          | --           | --           | --   |
1115   | headers  |     |             |              |              |      |
1116   | Re-added | --  | --          | --           | --           | --   |
1117   | headers  |     |             |              |              |      |
1118   | Modified | --  | --          | IP-in-       | IP-in-       | --   |
1119   | headers  |     |             | IP(RPI)      | IP(RPI)      |      |
1120   | Untouche | --  | --          | --           | --           | --   |
1121   | d        |     |             |              |              |      |
1122   | headers  |     |             |              |              |      |
1123   +----------+-----+-------------+--------------+--------------+------+

1125     Storing: Summary of the use of headers from not-RPL-aware-leaf to
1126                            non-RPL-aware-leaf

1128 7.  Non Storing mode
...
1147   +-----------------+--------------+-----+-----+----------+----------+
1148   |   Interaction   |   Use Case   | RPI | RH3 | IP-in-IP | IP-in-IP |
1149   |      between    |              |     |     |          |    dst   |
1150   +-----------------+--------------+-----+-----+----------+----------+
1151   |                 |  Raf to root | Yes | No  |    No    |    --    |
1152   +                 +--------------+-----+-----+----------+----------+
1153   |   Leaf - Root   |  root to Raf | Opt | Yes |    No    |    --    |
1154   +                 +--------------+-----+-----+----------+----------+
1155   |                 | root to ~Raf |no(1)| Yes |    Yes   |    6LR   |
1156   +                 +--------------+-----+-----+----------+----------+
1157   |                 | ~Raf to root | Yes | No  |    Yes   |   root   |
1158   +-----------------+--------------+-----+-----+----------+----------+
1159   |                 |  Raf to Int  | Yes | No  |    Yes   |   root   |
1160   +                 +--------------+-----+-----+----------+----------+
1161   | Leaf - Internet |  Int to Raf  |no(1)| Yes |   Yes    |    dst   |
1162   +                 +--------------+-----+-----+----------+----------+
1163   |                 |  ~Raf to Int | Yes | No  |    Yes   |   root   |
1164   +                 +--------------+-----+-----+----------+----------+
1165   |                 |  Int to ~Raf |no(1)| Yes |    Yes   |    6LR   |
1166   +-----------------+--------------+-----+-----+----------+----------+
1167   |                 |  Raf to Raf  | Yes | Yes |    Yes   | root/dst |
1168   +                 +--------------+-----+-----+----------+----------+
1169   |                 |  Raf to ~Raf | Yes | Yes |    Yes   | root/6LR |
1170   +   Leaf - Leaf   +--------------+-----+-----+----------+----------+
1171   |                 |  ~Raf to Raf | Yes | Yes |    Yes   | root/6LN |
1172   +                 +--------------+-----+-----+----------+----------+
1173   |                 | ~Raf to ~Raf | Yes | Yes |    Yes   | root/6LR |
1174   +-----------------+--------------+-----+-----+----------+----------+

1176   (1)-6tisch networks may need the RPI information.

[major] When?  What are the conditions when it is needed?

1178     Figure 8: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP
1179                              encapsulation.
...
1194 7.1.1.  Non-SM: Example of Flow from RPL-aware-leaf to root

1196   In non-storing mode the leaf node uses default routing to send
1197   traffic to the root.  The RPI header must be included to avoid/detect
1198   loops.

[major] Should that "must" be Normative?

...
1224 7.1.2.  Non-SM: Example of Flow from root to RPL-aware-leaf
...
1236   The 6LBR will insert an RH3, and may optionally insert an RPI header.

[major] Under which conditions should the RPI header be inserted?  Or is it
the case where it is not necessary, but it causes no harm if it's there?
Are there benefits?  It would be nice to be precise in the specification to
achieve consistent behavior.

...
1254 7.1.3.  Non-SM: Example of Flow from root to not-RPL-aware-leaf
...
1267   In 6LBR the RH3 is added, it is modified at each intermediate 6LR
1268   (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n),
1269   but left there.  If RPI is left present, the IPv6 node which does not
1270   understand it will ignore it (following RFC8200), thus encapsulation
1271   is not necesary.  Due the complete knowledge of the topology at the
1272   root, the 6LBR may optionally address the IP-in-IP header to the last
1273   6LR, such that it is removed prior to the IPv6 node.

s/necesary/necessary

[major] So...encapsulation is not needed, but an IP-in-IP header is
optional.  When?  Are there advantages, disadvantages?   Same questions
about the RPI.

1275   +---------------+-------------+---------------+--------------+------+
1276   | Header        | 6LBR        | 6LR_i(i=1)    | 6LR_n(i=n)   | IPv6 |
1277   +---------------+-------------+---------------+--------------+------+
1278   | Inserted      | (opt: RPI), | --            | --           | --   |
1279   | headers       | RH3         |               |              |      |
1280   | Removed       | --          | RH3           | --           | --   |
1281   | headers       |             |               |              |      |
1282   | Re-added      | --          | --            | --           | --   |
1283   | headers       |             |               |              |      |
1284   | Modified      | --          | (opt: RPI),   | (opt: RPI),  | --   |
1285   | headers       |             | RH3           | RH3          |      |
1286   | Untouched     | --          | --            | --           | RPI  |
1287   | headers       |             |               |              |      |
1288   +---------------+-------------+---------------+--------------+------+

[minor] In this case, the destination node would also leave the RH3 header
untouched, right?

1290     Non Storing: Summary of the use of headers from root to not-RPL-
1291                                aware-leaf

[minor] This table (and several others) have no name/number.

...
1375 7.2.2.  Non-SM: Example of Flow from Internet to RPL-aware-leaf
...
1393   The RPI may be added or not as required by networks such as 6tisch.

[major] When would that be?  Is there a reference?

1394   The RPI is unnecessary for loop detection.

[major] Yet the Table shows it...when would it be used, why, etc.?

1396   +----------+---------+--------------+---------------+---------------+
1397   | Header   | Interne | 6LBR         | 6LR_i         | 6LN           |
1398   |          | t       |              |               |               |
1399   +----------+---------+--------------+---------------+---------------+
1400   | Inserted | --      | IP-in-IP (RH | --            | --            |
1401   | headers  |         | 3,opt:RPI)   |               |               |
1402   | Removed  | --      | --           | --            | IP-in-IP      |
1403   | headers  |         |              |               | (RH3,opt:RPI) |
1404   | Re-added | --      | --           | --            | --            |
1405   | headers  |         |              |               |               |
1406   | Modified | --      | --           | IP-in-IP      | --            |
1407   | headers  |         |              | (RH3,opt:RPI) |               |
1408   | Untouche | --      | --           | --            | --            |
1409   | d        |         |              |               |               |
1410   | headers  |         |              |               |               |
1411   +----------+---------+--------------+---------------+---------------+

1413     Non Storing: Summary of the use of headers from Internet to RPL-
1414                                aware-leaf

...
1566 7.3.2.  Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware-
1567        leaf
...
1583   As in the previous case, the 6LN will insert an RPI (RPI_1) header
1584   which MUST be in an IP-in-IP header addressed to the root so that the
1585   6LBR can remove this RPI.  The 6LBR will then insert an RH3 inside a
1586   new IP-in-IP header addressed to the 6LN destination node.  The RPI
1587   is optional from 6LBR to 6LR_id (RPI_2).

[minor] The text says that the "new IP-in-IP header [is] addressed to the
6LN destination node", but the Table below shows the 6LR_id removing it.

1589   +-----------+----------+----------+------------+------------+-------+
1590   | Header    | 6LN      | 6LR_1    | 6LBR       | 6LR_id     | IPv6  |
1591   +-----------+----------+----------+------------+------------+-------+
1592   | Inserted  | IP-in-IP | --       | IP-in-IP   | --         | --    |
1593   | headers   | (RPI1)   |          | (RH3, opt  |            |       |
1594   |           |          |          | RPI_2)     |            |       |
1595   | Removed   | --       | --       | IP-in-IP   | IP-in-IP   | --    |
1596   | headers   |          |          | (RPI_1)    | (RH3, opt  |       |
1597   |           |          |          |            | RPI_2)     |       |
1598   | Re-added  | --       | --       | --         | --         | --    |
1599   | headers   |          |          |            |            |       |
1600   | Modified  | --       | IP-in-IP | --         | IP-in-IP   | --    |
1601   | headers   |          | (RPI_1)  |            | (RH3, opt  |       |
1602   |           |          |          |            | RPI_2)     |       |
1603   | Untouched | --       | --       | --         | --         | opt   |
1604   | headers   |          |          |            |            | RPI_2 |
1605   +-----------+----------+----------+------------+------------+-------+

1607     Non Storing: Summary of the use of headers from RPL-aware-leaf to
1608                            not-RPL-aware-leaf

...
1654 7.3.4.  Non-SM: Example of Flow from not-RPL-aware-leaf to not-RPL-
1655        aware-leaf
...
1674   +------------+-------+-----------+------------+-------------+-------+
1675   | Header     | IPv6  | 6LR_1     | 6LBR       | 6LR_id      | IPv6  |
1676   |            | src   |           |            |             | dst   |
1677   +------------+-------+-----------+------------+-------------+-------+
1678   | Inserted   | --    | IP-in-IP  | IP-in-IP   | --          | --    |
1679   | headers    |       | (RPI_1)   | (RH3)      |             |       |
1680   | Removed    | --    | --        | IP-in-IP   | IP-in-IP    | --    |
1681   | headers    |       |           | (RPI_1)    | (RH3, opt   |       |
1682   |            |       |           |            | RPI_2)      |       |
1683   | Re-added   | --    | --        | --         | --          | --    |
1684   | headers    |       |           |            |             |       |
1685   | Modified   | --    | --        | --         | --          | --    |
1686   | headers    |       |           |            |             |       |
1687   | Untouched  | --    | --        | --         | --          | --    |
1688   | headers    |       |           |            |             |       |
1689   +------------+-------+-----------+------------+-------------+-------+

[minor] The optional RPI_2 is not indicated in the 6LBR column.


...
1696 8.1.  Storing mode
...
1705   Thanks to the change of the RPI option type from 0x63 to 0x23, there
1706   is no longer any uncertainty about when to use an IP-in-IP header in
1707   the storing mode.  A Hop-by-Hop Options Header containing the RPI
1708   option SHOULD always be added when 6LRs originate packets (without
1709   IP-in-IP headers), and IP-in-IP headers should always be added
1710   (addressed to the root when on the way up, to the end-host when on
1711   the way down) when a 6LR find that it needs to insert a Hop-by-Hop
1712   Options Header containing the RPI option.

[major] This paragraph starts by saying that "there is no longer any
uncertainty about when to use an IP-in-IP header".  However, the
specification is a "SHOULD", which means that there are cases when the
action may not be performed.  It sounds like a contradiction to me.  In any
case, what are the cases that make it a "SHOULD" and not a "MUST"?

[major] Should this text include a "SHOULD" as well: "and IP-in-IP headers
should always be added..."?

...
1731 9.  6LoRH Compression cases

1733   The [RFC8138] proposes a compression method for RPI, RH3 and IPv6-in-
1734   IPv6.

1736   In Storing Mode, for the examples of Flow from RPL-aware-leaf to non-
1737   RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise
1738   an IP-in-IP and RPI compression headers.  The type of this case is
1739   critical since IP-in-IP is encapsulating a RPI header.

1741   +--+-----+---+--------------+-----------+-------------+-------------+
1742   |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC |
1743   +--+-----+---+--------------+-----------+-------------+-------------+

1745                    Figure 9: Critical IP-in-IP (RPI).

[major] Shouldn't this section also be an Update to rfc8138?

[major] 6LoRH Type 6 is defined in rfc8138 as an elective type, but it is
introduced as Critical here.  The header must then be completely specified
in this document and the appropriate registry must be updated (in the IANA
Consideration section).

Specifically...referring to rfc8138...
   - the meaning of the TSE depends on the Type (§4.2),
   - the Hop Limit is defined in §7, should it have the same
behavior/meaning here?
   - does the "RPI - 6LoRH" field correspond to the RPI-6LoRH header (§6.3)?
   - I'm assuming that the "LOWPAN IPHC" field refers to LOWPAN_IPHC
(rfc6282).

...
1774 11.  Security Considerations

1776   The security considerations covering of [RFC6553] and [RFC6554] apply
1777   when the packets get into RPL Domain.

s/covering of/covered in

[minor] Do you mean "are in the RPL Domain" instead of "get into" it?  Or
are you talking about when a packet comes into the domain from a
non-RPL-aware node (like a non-RPL-aware-leaf)?  I ask because it seems to
me that those RFCs only talk about packets that are inside the domain (and
not about them getting in).

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

1784   Nodes outside of the LLN will need to pass IPIP traffic through the
1785   RPL root to perform this attack.  To counter, the RPL root SHOULD
1786   either restrict ingress of IPIP packets (the simpler solution), or it
1787   SHOULD do a deep packet inspection wherein it walks the IP header
1788   extension chain until it can inspect the upper-layer-payload as
1789   described in [RFC7045].  In particular, the RPL root SHOULD do BCP38
1790   ([RFC2827]) processing on the source addresses of all IP headers that
1791   it examines in both directions.

[major] For all 3 SHOULDs above...  Why are they not a MUST?  IOW, when (if
countering) would the actions not be performed?  Are there other mechanisms
that the root could consider?

1793   Note: there are some situations where a prefix will spread across
1794   multiple LLNs via mechanisms such as described in
1795   [I-D.ietf-6lo-backbone-router].  In this case the BCP38 filtering
1796   needs to take this into account.

s/such as described/such as the one described

[major] The text above sounds like the root needs to get some type of
routing information from the other LLN, is that true?  What are the
security implications of that?

I took a very quick look at I-D.ietf-6lo-backbone-router and it seems to me
that there are probably other considerations to be included related to that
mechanism in the context of this document.  Given the "in passing" nature
of the note above, and the fact that I-D.ietf-6lo-backbone-router is still
in process in 6lo, I suggest you take the text/reference out.

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

s/Nodes with the LLN/Nodes within the LLN

[major] Is there any possible mitigation to this inside-the-LLN attack?  It
seems to me that this issue is not something introduced by this document,
right?  Would authentication help -- is it even possible? Is there a
discussion of this in the main spec?

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

[nit] Suggestion: reorder the paragraphs so that the discussion of the
internal threats starts in the third paragraph.  It should improve
readability and may avoid some repetition.

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

s/originate compromised/originate from compromised

[major] Yes, BCP38 will stop an attack, but only if the source addresses
are spoofed.  What if they're not?  Given that the attack may be hidden,
and assuming that nodes are compromised across multiple LLNs, an attacker
may not care enough to spoof the origins.

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

[major] Because of the "SHOULD", both references should be Normative.  The
second ID is Informational.  Does that really need to be a "SHOULD"??  It
seems to me that "should" would be enough in this case.

[minor] I'm having trouble parsing the last sentence.  What are you trying
to suggest?

1832   With the above precautions, an attack using IPIP tunnels will be by a
1833   node within the LLN on another node within the LLN.  Such an attack
1834   could, of course, be done directly.  An attack of this kind is
1835   meaningful only if the source addresses are either fake or if the
1836   point is to amplify return traffic.  Such an attack, could also be
1837   done without the use of IPIP headers using forged source addresses.

1839   If the attack requires bi-directional communication, then IPIP
1840   provides no advantages.

1842   [RFC2473] suggests that tunnel entry and exit points can be secured,
1843   via the "Use IPsec".  This solution has all the problems that

[minor] "This solution"...which one?  The rfc2473 suggestion or the one
described in this document?

1844   [RFC5406] goes into.  In an LLN such a solution would degenerate into
1845   every node having a tunnel with every other node.  It would provide a
1846   small amount of origin address authentication at a very high cost;
1847   doing BCP38 at every node (linking layer-3 addresses to layer-2
1848   addresses, and to already present layer-2 cryptographic mechanisms)
1849   would be cheaper should RPL be run in an environment where hostile
1850   nodes are likely to be a part of the LLN.

1852   The RH3 header usage described here can be abused in equivalent ways
1853   with an IPIP header to add the needed RH3 header.  As such, the
1854   attacker's RH3 header will not be seen by the network until it
1855   reaches the end host, which will decapsulate it.  An end-host SHOULD
1856   be suspicious about a RH3 header which has additional hops which have
1857   not yet been processed, and SHOULD ignore such a second RH3 header.

[nit] Hmmm...it seems like these threats should have been identified in
rfc6554...

[major] What does "SHOULD be suspicious" mean?  How is that a Normative
behavior?  Would being suspicious include dropping the packet or some other
similar action?  When would the router *not* be suspicious?  Why is that
not a "MUST"?

[major] When should a second RH3 header not be ignored?  Why is "MUST" not
used?

1859   In addition, the LLN will likely use [RFC8138] to compress the IPIP
1860   and RH3 headers.  As such, the compressor at the RPL-root will see
1861   the second RH3 header and MAY choose to discard the packet if the RH3
1862   header has not been completely consumed.  A consumed (inert) RH3

[major] It seems to me that the optional action of the root of discarding
the packet is is contradiction with the "SHOULD ignore such a second RH3
header" above.  Is the subtle difference that we're talking about the root
here, and the end-host above?  Why wouldn't the actions be the same if in
both cases the second RH3 header may indicate some type of attack, or at
least something anomalous??

1863   header could be present in a packet that flows from one LLN, crosses
1864   the Internet, and enters another LLN.  As per the discussion in this
1865   document, such headers do not need to be removed.  However, there is
1866   no case described in this document where an RH3 is inserted in a non-
1867   storing network on traffic that is leaving the LLN, but this document
1868   SHOULD NOT preclude such a future innovation.  It should just be
1869   noted that an incoming RH3 must be fully consumed, or very carefully
1870   inspected.

[major] The "SHOULD NOT" seems out of place as there is nothing Normative
in the statement.

[major] What does "very carefully inspected" mean?  Are there actions
resulting from that?

1872   The RPI header, if permitted to enter the LLN, could be used by an
1873   attacker to change the priority of a packet by selecting a different
1874   RPL instanceID, perhaps one with a higher energy cost, for instance.

s/RPL instanceID/RPLinstanceID

...
1911 13.1.  Normative References

[minor] I think that the following references can be made Informative:
RFC2473, RFC5406

...
1965 13.2.  Informative References

[nit] I-D.ietf-6man-rfc6434-bis is not referenced in the text.