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

Manually changing the state as it seems stuck after the official announcement was sent.  The RFC Editor is already editing this document.  Also, I opened a ticket (https://trac.tools.ietf.org/tools/ietfdb/ticket/3164).

[Ballot comment]
Unfortunately, I only had time to review the diff from the -29 (that
addressed my previous batch of comments) and the -42, and was not able
to attempt to look closely at the new tables and their depiction of the
added/modified/removed/untouched headers.  As such, I do not have many
comments.

Since we are marking MOP value 7 as reserved, do we expect this document
to be listed as a reference for that entry in the registry?


Section 1

  Most of the use cases described therein require the use of IPv6-in-

nit: s/therein/herein/

Section 2

  Flag Day: In this document, refers to a transition that involves
  having a network with different values of RPI Option Type.

Is the flag day the act of transitioning the network from one value to
the other, or only the sub-case when it is a disruptive transition, or
...?

Section 3

  routed.  A RPL Instance is either fully storing or fully non-storing,
  i.e. a RPL Instance with a combination of storing and non-storing
  nodes is not supported with the current specifications at the time of
  writing this document.

(I assume there is no conflict between this statement and the behavior
described in Section 4.1.1 whereby external routes are advertised with
non-storing-mode messaging even in a storing-mode network.)

Section 4.1.1

  In order to enable IP-in-IP all the way to a 6LN, it is beneficial
  that the 6LN supports decapsulating IP-in-IP, but that is not assumed
  by [RFC8504].  If the 6LN is a RUL, the Root that encapsulates a
  packet SHOULD terminate the tunnel at a parent 6LR unless it is aware
  that the RUL supports IP-in-IP decapsulation.

Is there anything useful to say about how the Root would know that the
RUL supports IP-in-IP decapsulation?  ("No" is a valid answer :)

Section 4.3

  This modification is required in order to be able to decompress the
  RPL Option with the new Option Type of 0x23.

nit(?): is it the RPL Option or the entire header that is decompressed?

Section 6

      - For traffic leaving a RUL, if the RUL adds an opaque RPI then
      the description of the RAL applies.  The 6LR as a RPL border
      router SHOULD rewrite the RPI to indicate the selected Instance
      and set the flags.

I'm not sure that I fully understand this point (specifically, "the
description of the RAL applies").  Similar text also appears in the
Security Considerations.

Section 8.2.4

There seem to be some changes in the table compared to the -29; were
these verified to be correct?

Section 12

  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.

nit: the second comma should probably be a colon or em dash.

[Ballot comment]
I would have liked to spend more time on this than I had, but I do have some non-blocking comments that I’d like you to consider:

— Section 2 —

  Flag Day: In this document, refers to a transition that involves
  having a network with different values of RPI Option Type.

I don’t understand.  First, I don’t find the text here clear at all: is it trying to say that two different values are coexisting (present at the same time) in one network?  Second, that seems to be exactly the opposite of what we usually use a flag day for.  The normal meaning of “flag day” is a preset time when a changeover is made, exactly *because* the old and the new can’t coexist interoperably.  A “flag day” isn’t a situation caused by two non-interoperable things... it’s a mechanism for resolving such a situation by making an abrupt, planned changeover from one to the other.

— Section 4.2 —

  Thus, this document updates the Option Type of the RPL Option
  [RFC6553], abusively naming it RPI Option Type for simplicity,


What is the point of “abusively” here?  What’s it supposed to mean?

— Section 10 —

  This options allows to send
  packets to not-RPL nodes, which should ignore the option and continue
  processing the packets.

I can’t sort this sentence out:
1. “This options” is mixing singular and plural.
2. No option or options has/have been mentioned before, so I don’t know what option(s) it’s talking about.
3. I guess you mean “non-RPL”, rather than “not-RPL“.
4. Allows *who* to send packets?  “Allows to” needs a subject, like “allows a node to send”, or some such.
5. What is the antecedent to “which”?  It’s not clear to me.

  As mentioned previously, indicating the new RPI in the DODAG
  Configuration option flag is a way to avoid the flag day (lack of
  interoperation) in a network using 0x63 as the RPI Option Type value.

I’ll just note that this is a correct use of “flag day”, but with an odd explanation in the parentheses.  I would say “(abrupt, disruptive changeover)”.

[Ballot comment]
Thank you to Daniel Migault for the SECDIR review.

I have nothing substantive to add to the new text here.  My feedback was addressed in -29 after the first IESG review of this document.

A few nits:

** Section 1.  Editorial. s/it is recommended the reading of [I-D.ietf-intarea-tunnels] that explains/ [I-D.ietf-intarea-tunnels] is recommended reading to explain/

** Section 4.2.  What is “abusively naming it”?

** Section 4.2.  Editorial. s/There is therefore no longer a necessity to/There is no longer a need to/

[Ballot discuss]
[ section 12 ]

* Ignoring an invalid RH3 header by the end host (I'm assuming this
  means that segments left > 0) doesn't specify whether the packet
  should be processed (ignore the RH) or the whole packet should be
  ignored.

  I might recommend instead referring to RFC 6554 S4.2 for how to handle
  RH3's if the node is also a RPL-aware router and say it MUST drop the
  packet if segments left is non-zero and it's not a RPL-aware router.

  Related: I'd also recommend:

  "It should just be noted that an incoming RH3 must be fully consumed, or
  very carefully inspected."

  ->

  "It should just be noted that an incoming RH3 MUST be fully consumed."

[Ballot comment]
[[ comments ]]

[ section 8.1.3 ]

* I'm confused by the use of "consumed" here.  Is the final RH3 entry
  RUL's address?  I guess you could say RH penultimate hop "consumes"
  the header because the ultimate destination address is put in the
  header DA field.  Seems a bit odd though.

  I assume 6LR_n gets RUL's address from the last segment in RH3.

  "Consumed" means segments left == 0, I guess?  I suppose should have
  picked up on this terminology when it was first used in Section 2.
  Maybe clarify what it means in that section (2)?


[[ questions ]]

[ section 4.1.3 ]

* To be clear, the DODAG Configuration option flags being updated
  is the one in 6550 S6.7.6?

[ section 9 ]

* This the final paragraph strictly true?  It seems that in some situations
  in section 7 full-encapsulated packets can arrived at the RUL with all
  RPL artifacts removed.  Again: in certain situations.


[[ nits ]]

[ section 1.1 ]

* "uses cases" -> "use cases"

[ section 4.1.3 ]

* "when a node joins to a network will know" ->
  "when a node joins to a network it will know", I think

* "MUST be initialize to zero" -> "MUST be initialized to zero"

  (Separately: if this is quoting text from 6.7.6, then it's not
  exactly a direct quote.)

[ section 6 ]

* "while adding significant in the code" ->
  "while adding significant  in the code", I think

[ section 9 ]

* "traffic originating from..." ->
  "Traffic originating from..."

[ section 12 ]

* "if attack" -> "if the attack" or "if an attack"

[Ballot comment]
Thank you for the work put into this document. It is long but also clear and easy to read.

Malisa's IoT directorate review indicates nothing to be addressed (thank you again Malisa !):
https://datatracker.ietf.org/doc/review-ietf-roll-useofrplinfo-42-iotdir-lc-vucinic-2020-12-09/

The changes since my latest "no objection" ballot appear to be mainly editorial beside a couple of big changes (rightfully causing a new IETF last call). Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 2 --
  "As an IPv6 node, a RPL Leaf is expected to ignore a
  consumed Routing Header and as an IPv6 host, it is expected to ignore
  a Hop-by-Hop header.  "

Suggest to define what is a "consumed RH".

Suggest to be clear about the HbH: some options in HbH can be ignored indeed but by all *nodes*, there is nothing specific for *hosts* (as they are also nodes) per section 4.3 of RFC 8200.

"RPL Packet Information (RPI): The abstract information" why is this 'abstract' ?

I also find the definition of 'flag day' confusing... can 2 values of RPI Option Types co-exist in the network?

-- Section 4.2 --
  "When originating new packets, implementations SHOULD have an option
  to determine which value to originate with, this option is controlled
  by the DIO option described below."
 
Unsure whether normative language should be used in the above text. Moreover, if the option type is controlled by the DIO option, then there is no more 'option' to determine the value as it is specified.
 
-- Section 7.2.2 --
Should the text also include 'decapsulate from IPv6-in-IPv6" in addition to "When the packet arrives at the RAL the RPI is removed " ?


== NITS ==

Is Ines' affiliation still correct?
 
-- Section 4.1.1 --
Suggest to start a new paragraph from "In the other direction, ..."

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-roll-useofrplinfo-42. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

We understand that, upon approval of this document, there are four actions which we must complete.

First, in the Destination Options and Hop-by-Hop Options registry on the Internet Protocol Version 6 (IPv6) Parameters registry page located at:

https://www.iana.org/assignments/ipv6-parameters/

the registration for Hex Value 023 will be permanently changed to:

Hex Value: 0x23
Binary value act: 00
Binary value chg: 1
Binary value rest: 00011
Description: RPL Option
Reference: [ RFC-to-be ]

and the registration for Hex Value 0x63 will be permanently changed to:

Hex Value: 0x63
Binary value act: 01
Binary value chg: 1
Binary value rest: 00011
Description: RPL Option(DEPRECATED)
Reference: [RFC6553][ RFC-to-be ]

Second, in the DODAG Configuration Option Flags registry on the Routing Protocol for Low Power and Lossy Networks (RPL) registry page located at:

https://www.iana.org/assignments/rpl/

the registration for bit number 3 will have its reference changed to [ RFC-to-be ]:

Bit Number: 3
Capability Description: RPI 0x23 enable
Reference: [ RFC-to-be ]

Third, the name of the DODAG Configuration Option Flags registry on the Routing Protocol for Low Power and Lossy Networks (RPL) registry page located at:

https://www.iana.org/assignments/rpl/

is to be changed from:

DODAG Configuration Option Flags

to:

DODAG Configuration Option Flags for MOP 0..6

IANA Question: Should [ RFC-to-be ] be listed as an additional reference for this registry?

Fourth, in the Mode of Operation registry also on the Routing Protocol for Low Power and Lossy Networks (RPL) registry page located at:

https://www.iana.org/assignments/rpl/

value 7 is to be changed from unassigned to

Value: 7
Description: Reserved
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-12-09):

