Re: [Roll] AD Review of draft-ietf-roll-unaware-leaves-18

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear Alvaro

Following up on the call on Monday and Michael's changes in useofrplinfo I published a version 20 of this draft.

You'll find that it still updates RFC 6550 and RFC 8505. The reasons are in eth second mail.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/

There is also a HTML versions available at:
https://www.ietf.org/id/draft-ietf-roll-unaware-leaves-20.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-20

I attached for your convenience my partial answers to you email below. Please let me know where you think we are now.

Keep safe;

Pascal



> -----Original Message-----
> From: Alvaro Retana <[e-mail]>
> Sent: mercredi 16 septembre 2020 16:58
> To: [e-mail]
> Cc: Rahul Jadhav <[e-mail]>; [e-mail]; Routing Over
> Low power and Lossy networks <[e-mail]>
> Subject: AD Review of draft-ietf-roll-unaware-leaves-18
> 
> 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

--- Begin Message ---

Hello again Alvaro


This is a quick pass on the nits (and snipped those I implemented as suggested):


> [major] A mention of Updating draft-ietf-roll-efficient-npdao is missing in the
> Abstract.  See also the comments in §5.

Removed the formal update and commented out the update text


> ...
> 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.
>

added
"
   This document is organized as follows:

   *  Section 3 and Section 4 present salient aspects of RPL and 6LoWPAN
      ND, respectively, that are leveraged in this specification to
      provide connectivity to a RUL across a RPL network.

   *  Section 5 lists the expectations that a RUL needs to match in
      order to be served by a RPL router that complies with this
      specification.

   *  Section 6, Section 7, and Section 8 presents the additions to
      [RFC6550], [EFFICIENT-NPDAO], and [RFC8505].

   *  Section 9 and Section 10 present the operation of this
      specification for unicast and multicast flows, respectively, and
      Section 11 presents associated security considerations.

"


> [minor] "routing stretch (see [RFC6687])"  The term "routing stretch"
> is not in rfc6687...but there are other terms that might be what you meant.

Yes, they use path stretch; updating.


> [] "lazily"  Maybe I'm not getting the proper meaning, but it doesn't sound
> good...

We use the term "lazy" to mean an update that is not done immediately upon the event but opportunistically sometime later. This applies for instance to writing to disk in the db world.


> [minor] Do we really need rfc4862 as a reference for IPv6 ND?

Hard to present classic IPv6 ND without mentioning SLAAC, is it?
I'd rather not make a change there


> ...or perhaps simply [USEofRPLinfo], since there will be an RFC number by the
> time we publish.

Even better yes


> 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.

Yes, this is the point of the text below:

"

11.  Security Considerations

   First of all, it is worth noting that with [RFC6550], every node in
   the LLN is RPL-aware and can inject any RPL-based attack in the
   network.  This specification isolates edge nodes that can only
   interact with the RPL Routers using 6LoWPAN ND, meaning that they
   cannot perform RPL insider attacks.

   6LoWPAN ND can optionally provide SAVI features with [AP-ND], which
   reduces even more the attack perimeter that is available to the edge
   nodes.

"

