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

Summary: Has a DISCUSS. Needs one more YES or NO OBJECTION position to pass.

Erik Kline Discuss

Discuss (2020-12-15 for -42)
[ 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."
Comment (2020-12-15 for -42)
[[ 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 <noun|noun phrase> in the code", I think

[ section 9 ]

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

[ section 12 ]

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

Alvaro Retana Yes

Deborah Brungard No Objection

Alissa Cooper No Objection

Roman Danyliw No Objection

Comment (2020-12-16 for -42)
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/

Martin Duke No Objection

Benjamin Kaduk No Objection

Comment (2020-12-17 for -42)
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.

Barry Leiba No Objection

Comment (2020-12-16 for -42)
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)”.

Éric Vyncke No Objection

Comment (2020-12-14 for -42)
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, ..."

Robert Wilton No Objection

Murray Kucherawy No Record

Warren Kumari No Record

Martin Vigoureux No Record

Magnus Westerlund No Record