From: The IESG
To: IETF-Announce
CC: draft-ietf-roll-useofrplinfo@ietf.org, roll-chairs@ietf.org, roll@ietf.org, consultancy@vanderstok.org, aretana.ietf@gmail.com, Peter Van der Stok
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane) to Proposed Standard


The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document: - 'Using RPI Option
Type, Routing Header for Source Routes and IPv6-in-
  IPv6 encapsulation in the RPL Data Plane'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-12-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document looks at different data flows through LLN (Low-Power
  and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
  and Lossy Networks) is used to establish routing.  The document
  enumerates the cases where RFC6553 (RPI Option Type), RFC6554
  (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is
  required in data plane.  This analysis provides the basis on which to
  design efficient compression of these headers.  This document updates
  RFC6553 adding a change to the RPI Option Type.  Additionally, this
  document updates RFC6550 defining a flag in the DIO Configuration
  option to indicate about this change and updates RFC8138 as well to
  consider the new Option Type when the RPL Option is decompressed.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/



No IPR declarations have been submitted directly on this I-D.

This document has gone through some changes since we requested the RFC Editor to put it in IESG state.  All the changes have been throughly discussed in the WG.  I am pulling the dcument off the RFC Editor's queue and putting it back in mine.  We will run a new IETF LC and IESG Evaluation.

Shepherd document for ietf-roll-useofrplinfo; This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
Document is submitted as Proposed Standard; the document prescribes the headers to be used when a packet travels between a RPL network and a non-RPL network.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
(2a) Technical Summary
This document looks at different data flows through LLN (Low-Power
  and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
  and Lossy Networks) is used to establish routing.  The document
  enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6
  encapsulation is required.  This analysis provides the basis on which
  to design efficient compression of these headers.  Additionally, this
  document updates the RFC 6553 by adding a change to the RPL Option Type and adds a Flag to the set of flags specified in RFC 6550. The draft-ietf-roll-unaware-leaves draft has necessitated additional text to align useofrplinfo with the header lay-outs proposed in the unaware leaves draft  and necessitated the removal of version -31 from the RFC editor queue. In the current version -39, the earlier hop-by-hop encapsulation/decapsulation within the RPL mesh have been modified, significantly simplifying the useofrplinfo specification.
These changes are reflected in Figure 7, Section 7.1.4, Section 7.2.1, Sections 7.2.3-4, Sections 7.3.2-4, Figure 22, Section 8.2.1 and Sections 8.3.1-2.

(2b) Working Group Summary
There was clear consensus in the ROLL WG that this document was needed.
The extensive subject, involving many details, has led to lengthy discussions about terminology, and a verification of the full coverage of all cases. The later
(2c) Document Quality
The document is of special value to the the 6tisch WG.
There are no known implementations by manufacturers, but comments have been incorporated from people who needed to address a subset of the  cases discussed in the document.
The drafts ietf-anima-bootstrapping-keyinfra and The related draft-ietf-roll-unaware-leaves draft -6tisch-dtsecurity-secure-join rely on the cases discussed in this document.
No media type is created. Extensive discussions with 6man occurred because the document was edited at the same time that RGFC8200 was prepared
(2d)Personnel
Document Shepherd is Peter van der Stok;
Responsible Area Director is Alvaro Retana

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
The shepherd has reviewed this document twice: Once to get terminology and structure correct and second time to look at security aspects and 6man conformance. This version is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
The shepherd has no concerns about breadth and depth of document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
The WGLC included the 6man WG. Brian carpenter was kind enough to express conformance with 6man guidelines.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
There are absolutely no concerns about the validity of the document. However, the number of uses cases tends to overwhelm the reader who is usually interested in two or three cases out of the 24 discussed cases.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Each author confirmed that no known IPR is related to this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
No IPR disclosure been filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?
The most active part of the WG stands solidly behind this document.
In the long process, all persons which are concerned by the issues solved by this document, have discussed the document on the Mailing List.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
No appeal or extreme discontent has been expressed.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
The document has passed all the nit checks.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
No formal review criteria, such as the MIB Doctor, media type, and URI type reviews are relevant.

(13) Have all references within this document been identified as
either normative or informative?
All references within this document have been identified as either normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
There are no normative references to documents in progress.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
There is one downward normative reference to RFC 7416.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
The publication of this document will not change the status of any
existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
The IANA considerations section, updates the registration made in [RFC6553] Destination Options and Hop-by-Hop Options registry from 0x63 to 0x23; and updates the DODAG configurations option Flag.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
No new IANA registries are created.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
No sections of the document contain text written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

Shepherd document for ietf-roll-useofrplinfo; This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
Document is submitted as Proposed Standard; the document prescribes the headers to be used when a packet travels between a RPL network and a non-RPL network.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
(2a) Technical Summary
This document looks at different data flows through LLN (Low-Power
  and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
  and Lossy Networks) is used to establish routing.  The document
  enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6
  encapsulation is required.  This analysis provides the basis on which
  to design efficient compression of these headers.  Additionally, this
  document updates the RFC 6553 by adding a change to the RPL Option Type
  and the RFC 6550 to indicate about this change. The draft-ietf-roll-unaware-leaves draft has necessitated additional text to align useofrplinfo with the header lay-outs proposed in the unaware leaves draft  and necessitated the remobal of version -31 from the RFC editor queue. In the current version -39, the earlier hop-by-hop encapsulation/decapsulation within the RPL mesh have been modified, significantly simplifying the useofrplinfo specification.
These changes are reflected in Figure 7, Section 7.1.4, Section 7.2.1, Sections 7.2.3-4, Sections 7.3.2-4, Figure 22, Section 8.2.1 and Sections 8.3.1-2.

(2b) Working Group Summary
There was clear consensus in the ROLL WG that this document was needed.
The extensive subject, involving many details, has led to lengthy discussions about terminology, and a verification of the full coverage of all cases. The later
(2c) Document Quality
The document is of special value to the the 6tisch WG.
There are no known implementations by manufacturers, but comments have been incorporated from people who needed to address a subset of the  cases discussed in the document.
The drafts ietf-anima-bootstrapping-keyinfra and The related draft-ietf-roll-unaware-leaves draft -6tisch-dtsecurity-secure-join rely on the cases discussed in this document.
No media type is created. Extensive discussions with 6man occurred because the document was edited at the same time that RGFC8200 was prepared
(2d)Personnel
Document Shepherd is Peter van der Stok;
Responsible Area Director is Alvaro Retana

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
The shepherd has reviewed this document twice: Once to get terminology and structure correct and second time to look at security aspects and 6man conformance. This version is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
The shepherd has no concerns about breadth and depth of document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
The WGLC included the 6man WG. Brian carpenter was kind enough to express conformance with 6man guidelines.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
There are absolutely no concerns about the validity of the document. However, the number of uses cases tends to overwhelm the reader who is usually interested in two or three cases out of the 24 discussed cases.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Each author confirmed that no known IPR is related to this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
No IPR disclosure been filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?
The most active part of the WG stands solidly behind this document.
In the long process, all persons which are concerned by the issues solved by this document, have discussed the document on the Mailing List.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
No appeal or extreme discontent has been expressed.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
The document has passed all the nit checks.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
No formal review criteria, such as the MIB Doctor, media type, and URI type reviews are relevant.

(13) Have all references within this document been identified as
either normative or informative?
All references within this document have been identified as either normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
There are no normative references to documents in progress.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
There is one downward normative reference to RFC 7416.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
The publication of this document will not change the status of any
existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
The IANA considerations section, updates the registration made in [RFC6553] Destination Options and Hop-by-Hop Options registry from 0x63 to 0x23.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
No new IANA registries are created.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
No sections of the document contain text written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

[Ballot comment]
* Section 3.1

This text following the RFC8200 quote is not supported or implied by the quote

"This means that while it should be avoided, the impact on the Internet of leaking a Hop-by-Hop header is acceptable."

Is this text necessary?

* Section 3.2

It is not clear if nodes are required to change option types when the config flag transitions from 0 to 1 (e.g. after the reboot mentioned). Can you please clarify?

* Section 6

In the cases where a hop-by-hop options header needs to be added (denoted by "hop" in the table), I am assuming that the destination address is copied from the inner packet into the encapsulating packet. If this is right, I think it might be useful to explicitly mention it as the dst field of the table does not provide the required information.

[Ballot comment]
Thank you for addressing my Discuss (and Comment) points!

I just have a few more minor notes on the -29:

the "(1)" footnote is no longer present.

I'm also not sure about the global change from "_i are the
intermediate routers" to "_i is the intermediate router", since the
general case can still have more than one intermediate in each
direction.  But perhaps we should leave this to the RFC Editor.

Section 11

nit: "especially if the target of the attack is targeting another LLN"
had redudant "target" added -- just "especially if attack is targeting
another LLN" would be fine.

I think the claim that "[i]n the end, the IPsec tunnels would be
providing only BCP38-like origin authentication!" could use some
additional justifcation.

[Ballot discuss]
There are several internal inconsistencies that needs to be
resolved before publication, specifically for:
(1) the destination address of the IPv6-in-IPv6 tunnel used for flows
from the Internet to a ~Raf -- Section 6.2.4 says addressed to the ~Raf,
but Figure 7 says "hop".
(2) the destination address of the IPv6-in-IPv6 tunnel used for flows
from a ~Raf to a ~Raf -- Section 6.3.4 says addressed to the ~Raf, but
Figure 7 says "hop"
(3) Table 14 says "(opt: RPI)" which, though not defined, I take to mean
as indicating that the insertion of the RPI is optional, but the body
text in Section 7.1.2 is unconditional that the 6LBR inserts an RPI
header
(4) Section 7.2.1 does not mention adding v6-in-v6 encapsulation, but
Figure 8 has a "must" in that column.
(5) Section 7.3.1 only has descriptive text that "[t]he originating node
should put the RPI into an IPv6-in-IPv6 header", but Figure 8 lists this
behavior as "must" (though there would also be a second v6-in-v6
encapsulationi from root to destination, which is clearly a must).
(Note that Section 7.3.2 covers essentially the same flow, but uses
"which must be in an IPv6-in-IPv6 header addressed to the root".)
(6) In Section 5, we say that the DODAG root "SHOULD force [rank information]
to zero" but then that "[t]he Internet will therefore not see any SenderRank
information", and a SHOULD-level requirement is not enough to guarantee
this statement as fact.

Additionally, there are some terminology inconsistencies in Figures 7
and 8 that need to be cleaned up or explained.  For example, in Figure
7, what is the difference between "Yes" and "must" in the "IPv6-in-IPv6"
column, and in the "v6-in-v6 dst" column, what does "root" mean?
In Figure 8, what does "Opt" mean in the "RPI" column?

[Ballot comment]
Section 1

  An interim meeting went through the 24 cases defined here to discover
  if there were any shortcuts, and this document is the result of that
  discussion.  This document clarifies examples that intend to
  illustrate the result of the normative language in RFC8200 and
  RFC6553.  In other words, the examples are intended to be normative
  explanation of the results of executing that language.

I agree with the GenART reviewer that this language is hard to parse
into useful expectations, and I'm not sure that the suggestion in
https://mailarchive.ietf.org/arch/msg/gen-art/FnrfXDQ4ZmGniUpa2y-qKA6bkOg
helps very much.  In particular, what does it mean for an example to be
a "normative explanation"?

Section 2

As noted by the rtgdir reviewer, the volume of new terminology
introduced is rather extensive, and hard for a newcomer to overcome.

  Flag Day: A transition that involves having a network with different
  values of RPL Option Type.  Thus the network does not work correctly.

This does not match up with what I understood the colloquial definition
of "flag day" to be (i.e., the specific act of cutting over from old to
new, designed to minimize the duration of the transient period when the
network does not work correctly, with extensive planning and
coordination needed to effectuate a scheduled, as opposed to rolling,
cutover).  It seems that the later usage of the term "flag day" in this
document is internally consistent with the definition here, at least.

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

I'm not seeing where in the description the "IPv6-in-IPv6" nature is
used -- couldn't this description equally apply to regular hop-by-hop
IPv6 headers?  Is the distinction that the added header is specifically
on the *inner* IPv6 representation?

Section 3.1

  Based on that, if an IPv6 (intermediate) node (RPL-not-capable)
  receives a packet with an RPL Option, it should ignore the HBH RPL
  option (skip over this option and continue processing the header).
  This is relevant, as it was mentioned previously, in the case that
  there is a flow from RPL-aware-leaf to Internet (see Section 6.2.1).

  Thus, this document updates the Option Type field to: the two high
  order bits MUST be set to '00' and the third bit is equal to '1'.

I am not sure that the "Thus" is appropriate -- as the secdir reviewer
notes, the logical connection is a bit tenuous, and the main connection
here seems to just be that 8200 endorses the concept of skipping over
some things, which gives us cover to use an option type that is
skippable.  But I'm probably misunderstanding here, and would welcome an
explanation of the nature of my confusion.

  The non-storing mode case does not require the type change from 0x63
  to 0x23, as the root can always create the right packet.  The type
  change does not adversely affect the non-storing case.

This section doesn't seem to explicitly call out the storing case for
special discussion.  Is there anything useful to say about it?

Section 3.2

                                                        The node will
  know which to use based upon the presence of the DODAG Configuration
  Option described in the next section.  [...]

nit: is it the mere *presence* of the DODAG Configuration Option, or the
information contained therein, that is relevant for this decision?

  There are potential significant advantages to having a single code
  path that always processes IPv6-in-IPv6 headers with no options.

nit(?): There seems to be potential ambiguity about whether "no options"
means "no IPv6 options" or "no conditional branches in the processing
flow".

I'm also not entirely sure how this sentence is supposed to tie in to
the rest of the section.

Figure 3 is pretty sparsely annotated.

Section 4

In Figure 5, why does the line from D to B have an arrowhead but none of
the other lines do?

Section 5

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

The risk seems open-ended given the potential for sub-TLVs in the RPI.
Where would a potential author of a new sub-TLV look to get guidance on
the potential security risks from having the sub-TLV contents released
to the internet?  Is there something useful we could add via this
document?
Also, I agree with the secdir reviewer that "at worst" should be "at a
minimum".

  Despite being legal to leave the RPI artifact in place, an
  intermediate router that needs to add an extension header (RH3 or RPI
  Option) MUST still encapsulate the packet in an (additional) outer IP
  header.  The new header is placed after this new outer IP header.

I didn't think that "RH3 or RPI Option" was an exhaustive list, and
isn't this duplicating a requirement from another specification anyway?
(That is, the "MUST" is probably not appropriate.)

  RPI MUST be present in every single RPL data packet.  There is one
  exception in non-storing mode: when a packet is going down from the
  root the RPI MAY be omitted.  The rational is that in a downward non-

This "MUST be present [...] one exception" is not a great way to phrase
things.  Collapsing into the same sentence with a comma "MUST be present
[...], with one execption: [...]" would help some, but it may even be
possible to use descriptive rather than normative language.

nit: s/rational/rationale/

Section 6

  The following table (Figure 7) itemizes which headers are needed in
  each of the following scenarios.  It indicate if an IPv6-in-IPv6
  header must be inserted, and whether the destination address of the
  IPv6-in-IPv6 header is the next hop, or the final target address.
  There are these possible situations: hop-by-hop necessary (indicated
  by "hop"), or final target address possible (indicated by "tgt").  In
  all cases hop by hop may be used rather than the final target
  address.

nit: we could probably make a stronger rhetorical connection betweeen
"the destination address is the next hop" and "hop-by-hop necessary" --
these tables are pretty complicated as-is, so every bit helps!

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

nit: singular/plural mismatch with "packet" and "go through"

Section 6.1.1

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

I think maybe a directorate reviewer already noted, but it seems that
node D was intended rather than node E.

Section 6.2.2

Should we say what the IPv6-in-IPv6 destination address is set to in
this case?

Section 6.2.3

Why does the 6LBR not remove headers in the the IPv6-in-IPv6(RPI)(2) case?

Section 6.2.4

I'm not sure how to interpret the Table.  Does the IPv6 node remove the
RPI or ignore it?

Section 6.3.1

  While the 6LR nodes will update the RPI, no node needs to add or
  remove the RPI, so no IPv6-in-IPv6 headers are necessary.  This may
  be done regardless of where the destination is, as the included RPI
  will be ignored by the receiver.

I'm not sure what variation in the receiver location this is supposed to
allow, given that we have already specified it to be a Raf in the same
RPL Domain.

Section 6.3.4

  not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LR_id --> not-
  RPL-aware 6LN (IPv6 dst)

Is the root considered to be a 6LR_ia or a 6LR_id?

  Note that this flow is identical to Section 6.3.3, except for where
  the IPv6-in-IPv6 header is inserted.

I'm still not seeing a difference in where the IPv6-in-IPv6 header is
inserted.

Section 7

  The following table (Figure 8) summarizes what headers are needed in
  the following scenarios, and indicates when the RPI, RH3 and IPv6-in-
  IPv6 header are to be inserted.  There are these possible situations:
  target destination address possible (indicated by "tgt"), to a 6LR,
  to a 6LN or to the root.  In cases where no IPv6-in-IPv6 header is
  needed, the column states as "No".

"There are these possible situations" seems overly broad; if I
understand correctly, it is discussing only the last ("v6-in-v6 dst")
column's possible values.

Is the "to a 6LR" case always going to be "the last 6LR before the 6LN
or 6LBR"?  It may be worth a few words to clarify that.

  The leaf can be a router 6LR or a host, both indicated as 6LN
  (Figure 3).  In the Figure the (1) indicates a 6tisch case [RFC8180],
  where the instanceID portion of the RPI header may still be needed to
  pick an appropriate priority or channel at each hop.

This wording seems to imply that it is possible to cherry-pick just the
instanceID portion of the RPI header without (e.g.) the SenderRank,
which does not match my understanding of what is possible.  Perhaps
"where the RPI header may still be needed for the instanceID to be
available for priority/channel selection at each hop" is better wording?

Section 7.1.2

  The destination is known to RPL-aware because, the root knows the
  whole topology in non-storing mode.

nits: "to be", and no comma is needed.

Section 7.1.3

I think I would prefer if the body text mentioned that an RPI is
optionally added (for the 6tisch case where the instanceID is needed).

I'm not sure that I understand why the RPI is marked as being modified
by the 6LR_i in this case but not in Section 7.1.2.

Table 15 should probably keep the parentheses around "(opt: RPI)" in the
column for the ~Raf.

Section 7.2.4

It seems that Table 20 could coalesce the 6LR_1 column into the 6LR_i
column, and instead break out a 6LR_n column as is done in (e.g.)
Section 7.1.3.

Section 7.3.1

The conventions established previously in this document would seem to
have us include the "IPv6-in-IPV6()" indicator in the "Modified headers"
row.

Section 7.3.2

I think the Table 22 column header is better as 6LR_ia than 6LR_1.
It would be nice to be able to distinguish the generic 6LR_id and 6LR_m
cases, but I'm not sure if there's enough horizontal space for that.
Some textual discussion in the Table legend would be very helpful,
though.

Section 7.3.3

  not-RPL-aware 6LN (IPv6) --> 6LR_ia --> root (6LBR) --> 6LR_id -->
  6LN

Is there a separate 6LR_1 step to be mentioned here?

It's unclear if there's enough room for it in Table 23, but presumably
the generic 6LR_ia are modifying the IPv6-in-IPv6(RPI_1) headers?

Section 7.3.4

  not-RPL-aware 6LN (IPv6 src)--> 6LR_ia --> root (6LBR) --> 6LR_id -->
  not-RPL-aware (IPv6 dst)

Are there separate 6LR_1 and 6LR_m steps to mention here?

As for 7.3.3, Table 24 seems to be missing some columns for intermediate
6LRs that merely modify the RPI headers, though I recognize space
concerns.

Section 8

  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 be create the RH3 header), and therefore knows what the 6LR
  prior to the leaf --- the 6LR_n.

