Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane
draft-ietf-roll-useofrplinfo-44
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
44 | Gunter Van de Velde | Request closed, assignment withdrawn: Carlos Martínez Last Call OPSDIR review |
2024-01-26
|
44 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2021-03-26
|
44 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-03-22
|
44 | (System) | RFC Editor state changed to AUTH48 |
2021-02-16
|
44 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-01-28
|
44 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-01-28
|
44 | Alvaro Retana | 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 … 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). |
2021-01-28
|
44 | Alvaro Retana | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-01-27
|
44 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-01-27
|
44 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-01-27
|
44 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-01-26
|
44 | (System) | RFC Editor state changed to EDIT |
2021-01-26
|
44 | (System) | IANA Action state changed to In Progress from RFC-Ed-Ack |
2021-01-26
|
44 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-01-26
|
44 | Amy Vezza | IESG has approved the document |
2021-01-26
|
44 | Amy Vezza | Closed "Approve" ballot |
2021-01-26
|
44 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2021-01-26
|
44 | Alvaro Retana | Ballot approval text was generated |
2021-01-25
|
44 | Erik Kline | [Ballot Position Update] Position for Erik Kline has been changed to No Objection from Discuss |
2021-01-15
|
44 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-44.txt |
2021-01-15
|
44 | (System) | New version accepted (logged-in submitter: Ines Robles) |
2021-01-15
|
44 | Ines Robles | Uploaded new revision |
2021-01-10
|
43 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-01-10
|
43 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-01-10
|
43 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-43.txt |
2021-01-10
|
43 | (System) | New version accepted (logged-in submitter: Ines Robles) |
2021-01-10
|
43 | Ines Robles | Uploaded new revision |
2020-12-17
|
42 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-12-17
|
42 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-12-17
|
42 | Benjamin Kaduk | [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 … [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. |
2020-12-17
|
42 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2020-12-16
|
42 | Barry Leiba | [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 … [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)”. |
2020-12-16
|
42 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-12-16
|
42 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-12-16
|
42 | Roman Danyliw | [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 … [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/ |
2020-12-16
|
42 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-12-15
|
42 | Erik Kline | [Ballot discuss] [ section 12 ] * Ignoring an invalid RH3 header by the end host (I'm assuming this means that segments left > … [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." |
2020-12-15
|
42 | Erik Kline | [Ballot comment] [[ comments ]] [ section 8.1.3 ] * I'm confused by the use of "consumed" here. Is the final RH3 entry RUL's … [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" |
2020-12-15
|
42 | Erik Kline | [Ballot Position Update] New position, Discuss, has been recorded for Erik Kline |
2020-12-15
|
42 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-12-14
|
42 | Éric Vyncke | [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 … [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, ..." |
2020-12-14
|
42 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-12-10
|
42 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-12-09
|
42 | Amy Vezza | Telechat date has been changed to 2020-12-17 from 2019-05-30 |
2020-12-09
|
42 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2020-12-09
|
42 | Alvaro Retana | Ballot has been issued |
2020-12-09
|
42 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2020-12-09
|
42 | Alvaro Retana | Created "Approve" ballot |
2020-12-09
|
42 | Alvaro Retana | Ballot writeup was changed |
2020-12-09
|
42 | Mališa Vučinić | Request for Last Call review by IOTDIR Completed: Ready. Reviewer: Mališa Vučinić. Sent review to list. |
2020-12-09
|
42 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2020-12-08
|
42 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-12-08
|
42 | Sabrina Tanamal | (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 … (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 |
2020-12-06
|
42 | Henning Rogge | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Henning Rogge. Sent review to list. |
2020-11-17
|
42 | Ines Robles | Request for Last Call review by IOTDIR is assigned to Mališa Vučinić |
2020-11-17
|
42 | Ines Robles | Request for Last Call review by IOTDIR is assigned to Mališa Vučinić |
2020-11-17
|
42 | Min Ye | Request for Last Call review by RTGDIR is assigned to Henning Rogge |
2020-11-17
|
42 | Min Ye | Request for Last Call review by RTGDIR is assigned to Henning Rogge |
2020-11-16
|
42 | Alvaro Retana | Requested Last Call review by RTGDIR |
2020-11-16
|
42 | Alvaro Retana | Requested Last Call review by IOTDIR |
2020-11-15
|
42 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2020-11-15
|
42 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2020-11-13
|
42 | Cindy Morgan | < |
2020-11-13
|
42 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-11-13
|
42 | Alvaro Retana | Last call was requested |
2020-11-13
|
42 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2020-11-13
|
42 | Alvaro Retana | Last call announcement was changed |
2020-11-13
|
42 | Alvaro Retana | Last call announcement was generated |
2020-11-12
|
42 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-11-12
|
42 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-11-12
|
42 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-42.txt |
2020-11-12
|
42 | (System) | Forced post of submission |
2020-11-12
|
42 | (System) | Request for posting confirmation emailed to previous authors: Michael Richardson , Ines Robles , Pascal Thubert |
2020-11-12
|
42 | Ines Robles | Uploaded new revision |
2020-11-09
|
41 | Alvaro Retana | == AD Review of draft-ietf-roll-useofrplinfo-41 == https://mailarchive.ietf.org/arch/msg/roll/-bVUL_aDX3yVknlbzHbTJHLQn1I/ |
2020-11-09
|
41 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2020-10-22
|
41 | Alvaro Retana | 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 … 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. |
2020-10-22
|
41 | Alvaro Retana | IESG state changed to AD Evaluation::AD Followup from RFC Ed Queue |
2020-09-21
|
41 | Michael Richardson | New version available: draft-ietf-roll-useofrplinfo-41.txt |
2020-09-21
|
41 | (System) | New version approved |
2020-09-21
|
41 | (System) | Request for posting confirmation emailed to previous authors: Ines Robles , Pascal Thubert , Michael Richardson |
2020-09-21
|
41 | Michael Richardson | Uploaded new revision |
2020-09-21
|
41 | Michael Richardson | Uploaded new revision |
2020-07-29
|
40 | Mališa Vučinić | Request for Telechat review by IOTDIR Completed: Ready with Issues. Reviewer: Mališa Vučinić. Sent review to list. |
2020-06-29
|
40 | Samita Chakrabarti | Request for Telechat review by IOTDIR is assigned to Mališa Vučinić |
2020-06-29
|
40 | Samita Chakrabarti | Request for Telechat review by IOTDIR is assigned to Mališa Vučinić |
2020-06-26
|
40 | Dominique Barthel | Requested Telechat review by IOTDIR |
2020-06-25
|
40 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-40.txt |
2020-06-25
|
40 | (System) | New version accepted (logged-in submitter: Ines Robles) |
2020-06-25
|
40 | Ines Robles | Uploaded new revision |
2020-06-14
|
39 | Peter Van der Stok | 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, … 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. |
2020-06-14
|
39 | Peter Van der Stok | 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, … 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. |
2020-06-08
|
39 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-39.txt |
2020-06-08
|
39 | (System) | New version accepted (logged-in submitter: Ines Robles) |
2020-06-08
|
39 | Ines Robles | Uploaded new revision |
2020-03-23
|
38 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-38.txt |
2020-03-23
|
38 | (System) | New version approved |
2020-03-23
|
38 | (System) | Request for posting confirmation emailed to previous authors: Michael Richardson , Pascal Thubert , Ines Robles |
2020-03-23
|
38 | Ines Robles | Uploaded new revision |
2020-03-14
|
37 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-37.txt |
2020-03-14
|
37 | (System) | New version approved |
2020-03-14
|
37 | (System) | Request for posting confirmation emailed to previous authors: Michael Richardson , Ines Robles , Pascal Thubert |
2020-03-14
|
37 | Ines Robles | Uploaded new revision |
2020-02-26
|
36 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-36.txt |
2020-02-26
|
36 | (System) | New version accepted (logged-in submitter: Ines Robles) |
2020-02-26
|
36 | Ines Robles | Uploaded new revision |
2020-02-12
|
35 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-35.txt |
2020-02-12
|
35 | (System) | New version accepted (logged-in submitter: Ines Robles) |
2020-02-12
|
35 | Ines Robles | Uploaded new revision |
2020-01-20
|
34 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-34.txt |
2020-01-20
|
34 | (System) | New version accepted (logged-in submitter: Ines Robles) |
2020-01-20
|
34 | Ines Robles | Uploaded new revision |
2019-12-13
|
33 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-33.txt |
2019-12-13
|
33 | (System) | New version accepted (logged-in submitter: Ines Robles) |
2019-12-13
|
33 | Ines Robles | Uploaded new revision |
2019-11-08
|
32 | Éric Vyncke | Request closed, assignment withdrawn: Charles Perkins Last Call IOTDIR review |
2019-11-08
|
32 | Éric Vyncke | Closed request for Last Call review by IOTDIR with state 'Withdrawn': Document is already in RFC Ed Queue |
2019-11-05
|
32 | Dominique Barthel | Added to session: IETF-106: roll Tue-1000 |
2019-11-04
|
32 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-32.txt |
2019-11-04
|
32 | (System) | New version accepted (logged-in submitter: Ines Robles) |
2019-11-04
|
32 | Ines Robles | Uploaded new revision |
2019-09-03
|
31 | (System) | RFC Editor state changed to IESG from EDIT |
2019-08-26
|
31 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Qin Wu was marked no-response |
2019-08-07
|
32 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-32.txt |
2019-08-07
|
32 | (System) | New version approved |
2019-08-07
|
32 | (System) | Request for posting confirmation emailed to previous authors: Ines Robles , Pascal Thubert , Michael Richardson |
2019-08-07
|
32 | Ines Robles | Uploaded new revision |
2019-07-15
|
31 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-07-12
|
31 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-07-12
|
31 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-07-12
|
31 | (System) | RFC Editor state changed to EDIT |
2019-07-12
|
31 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-07-12
|
31 | (System) | Announcement was received by RFC Editor |
2019-07-11
|
31 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-07-11
|
31 | (System) | IANA Action state changed to In Progress |
2019-07-11
|
31 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-07-11
|
31 | Cindy Morgan | IESG has approved the document |
2019-07-11
|
31 | Cindy Morgan | Closed "Approve" ballot |
2019-07-11
|
31 | Cindy Morgan | Ballot approval text was generated |
2019-07-11
|
31 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2019-07-04
|
31 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-07-04
|
31 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-31.txt |
2019-07-04
|
31 | (System) | New version approved |
2019-07-04
|
31 | (System) | Request for posting confirmation emailed to previous authors: Ines Robles , Pascal Thubert , Michael Richardson |
2019-07-04
|
31 | Ines Robles | Uploaded new revision |
2019-07-03
|
30 | Alvaro Retana | Pascal identified one more change to be made. |
2019-07-03
|
30 | Alvaro Retana | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
2019-06-25
|
30 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-06-25
|
30 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-30.txt |
2019-06-25
|
30 | (System) | New version approved |
2019-06-25
|
30 | (System) | Request for posting confirmation emailed to previous authors: Ines Robles , Pascal Thubert , Michael Richardson |
2019-06-25
|
30 | Ines Robles | Uploaded new revision |
2019-05-30
|
29 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2019-05-30
|
29 | Suresh Krishnan | [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 … [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. |
2019-05-30
|
29 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-05-29
|
29 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-05-29
|
29 | Roman Danyliw | [Ballot comment] Thanks for addressing my DISCUSSes and COMMENTs. |
2019-05-29
|
29 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2019-05-28
|
29 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-05-26
|
29 | Benjamin Kaduk | [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 … [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. |
2019-05-26
|
29 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-05-20
|
29 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-29.txt |
2019-05-20
|
29 | (System) | New version approved |
2019-05-20
|
29 | (System) | Request for posting confirmation emailed to previous authors: Ines Robles , Pascal Thubert , Michael Richardson |
2019-05-20
|
29 | Ines Robles | Uploaded new revision |
2019-05-17
|
28 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-28.txt |
2019-05-17
|
28 | (System) | New version approved |
2019-05-17
|
28 | (System) | Request for posting confirmation emailed to previous authors: Ines Robles , Pascal Thubert , Michael Richardson |
2019-05-17
|
28 | Ines Robles | Uploaded new revision |
2019-05-16
|
27 | Éric Vyncke | [Ballot comment] The revised ID has fixed all my DISCUSS points. Thank you to the authors. |
2019-05-16
|
27 | Éric Vyncke | [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss |
2019-05-16
|
27 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-27.txt |
2019-05-16
|
27 | (System) | New version approved |
2019-05-16
|
27 | (System) | Request for posting confirmation emailed to previous authors: Ines Robles , Pascal Thubert , Michael Richardson |
2019-05-16
|
27 | Ines Robles | Uploaded new revision |
2019-05-15
|
26 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-05-15
|
26 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-26.txt |
2019-05-15
|
26 | (System) | New version approved |
2019-05-15
|
26 | (System) | Request for posting confirmation emailed to previous authors: Ines Robles , Pascal Thubert , Michael Richardson |
2019-05-15
|
26 | Ines Robles | Uploaded new revision |
2019-05-06
|
25 | Cindy Morgan | IESG state changed to IESG Evaluation from IESG Evaluation - Defer |
2019-05-06
|
25 | Cindy Morgan | Telechat date has been changed to 2019-05-30 from 2019-05-16 |
2019-05-02
|
25 | Suresh Krishnan | Telechat date has been changed to 2019-05-16 from 2019-05-02 |
2019-05-02
|
25 | Suresh Krishnan | IESG state changed to IESG Evaluation - Defer from IESG Evaluation |
2019-05-02
|
25 | Benjamin Kaduk | [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 … [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? |
2019-05-02
|
25 | Benjamin Kaduk | [Ballot comment] Section 1 An interim meeting went through the 24 cases defined here to discover if there were any shortcuts, and this … [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. |
2019-05-02
|
25 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-05-02
|
25 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2019-05-02
|
25 | Mirja Kühlewind | [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 … [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. |
2019-05-02
|
25 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-05-01
|
25 | Éric Vyncke | [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 … [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. |
2019-05-01
|
25 | Éric Vyncke | [Ballot comment] Comments -------- C1) Section 1, having a date or short description of the interim meeting could be useful here. C2) Section 2, the … [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/ |
2019-05-01
|
25 | Éric Vyncke | [Ballot Position Update] Position for Éric Vyncke has been changed to Discuss from No Record |
2019-05-01
|
25 | Warren Kumari | [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 … [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? |
2019-05-01
|
25 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-05-01
|
25 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-04-30
|
25 | Adam Roach | [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 … [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. |
2019-04-30
|
25 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-04-30
|
25 | Roman Danyliw | [Ballot discuss] Per Section 11: [RFC2473] suggests that tunnel entry and exit points can be secured, via the "Use IPsec". The … [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) |
2019-04-30
|
25 | Roman Danyliw | Ballot discuss text updated for Roman Danyliw |
2019-04-30
|
25 | Roman Danyliw | [Ballot discuss] Per Section 11: [RFC2473] suggests that tunnel entry and exit points can be secured, via the "Use IPsec". The … [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) |
2019-04-30
|
25 | Roman Danyliw | [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 … [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]) |
2019-04-30
|
25 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2019-04-30
|
25 | Alissa Cooper | [Ballot comment] = Section 1 = "An interim meeting went through the 24 cases defined here to discover if there were any shortcuts, and … [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. |
2019-04-30
|
25 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-04-29
|
25 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-04-29
|
25 | Éric Vyncke | [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 … [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/ |
2019-04-29
|
25 | Éric Vyncke | Ballot comment text updated for Éric Vyncke |
2019-04-17
|
25 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Henning Rogge. Sent review to list. |
2019-04-12
|
25 | Samita Chakrabarti | Request for Last Call review by IOTDIR is assigned to Charles Perkins |
2019-04-12
|
25 | Samita Chakrabarti | Request for Last Call review by IOTDIR is assigned to Charles Perkins |
2019-04-11
|
25 | Amy Vezza | Placed on agenda for telechat - 2019-05-02 |
2019-04-11
|
25 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-04-11
|
25 | Alvaro Retana | Ballot has been issued |
2019-04-11
|
25 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2019-04-11
|
25 | Alvaro Retana | Created "Approve" ballot |
2019-04-11
|
25 | Alvaro Retana | Ballot writeup was changed |
2019-04-11
|
25 | Colin Perkins | Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Colin Perkins. Sent review to list. |
2019-04-11
|
25 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-04-10
|
25 | Daniel Migault | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Daniel Migault. Sent review to list. |
2019-04-09
|
25 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2019-04-09
|
25 | Sabrina Tanamal | (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 … (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 |
2019-04-03
|
25 | Russ Housley | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Russ Housley. Sent review to list. |
2019-04-03
|
25 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Qin Wu |
2019-04-03
|
25 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Qin Wu |
2019-03-28
|
25 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2019-03-28
|
25 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2019-03-24
|
25 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Colin Perkins |
2019-03-24
|
25 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Colin Perkins |
2019-03-22
|
25 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Migault |
2019-03-22
|
25 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Migault |
2019-03-21
|
25 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-03-21
|
25 | Cindy Morgan | 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 … 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. |
2019-03-21
|
25 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-03-21
|
25 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Henning Rogge |
2019-03-21
|
25 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Henning Rogge |
2019-03-21
|
25 | Alvaro Retana | Requested Last Call review by RTGDIR |
2019-03-21
|
25 | Alvaro Retana | Requested Last Call review by IOTDIR |
2019-03-21
|
25 | Alvaro Retana | Last call was requested |
2019-03-21
|
25 | Alvaro Retana | Ballot approval text was generated |
2019-03-21
|
25 | Alvaro Retana | Ballot writeup was generated |
2019-03-21
|
25 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-03-21
|
25 | Alvaro Retana | Last call announcement was changed |
2019-03-21
|
25 | Alvaro Retana | Last call announcement was generated |
2019-03-12
|
25 | Ines Robles | Added to session: IETF-104: roll Mon-1610 |
2019-03-11
|
25 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-03-11
|
25 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-25.txt |
2019-03-11
|
25 | (System) | New version approved |
2019-03-11
|
25 | (System) | Request for posting confirmation emailed to previous authors: Ines Robles , Pascal Thubert , Michael Richardson |
2019-03-11
|
25 | Ines Robles | Uploaded new revision |
2019-01-30
|
24 | Alvaro Retana | There's still some work needed on the Operational Considerations and other points. |
2019-01-30
|
24 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2019-01-23
|
24 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-01-23
|
24 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-24.txt |
2019-01-23
|
24 | (System) | New version approved |
2019-01-23
|
24 | (System) | Request for posting confirmation emailed to previous authors: roll-chairs@ietf.org, Pascal Thubert , Michael Richardson , Ines Robles |
2019-01-23
|
24 | Ines Robles | Uploaded new revision |
2018-08-14
|
23 | Alvaro Retana | === 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 … === 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. |
2018-08-14
|
23 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2018-08-14
|
23 | Alvaro Retana | Notification list changed to Peter Van der Stok <consultancy@vanderstok.org>, aretana.ietf@gmail.com from Peter Van der Stok <consultancy@vanderstok.org> |
2018-05-01
|
23 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-05-01
|
23 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-23.txt |
2018-05-01
|
23 | (System) | New version approved |
2018-05-01
|
23 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Michael Richardson , Ines Robles |
2018-05-01
|
23 | Ines Robles | Uploaded new revision |
2018-03-19
|
22 | Alvaro Retana | The authors mentioned that an update is needed because of some recent comments. |
2018-03-19
|
22 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-03-01
|
22 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-22.txt |
2018-03-01
|
22 | (System) | New version approved |
2018-03-01
|
22 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Michael Richardson , Ines Robles |
2018-03-01
|
22 | Ines Robles | Uploaded new revision |
2018-02-15
|
21 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2018-02-13
|
21 | Peter Van der Stok | 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, … 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. |
2018-02-13
|
21 | Peter Van der Stok | Responsible AD changed to Alvaro Retana |
2018-02-13
|
21 | Peter Van der Stok | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2018-02-13
|
21 | Peter Van der Stok | IESG state changed to Publication Requested |
2018-02-13
|
21 | Peter Van der Stok | IESG process started in state Publication Requested |
2018-02-13
|
21 | Peter Van der Stok | Notification list changed to Peter Van der Stok <consultancy@vanderstok.org> from "Ralph Droms" <rdroms@cisco.com>, Peter Van der Stok <consultancy@vanderstok.org> |
2018-02-10
|
21 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-21.txt |
2018-02-10
|
21 | (System) | New version approved |
2018-02-10
|
21 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Michael Richardson , Ines Robles |
2018-02-10
|
21 | Ines Robles | Uploaded new revision |
2018-02-07
|
20 | Peter Van der Stok | Changed document writeup |
2018-01-29
|
20 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-20.txt |
2018-01-29
|
20 | (System) | New version approved |
2018-01-29
|
20 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Michael Richardson , Ines Robles |
2018-01-29
|
20 | Ines Robles | Uploaded new revision |
2017-11-12
|
19 | Ines Robles | Added to session: IETF-100: roll Wed-1330 |
2017-10-30
|
19 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-19.txt |
2017-10-30
|
19 | (System) | New version approved |
2017-10-30
|
19 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Michael Richardson , Ines Robles |
2017-10-30
|
19 | Ines Robles | Uploaded new revision |
2017-10-30
|
18 | Michael Richardson | New version available: draft-ietf-roll-useofrplinfo-18.txt |
2017-10-30
|
18 | (System) | New version approved |
2017-10-30
|
18 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Michael Richardson , Ines Robles |
2017-10-30
|
18 | Michael Richardson | Uploaded new revision |
2017-10-30
|
18 | Michael Richardson | Uploaded new revision |
2017-10-28
|
17 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-17.txt |
2017-10-28
|
17 | (System) | New version approved |
2017-10-28
|
17 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Michael Richardson , Ines Robles |
2017-10-28
|
17 | Ines Robles | Uploaded new revision |
2017-07-04
|
16 | Ines Robles | Added to session: IETF-99: roll Thu-1330 |
2017-07-03
|
16 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-16.txt |
2017-07-03
|
16 | (System) | New version approved |
2017-07-03
|
16 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , Michael Richardson , Ines Robles |
2017-07-03
|
16 | Ines Robles | Uploaded new revision |
2017-06-29
|
15 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-15.txt |
2017-06-29
|
15 | (System) | New version approved |
2017-06-29
|
15 | (System) | Request for posting confirmation emailed to previous authors: roll-chairs@ietf.org, Michael Richardson , Ines Robles |
2017-06-29
|
15 | Ines Robles | Uploaded new revision |
2017-04-14
|
14 | Ines Robles | Notification list changed to "Ralph Droms" <rdroms@cisco.com>, Peter Van der Stok <consultancy@vanderstok.org> from "Ralph Droms" <rdroms@cisco.com> |
2017-04-14
|
14 | Ines Robles | Document shepherd changed to Peter Van der Stok |
2017-04-05
|
14 | Michael Richardson | New version available: draft-ietf-roll-useofrplinfo-14.txt |
2017-04-05
|
14 | (System) | New version approved |
2017-04-05
|
14 | (System) | Request for posting confirmation emailed to previous authors: roll-chairs@ietf.org, Michael Richardson , Ines Robles |
2017-04-05
|
14 | Michael Richardson | Uploaded new revision |
2017-04-03
|
13 | Michael Richardson | New version available: draft-ietf-roll-useofrplinfo-13.txt |
2017-04-03
|
13 | (System) | New version approved |
2017-04-03
|
13 | (System) | Request for posting confirmation emailed to previous authors: roll-chairs@ietf.org, Pascal Thubert , Michael Richardson , Ines Robles |
2017-04-03
|
13 | Michael Richardson | Uploaded new revision |
2017-03-30
|
12 | Ines Robles | Added to session: IETF-98: roll Thu-1740 |
2017-03-13
|
12 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-12.txt |
2017-03-13
|
12 | (System) | New version approved |
2017-03-13
|
12 | (System) | Request for posting confirmation emailed to previous authors: roll-chairs@ietf.org, Pascal Thubert , Michael Richardson , Ines Robles |
2017-03-13
|
12 | Ines Robles | Uploaded new revision |
2017-03-03
|
11 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-11.txt |
2017-03-03
|
11 | (System) | New version approved |
2017-03-03
|
11 | (System) | Request for posting confirmation emailed to previous authors: roll-chairs@ietf.org, Pascal Thubert , Michael Richardson , Ines Robles |
2017-03-03
|
11 | Ines Robles | Uploaded new revision |
2016-12-12
|
10 | Michael Richardson | New version available: draft-ietf-roll-useofrplinfo-10.txt |
2016-12-12
|
10 | (System) | New version approved |
2016-12-12
|
10 | (System) | Request for posting confirmation emailed to previous authors: roll-chairs@ietf.org, "Ines Robles" , "Pascal Thubert" , "Michael Richardson" |
2016-12-12
|
10 | Michael Richardson | Uploaded new revision |
2016-11-11
|
09 | Ines Robles | IETF WG state changed to In WG Last Call from WG Document |
2016-11-07
|
09 | Peter Van der Stok | Added to session: IETF-97: roll Wed-1110 |
2016-10-21
|
09 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-09.txt |
2016-10-21
|
09 | (System) | New version approved |
2016-10-21
|
09 | (System) | Request for posting confirmation emailed to previous authors: roll-chairs@ietf.org, "Ines Robles" , "Pascal Thubert" , "Michael Richardson" |
2016-10-21
|
09 | Ines Robles | Uploaded new revision |
2016-09-14
|
08 | Michael Richardson | New version available: draft-ietf-roll-useofrplinfo-08.txt |
2016-09-14
|
08 | Michael Richardson | New version approved |
2016-09-13
|
07 | Michael Richardson | Request for posting confirmation emailed to previous authors: roll-chairs@ietf.org, "Ines Robles" , "Pascal Thubert" , "Michael Richardson" |
2016-09-13
|
07 | (System) | Uploaded new revision |
2016-07-20
|
07 | Michael Richardson | New version available: draft-ietf-roll-useofrplinfo-07.txt |
2016-07-18
|
06 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-06.txt |
2016-06-10
|
05 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-05.txt |
2016-04-05
|
04 | Michael Richardson | New version available: draft-ietf-roll-useofrplinfo-04.txt |
2016-04-04
|
03 | Michael Richardson | New version available: draft-ietf-roll-useofrplinfo-03.txt |
2016-04-03
|
02 | Ines Robles | Notification list changed to "Ralph Droms" <rdroms@cisco.com> |
2016-04-03
|
02 | Ines Robles | Document shepherd changed to Ralph Droms |
2016-03-21
|
02 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-02.txt |
2016-02-27
|
01 | Michael Richardson | New version available: draft-ietf-roll-useofrplinfo-01.txt |
2016-02-09
|
00 | Michael Richardson | Added version 00 to session: IETF-95: roll (unscheduled) |
2016-01-29
|
00 | Michael Richardson | Changed consensus to Yes from Unknown |
2016-01-29
|
00 | Michael Richardson | Intended Status changed to Proposed Standard from None |
2016-01-29
|
00 | Michael Richardson | Per adoption call, counted by Ralph Droms. |
2016-01-29
|
00 | Michael Richardson | This document now replaces draft-robles-roll-useofrplinfo instead of None |
2016-01-29
|
00 | Ines Robles | New version available: draft-ietf-roll-useofrplinfo-00.txt |