>
> [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.

We had
"
   This trust model could be at a minimum based on a Layer-2 Secure
   joining and the Link-Layer security.  This is a generic 6LoWPAN
   requirement, see Req5.1 in Appendix of [RFC8505].
"

I'm now adding
"
                                                                                                   It is needed in
   particular to prevent Denial-Of-Service attacks whereby a rogue 6LN
   creates a high churn in the RPL network by constantly registering and
   deregistering addresses with the "R" flag set in the EARO.
"


>
> ...
> 186   2.1.  BCP 14
>
> [] s/BCP 14/Requirements Language

Yes I saw it coming and did that in the previous pass

>
>
> 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.

This was the final intention after some back and forth fluctuation.
And yes it is a normative reference for exactly that reason.

>
> 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.
>


Reworded
"
   When the "T" flag is set, the EARO includes a sequence counter called
   Transaction ID (TID), that is needed to fill the Path Sequence Field
   in the RPL Transit Option.  This is the reason why the support of
   [RFC8505] by the RUL as opposed to only [RFC6775] is a prerequisite
   for this specification (more in Section 5.1).
"

>
>
> ...
> 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?

Could be configuration. But OK made it a MUST


>
> 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?

Well, I have not seen that we converged to that understanding.
There were reviews after yours that told me to do the opposite on the turnon RFC 8138 draft
Did we reach an agreement at IESG level on this?
In the meantime, I'll trust you again though I'm prepared for more churn.

> Note that Updating is different than simply expecting the nodes that
> implement this specification to comply.

There's updated that replaces stuff and updated that adds stuff on top.
Here we are updating the format of RPL messages in a backward compatible fashion.
For me that means updates. Anyway we find later that updates is needed.

>
> [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.]

Very correct. If only enough 6LRs at the edge do it we're done.


>
> 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.
>

>
> [] 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.
>

True, that is not why we have the updates. See sections "Updated RPL Status " and "Updated RPL Target Option"

>
> 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.

This is why we also update 8505, see section" Updating RFC 8505 ". I restored that updates too.

>
> 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...

Not so. The RUL is advertised in non-storing mode, meaning unicast from access 6LR straight to the Root
So this particular spec is backward compatible, as per your own intuition (your [personal opinion point above)


>
> [] 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.
>

Sorry I'm not following. Please let me know if I need to restore the updates or not?

> [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?
>

Reworded to
"
   Section 6.7.7 of [RFC6550] introduces the RPL Target Option, which
   can be used in RPL Control messages such as the DAO message to signal
   a destination prefix.  Section 6.2 adds the capabilities to transport
   the ROVR field (see Section 4.2.3) and the full IPv6 Address of the
   prefix advertiser when the Target is a shorter prefix, signaled by a
   new "F" flag.

"
Added "full". The point of "F" is similar to what we do in mobile IP. We place the 128bits address of the advertising node within the longer prefix that is advertised for routing purpose.


>
> 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.

That was the definition of the "P" flag. I added a subsection based on the converged text in the turnon RFC 8138 draft. Note that I still need you and Benjamin Kaduk to agree on the updates or not there too - at the latest it is back on.

"
6.2.  Updated DODAG Configuration Option

   The DODAG Configuration Option is defined in Section 6.7.6 of
   [RFC6550].  Its purpose is extended to distribute configuration
   information affecting the construction and maintenance of the DODAG,
   as well as operational parameters for RPL on the DODAG, through the
   DODAG.  As shown in Figure 4, the Option was originally designed with
   4 bit positions reserved for future use as Flags.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type = 0x04 |Opt Length = 14| |P| | |A|       ...           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     +

            Figure 4: DODAG Configuration Option (Partial View)

   This specification defines a new flag "Root Proxies EDAR/EDAC" (P).
   The "P" flag is set to indicate support for this specification at the
   Root within the DODAG.  The "P" flag is encoded in position 1 of the
   reserved Flags in the DODAG Configuration Option (counting from bit 0
   as the most significant bit) and set to 0 in legacy implementations
   as specified respectively in Sections 20.14 and 6.7.6 of [RFC6550].

   The "P" flag is set to indicate that the Root performs the proxy
   operation, which implies that it supports the Updated RPL Target
   Option (see Section 6.1).

   The RPL DODAG Configuration Option is typically placed in a DODAG
   Information Object (DIO) message.  The DIO message propagates down
   the DODAG to form and then maintain its structure.  The DODAG
   Configuration Option is copied unmodified from parents to children.

   Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in
   the DIO Base Object.  This specification applies to MOP values 0 to
   6.  For a MOP value of 7, the bit in position 1 is considered
   unallocated and [RFC8138] MUST be used by default.

   [RFC6550] states that "Nodes other than the DODAG Root MUST NOT
   modify this information when propagating the DODAG Configuration
   option".  Therefore, a legacy parent propagates the "P" flag as set
   by the Root whether it supports this specification or not.  So when
   the "P" flag is set, it is transparently flooded to all the nodes in
   the DODAG.


"
>
> [] Hard to say if this change is an Update without a specification of the P flag.
>

Please consider sections

  7.  Updating draft-ietf-roll-efficient-npdao  . . . . . . . . . .  16
   8.  Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . .  16
   9.  Protocol Operations for Unicast Addresses . . . . . . . . . .  16

For now based on discussion deeper in tis thread I restored the formal updates.

> 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.

I used the final text in turnon RFC 8138 to create the new section above


>
> ...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.

I'll rather use the new section that went through IESG reviews

>
> 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.
>

Restored!


> [] 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?

Actually that would be better for e.g., the backbone router, but is not necessary for this spec.
With this reading I'd rather do the updates but I keep it out for now.

> 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"...]

OK then!

Voila!

This second set of diffs is available here

https://github.com/roll-wg/roll-unaware-leaves/commit/de2ce1ae31b78b664a94dfc08bb0f52dac882d62

That's a bunch! I published -20 so we can have a new reference to discuss about with the aggregation of the 2 diff sets.


Html:           https://www.ietf.org/id/draft-ietf-roll-unaware-leaves-19.html
Htmlized:       https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-19
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-19


Please let me know : )
Many thanks Alvaro!

Take care,

Pascal

--- End Message ---

--- Begin Message ---

Hello Alvaro

Many thanks again and again!

>
> 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.

I see it this way:

RFC 8504 expects classic ND, on-link subnet. We're doing ML Subnet and designed RFC 8505 as the evolution of ND to cover that case.
This draft is the first time we use RFC 8505 as a host-to-router (UNI) abstract interface to the router-to-router (NNI).
We use RPL in this case, but could be any routing protocol.

So yes there can be a lot to iron out but it is worth the effort. Many thanks for your help and patience 😊


> (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...

Yes. I believe that is how we defined it.
The RUL is an IPv6 host connected to RPL that does not speak RPL.

> 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...


RPL expects only RPL Aware Nodes, and the unprepared RUL will not get connectivity in a RPL network.
So we define here what needs to be added to a classic host to connect to RPL.
Unsurprisingly, it is based on the ND version that we defined for LLNs.


>  The definition of a RUL starts in the Introduction with a simple
>  description: "RUL is an IPv6 Host [RFC8504]".

This was not meant to be a definition of a RUL but just one of its characteristics.


 And we say it in section 2.1

"
   This document uses the terms RPL-Unaware Leaf (RUL) and RPL-Aware
   Leaf (RAL) consistently with "Using RPI Option Type, Routing Header
   for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data
   Plane" [USEofRPLinfo].
"

And useofrplinfo says :

"
   RPL Leaf: An IPv6 host that is attached to a RPL router and obtains
   connectivity through a RPL Destination Oriented Directed Acyclic
   Graph (DODAG).  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.  It results that a RPL Leaf can correctly
   receive a packet with RPL artifacts.  On the other hand, a RPL Leaf
   is not expected to generate RPL artifacts or to support IP-in-IP
   encapsulation.  For simplification, this document uses the standalone
   term leaf to mean a RPL leaf.

   RPL-unaware-node: A device which does not implement RPL, thus the
   device is not-RPL-aware.  Please note that the device can be found
   inside the LLN.

   RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf.

"

>  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...

The  RUL must be an IPv6 host, which means comply with RFC 8504; but RFC 8504 compliance is not sufficient for a RUL to connect to a RPL network, thus this spec.
This spec specifies the additions to RFC 8504 for that to happen.
The RUL is an IPv6 host, that much is true. But not only that. It is a Leaf, which means reachable though RPL.
Some magic must happen. That magic will not be found in classic ND because ND does not support MLSN. But 6LoWPAN ND does.

I see that the text could be read differently and that we need to reword to avoid it. Proposal:

OLD
"
  RPL can be deployed as an extension to IPv6 Neighbor Discovery (ND)
   [RFC4861][RFC4862] and 6LoWPAN ND [RFC6775][RFC8505] to maintain
   reachability within a Non-Broadcast Multi-Access (NBMA) subnet.  In
   that mode, some nodes may act as Routers and participate to the
   forwarding operations whereas others will only terminate packets,
   acting as Hosts in the data-plane.  In [RFC6550] terms, a Host that
   is reachable over the RPL network is called a Leaf.

   "When to use RFC 6553, 6554 and IPv6-in-IPv6" [USEofRPLinfo]
   introduces the term RPL-Aware-Leaf (RAL) for a Leaf that injects
   routes in RPL to manage the reachability of its own IPv6 addresses.
   In contrast, the term RPL-Unaware Leaf (RUL) designates a Leaf that
   does not participate to RPL at all.  A RUL is an IPv6 Host [RFC8504]
   that needs a RPL-Aware Router to obtain routing services over the RPL
   network.

"

NEW
"
   RPL can be deployed as an extension to IPv6 Neighbor Discovery (ND)
   [RFC4861][RFC4862] and 6LoWPAN ND [RFC6775][RFC8505] to maintain
   reachability within a Non-Broadcast Multi-Access (NBMA) subnet.
   In that mode, IPv6 addresses are advertised individually as Host
   routes.  Some nodes may act as Routers and participate to the
   forwarding operations whereas others will only terminate packets,
   acting as Hosts in the data-plane.  In [RFC6550] terms, an IPv6 Host
   [RFC8504] that is reachable over the RPL network is called a Leaf.

   "When to use RFC 6553, 6554 and IPv6-in-IPv6" [USEofRPLinfo]
   introduces the term RPL-Aware-Leaf (RAL) for a Leaf that injects Host
   routes in RPL to manage the reachability of its IPv6 addresses.  In
   contrast, the term RPL-Unaware Leaf (RUL) designates a Leaf that does
   not participate to RPL and cannot inject its Host routes in RPL.  The
   RUL therefore needs a Host-to-Router interface to advertise its IPv6
   addresses to its Router so the Router can inject them the RPL
   network, as detailed in Section 4.

"

Section 4 being the uplifted location of the requirements on the RUL as you suggest later.

>  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*

You are correct in the intent. Does the change above help?

>  least, an early discussion (don't wait until §7!) of the expectations for a
>  RUL.  Move §7 *before* you start discussing 6LoWPAN ND.

Do you really want that?
Section 7 heavily uses the description of 6LoWPAN ND provided in section 3, see 7.1.
Moving section 7 before 3 does not compile without heavy forward referencing
But I can move it right after as follows:


   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  RPL External Routes and Dataplane Artifacts . . . . . . . . .   7
   4.  6LoWPAN Neighbor Discovery  . . . . . . . . . . . . . . . . .   8
   5.  Requirements on the RPL-Unware Leaf . . . . . . . . . . . . .  11
   6.  Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Updating draft-ietf-roll-efficient-npdao  . . . . . . . . . .  15
   8.  Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . .  15   <SNIP>

Note that due to a point later, text was moved away from the ".Requirements on the RPL-Unware Leaf" to become its own section " RPL External Routes and Dataplane Artifacts " because it has normative text on the router that did not fit there.

>  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.

A leaf is a generic terms that says that the node gets reachability over RPL but does not say how the address is injected and by whom.
For a RAL, the leaf uses RPL. For a RUL there can be many ways, but outside of RPL. RFC 8505 was crafted in preparation of this spec.
All we need now is that the RUL uses RFC 8505 with the settings that RFC 8505 says it should in the circumstances, as reminded in section 3.
So I guess it was improper from our side to duplicate the normative language. I like your term expectation.

"

4.1.  Support of 6LoWPAN ND

   To obtain routing services from a 6LR that implements this
   specification, a RUL is expected to implement [RFC8505] and set the
   "R" and "T" flags in the EARO.  The RUL may provide support of
   [AP-ND] to protect the ownership of its addresses.  The RUL is
   expected not to request routing services from a 6LR that does not
   originate RA messages with a CIO that has the L, P, and E flags all
   set as discussed in Section 3.3.1, unless configured to do so.

   A RUL that may attach to multiple 6LRs is expected to prefer those
   that provide routing services.  The RUL needs to register to all the
   6LRs from which it desires routing services.

   Parallel Address Registrations to several 6LRs should be performed in
   an rapid sequence, using the exact same EARO for the same Address.
   Gaps between the Address Registrations will invalidate some of the
   routes till the Address Registration finally shows on those routes.

   [RFC8505] introduces error Status values in the NA(EARO) which can be
   received synchronously upon an NS(EARO) or asynchronously.  The RUL
   MUST support both cases and MUST refrain from using the address when
   the Status Value indicates a rejection.

"

>  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?

Same. This is not a LLN problem. It is a problem in a MLSN where proactive routing is used. The router must be told to inject host routes in advance and we need a host-router interface for that. If you like, Classic ND is a form of UNI, and RFC 8505 extends it for proactive operations, whereas RPL is an NNI.

RFC 8504 only mandates classic ND (RFC 8505 missed that train by 1 RFC!!! ); With classic ND, the router does not have a prior knowledge of the host. ND discovers the host reactively. To match that in a MLSN, we'd need to flood the lookup; in a RPL network you'd have to use AODV-RPL. And then implement some route maintenance is the host moves.


>
>  [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?]

Nothing, sadly. There's always a voice saying we do not need it and the discussion dries out.
There's https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ but it is just about wireless.
There's also https://datatracker.ietf.org/doc/draft-ietf-rift-rift/ which shows how RFC 8505 can be useful in a DC.

Seems to me that 6MAN is more concerned with the interests of the host than of the router. Maybe a consequence of the way we do areas at the IETF.
If we could get the routing area to flood 6MAN and explains the needs of modern (routed) subnets like overlays, maybe we could progress this work.

> [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?

RFC 8505 defines a 6LN functionality and the RUL needs to implement that functionality.
A 6LN as defined in 6LoWPAN can do things that the RUL does not need to for the sake of this spec, e.g., RFC 6282 compression.
So I need to be very careful every time 6LN is mentioned. Note that useofrplinfo uses 6LR for the border router, which is echoed here.

>
>  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...

Yes, I need to scan and clean that up ref by ref. here's a sample:

"
 This specification leverages the Address Registration mechanism defined in
   6LoWPAN ND to enable a RUL acting as a 6LoWPAN Node (6LN) to interface with a
   RPL-Aware Router as a 6LoWPAN Router (6LR) and request that the 6LR injects
   a Host route for the Registered Address in the RPL routing on its behalf."
"
   The unicast packet forwarding operation by the 6LR serving a RUL as described in section 4.1 of <xref target='I-D.ietf-roll-useofrplinfo'/>.
"
"
    A RPL Leaf that implements the 6LN functionality in <xref target='RFC8505'/>
   requires reachability services for an IPv6 address if and only
   if it sets the "R" flag in the NS(EARO) used to register the address to a RPL
"
"
   which means that nodes that are aware of the Host route are also
   aware of the ROVR associated to the Target Address.
"


>  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...).

Yes. In my update I'm trying to use 6LN in the context of the registration flow, which is the piece that the RUL needs to implement.

>
>  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.
>



When we describe a 6LoWPAN ND flow, it is easier to speak in 6LoWPAN terms, so there are multiple places where we want to conserve that term.

So I added in the terminology:
"
   This specification uses the terms 6LN and 6LR to refer specifically to the
   roles defined in 6LoWPAN ND and does expect other functionality
   such as 6LoWPAN Header Compression <xref target='RFC6282'/> from those nodes.
"



>  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.

It is indeed. I made a long pass.

>
> (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.

We have this unresolved item on turnon RFC 8138. Seems very similar from my perspective and I'm concerned that we may have other reviewer asking it back.

But OK, I'll remove the formal update for now.



>
>  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. :-)

Very true, do we have a standard for that?

I'll do the nits tomorrow but would like to assess your approval on the above already so I
Please see https://github.com/roll-wg/roll-unaware-leaves/commit/7b4e13a002ae2da39fd4655b2c2c23c70925ed6c

Many, many thanks Alvaro!

Pascal

--- End Message ---