nit: "what the 6LR prior to the leaf is" or "which 6LR is immediately
prior to the leaf" or similar

Section 9

  During bootstrapping the node get the DIO with the information of RPL
  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.  [...]

Perhaps a reminder of how "all the nodes are set with the new value" is
detected by the root would be helpful.

  The migration path to the change from 0x63 to 0x23 in networks that
  accepts both values is changed when the DIO is sent with the flag
  indicating the new RPI value.  Namely, it remains at 0x63 until it is

nit: How is it the *migration path* that is changed when the DIO with
flag is sent?  That seems to be making the migration happen, but the
path is the same as it ever was.

Section 11

  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, they could still have a significant
  impact, particularly if the attack was on another LLN!  Additionally,

I agree with the secdir reviewer that "target of the attack was another
LLN!" (or similar) would be clearer.

  With the above precautions, an attack using IPv6-in-IPv6 tunnels will
  be by a node within the LLN on another node within the LLN.  Such an

nit: I'd suggest s/will be/can only be/ to emphasize the restrictive
nature of the precautions.

  The RH3 header usage described here can be abused in equivalent ways
  with an IPv6-in-IPv6 header to add the needed RH3 header.  As such,

I don't think I understand what this is trying to say.  What are the
things that are equivalent?

  The RPI header, 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 instanceID, but a change of instanceID would permit an
  attacker to bypass such filtering.  Like the RH3, a RPI header 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 header
  therefore will not be seen by the network.  Upon reaching the
  destination node the RPI header has no further meaning and is just
  skipped; the presence of a second RPI header will have no meaning to
  the end node as the packet has already been identified as being at
  it's final destination.

