[Roll] AD Review of draft-ietf-roll-unaware-leaves-18
Alvaro Retana <aretana.ietf@gmail.com> Wed, 16 September 2020 14:58 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D20A3A0957; Wed, 16 Sep 2020 07:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCXDXkCeLcPR; Wed, 16 Sep 2020 07:58:18 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BFE43A093D; Wed, 16 Sep 2020 07:58:18 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id o8so10765882ejb.10; Wed, 16 Sep 2020 07:58:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=nlQe4W15aDxBr4UOOsDrK4ZNjLxZnTaRLmxcmyfwd5M=; b=oIofQOxokz9r4IRqDnKEY/LKF5/N4JCt2mS5HHdThlFIjXqEdnqIhcllGg8jT+fOad 4SoE2AGjF2CPvaJkygWk/YA0OWBllnGu5mpyPhdX6AbCQMuqnSeLC9E1I2ZCDygDGdVY sZYX0wRMBhv2eGdCf3VPDrJg4yoMCS/m9iGkAW29H2KxxhaEZ9rG2zW4pn71LCIF+8sW 9IcNqLYNxmOFMwYG//ZQn2hGkdb91Qr7O3VbURbP92nkVvegdmP9CsULaV+Ms41ZZlBN x5vo4iXV2UAa4Rqf7bXrYGpuETOBrfVC64/qYhlFwHEHjdYiOuOSS0ExY05OaYeTZVcE JRHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=nlQe4W15aDxBr4UOOsDrK4ZNjLxZnTaRLmxcmyfwd5M=; b=nA5I4wR9oBrwHbx8NrrRpcLZqh4uuU1h/eq9ppC8ZnA8u2tNZDbn1VAG7WMvwWDL4h dhjU6d+Dlzbau+5weP9A4fMLv6CE2Hfbp4OBipim13RontHi1LJH0lrhzQ89uQXOKcy0 AdM2x8SXFnnJYxMckIBWd1lF6u9R6Vpml8hewFijsQJMSMMaDFG1ZflLqXyTcLWPK+7A Cy75lkHysZxfMGe2X4J2a6usLKnd/k6sKI9IMC0vSkc1ggDWFHIP/APnJwdrTU3L4l0g KclVH1DFlctdTPFgRVxDiFnolA81c9Pp5kQQzut/SM3O2MlEUoL0J7n8v9+47vvnBMjK 8a9w==
X-Gm-Message-State: AOAM531oe0rFDl1nCxBhLeXtOnTinPDilYw+Cgh1JQm3qwhHb2RG1gPs P4hbaRwGRaimGEtTgXy6booDRzmQjxQdT5MqyCQ/FWey
X-Google-Smtp-Source: ABdhPJxfv+s2yqakp3ZakstKZXwLeEi3jcG7DymANMF4vuI9WtBoTSwghj/HCxSU1fQsi2vUJRkvIoqFcCDnIguXRh8=
X-Received: by 2002:a17:906:8c1:: with SMTP id o1mr26653743eje.478.1600268293578; Wed, 16 Sep 2020 07:58:13 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 16 Sep 2020 07:58:12 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
MIME-Version: 1.0
Date: Wed, 16 Sep 2020 07:58:12 -0700
Message-ID: <CAMMESszw4SuUQtchiqk-o7Z=62X+U2af4==X5S_=rJ-3y4Dn=w@mail.gmail.com>
To: draft-ietf-roll-unaware-leaves@ietf.org
Cc: Rahul Jadhav <rahul.ietf@gmail.com>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/wp3UFGCCCDUfWfUoYH820jj7Ebk>
Subject: [Roll] AD Review of draft-ietf-roll-unaware-leaves-18
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2020 14:58:25 -0000
Dear Pascal/Michael: Thank you for working on this document! I just finished reviewing it and find myself with a lot more comments, questions, and concerns that I thought I would. I'm highlighting some of my major issues here, and have detailed comments in-line. (1) What is a RUL? I assumed that a RUL would be a "plain" IPv6 node that is not aware of RPL at all. That definition would include, of course, not being aware of this document...but §7 normatively defines requirements and expected behaviors for the RUL. It feels like the chicken and the egg: the RUL is not aware...but it is expected to comply with this specification....but it's not aware... The definition of a RUL starts in the Introduction with a simple description: "RUL is an IPv6 Host [RFC8504]". I know that rfc8504 includes a section on "Constrained Devices", but it just mentions that "compromises may need to be made". This document, in the very next paragraph (!), adds other expectations (beyond rfc8504): support for 6LoWPAN ND... I can see in the email archive that going beyond rfc8504 is the intent, but that is not clearly reflected in the document. I would like to see, at least, an early discussion (don't wait until §7!) of the expectations for a RUL. Move §7 *before* you start discussing 6LoWPAN ND. I believe that describing the expectations may not preclude from assuming that the RUL is, in fact, unaware (of this document and RPL). For example, instead of saying "a RUL MUST implement [RFC8505]", the text could say something like this: This document is based on the assumption that a RUL supports rfc8505... If the RUL doesn't support rfc8505, then the following behavior is not possible...or the node won't be able to join the LLN at all...or... IOW, instead of specifying how the unaware node should behave, describe what is expected and the resulting effect if those expectations are not met. Honestly, given some of the specifics in §7.1, for example "MUST...set the "R" and "T" flags in the EARO", I'm not sure it is possible to describe a general RUL without it having to comply with this document...but maybe worth a try. I don't think this specification can support an rfc8504 node trying to join the LLN, right? What about cases where RPL is not used in a 6LoWPAN? [Aside: I ran into the "Advocating a generalisation of RFC8505 to non-6lo LANs" thread [1]. Did anything come out of that? Is there a draft we can Informatively reference?] [1] https://mailarchive.ietf.org/arch/msg/6lo/mKWgLd5013cTBIOlgPg1op614z0/ (2) RUL vs. 6LN: does the RUL act as a 6LN, or does the 6LN act like a RUL? The text talks about a "6LN that is also a RUL", "a RUL acting as 6LN", a "6LN acting as a RUL"...and §10 specifies the behavior of the "6LN/RUL", which seems to imply that they are the same, or at least have the same functionality...or that one is acting as the other... If I understand correctly, the main difference between a RUL and a 6LN (as defined in USEofRPLinfo) is that a 6LN connects to the RPL network through a LoWPAN, but the RUL may not. But, as pointed out above, it seems that this document (§7) expects the RUL to be a 6LN (support rfc6775/rfc8505...). In most cases, the two terms seem to be used interchangeably, but in others, a clear distinction is made -- for example in this text from §7.2.1: To terminate the IP-in-IP tunnel, the 6LN, as an IPv6 Host, must be able to decapsulate the tunneled packet and either drop the inner packet if it is not the final destination, or pass it to the upper layer for further processing. Unless it is aware by other means that the RUL can handle IP-in-IP properly, which is not mandated by [RFC8504], the Root terminates the IP-in-IP tunnel at the parent 6LR. It is thus not necessary for a RUL to support IP-in-IP decapsulation. As part of clarifying the expectations for the RUL (from above), please also clearly distinguish between the definition of RUL and 6LN...or tell the reader how they are (?) considered the same in this document. Consistency and clarity throughout the document is important. (3) Formal Updates Please take a close look at my comments in §4, 5 and 6 about formally Updating other documents. In short, I don't believe that a formal Update is necessary for all the changes mentioned in those sections. Having said that, I did mention a couple of places where I think rfc6775 should (also) be Updated...and others for rfc6550 and rfc8505 that were not listed. I expect the resolution of the major issues before moving the document forward. Thanks! Alvaro. P.S.: I noticed too late the GitHub location...I could have at least included some of the nits as a PR there. Maybe it would be a good idea to indicate in the draft and the datatracker when GitHub is being used. :-) [Line numbers from idnits.] ... 12 Abstract 14 This specification extends RFC6550 and RFC8505 to provide routing 15 services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND 16 but do not participate to RPL. This specification also enables the 17 RPL Root to proxy the 6LoWPAN keep-alive flows in its DODAG. [nit] s/participate to/participate in/g [major] A mention of Updating draft-ietf-roll-efficient-npdao is missing in the Abstract. See also the comments in §5. ... 98 1. Introduction [nit] It would be nice to offer a roadmap ("Section x talks about y, ...") in the Introduction...perhaps at the end of the section. ... 113 To save signaling and routing state in constrained networks, RPL 114 allows a routing stretch (see [RFC6687]), whereby routing is only 115 performed along an acyclic graph optimized to reach a Root node, as 116 opposed to straight along a shortest path between 2 peers, whatever 117 that would mean in a given LLN. This trades the quality of peer-to- 118 peer (P2P) paths for a vastly reduced amount of control traffic and 119 routing state that would be required to operate a any-to-any shortest 120 path protocol. Finally, broken routes may be fixed lazily and on- 121 demand, based on dataplane inconsistency discovery, which avoids 122 wasting energy in the proactive repair of unused paths. [minor] "routing stretch (see [RFC6687])" The term "routing stretch" is not in rfc6687...but there are other terms that might be what you meant. [nit] s/as opposed to straight along a shortest path between 2 peers, whatever that would mean in a given LLN./as opposed to along the shortest path between 2 peers. [nit] s/a any-to-any /an any-to-any [] "lazily" Maybe I'm not getting the proper meaning, but it doesn't sound good... ... 145 RPL can be deployed as an extension to IPv6 Neighbor Discovery (ND) 146 [RFC4861][RFC4862] and 6LoWPAN ND [RFC6775][RFC8505] to maintain 147 reachability within a Non-Broadcast Multi-Access (NBMA) subnet. In 148 that mode, some nodes may act as Routers and participate to the 149 forwarding operations whereas others will only terminate packets, 150 acting as Hosts in the data-plane. In [RFC6550] terms, a Host that 151 is reachable over the RPL network is called a Leaf. [nit] s/][/] [/g [minor] Do we really need rfc4862 as a reference for IPv6 ND? [nit] s/operations whereas/operations, whereas 153 "When to use RFC 6553, 6554 and IPv6-in-IPv6" [USEofRPLinfo] 154 introduces the term RPL-Aware-Leaf (RAL) for a Leaf that injects 155 routes in RPL to manage the reachability of its own IPv6 addresses. 156 In contrast, the term RPL-Unaware Leaf (RUL) designates a Leaf that 157 does not participate to RPL at all. A RUL is an IPv6 Host [RFC8504] 158 that needs a RPL-Aware Router to obtain routing services over the RPL 159 network. [minor] s/"When to use RFC 6553, 6554 and IPv6-in-IPv6" [USEofRPLinfo]/"Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane" [USEofRPLinfo] ...or perhaps simply [USEofRPLinfo], since there will be an RFC number by the time we publish. 161 This specification leverages the Address Registration mechanism 162 defined in 6LoWPAN ND to enable a RUL as a 6LoWPAN Node (6LN) to 163 interface with a RPL-Aware Router as a 6LoWPAN Router (6LR) and 164 request that the 6LR injects a Host route for the Registered Address 165 in the RPL routing on its behalf. A RUL may be unable to participate 166 because it is very energy-constrained, or because it is unsafe to let 167 it inject routes in RPL, in which case using 6LowPAN ND as the 168 interface for the RUL limits the surface of the possible attacks and 169 optionally protects the address ownership. [major] "unsafe to let it inject routes in RPL" This is a good topic to talk about more in the Security Considerations section. [major] Even if 6LoWPAN ND is used, a rogue router can still inject instability, or too much control information in the LLN by adding/removing addresses constantly, for example. Maybe a risk to be flagged in the Security Considerations. ... 186 2.1. BCP 14 [] s/BCP 14/Requirements Language ... 194 2.2. References ... 202 "RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by 203 a RPLInstanceID) are defined in "RPL: IPv6 Routing Protocol for 204 Low-Power and Lossy Networks" [RFC6550]. The RPI is the abstract 205 information that RPL defines to be placed in data packets, e.g., as 206 the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header. By 207 extension the term "RPI" is often used to refer to the RPL Option 208 itself. The DODAG Information solicitation (DIS), Destination 209 Advertisement Object (DAO) and DODAG Information Object (DIO) 210 messages are also specified in [RFC6550]. The Destination Cleanup 211 Object (DCO) message is defined in [EFFICIENT-NPDAO]. [nit] s/By extension/By extension, 213 This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware 214 Leaf (RAL) consistently with [USEofRPLinfo]. The term RPL-Aware Node 215 (RAN) is introduced to refer to a node that is either an RAL or a RPL 216 Router. As opposed to a RUL, a RAN manages the reachability of its 217 addresses and prefixes by injecting them in RPL by itself. [a comment for USEofRPLinfo] "consistently with [USEofRPLinfo]" It would be nice if USEofRPLinfo referenced this document on the definition of a RUL, instead of defining it there too. Yes, that would mean a Normative dependency. ... 231 6LoWPAN ND: Neighbor Discovery Optimization for Low-Power and Lossy 232 Networks [RFC6775], "Registration Extensions for 6LoWPAN Neighbor 233 Discovery" [RFC8505], and "Address Protected Neighbor Discovery 234 for Low-power and Lossy Networks" [AP-ND] . [nit] s/[AP-ND] ./[AP-ND]. ... 337 3.2.1. R Flag ... 347 This document specifies how the "R" flag is used in the context of 348 RPL. A 6LN is a RUL that requires reachability services for an IPv6 349 address if and only if it sets the "R" flag in the NS(EARO) used to 350 register the address to a RPL border router acting as 6LR. Upon 351 receiving the NS(EARO), the RPL router generates a DAO message for 352 the Registered Address if and only if the "R" flag is set. [nit] "This document specifies..." Please add a forward reference to where it is done. 354 3.2.2. TID, I Field and Opaque Fields 356 When the "T" flag is set, the EARO includes a sequence counter called 357 Transaction ID (TID), which maps to the Path Sequence Field found in 358 the RPL Transit Option. This is the reason why the support of 359 [RFC8505] by the RUL as opposed to only [RFC6775] is a prerequisite 360 for this specification (more in Section 7.1). The EARO also 361 transports an Opaque field and an associated "I" field that describes 362 what the Opaque field transports and how to use it. Section 10.2.1 363 specifies the use of the "I" field and of the Opaque field by a RUL. [nit] "This is the reason..." What is the reason? A counter? It may not be clear to other readers what you're referring to. [nit] s/RUL as opposed to only [RFC6775]/RUL, as opposed to only [RFC6775], [nit] s/and of the/and the 365 3.2.3. ROVR ... 380 This specification does not address how the protection by [AP-ND] 381 could be extended to RPL. On the other hand, it adds the ROVR to the 382 DAO to build the proxied EDAR at the Root (see Section 9), which 383 means that nodes that are aware of the Host route to the 6LN are made 384 aware of the associated ROVR as well. [minor] s/extended to RPL/extended (for|to the use of) RPL ? 386 3.3. RFC 8505 Extended DAR/DAC 388 [RFC8505] updates the DAR/DAC messages into the Extended DAR/DAC to 389 carry the ROVR field. The EDAR/EDAC exchange takes place between the 390 6LR and the 6LBR. It is triggered by an NS(EARO) message from a 6LN 391 to create, refresh and delete the corresponding state in the 6LBR. 392 The exchange is protected by the ARQ mechanism specified in 8.2.6 of 393 [RFC6775], though in an LLN, a duration longer than the RETRANS_TIMER 394 [RFC4861] of 1 second may be necessary to cover the Turn Around Trip 395 delay between the 6LR and the 6LBR. [nit] s/refresh and delete/refresh, and delete [minor] Expand ARQ on first use, or add it to the Glossary. ... 411 3.3.1. RFC 7400 Capability Indication Option ... 435 A 6LR that can provide reachability services for a RUL in a RPL 436 network as specified in this document SHOULD include a 6CIO in its RA 437 messages and set the L, P and E flags as prescribed by [RFC8505], see 438 Section 7.1 for the corresponding behavior of the RUL. [major] "SHOULD include a 6CIO" What are the cases where it is ok to not include the 6CIO? IOW, why is this behavior not a requirement? 440 4. Updating RFC 6550 [major] To me, Updating an RFC means that the implementations of that RFC should also implement this one. In this case, there would be an expectation that all RPL nodes would support everything mentioned here. Is that what is intended? Should all the changes in this section be part of the Update? Note that Updating is different than simply expecting the nodes that implement this specification to comply. [Personal opinion: it seems to me that some of the enhancements make sense on some nodes, but it is not necessary for all the nodes to support this specification for it to work. For example, Figure 5 shows the flow with participation from the 6LR, Root, and 6LBR -- the other nodes in the LLN don't need to be aware of the changes.] 442 This document specifies a new behavior whereby a 6LR injects DAO 443 messages for unicast addresses (see Section 10) and multicast 444 addresses (see Section 11) on behalf of leaves that are not aware of 445 RPL. The RUL addresses are exposed as external targets [RFC6550]. 446 Conforming [USEofRPLinfo], an IP-in-IP encapsulation between the 6LR 447 and the RPL Root is used to carry the RPL artifacts and remove them 448 when forwarding outside the RPL domain, e.g., to a RUL. [minor] s/Conforming [USEofRPLinfo]/Conforming to [USEofRPLinfo] [] Is there anything in rfc6550 that limits the source of the routing information in the DAOs? It seems to me that rfc6550 already allows external information to be injected in the network...so getting it from a RUL doesn't sound like an Update to me. 450 This document also synchronizes the liveness monitoring at the Root 451 and the 6LBR. The same value of lifetime is used for both, and a 452 single keep-alive message, the RPL DAO, traverses the RPL network. A 453 new behavior is introduced whereby the RPL Root proxies the EDAR 454 message to the 6LBR on behalf of the 6LR (more in Section 6), for any 455 6LN, RUL or RAN. [] Yes, there's a proxy behavior...but I would see that more as a change to ND than an Update to rfc6550. 457 Section 6.7.7 of [RFC6550] introduces RPL Target Option, which can be 458 used in RPL Control messages such as the DAO message to signal a 459 destination prefix. Section 9 adds the capabilities to transport the 460 ROVR field (see Section 3.2.3) and the IPv6 Address of the prefix 461 advertiser when the Target is a shorter prefix, signaled by a new "F" 462 flag. The position of the "F" flag is indicated in Section 15. [] §9 says that this change is backward compatible; do we need all RPL nodes to support it? See my comment there about requiring (vs recommending) the use...and about the potential forward compatibility need to Update... [] I put a note in §15 about Updading rfc6550 because of the changes in the registry (which is different than the functionality described here)...take a look. [nit] s/introduces RPL Target Option/introduces the RPL Target Option [minor] "the IPv6 Address of the prefix advertiser when the Target is a shorter prefix" I'm confused about this because then the F flag is set the Target is a full 128 bit address, not a shorter one. What did I miss? 464 Section 6.7.6 of [RFC6550] defines the DODAG Configuration option 465 with reserved flags. This specification defines the new "Root 466 Proxies EDAR/EDAC" (P) flag and encodes it in one of these reserved 467 flags. The "P" flag is set to indicate that the Root performs the 468 proxy operation, which implies that it supports the Updated RPL 469 Target Option (see Section 9). The position of the "P" flag is 470 indicated in Section 14. [major] The P flag is not defined in §9...or anywhere else. [] Hard to say if this change is an Update without a specification of the P flag. 472 Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in 473 the DIO Base Object. The new "P" flag is defined only for MOP value 474 between 0 to 6. For a MOP value of 7 or above, the flag MAY be 475 redefined and MUST NOT be interpreted as "Root Proxies EDAR/EDAC" 476 unless the specification of the MOP indicates to do so. [] We have an ongoing discussion about MOPs elsewhere. For now, I think that the Update should happen elsewhere. ...but here's a suggestion anyway... [] NEW> Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base Object. This specification of the new "P" flag applies to MOP values 0 to 6. 478 The RPL Status defined in section 6.5.1 of [RFC6550] for use in the 479 DAO-ACK message is extended to be placed in DCO messages 480 [EFFICIENT-NPDAO] as well. Furthermore, this specification enables 481 to carry the EARO Status defined for 6LoWPAN ND in RPL DAO and DCO 482 messages, embedded in a RPL Status, more in Section 8. [major] Besides enabling the EARO status to be carried, §8 also reduces the size of the status from 8 to 6 bits, with the new encoding... This *is* a necessary Update to rfc6550. [] Note that even though the same RPL Status is used in the DCO message, a formal Update is not required for EFFICIENT-NPDAO for the reduction of the size since that document is already inheriting the Update from rfc6500: "RPL Status: As defined in [RFC6550] and updated in [I-D.ietf-roll-unaware-leaves]." 484 5. Updating draft-ietf-roll-efficient-npdao [major] To me, Updating an RFC means that the implementations of that RFC should also implement this one. In this case, there would be an expectation that all nodes that support the DCO would support the Non-Storing MOP as well. Is that what is intended? Note that Updating is different than simply expecting the nodes that implement this specification to comply. [Personal opinion: I don't think a formal Update of draft-ietf-roll-efficient-npdao is needed. As mentioned below, this document "extends"...] 486 [EFFICIENT-NPDAO] defines the DCO for RPL Storing Mode only, with a 487 link-local scope. This specification extends its use to the Non- 488 Storing MOP, whereby the DCO is sent unicast by the Root directly to 489 the RAN that injected the DAO message for the considered target. 491 This specification leverages the DCO between the Root and the 6LR 492 that serves as attachment router for a RUL. [] Just another piece of information: draft-ietf-roll-efficient-npdao already "assumes that all the 6LRs in the network support this specification". draft-ietf-roll-efficient-npdao did not Update rfc6550, so it is not expected that "basic" RPL nodes would know what the DCO is... [major] Regardless of whether this document Updates NPDAO or not, some text should be added related to the possibility that not all nodes may know what the DCO is. See §10.2.3. 494 6. Updating RFC 8505 [major] To me, Updating an RFC means that the implementations of that RFC should also implement this one. In this case, there would be an expectation that all 6LRs would support the change. Is that what is intended? Note that Updating is different than simply expecting the nodes that implement this specification to comply...in this case, *if* "the RPL Root advertise[s] the capability...". [Personal opinion: rfc8505 applies to 6LRs in general, not just RPL routers in particular...so I think that Updating it is not the right choice.] 496 This document updates [RFC8505] to change the behavior of a RPL 497 Router acting as 6LR in the 6LoWPAN ND Address Registration of a RUL 498 acting as 6LN. If the RPL Root advertise the capability to proxy the 499 EDAR/EDAC exchange to the 6LBR, the 6LR refrains from sending the 500 keep-alive EDAR message. Instead, if it is separated from the 6LBR, 501 the Root regenerates the EDAR message to the 6LBR periodically, upon 502 a DAO message that signals the liveliness of the Address. [nit] s/Root advertise/Root advertises [] See the comment in §8 about a separate reason to Update rfc8505 and rfc6775. ... 510 7.1. Support of 6LoWPAN ND 512 In order to obtain routing services from a 6LR, a RUL MUST implement 513 [RFC8505] and set the "R" and "T" flags in the EARO. The RUL SHOULD 514 support [AP-ND] to protect the ownership of its addresses. The RUL 515 MUST NOT request routing services from a 6LR that does not originate 516 RA messages with a CIO that has the L, P, and E flags all set as 517 discussed in Section 3.3.1, unless configured to do so. [major] I may be lost already... A RUL is by definition RPL-unaware. It then follows that a RUL can't be assumed to be aware of this specification, right? If so, then all the Normative language used in this section can't be used because we can't specify the behavior of a node that (by definition) is not aware of this document. [See more related comments below.] Note that §1 defines a RUL this way: "A RUL is an IPv6 Host [RFC8504] that needs a RPL-Aware Router to obtain routing services over the RPL network." [major] "The RUL SHOULD support [AP-ND] to protect the ownership of its addresses." When it is ok for the RUL not to support AP-ND? IOW, why is the support only recommended and not required? ... 523 Parallel Address Registrations to several 6LRs SHOULD be performed in 524 an rapid sequence, using the exact same EARO for the same Address. 525 Gaps between the Address Registrations will invalidate some of the 526 routes till the Address Registration finally shows on those routes. [nit] s/an rapid sequence/rapid sequence [nit] s/the exact same EARO/the same EARO [major] How fast is in "rapid sequence"...how big can "gaps" be? If using Normative language, then the text needs to be specific. 528 [RFC8505] introduces error Status values in the NA(EARO) which can be 529 received synchronously upon an NS(EARO) or asynchronously. The RUL 530 MUST support both cases and MUST refrain from using the address when 531 the Status Value indicates a rejection. [major] "MUST support both cases and MUST refrain" Isn't this behavior already specified in rfc8505? We shouldn't use normative language in that case (unless you are quoting directly). [major] I didn't find a "rejection" Status Value. I'm assuming you're referring to a group of values: Duplicate Address, Moved, etc.. Please be explicit. 533 7.2. External Routes and RPL Artifacts 535 Section 4.1 of [USEofRPLinfo] provides a set of rules detailed below 536 that MUST be followed for routing packets from and to a RUL. [major] Because the specification is in USEofRPLinfo already, then there's no need to normatively require it here as well. Also, not all the actions in §4.1/USEofRPLinfo are required, some are just recommended, so there would be a Normative conflict. s/MUST/must ... 554 The RPL data packets always carry a Hop-by-Hop Header to transport a 555 RPL Packet Information (RPI) [RFC6550]. So unless the RUL originates 556 its packets with an RPI, the 6LR needs to tunnel them to the Root to 557 add the RPI. As a rule of a thumb and except for the very special 558 case above, the packets from and to a RUL are always encapsulated 559 using an IP-in-IP tunnel between the Root and the 6LR that serves the 560 RUL (see sections 7.1.4, 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4, 561 8.2.3, 8.2.4, 8.3.3 and 8.3.4 of [USEofRPLinfo] for details). [minor] Listing all these sections may be prone to errors or inconsistency. What about §7.1.3/§8.3.2? Maybe simply "see [USEofRPLinfo] for details" is better. 563 In Non-Storing Mode, packets going down carry a Source Routing Header 564 (SRH). The IP-in-IP encapsulation, the RPI and the SRH are 565 collectively called the "RPL artifacts" and can be compressed using 566 [RFC8138]. Figure 10 presents an example compressed format for a 567 packet forwarded by the Root to a RUL in a Storing Mode DODAG. [minor] s/Figure 10/Appendix A ... 576 A RUL is not expected to support the compression method defined in 577 [RFC8138]. Unless configured otherwise, the border router MUST 578 restore the outgoing packet before forwarding over an external route, 579 even if it is not the destination of the incoming packet, and even 580 when delivering to a RUL. [minor] s/restore/uncompress [major] "the border router MUST restore the outgoing packet before forwarding over an external route, even if it is not the destination of the incoming packet" USEofRPLinfo already specifies this behavior, so please don't specify it again. Also, the language of "even if it is not the destination" made me think twice about complying with rfc8200. Maybe better to describe the behavior in the same way that USEofRPLinfo does. Suggestion> A RUL is not expected to support the compression method defined in [RFC8138]. The border router uncompresses the packet before forwarding over an external route to a RUL [USEofRPLinfo]. ... 608 8. Updated RPL Status ... 623 Table 1: RPL Status per RFC 6550 [minor] Please add a table (later in this section) showing the updated RPL Status...along with a forward reference to the IANA Considerations sub-section where the new registry is created. [] BTW, this change should formally Update rfc6500. 625 The 6LoWPAN ND Status was defined for use in the EARO and the 626 currently defined values are listed in table 1 of [RFC8505]. This 627 specification enables to carry the 6LoWPAN ND Status values in RPL 628 DAO and DCO messages, embedded in the RPL Status field. [minor] "the currently defined values are listed in table 1 of [RFC8505]" Given that the registry is being modified, and that other values may be added...it doesn't seem like a good idea to point at "currently defined values". Please take out that part of the sentence. 630 To achieve this, Section 13.2 reduces the range of the EARO Status 631 values to 0-63 to ensure that they fit within a RPL Status as shown 632 in Figure 3. [major] "Section 13.2 reduces the range" §13.2 is part of the IANA Considerations, which reflects what is specified elsewhere. IOW, specify the reduced range elsewhere (here?). Suggestion> To achieve this, the range of the EARO Status values is reduced to 0-63. This reduction ensures that the values fit within a RPL Status as shown in Figure 3. [major] What about the ARO? The Status values are shared between the EARO and the ARO. [major] Changing the range of values is not as easy as updating the registry...the behavior of the EARO and ARO have to be updated. This means that this document should Update both rfc6775 and rfc8505 where it relates to the redefined Status field. The E/A flags (below) don't seem to apply to the ARO/EARO, so a specification of the behavior is needed; something like "ignore the first two bits". 634 0 1 2 3 4 5 6 7 635 +-+-+-+-+-+-+-+-+ 636 |E|A| Value | 637 +-+-+-+-+-+-+-+-+ ... 643 E: 1-bit flag. Set to indicate a rejection. When not set, a value 644 of 0 indicates Success/Unqualified acceptance and other values 645 indicate "not an outright rejection" as per RFC 6550. [minor] "When not set, a value of 0...and other values..." This is just one bit, so there are only two values, not "other values". ;-) You obviously mean "a value of 0...and other values of the RPL Status". s/a value of 0/an RPL Status value of 0 [major] ""not an outright rejection" as per RFC 6550" rfc6550 differentiated between a "rejection" and "not an outright rejection". Is the intent for the rejection codes to reflect that difference (at some point), or is the ability to signal the difference lost? ... 649 Status Value: 6-bit unsigned integer. If the 'A' flag is set this 650 field transports a Status Value defined for IPv6 ND EARO. When 651 the 'A' flag is not set, the Status Value is defined for RPL. [major] This change in the RPL Status format should be a formal Update of rfc6550. 653 When building a DCO or a DAO-ACK message upon an IPv6 ND NA or a EDAC 654 message, the RPL Root MUST copy the 6LoWPAN ND Status unchanged in 655 the RPL Status and set the 'A' bit. The RPL Root MUST set the 'E' 656 flag for Values in range 1-10 which are all considered rejections. [nit] s/'A' bit/'A' flag [major] What should the receiver do if the corresponding 6LoWPAN ND Status is unknown? Or does it matter? I'm wondering if "MUST" is the right requirement, or if should be "SHOULD"... [major] What should a receiver do if the E flag is not set for "Values in range 1-10"? [major] For future rejection-related values, the E flag has to also be set, right? How can we word the specification so that we don't depend on future specification saying that the E flag has to be set? I worry that not all the status codes use the work "rejection", even if their description (rfc8505) can be interpreted as such. Maybe something like this: The RPL Root MUST set the 'E' flag for all rejection Values. The Status Codes in range 1-10 [rfc8505] are all considered rejections. 658 Reciprocally, upon a DCO or a DAO-ACK message from the RPL Root with 659 a RPL Status that has the 'A' bit set, the 6LR MUST copy the RPL 660 Status Value unchanged in the Status field of the EARO when 661 generating an NA to the RUL. [major] "MUST copy the RPL Status Value unchanged" Even if the value is unknown? 663 9. Updated RPL Target Option ... 679 With this specification the ROVR is the remainder of the RPL Target 680 Option. The size of the ROVR is indicated in a new ROVR Size field 681 that is encoded to map one-to-one with the Code Suffix in the EDAR 682 message (see table 4 of [RFC8505]). [nit] "ROVR Size field" The field is called ROVRsz. To be consistent, perhaps describe the field (below) as "ROVRsz (ROVR Size):" [?] Why is the size of the ROVR needed? It can be figured out from the setting of the F flag and the Option and Prefix Lengths. Just curious. 684 The modified format is illustrated in Figure 4. It is backward 685 compatible with the Target Option in [RFC6550] and SHOULD be used as 686 a replacement in new implementations even for Storing Mode operations 687 in preparation for upcoming security mechanisms based in the ROVR. [nit] s/modified format/updated format [nit] s/based in/based on [major] "It is backward compatible..." True, but what about "forward" compatible? If the F flag is not set, how does a receiver know that this is the updated Option? Is there a chance of spurious information (in either the flag or the ROVRsz) to be present and cause the receiver to misinterpret the information? I know that rfc6550 specifies that the "field MUST be initialized to zero by the sender and MUST be ignored by the receiver"...but I just want to test the edges. This forward compatibility may be a reason to formally Update rfc6550. [major] "SHOULD be used as a replacement in new implementations" Referring to §4 (Updating RFC 6550) and my comments there about Updating... If this change is an Update -- meaning that all RPL nodes must support it --, when would it be ok to not use it? IOW, why is it a recommendation and not a requirement. OTOH, the modification is backwards compatible...so only the nodes that need to understand the change need to implement it. [major] "...in preparation for upcoming security mechanisms" What it that? If support is required for a different specification, what is it? It seems to me that recommending the use in preparation for something in the future is not appropriate in a specification without an explicit reference. 689 0 1 2 3 690 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Type = 0x05 | Option Length |ROVRsz |F|Flags| Prefix Length | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | | 695 | Target Prefix (Variable Length) | 696 . . 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | | 699 ... Registration Ownership Verifier (ROVR) ... 700 | | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 Figure 4: Updated Target Option [nit] Align the bit numbers: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 New fields: 707 ROVRsz: Indicates the Size of the ROVR. It MAY be 1, 2, 3, or 4, 708 denoting a ROVR size of 64, 128, 192, or 256 bits, respectively. [major] s/MAY be 1, 2, 3, or 4/MUST be 1, 2, 3, or 4 It is not optional to use those values, they are the only ones. [?] Why are 4 bits needed if there are only 4 values? Why not just use 3? [major] What should the receiver do if a different value is used? 710 F: 1-bit flag. Set to indicate that Target Prefix field contains an 711 Address of prefix advertiser in full. [minor] To be in sync with the Registry in §15: s/F:/F (Advertiser Address in Full): ... 716 10. Protocol Operations for Unicast Addresses 718 The description below assumes that the Root sets the "P" flag in the 719 DODAG Configuration Option and performs the EDAR proxy operation. [major] Where is the "P" flag defined? I didn't find it in this draft. ... 726 10.1. General Flow [minor] It would be very nice if at the start of this sub-section a note mentioned the fact that §10.2 contains the detailed operation. That would help the linear reader (like me!) time in trying to figure out the details. ;-) [minor] Also, it would be great if this overview had forward references to where the detail is provided. ... 775 On the first Address Registration, illustrated in Figure 5 for RPL 776 Non-Storing Mode, the Extended Duplicate Address exchange takes place 777 as prescribed by [RFC8505]. If the exchange fails, the 6LR returns 778 an NA message with a negative status to the 6LN, the NCE is not 779 created and the address is not injected in RPL. If it is successful, 780 the 6LR creates an NCE and injects the Registered Address in the RPL 781 routing using a DAO/DAO-ACK exchange with the RPL DODAG Root. [major] "the Extended Duplicate Address exchange takes place as prescribed by [RFC8505]" Yes, except that NA is delayed until after the RPL registration is completed. (See related comments in §10.2.2 below.) [nit] s/created and/created, and 783 An issue may be detected later, e.g., the address moves within the 784 LLN or to a different Root on a backbone [6BBR]. In that case the 785 value of the status that indicates the issue can be passed from 786 6LoWPAN ND to RPL and back as illustrated in Figure 6. [minor] "backbone router" is not used anywhere else. Do we need to introduce this term and reference here? It seems like an unnecessary reference to me. [nit] s/In that case/In that case, [nit] s/back as/back, as ... 800 An Address re-Registration is performed by the 6LN to maintain the 801 NCE in the 6LR alive before lifetime expires. Upon the refresh of an 802 Address re-Registration, as illustrated in Figure 7, the 6LR injects 803 the Registered Address in RPL. [nit] s/before lifetime/before the lifetime [major] Under what circumstances does the process in Figure 7 apply? I'm assuming that only if the registration hasn't expired, is that true? If the registration already expired, should the whole process (Figure 5) be repeated? I see mention of (re)registration in §10.2.1, but none in §10.2.2. 805 6LN/RUL 6LR Root 6LBR 806 | | | | 807 | NS(EARO) | | | 808 |--------------->| | 809 | | DAO | | 810 | |------------->| | 811 | | | EDAR | 812 | | |------------------>| 813 | | | EDAC | 814 | | |<------------------| 815 | | DAO-ACK | | 816 | |<-------------| | 817 | NA(EARO) | | | 818 |<---------------| | | [nit] A "|" is missing under the Root. ... 828 The 6LR may receive a requested DAO-ACK after it received an 829 asynchronous DCO, but the negative Status in the DCO supersedes a 830 positive Status in the DAO-ACK regardless of the order in which they 831 are received. Upon the DAO-ACK - or the DCO if one arrives first - 832 the 6LR responds to the RUL with an NA(EARO). [major] "the negative Status in the DCO supersedes a positive Status in the DAO-ACK regardless of the order in which they are received" I don't remember anything like this in draft-ietf-roll-efficient-npdao. Should something be mentioned? The ability of a parent to send an unsolicited DCO seems to fall in the same category: the DAO-ACK doesn't matter if the DCO was received first... I'm assuming the DCO negative status in this case has some type of expiration time, right? I'm thinking of the case where a problem did occur, but on a retry there is success...?? This property of the DCO allows a rogue node to invalidate a registration. Something similar to this text from draft-ietf-roll-efficient-npdao should be included in the Security Considerations section: This document introduces the ability for a common ancestor node to invalidate a route on behalf of the target node. The common ancestor node could be directed to do so by the target node using the 'I' flag in DCO's Transit Information Option. However, the common ancestor node is in a position to unilaterally initiate the route invalidation since it possesses all the required state information, namely, the Target address and the corresponding Path Sequence. Thus a rogue common ancestor node could initiate such an invalidation and impact the traffic to the target node. 834 The RUL MAY terminate the registration at any time by using a 835 Registration Lifetime of 0. This specification requires that the RPL 836 Target Option transports the ROVR. This way, the same flow as the 837 heartbeat flow is sufficient to inform the 6LBR using the Root as 838 proxy as illustrated in Figure 7. [major] s/MAY/may In this case, the sentence is just pointing at a fact, not making a normative statement. [nit] s/proxy as/proxy, as 840 Any combination of the logical functions of 6LR, Root and 6LBR might 841 be collapsed in a single node. [nit] s/Root and/Root, and 843 10.2. Detailed Operation 845 10.2.1. Perspective of the RUL Acting as 6LN 847 This specification does not alter the operation of a 6LoWPAN ND- 848 compliant 6LN, and a RUL is expected to operate as follows: [minor] s/6LN, and a RUL /6LN/RUL, which 850 1. The 6LN obtains an IPv6 global address, either using Stateless 851 Address Autoconfiguration (SLAAC) [RFC4862] based on a Prefix 852 Information Option (PIO) [RFC4861] found in an RA message, or 853 some other means such as DHCPv6 [RFC3315]. [nit] s/means such/means, such [major] s/RFC3315/RFC8415 855 2. Once it has formed an address, the 6LN (re)registers its address 856 periodically, within the Lifetime of the previous Address 857 Registration, as prescribed by [RFC6775], to refresh the NCE 858 before the lifetime indicated in the EARO expires. It MUST set 859 the "T" flag and the TID is incremented each time and wraps in a 860 lollipop fashion (see section 5.2.1 of [RFC8505] which is fully 861 compatible with section 7.2 of [RFC6550]). [minor] s/It MUST set the "T" flag and the TID is incremented/It MUST set the "T" flag. The TID is incremented [nit] s/[RFC8505] which/[RFC8505], which 863 3. As stated in section 5.2 of [RFC8505], the 6LN can register to 864 more than one 6LR at the same time. In that case, it uses the 865 same EARO for all of the parallel Address Registrations. The 6LN 866 SHOULD send the registration(s) that have a non-zero Registration 867 Lifetime and ensure that one succeeds before it terminates other 868 registrations, to maintain the state in the network and at the 869 6LBR and minimize the churn. [major] "The 6LN SHOULD send the registration(s) that have a non-zero Registration Lifetime..." It sounds as if you're trying to specify what the value of the Registration Lifetime should be. If so: s/that have a non-zero/with a non-zero What are the cases when it is ok to not use a non-zero value? IOW, why is it recommended and not required? rfc8505 talks about setting the Registration Lifetime to 0, which brings me to: it seems to me that the Normative language may be out of place since the specification is already made in rfc8505. ?? 871 4. Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets 872 the "R" flag in the EARO of at least one registration, whereas 873 acting as a RAN it never does. If the "R" flag is not echoed in 874 the NA, the RUL SHOULD attempt to use another 6LR. The RUL 875 SHOULD send the registration(s) with the "R" flag set and ensure 876 that one succeeds before it sends the registrations with the flag 877 reset. In case of a conflict with the preceeding rule on 878 lifetime, the rule on lifetime has precedence. [nit] "6LN acting as a RUL" The title of this section is "Perspective of the RUL Acting as 6LN", which one is it? ;-) [minor] "whereas acting as a RAN it never does" rfc8505 says this: "A 6LR that manages its reachability SHOULD NOT set the R flag". "SHOULD NOT" doesn't imply never. [minor] "If the "R" flag is not echoed in the NA..." I didn't find in rfc8505 where echoing the R flag is discussed. But §10.2.2 requires the R flag set...is that where the specification is? [major] "SHOULD send the registration(s) with the "R" flag set and ensure that one succeeds before it sends the registrations with the flag reset." This text is in conflict with §5.1/rfc8505: "MUST set the R flag to indicate that it is not a router and that it will not handle its own reachability". There isn't a provision for a RUL to not set the R flag. [nit] s/preceeding/preceding 880 5. The 6LN may use any of the 6LRs to which it registered as default 881 gateway. Using a 6LR to which the 6LN is not registered may 882 result in packets dropped at the 6LR by a Source Address 883 Validation function (SAVI) so it is NOT RECOMMENDED. [nit] s/as default/as the default [minor] Please add an Informative reference to SAVI. [major] s/NOT RECOMMENDED/not recommended This text is not specifying normative behavior related to interoperability. 885 Even without support for RPL, a RUL may be aware of opaque values to 886 be provided to the routing protocol. If the RUL has a knowledge of 887 the RPL Instance the packet should be injected into, then it SHOULD 888 set the Opaque field in the EARO to the RPLInstanceID, else it MUST 889 leave the Opaque field to zero. [nit] s/has a knowledge/has knowledge [major] If a RUL is *unaware* by definition, I don't see how this paragraph can fit in this specification...especially because it seems to be speculating about potential knowledge ("may be aware of opaque values")... What do we call a RUL that has partial knowledge? 891 Regardless of the setting of the Opaque field, the 6LN MUST set the 892 "I" field to zero to signal "topological information to be passed to 893 a routing process" as specified in section 5.1 of [RFC8505]. [nit] s/process" as/process", as 895 A RUL is not expected to produce RPL artifacts in the data packets, 896 but it MAY do so. For instance, if the RUL has a minimal awareness 897 of the RPL Instance then it can build an RPI. A RUL that places an 898 RPI in a data packet MUST indicate the RPLInstanceID of the RPL 899 Instance where the packet should be forwarded. All the flags and the 900 Rank field are set to zero as specified by section 11.2 of [RFC6550]. [major] s/MAY/may In this case, the text is just expressing a fact, not a Normative action. [nit] s/has a minimal/has minimal [major] The Normative text in this paragraph is equivalent to the one above (two paragraphs up)...please avoid duplication/redundancy. [major] "A RUL that places an RPI in a data packet MUST indicate the RPLInstanceID of the RPL Instance where the packet should be forwarded." So...even if we leave the *unaware* nature of a RUL out...this text means that any leaf can inject traffic onto an RPL Instance, just by knowing the ID (or even guessing it). Please add some text in the Security Considerations about how the rfc6553 considerations apply here too. 902 10.2.2. Perspective of the Border Router Acting as 6LR [nit] How else would a Border Router act as? [] This terminology of "acting as" is confusing... <sigh> 904 Also as prescribed by [RFC8505], the 6LR generates an EDAR message 905 upon reception of a valid NS(EARO) message for the registration of a 906 new IPv6 Address by a 6LN. If the initial EDAR/EDAC exchange 907 succeeds, then the 6LR installs an NCE for the Registration Lifetime. 908 For the registration refreshes, if the RPL Root has indicated that it 909 proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see 910 Section 4), the 6LR MUST refrain from sending the keep-alive EDAR. [nit] s/Also as prescribed/As prescribed 912 If the "R" flag is set in the NS(EARO), the 6LR MUST inject the Host 913 route in RPL, unless this is barred for other reasons, such as the 914 saturation of the RPL parents. The 6LR MUST use a RPL Non-Storing 915 Mode signaling and the updated Target Option (see Section 9). The 916 6LR MUST request a DAO-ACK by setting the 'K' flag in the DAO 917 message. Success injecting the route to the RUL is indicated by the 918 'E' flag set to 0 in the RPL status of the DAO-ACK message. [major] What is "the Host route"? I guess you mean a "host route to the Registered Address contained in the EDAC". Or, as you mention later, "router to the RUL". [major] "MUST...unless" The use of MUST implies no exceptions. s/MUST/SHOULD 920 The Opaque field in the EARO hints the 6LR on the RPL Instance that 921 SHOULD be used for the DAO advertisements, and for the forwarding of 922 packets sourced at the registered address when there is no RPI in the 923 packet, in which case the 6LR MUST encapsulate the packet to the Root 924 adding an RPI in the outer header. If the Opaque field is zero, the 925 6LR is free to use the default RPL Instance (zero) for the registered 926 address or to select an Instance of its choice. [major] "hints" It is really a hint, or the RPL Instance? If only a hint, where would the Instance that "SHOULD be used" come from? The text in §10.2.1 implies that the 6LN knows what the Instance is. [major] "the RPL Instance that SHOULD be used for the DAO advertisements" When would the 6LR not use the Instance signaled by the 6LN? IOW, why is this a recommendation and not a requirement? [nit] s/and for the/and the [major] "SHOULD be used for...forwarding...in which case the 6LR MUST encapsulate the packet to the Root adding an RPI in the outer header" There's a Normative conflict between recommending the use of the RPLInstanceID and requiring the use of the RPI (which contains the RPLInstanceID). [minor] How is the 6LR to "select an Instance of its choice"? §11.2/rfc6550 talks specifically about the need for guidance for external packets: The definition and provisioning of RPL Instances are out of scope for this specification. Guidelines may be application and implementation specific, and they are expected to be elaborated in future companion specifications. Those operations are expected to be such that data packets coming from the outside of the RPL network can unambiguously be associated to at least one RPL Instance and be safely routed over any instance that would match the packet. 928 If the "I" field is not zero, then the 6LR MUST consider that the 929 Opaque field is zero. If the Opaque field is not zero, then it is 930 expected to carry a RPLInstanceID for the RPL Instance suggested by 931 the 6LN. If the 6LR does not participate to the associated Instance, 932 then the 6LR MUST consider that the Opaque field is zero; else, that 933 is if the 6LR participates to the suggested RPL Instance, then the 934 6LR SHOULD use that Instance for the Registered Address. [nit] There is some redundancy/repetition between this paragraph and the last one. [major] "If the "I" field is not zero, then the 6LR MUST consider that the Opaque field is zero." rfc8505 already specifies pretty much the same thing. OLD> If the "I" field is not zero, then the 6LR MUST consider that the Opaque field is zero. If the Opaque field is not zero, then it is expected to carry a RPLInstanceID for the RPL Instance suggested by the 6LN. NEW> As described in rfc8505, if the "I" field is zero, then the Opaque field is expected to carry the RPLInstanceID suggested by the 6LN. Otherwise, the Opaque field is ignored. [nit] s/participate to the/participate in the ... 939 1. The Registered Address is signaled as Target Prefix in the 940 updated Target Option in the DAO message; the Prefix Length is 941 set to 128. The ROVR field is copied unchanged from the EARO 942 (see Section 9). [nit] s/as Target Prefix/as the Target Prefix [minor] "Prefix Length is set to 128" ...and the F flag is set. ... 948 3. The 6LR sets the External 'E' flag in the TIO to indicate that it 949 redistributes an external target into the RPL network [nit] s/it redistributes/it is redistributing 951 4. the Path Lifetime in the TIO is computed from the Lifetime in the 952 EARO Option. This adapts it to the Lifetime Units used in the 953 RPL operation; note that if the lifetime is 0, then the DAO 954 message is a No-Path DAO that cleans up the the routes down to 955 the RUL; this also causes the Root as a proxy to send an EDAR 956 message to the 6LBR with a Lifetime of 0. [minor] s/Lifetime/Registration Lifetime [minor] "Path Lifetime in the TIO is computed" How? Given that the Registration Lifetime is in seconds, but the Lifetime Unit can be in days, there may be cases where the result is close to 0. Would that result in an NPDAO? [nit] s/the the/the ... 961 Upon receiving the DAO-ACK or an asynchronous DCO message, the 6LR 962 MUST send the NA(EARO) to the RUL. [major] "Upon receiving the DAO-ACK ...the 6LR MUST send the NA(EARO)". My interpretation is that the 6LR will wait for the DAO-ACK before sending the NA(EARO), is that correct? §9.3/rfc6550: 4. A node receiving a unicast DAO message with the 'K' flag set SHOULD respond with a DAO-ACK. A node receiving a DAO message without the 'K' flag set MAY respond with a DAO-ACK, especially to report an error condition. 5. A node that sets the 'K' flag in a unicast DAO message but does not receive a DAO-ACK in response MAY reschedule the DAO message transmission for another attempt, up until an implementation- specific number of retries. This text says that the 6LR may never receive a DAO-ACK. If that happens (even after trying again), what should the 6LR do? During this time the RUL is waiting for the NS(EARO)... 964 The 6LR MUST set "R" flag in the NA(EARO) back if and only if the 'E' 965 flag is reset, indicating that the 6LR injected the Registered 966 Address in the RPL routing successfully and that the EDAR proxy 967 operation succeeded. [nit] s/set "R"/set the "R" 969 If the 'A' flag in the RPL Status is set, the embedded Status Value 970 is passed back to the RUL in the EARO Status. If the 'E' flags is 971 also set, the registration failed for 6LoWPAN ND related reasons, and 972 the NCE is removed. [nit] s/'E' flags/'E' flag 974 If the 'A' flag is not set in the RPL Status of the DAO-ACK, then the 975 6LoWPAN ND operation succeeded and an EARO Status of 0 (Success) MUST 976 be returned to the RUL, even if the 'E' flag is set in the RPL 977 Status. The EARO Status of 0 MUST also be used if the 6LR could not 978 even try to inject the route. [major] "If the 'A' flag is not set in the RPL Status of the DAO-ACK, then the 6LoWPAN ND operation succeeded..." §8 says this: "the RPL Root MUST copy the 6LoWPAN ND Status unchanged in the RPL Status and set the 'A' bit" This means that if the A flag is not set then the Root didn't comply with the MUST in §8...or that it did not copy result from the EDAC...which then means that the DAO-ACK is not valid. What am I missing? [nit] s/succeeded and/succeeded, and [major] "even if the 'E' flag is set" Sorry, what? The E flag indicates a rejection... I thought I understood the logic (in §8) of setting the A/E flags...but it seems that I didn't. It would be ideal to then be explicit about the different combinations and how we can get to them. 980 This means that, in case of an error injecting the route that is not 981 related to ND, the registration succeeds but the RPL route is not 982 installed, which is signaled by the "R" flag reset. It is up to the 983 6LN to keep the binding with the 6LR or destroy it. [nit] s/succeeds but/succeeds, but [major] Figure 5 seems to indicate that the DAO-ACK is generated when the EDAC is received, which is inline with the specification in §8 ("the RPL Root MUST copy the 6LoWPAN ND Status unchanged in the RPL Status and set the 'A' bit")...but from the last few paragraphs it seems that there are other reasons for generating the DAO-ACK. While not clear from the Figure, §10.2.3 does hint by saying "if a DAO is pending"... Again, I think that this part of the operation has to be much more explicit. rfc6550 has no information about "pending" DAOs, or how fast the DAO-ACK is to be sent. In fact, there is no firm requirement for the DAO-ACK to exist, just hope that it does: - §6.4/rfc6550: "The DAO message may optionally, upon explicit request or error, be acknowledged by its destination with a Destination Advertisement Acknowledgement (DAO-ACK) message back to the sender of the DAO." This sentence suggests that the DAO-ACK is optional, even if requested, and §9.3/rfc6550 supports that: " 3. A node MAY set the 'K' flag in a unicast DAO message to solicit a unicast DAO-ACK in response in order to confirm the attempt. 4. A node receiving a unicast DAO message with the 'K' flag set SHOULD respond with a DAO-ACK. A node receiving a DAO message without the 'K' flag set MAY respond with a DAO-ACK, especially to report an error condition. " Note that "SHOULD respond with a DAO-ACK" leaves the door open to not doing it. Unfortunately rfc6550 didn't explicitly mention what may be the reasons to not send a DAO-ACK (or not using MUST instead). In summary, there doesn't seem to be a guarantee that a DAO-ACK will be received...which means that the 6LN may be left waiting for a response to the registration (the same issues appears to be present for a re-registration). 985 In a network where Address Protected Neighbor Discovery (AP-ND) is 986 enabled, in case of a DAO-ACK or a DCO indicating transporting an 987 EARO Status Value of 5 (Validation Requested), the 6LR MUST challenge 988 the 6LN for ownership of the address, as described in section 6.1 of 989 [AP-ND], before the Registration is complete. This ensures that the 990 address is validated before it is injected in the RPL routing. [major maybe] "network where...(AP-ND) is enabled" Just to make sure I'm understanding: the network itself is not enabled for AP-ND, but the important nodes (6LN, 6LR, Root and 6LBR) are. IOW, RPL only carries the EARO status values that result from the AP-ND operation. If this true? Also, the only reason the EARO Status Value would be 5 is if the 6LN already supports AP-ND, right? I'm asking this because of the "MUST challenge" above, and §7.1 saying that the "RUL SHOULD support [AP-ND]" (recommended, not required). If my understanding is correct, then the text as is looks fine. :-) 992 If the challenge succeeds then the operations continue as normal. In 993 particular a DAO message is generated upon the NS(EARO) that proves 994 the ownership of the address. If the challenge failed, the 6LR 995 rejects the registration as prescribed by AP-ND and may take actions 996 to protect itself against DoS attacks by a rogue 6LN, see Section 12. [nit] s/succeeds then the operations continue/succeeds, then the operation continues [nit] s/particular/particular, [minor] "a DAO message is generated upon the NS(EARO) that proves the ownership of the address" It would be very nice is a new figure was included (either here or in §10.1) to show this updated flow. 998 The 6LR may at any time send a unicast asynchronous NA(EARO) with the 999 "R" flag reset to signal that it stops providing routing services, 1000 and/or with the EARO Status 2 "Neighbor Cache full" to signal that it 1001 removes the NCE. It may also send a final RA, unicast or multicast, 1002 with a Router Lifetime field of zero, to signal that it stops serving 1003 as router, as specified in section 6.2.5 of [RFC4861]. [minor] What are the RPL actions that should take place? For example, if the 6LR "stops providing routing services" to a specific 6LN, but still acts as a router for others...should it also send an NPDAO/DCO to remove the routing state? Is there a reference somewhere about how a RPL router gracefully "stops serving as router"? 1005 If a 6LR receives a valid NS(EARO) message with the "R" flag reset 1006 and a Registration Lifetime that is not 0, and the 6LR was injecting 1007 the Registered Address due to previous NS(EARO) messages with the "R" 1008 flag set, then the 6LR MUST stop injecting the address. It is up to 1009 the Registering 6LN to maintain the corresponding route from then on, 1010 either keeping it active via a different 6LR or by acting as a RAN 1011 and managing its own reachability. [major] "MUST stop injecting the address" Can you be more specific? What does this mean in RPL terms? Send an NPDAO/DCO? 1013 10.2.3. Perspective of the RPL Root 1015 A RPL Root SHOULD set the "P" flag in the RPL DODAG Configuration 1016 Option of the DIO messages that it generates (see Section 4) to 1017 signal that it proxies the EDAR/EDAC exchange and supports the 1018 Updated RPL Target option. The remainder of this section assumes 1019 that it does. [major] If the Root supports the functionality, when would it be ok for it to not set the P flag? IOW, why is it recommended and not required? [Note that I may be missing context because there is no specification for that flag.] 1021 Upon reception of a DAO message, for each updated RPL Target Option 1022 (see Section 9) that creates or updates an existing RPL state, the 1023 Root MUST notify the 6LBR. This can be done using an internal API if 1024 they are integrated, or using a proxied EDAR/EDAC exchange if they 1025 are separate entities. [major nit] "MUST notify the 6LBR. This can be done..." I'm not too happy with the wording as it seems to provide options to a requirement... Suggestion> The Root MUST notify the 6LBR by using a proxied EDAR/EDAC exchange if they are separate entities. If the RPL Root and 6LBR are integrated, then an internal API can be used. ... 1043 Upon receiving an EDAC message from the 6LBR, if a DAO is pending, 1044 then the Root MUST send a DAO-ACK back to the 6LR. Else, if the 1045 Status in the EDAC message is not "Success", then it MUST send an 1046 asynchronous DCO to the 6LR. [?] "if a DAO is pending" Even though rfc6550 doesn't talk about "pending", I take this to mean that the DAO hasn't been ack'd. Just wondering (because I couldn't find it in rfc6550), is there a timer that defines the time between receiving the DAO and sending a DAO-ACK. I'm also wondering about it since sending a DAO-ACK is only recommended. [major] What if the EDAC message is not received? Should the Root signal a failure? What if the EDAC message comes in after a failure is signaled? This should presumably not happen, especially since the 6LN already registered...but I'm worried about the timing. [major] Some text should be added related to the possibility that not all nodes may know what the DCO is. Suggestion (borrowing from §4.6.2/EFFICIENT-NPDAO)> This document assumes that all the 6LRs in the network support this specification. If there are 6LRs in the DCO message path which do not support this document, then the issue indication may not reach the 6LR. Alternatively, the Root could... I stopped there because the text above says that the Root "MUST send an asynchronous DCO". ... 1059 11. Protocol Operations for Multicast Addresses ... 1068 "Multicast Listener Discovery (MLD) for IPv6" [RFC2710] and its 1069 updated version "Multicast Listener Discovery Version 2 (MLDv2) for 1070 IPv6" [RFC3810] provide an interface for a listener to register to 1071 multicast flows. MLDv2 is backwards compatible with MLD, and adds in 1072 particular the capability to filter the sources via black lists and 1073 white lists. In the MLD model, the Router is a "querier" and the 1074 Host is a multicast listener that registers to the querier to obtain 1075 copies of the particular flows it is interested in. [nit] s/backwards/backward [nit] s/"querier" and/"querier", and [major] In general, the text talks about an "MLD listener/querier" -- are you using "MLD" to indicate support for both rfc2710/rfc3810, or are you assuming MLDv1 support only? The phrase "MLDv2 is backwards compatible with MLD" is what is confusing me. I also ask because the pim WG has an ongoing discussion about deprecating MLDv1. I am assuming MLDv2, which is what rfc8504 requires. If so, let's focus on rfc3810. [-] s/capability to filter the sources via black lists and white lists/support for source filtering That is the language used in rfc3810. 1077 On the first Address Registration, as illustrated in Figure 8, the 1078 6LN, as an MLD listener, sends an unsolicited Report to the 6LR in 1079 order to start receiving the flow immediately. [minor] "On the first Address Registration..." Do you mean when the 6LN registers its own address (Figure 5)? I would assume you're talking about when the 6LN decides to listen to multicast; maybe reword... 1081 6LN/RUL 6LR Root 6LBR 1082 | | | | 1083 | unsolicited Report | | | 1084 |------------------->| | | 1085 | <L2 ack> | | | [] See the comment below about the L2 ack. This same phrase shows up in Figure 9 later on... 1086 | | DAO | | 1087 | |-------------->| | 1088 | | DAO-ACK | | 1089 | |<--------------| | 1090 | | | <if not listening> | [minor] "if not listening" Even if the 6LBR is listening, the Report should be unsolicited, right? I'm not sure what this phrase means... ... 1097 Since multicast Layer-2 messages are avoided, it is important that 1098 the asynchronous messages for unsolicited Report and Done are sent 1099 reliably, for instance using a Layer-2 acknowledgment, or attempted 1100 multiple times. [major] The lack of reliable transmission is already addressed in rfc3810. What concerns me about the text is the suggestion that a different (L2 ack) mechanism can be used for MLD without any specifics. 1102 The 6LR acts as a generic MLD querier and generates a DAO for the 1103 multicast target. The lifetime of the DAO is set to be in the order 1104 of the Query Interval, yet larger to account for variable propagation 1105 delays. [minor] s/multicast target/Multicast Address in the Report message [major] "generates a DAO for the multicast target" This document is a standards track specification...we need to be more explicit. I'm assuming that the Multicast Address is included as the Target Prefix in the Target Option... [major] One Multicast Address per DAO? I think I saw a related discussion on the list recently. [major] "lifetime of the DAO" The Path Lifetime? [major] "lifetime...is set to be in the order of the Query Interval, yet larger..." How much is that? Double? Just a few seconds more? ms? ... 1111 Upon a DAO with a multicast target, the RPL Root checks if it is 1112 already registered as a listener for that address, and if not, it 1113 performs its own unsolicited Report for the multicast target. [major] As above, please be specific. How is the DAO information used to build a Query? 1115 An Address re-Registration is pulled periodically by 6LR acting as 1116 querier. Note that the message may be sent unicast to all the known 1117 individual listeners. [major] In MLDv2 that is called a Query... [nit] s/by 6LR/by the 6LR [major] "message may be sent unicast to all the known individual listeners" The first paragraph in this section says that "the multicast packet is passed as a Layer-2 unicast to each of the interested children", so there is no other option, right? ... 1144 Note that any of the functions 6LR, Root and 6LBR might be collapsed 1145 in a single node, in which case the flow above happens internally, 1146 and possibly through internal API calls as opposed to messaging. [nit] s/Root and/Root, and 1148 12. Security Considerations 1150 First of all, it is worth noting that with [RFC6550], every node in 1151 the LLN is RPL-aware and can inject any RPL-based attack in the 1152 network. This specification isolates edge nodes that can only 1153 interact with the RPL routers using 6LoWPAN ND, meaning that they 1154 cannot perform RPL insider attacks. [nit] s/First of all, it/I [major] Because 6LoWPAN ND is used, please add text about the Security Considerations from rfc6775, rfc8505 apply. [major] Also, let's work in a general pointer to rfc7416 somewhere (instead of the very specific one below). [major ?] Are there attacks that can be injected into the RPL network through ND? I'm wondering if a RUL can request and inject a significant number of addresses so that it could hinder the operation of the LLN. I don't know if that's even an issue...just thinking out loud. 1156 6LoWPAN ND can optionally provide SAVI features with [AP-ND], which 1157 reduces even more the attack perimeter that is available to the edge 1158 nodes. [minor] I think there's some discussion of this in rfc8505...maybe point to that. Otherwise, this paragraph feels orphan... 1160 The LLN nodes depend on the 6LBR and the RPL participants for their 1161 operation. A trust model must be put in place to ensure that the 1162 right devices are acting in these roles, so as to avoid threats such 1163 as black-holing, (see [RFC7416] section 7) or bombing attack whereby 1164 an impersonated 6LBR would destroy state in the network by using the 1165 "Removed" Status code. 1167 This trust model could be at a minimum based on a Layer-2 Secure 1168 joining and the Link-Layer security. This is a generic 6LoWPAN 1169 requirement, see Req5.1 in Appendix of [RFC8505]. 1171 Additionally, the trust model could include a role validation to 1172 ensure that the node that claims to be a 6LBR or a RPL Root is 1173 entitled to do so. [major] There was some trust model-related text in draft-ietf-roll-turnon-rfc8138 that we ended up replacing. Please do the same here. 1175 At the time of this writing RPL does not have a zerotrust model 1176 whereby it is possible to validate the origin of an address that is 1177 injected in a DAO. This specification makes a first step in that 1178 direction by allowing the Root to challenge the RUL via the 6LR that 1179 serves it. [nit] s/writing RPL/writing, RPL [nit] s/zerotrust/zero-trust [minor] The challenge really comes from the 6LBR (not the Root)...but only if AP-ND is present. IOW, the use of AP-ND is what adds the protection, not the specification itself. Is that what we're talking about here? If so, then I have a couple more things to point at: - §3.2.3: "This specification does not address how the protection by [AP-ND] could be extended to RPL." But that is what seems to be claimed above. - §7.1: "The RUL SHOULD support [AP-ND] to protect the ownership of its addresses." If the RUL doesn't, then whatever benefit is claimed/expected is lost. 1181 13. IANA Considerations [major] §14-17 should be sub-sections of this one. ... 1191 13.2. Resizing the ARO Status values 1193 Section 12 of [RFC6775] creates the Address Registration Option 1194 Status Values Registry with a range 0-255. 1196 This specification reduces that range to 0-63. [minor] NEW> This specification reduces that range to 0-63 (Section 8). 1198 IANA is requested to reduce the upper bound of the unassigned values 1199 in the Address Registration Option Status Values Registry from -255 1200 to -63. [major] NEW> IANA is requested modify the Address Registration Option Status Values Registry so that the upper bound of the unassigned values is 63. This document should be added as a reference. The registration procedure does not change. [major] Because of this change in the registry defined by rfc6775, that RFC should be formally Updated. 1202 14. New DODAG Configuration Option Flag 1204 This specification updates the Registry for the "DODAG Configuration 1205 Option Flags" that was created for [RFC6550] as follows: [major] NEW> IANA is requested to assign a flag from the "DODAG Configuration Option Flags" registry as follows: 1207 +------------+----------------------------+-----------+ 1208 | Bit Number | Capability Description | Reference | 1209 +============+============================+===========+ 1210 | 1 | Root Proxies EDAR/EDAC (P) | THIS RFC | 1211 +------------+----------------------------+-----------+ [major] Please mark the value (1) as suggested. ... 1215 15. New RPL Target Option Flag 1217 Section 20.15 of [RFC6550] creates a Registry for the 8-bit "RPL 1218 Target Option Flags" field. IANA is requested to reduce the size of 1219 the field in the Registry to 4 bits. This specification also defines 1220 a new entry in the Registry as follows: [] Suggestion> This document modifies the "RPL Target Option Flags" registry initially created in Section 20.15 of [RFC6550]. The registry now includes only 4-bits (Section 9) and should point to this document as an additional reference. The registration procedure doesn't change. The following table shows the initial assignment. [major] This change in the registry should be flagged as an Update to rfc6550. ... 1228 Table 3: New RPL Target Option Flag [minor] s/New RPL Target Option Flag/RPL Target Option Registry 1230 16. New Subregistry for the RPL Non-Rejection Status values 1232 This specification creates a new Subregistry for the RPL Non- 1233 Rejection Status values for use in RPL DAO-ACK and DCO messages with 1234 the 'A' flag reset, under the ICMPv6 parameters registry. [nit] s/in RPL/in the RPL [major] The DCO-ACK Status registry is under the RPL registry. Why isn't this one there too? It is RPL-related. ... 1238 * Registration procedure is "Standards Action" [RFC8126]. [major ?] All the other RPL registries have an "IETF Review" registration procedure. Why is this one different? ... 1242 +-------+------------------------+-----------+ 1243 | Value | Meaning | Reference | 1244 +=======+========================+===========+ 1245 | 0 | Unqualified acceptance | RFC 6550 | 1246 +-------+------------------------+-----------+ [major] Let's also add this document as a reference for this initial allocation. ... 1250 17. New Subregistry for the RPL Rejection Status values 1252 This specification creates a new Subregistry for the RPL Rejection 1253 Status values for use in RPL DAO-ACK and RCO messages with the 'A' 1254 flag reset, under the ICMPv6 parameters registry. [nit] s/in RPL/in the RPL [minor] s/RCO/DCO [major] The DCO-ACK Status registry is under the RPL registry. Why isn't this one there too? It is RPL-related. ... 1258 * Registration procedure is "Standards Action" [RFC8126]. [major ?] All the other RPL registries have an "IETF Review" registration procedure. Why is this one different? ... 1276 19. Normative References [minor] The following references can be Informative: ... 1293 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1294 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1295 Overview, Assumptions, Problem Statement, and Goals", 1296 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1297 <https://www.rfc-editor.org/info/rfc4919>. ... 1304 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1305 Address Autoconfiguration", RFC 4862, 1306 DOI 10.17487/RFC4862, September 2007, 1307 <https://www.rfc-editor.org/info/rfc4862>. ... 1316 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1317 Power and Lossy Networks (RPL) Option for Carrying RPL 1318 Information in Data-Plane Datagrams", RFC 6553, 1319 DOI 10.17487/RFC6553, March 2012, 1320 <https://www.rfc-editor.org/info/rfc6553>. ... 1322 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1323 Routing Header for Source Routes with the Routing Protocol 1324 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1325 DOI 10.17487/RFC6554, March 2012, 1326 <https://www.rfc-editor.org/info/rfc6554>. ... 1338 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1339 Constrained-Node Networks", RFC 7228, 1340 DOI 10.17487/RFC7228, May 2014, 1341 <https://www.rfc-editor.org/info/rfc7228>. ... 1353 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 1354 "IPv6 over Low-Power Wireless Personal Area Network 1355 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 1356 April 2017, <https://www.rfc-editor.org/info/rfc8138>. ... 1394 20. Informative References ... 1429 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 1430 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 1431 January 2019, <https://www.rfc-editor.org/info/rfc8504>. [major] This reference should be Normative. ... 1439 Appendix A. Example Compression ... 1455 The difference with the example presented in Figure 19 of [RFC8138] 1456 is the addition of a SRH-6LoRH before the RPI-6LoRH to transport the 1457 compressed address of the 6LR as the destination address of the outer 1458 IPv6 header. In the original example the destination IP of the outer 1459 header was elided and was implicitly the same address as the 1460 destination of the inner header. Type 1 was arbitrarily chosen, and 1461 the size of 0 denotes a single address in the SRH. [minor] Which one is the "original example", this one, or the one in rfc8138?
- [Roll] AD Review of draft-ietf-roll-unaware-leave… Alvaro Retana
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Pascal Thubert (pthubert)
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Pascal Thubert (pthubert)
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Michael Richardson
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Pascal Thubert (pthubert)
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Michael Richardson
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Alvaro Retana
- [Roll] In what way is roll-unaware-leaves updatin… Michael Richardson
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Michael Richardson
- Re: [Roll] In what way is roll-unaware-leaves upd… Alvaro Retana
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Alvaro Retana
- Re: [Roll] In what way is roll-unaware-leaves upd… Michael Richardson
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Michael Richardson
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Pascal Thubert (pthubert)
- Re: [Roll] In what way is roll-unaware-leaves upd… Pascal Thubert (pthubert)
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Pascal Thubert (pthubert)
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Michael Richardson
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Pascal Thubert (pthubert)
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Alvaro Retana
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Pascal Thubert (pthubert)
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Pascal Thubert (pthubert)
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Michael Richardson
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Michael Richardson