This text does not really convince me that it considers the non-storing
case where a packet is directed to a non-6LR-aware leaf, and the last
6LR removes the IPv6-in-IPv6 encapsulation prior to sending the packet
on to the IPv6 node.

  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.

It's not really clear to me that [DDOS-KREBS] is illustrative of
IPv6-in-IPv6 spoofing from a LLN.

  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 with

nit: is "source with" a common term?

  an address that is not registered, and the registration checks for

nit: "registration process"?

  topological correctness.  Notice that there is an 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 RH3 is protected
  by its definition.

Protected from what?  How?

  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 do a deep packet inspection wherein
  it walks the IP header extension chain until it can inspect the
  upper-layer-payload as described in [RFC7045].  In particular, the

RFC 7045 does not use the term "deep packet inspection", that term has
negative connotations for many people, and it's not entirely clear that
it's the right term to describe the process of fully parsing the IPv6
headers, either.

[Ballot comment]
I only did a quick read of this document but I would like to echo the TSV-ART review (Thanks Colin!) that a pointer to RFC6040 could be good in order to highlight support of ECN for any tunnelling solutions. Also there is draft-ietf-intarea-tunnels which could be a good pointer/read for this spec.

[Ballot discuss]
The document is interesting and is about an interesting twist of behavior in the light of RFC 8200 new behavior with respect to Hop-by-hop extension header.

But, I am balloting a DISCUSS for two reasons:

1) in section 3.1,  I am failing to understand the link between RFC8200 HbH behavior and why the RPI code needs to be changed to 0x23.  => a clear explanation is required on why the option 0x23 is linked to RFC 8200: I fail to understand the authors' logic. At first sight, with the new RFC8200 HbH handling, there is no need to change the RPI code from 0x63 as most routers will ignore HbH anyway.

2) the document deserves a better text as there are too many nits, unexpanded acronyms, ... the reader has hard time to understand the document.

Again, the content is useful but need some more work.

[Ballot comment]


Comments
--------

C1) Section 1, having a date or short description of the interim meeting could be useful here.

C2) Section 2, the term "Hop-by-hop IPv6-in-IPv6 headers" is confusing at first reading, what about "Link IPv6-in-IPv6 header" ? or "Single link IPv6-in-IPv6 header" ? Hop-by-hop has a specific meaning in IPv6. This term is not also used consistenly in the document.

C3) section 3.2 how does a network node would understand / learn that it is in "0x23 mode" ? It should provide a hint to section 3.3 or swap section 3.2 and 3.3 to make the task easier for the reader.

C4) section 3.3 if the decompression is also to 0x23 or 0x63, then what is the compressor behavior when receiving the other code?

C5) the introduction to RPL in section 4 after the topology is nice and concise but it is either too late in the document or useless (I prefer the former, for example in section 2).

C6) the code 0x23 is assumed everywhere but AFAIK there is no guarantee that IANA will use this code (even if this is the logical choice)

C7) it is assumed that the Internet has moved to RFC8200 and does not drop packets with HbH... "will not be discarded" I would prefer to have a disclaimer on the current sad state of the Internet

C8) section 5, while I am not an expert in RPL, I wonder whether the sentence "there can be no loops by construction" is true even in transient states ?

C9) section 6, is there any reason why the 'must' and 'root' values are not specified while 'hop' and others are ?

C10) Section 6.1.1 title is "SM: Example of Flow from RPL-aware-leaf to root" while SM has NOT been specified only RPL-SM.

C11) Section 7, AFAIK RPL has been designed to be confined in one domain, if I am not mistaken, then extending RPL to work over the Internet would require some considerations early in this document (even if IPv6-in-IPv6 should clear the security issues of RH3 as discussed in the security section).

C12) the 2nd paragraph of section 9 is probably useless as it is a snapshot taken in 2018/2019 which may not be the case anymore in a couple of years

Nits
----

N1) in section 1, this is a unexpected abbreviation < "RPL option" (RPI) >

N2) in section 2, another unexpected abbreviation < RPL-aware-leaf (Raf) >

N3) section 3.1, inconsistent use of quotes around 01 and 1 in the same section

N4) section 4, acronyms such 6LR are here explained while section 2 referred to an external document... perhaps worth augmenting section 2 and removing the description in section 4 ?

N5) section 4, s/in non-storing (RPL-NSM)/in non-storing mode (RPL-NSM)/

N6) section 5 does not use the previously introduced abbreviations... this I-D looks like a patchwork (different authors -- and I made multiple times the same 'mistake' ;-) )

N7) section 5 s/Extensions may not be added/Extensions Headers may not be added/

N8) section 5 repeat the use of 01 in the option and its explanation => remove this part

N9) section 5 s/to add to remove/to add and remove/ ?

N10) section 6, s/It indicate/It indicates/

N11) section 6, s/hop by hop/hop-by-hop/

[Ballot comment]
I strongly support Roman's DISCUSS - the scaling *seems* like it would end poorly, and I'm a bit confused about what exactly is being recommended.
I'm not 100% sure I understand how the deployment will actually occur, and so perhaps the IPSEC scaling doesn't cause an issue?

[Ballot comment]
Thanks to everyone who worked on this document. I have only one minor comment.

I'm a bit perplexed by the interplay between sections 3.1 and 3.3.

Section 3.1 says:

>  This change creates a flag day for existing networks which are
>  currently using 0x63 as the RPI value.

And then section 3.3 says:

>  In order to avoid a Flag Day caused by lack of interoperation between
>  new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag
>  in the DIO Configuration Option...

Which leaves me wondering whether the net effect of this document does or does
not create a flag day for networks. Please consider updating these sections to
be consistent with each other.

[Ballot discuss]
Per Section 11:
  [RFC2473] suggests that tunnel entry and exit points can be secured,
  via the "Use IPsec".  The suggested solution has all the problems
  that [RFC5406] goes into.  In an LLN such a solution would degenerate
  into every node having a tunnel with every other node.  It would
  provide a small amount of origin address authentication at a very
  high cost; doing BCP38 at every node (linking layer-3 addresses to
  layer-2 addresses, and to already present layer-2 cryptographic
  mechanisms) would be cheaper should RPL be run in an environment
  where hostile nodes are likely to be a part of the LLN.

** I'm having trouble understanding what recommendation this text was making.  The first sentence seems to suggest IPSec, the second sentence seems to discount that advice; and the third seems to suggest BCP38 as an alternative.  Could you please clarify.

** Please be explicit on which challenges in RFC5406 are being cited (e.g., which sections)

[Ballot discuss]
Per Section 11:
  [RFC2473] suggests that tunnel entry and exit points can be secured,
  via the "Use IPsec".  The suggested solution has all the problems
  that [RFC5406] goes into.  In an LLN such a solution would degenerate
  into every node having a tunnel with every other node.  It would
  provide a small amount of origin address authentication at a very
  high cost; doing BCP38 at every node (linking layer-3 addresses to
  layer-2 addresses, and to already present layer-2 cryptographic
  mechanisms) would be cheaper should RPL be run in an environment
  where hostile nodes are likely to be a part of the LLN.

** I having trouble understanding what recommendation this text was making.  The first sentence seems to suggest IPSec, the second sentence seems to discount that advice; and the third seems to suggest BCP38 as an alternative.  Could you please clarify.

** Please be explicit on which challenges in RFC5406 are being cited (e.g., which sections)

[Ballot comment]
(1) Abstract.  Per “Additionally, this document updates RFC 6550 to indicate about this change …”, this sentence didn’t parse for me in explaining the relationship with RFC6550.

(2) Section 1.  Typo.  s/implementors/implementers/

(3) Section 2.  Editorial Nit.  s/header refers to:/header refers to/

(4) Section 3.  A few editorial comments on how these updates are presented:

** Inconsistent spacing in Section 3 title:
s/Updates to RFC6553, RFC6550 and RFC 8138/
Updates to RFC6553, RFC6550 and RFC8138/

** Section 3.1 and Section 3.3 open with the motivation for the change.  Section 3.2 does not.

** Section 3.3 title describes the proposed change.  Section 3.1 and 3.2 simple state “Updates to RFCxxx”

** Section 3.1 – 3 titles include a space in the RFC names (i.e., RFC-space-number).  The Section 3 title does not.

(5) Section 3.1.  Editorial Nit.

** s/[RFC6553] states as shown below/[RFC6553] states as shown in Figure 1/

** Recommend citing the relevant page and section number from RFC6553 too.

(6) Section 3.2.  Please use more explicit language to describe how this section updates RFC8138.

(7) Section 3.2.  Figure 3 is depicted in this section but not referenced in the text.

(8) Section 4.  Typo.  s/A RPL Stack is shown in Figure 5/A RPL Stack is shown in Figure 6/

(9) Section 5.  Editorial Nit. s/these nodes are/These nodes are/

(10) Section 5.  A few editorial recommendations for this paragraph: 

The uses cases describe the communication between RPL-aware-nodes,
  with the root (6LBR), and with Internet.  This document also describe
  the communication between nodes acting as leaves that do not
  understand RPL, but are part of the LLN.  these  nodes are named as
  not-RPL-aware-leaf, mentioned previously.  (e.g.  Section 6.1.4 Flow
  from not-RPL-aware-leaf to root) This  document describes also how is
  the communication inside of the LLN when it has the final destination
  addressed outside of the LLN e.g. with destination to Internet.
  (e.g.  Section 6.2.3 Flow from not-RPL-aware-leaf to Internet)
** s/these nodes are/These nodes are/

** The sentence “This document describes also how …” doesn’t parse.

** The use of “(e.g. …)” as a standalone sentence doesn’t parse.

(11) Section 5.  Per “There is some possible security risk when the RPI information is released on the internet …”, I recommend reframing this text around the fact that the leak of RPI info would not present an issue. As is, the impact reads ambiguously to me.

(12) Section 6.  The meaning of “root” in Figure 7 is not explained in the text above it.

(13) Section 6.1.4.  Typo. s/encapsuladed/encapsulated/

(14) Section 9.  Editorial Nit.
s/ During bootstrapping the node get the DIO with the information of RPL Option Type/
During bootstrapping the node gets the DIO with the information of RPL Option Type/

(15) Section 11.  Make BCP38 a reference (i.e., [BCP38])

[Ballot comment]
= Section 1 =

"An interim meeting went through the 24 cases defined here to discover
  if there were any shortcuts, and this document is the result of that
  discussion."

These details seem unnecessary to include in an archival document.

= Section 3.1 =

"[RFCXXXX] represents this document."

This is not necessary to include.

= Section 9 =

"Related to the deployment of RPL, there are no known multivendor
  deployments outside of the research groups!  All known deployments of
  RPL are in market verticals, with a single vendor providing all
  components.  Research groups typically are using Contiki, RiotOS, or
  OpenWSN, and these are easily adapted to 0x23 functionality."

It seems like this text should be dropped or marked for removal once the RFC is published, since it will likely become out-of-date soon enough.

[Ballot comment]
The document goes in many many details about all messages, I am trusted the responsible AD's YES ballot as well as the WGLC on the correctness of those values.

Please note my comment C11:

Comments
--------

C1) Section 1, having a date or short description of the interim meeting could be useful here.

C2) Section 2, the term "Hop-by-hop IPv6-in-IPv6 headers" is confusing at first reading, what about "Link IPv6-in-IPv6 header" ? or "Single link IPv6-in-IPv6 header" ? Hop-by-hop has a specific meaning in IPv6. This term is not also used consistenly in the document.

C3) Section 3.1 after figure 1, routers will only drop HbH option starting with 01 IFF they do not understand the option type. The following paragraph describes a behavior that will only happens on nodes configured to ignore HbH.  In short, I am failing to understand why the code needs to be changed due to HbH processing is now optional per RFC 8200 (albeit I understand why changing it to 0x23 is useful).

C4) section 3.2 how does a network node would understand / learn that it is in "0x23 mode" ? It should provide a hint to section 3.3 or swap section 3.2 and 3.3 to make the task easier for the reader.

C5) section 3.3 if the decompression is also to 0x23 or 0x63, then what is the compressor behavior when receiving the other code?

C6) the introduction to RPL in section 4 after the topology is nice an concise but it is either too late in the document or useless (I prefer the former, for example in section 2).

C7) the code 0x23 is assumed everywhere but AFAIK there is no guarantee that IANA will use this code (even if this is the logical choice)

C8) it is assumed that the Internet has moved to RFC8200 and does not drop packets with HbH... "will not be discarded" I would prefer to have a disclaimer on the current sad state of the Internet

C9) section 5, while I am not an expert in RPL, I wonder whether the sentence "there can be no loops by construction" is true even in transient states ?

C10) section 6, is there any reason why the 'must' and 'root' values are not specified while 'hop' and others are ?

C11) section 6, I am afraid that I stop reading this document. Section 6.1.1 title is "SM: Example of Flow from RPL-aware-leaf to root" while SM has NOT been specified only RPL-SM.

There are many nits that makes the reader's job complex. A new revision fixing those nites is REQUIRED IMHO... Again, I am trusting your AD and WG for the correctness of the ideas but the document is NOT ready.

Nits
----

N1) in section 1, this is a unexpected abbreviation < "RPL option" (RPI) >

N2) in section 2, another unexpected abbreviation < RPL-aware-leaf (Raf) >

N3) section 3.1, inconsistent use of quotes around 01 and 1 in the same section

N4) section 4, acronyms such 6LR are here explained while section 2 referred to an external document... perhaps worth augmenting section 2 and removing the description in section 4 ?

N5) section 4, s/in non-storing (RPL-NSM)/in non-storing mode (RPL-NSM)/

N6) section 5 does not use the previously introduced abbreviations... this I-D looks like a patchwork (different authors -- and I made multiple times the same 'mistake' ;-) )

N7) section 5 s/Extensions may not be added/Extensions Headers may not be added/

N8) section 5 repeat the use of 01 in the option and its explanation => remove this part

N9) section 5 s/to add to remove/to add and remove/ ?

N10) section 6, s/It indicate/It indicates/

N11) section 6, s/hop by hop/hop-by-hop/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-roll-useofrplinfo-25. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Destination Options and Hop-by-Hop Options registry on the Internet Protocol Version 6 (IPv6) Parameters registry page located at:

https://www.iana.org/assignments/ipv6-parameters/

a new registration will be made as follows:

Hex Value: 0x23
Binary value act: 00
Binary value chg: 1
Binary value rest: 00011
Description: RPL Option
Reference: [ RFC-to-be ]

and the existing registration for Hex Value 0x63 will be changed to the following:

Hex Value: 0x63
Binary value act: 01
Binary value chg: 1
Binary value rest: 00011
Description: RPL Option (DEPRECATED)
Reference: [ RFC6553 ][ RFC-to-be ]

Second, in the DODAG Configuration Option Flags registry on the Routing Protocol for Low Power and Lossy Networks (RPL) registry page located at:

https://www.iana.org/assignments/rpl/

a single, new registration is to be made as follows:

Bit number: 3
Capability Description: RPI 0x23 enable
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-04-11):

From: The IESG
To: IETF-Announce
CC: consultancy@vanderstok.org, roll-chairs@ietf.org, roll@ietf.org, Peter Van der Stok , aretana.ietf@gmail.com, draft-ietf-roll-useofrplinfo@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane) to Proposed Standard


The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document: - 'Using RPL Option
Type, Routing Header for Source Routes and IPv6-in-
  IPv6 encapsulation in the RPL Data Plane'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-04-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document looks at different data flows through LLN (Low-Power
  and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
  and Lossy Networks) is used to establish routing.  The document
  enumerates the cases where RFC 6553 (RPL Option Type), RFC 6554
  (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is
  required in data plane.  This analysis provides the basis on which to
  design efficient compression of these headers.  This document updates
  RFC 6553 adding a change to the RPL Option Type.  Additionally, this
  document updates RFC 6550 to indicate about this change and updates
  RFC8138 as well to consider the new Option Type when RPL Option is
  decompressed.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ballot/


No IPR declarations have been submitted directly on this I-D.

=== AD Review of draft-ietf-roll-useofrplinfo-23 ===


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.

Shepherd document for ietf-roll-useofrplinfo; This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
Document is submitted as Proposed Standard; the document prescribes the headers to be used when a packet travels between a RPL network and a non-RPL network.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
(2a) Technical Summary
This document looks at different data flows through LLN (Low-Power
  and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
  and Lossy Networks) is used to establish routing.  The document
  enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6
  encapsulation is required.  This analysis provides the basis on which
  to design efficient compression of these headers.  Additionally, this
  document updates the RFC 6553 adding a change to the RPL Option Type
  and the RFC 6550 to indicate about this change.
(2b) Working Group Summary
There was clear consensus in the ROLL WG that this document was needed.
The extensive subject, involving many details, has led to lengthy discussions about terminology, and coverage of all cases.
(2c) Document Quality
The document is of special value to the the 6tisch WG.
There are no known implementations by manufacturers, but comments have been incorporated from people who needed to address a subset of the  cases discussed in the document.
The drafts ietf-anima-bootstrapping-keyinfra and ietf-6tisch-dtsecurity-secure-join rely on the cases discussed in this document.
No media type is created. Extensive discussions with 6man occurred because the document was edited at the same time that RGFC8200 was prepared
(2d)Personnel
Document Shepherd is Peter van der Stok;
Responsible Area Director is Alvaro Retana

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
The shepherd has reviewed this document twice: Once to get terminology and structure correct and second time to look at security aspects and 6man conformance. This version is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
The shepherd has no concerns about breadth and depth of document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
The WGLC included the 6man WG. Brian carpenter was kind enough to express conformance with 6man guidelines.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
There are absolutely no concerns about the validity of the document. However, the number of uses cases tends to overwhelm the reader who is usually interested in two or three cases out of the 24 discussed cases.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Each author confirmed that no known IPR is related to this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
No IPR disclosure been filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?
The most active part of the WG stands solidly behind this document.
In the long process, all relevant persons have discussed the document on the Mailing List.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
No appeal or extreme discontent has been expressed.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
The document has passed all the nit checks.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
No formal review criteria, such as the MIB Doctor, media type, and URI type reviews are relevant.

(13) Have all references within this document been identified as
either normative or informative?
All references within this document have been identified as either normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
There are no normative references to documents in progress.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
There is one downward normative reference to RFC 7416.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
The publication of this document will not change the status of any
existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
The IANA considerations section, updates the registration made in [RFC6553] Destination Options and Hop-by-Hop Options registry from 0x63 to 0x23.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
No new IANA registries are created.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
No sections of the document contain text written in a formal language, such as XML code, BNF rules, MIB definitions, etc.