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

[Alvaro Retana <[e-mail]>]

On October 9, 2020 at 3:45:45 PM, Pascal Thubert wrote:


Pascal:

Hi!

...
> I committed the result in the IETF datatracker as draft 22 as a reference
> since we made major changes already.

I am including 2 parts below. First a reply to this message
(specifically to the -21 comments), and then some comments based on
-22.  In some cases I put comments on -22 simply because it seemed
"cleaner" (so not all the comments are new, but a continuation of the
discussion).

This is a quick list of the major items I want to resolve (MUST)
before starting the IETF LC -- I'm putting it here for my own
reference, please put any comments inline below and not up here.

(1) DCO-ACK Status update and registry.

(2) Mention of Update details in the Introduction.

(3) Suggested RPL Instance (§9.2.2).

(4) Multicast Operation (§10).


Thanks!

Alvaro.



=== Part 1: Reply ===

> > === Part 3: remaining comments (based on -18) ===
...
> But we're also merging the statis with the DCO-ACK Status
> In that we deprecate
> https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-dco-ack-status

That is new!!  I don't even see DCO-ACK mentioned in the document at all.

Does this mean that §12.5 should also be changed to include the
DCO-ACK message in it?


> So we should update the NPDAO draft and remove that entry shouldn't we?
> Note that NPDAO is already in missref because of this draft
> https://www.rfc-editor.org/cluster_info.php?cid=C310

Yes.

Also, the specification of the DAO-ACK needs to be changed to at least
make it clear that the "DCO-ACK Status" field refers to the "RPL
Status".

About deprecating the registry...  We should ask IANA what to do: they
already created the registry, but the efficient-npdao hasn't been
published as an RFC.  I don't know if we just delete §6.2 or if we
have to formally deprecate the registry (possible in this document).

Please ack to this to make sure we're in sync before asking IANA.



...
> > 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] What about the ARO? The Status values are shared between the
> > EARO and the ARO.
>
> The IANA update applies to the registry that was created by RFC 6775 and
> updated by RFC 8505.
> The text actually points at RFC 6775 as the reference for the registry so
> we are impacting both ARO and EARO.

Yes.  The point was that we should mention the ARO here as well:
s/EARO Status/ARO/EARO Status



> 12.2. Resizing the ARO Status values
...
> > [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.
>
> Isn't this transitive? I mean the field defined in RFC 6775 is updated by
> RFC 8505.

No, the updates in rfc8505 are just the ones specified there.


It would then de ideal if the Update to cut the size of the Status
also said that the rfc6775/rfc8505 nodes MUST ignore the first two
bits.  Note that by cutting the size of the Status we're really
leaving two bits unused/undefined.



...
> > 845 10.2.1. Perspective of the RUL Acting as 6LN
...
> > 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.
> >
...
> > [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.
>
> I did not write that text in that meaning. Maybe that's my English.
> The text is meant to say that it MUST set the R flag if it wishes to
> indicate that it is not a router and blah.

Hmm...looking at the whole paragraph, I can see how it could be
interpreted that way.  In either case, I assume that the intent here
is the same: set the R flag if it is not a router, etc...and the RUL
is not RPL-aware.

Given that this bullet already starts with "Following section 5.1 of
[RFC8505], a 6LN acting as a RUL sets the R Flag...", then we don't
need to say it again:

OLD>
   4.  Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets
       the R Flag in the EARO of its registration(s) for which it
       requires routing services.  If the R Flag is not echoed in the
       NA, the RUL SHOULD attempt to use another 6LR.  The RUL SHOULD
       send the registration(s) with the R Flag set and ensure that one
       succeeds before it sends the registrations with the flag reset.
       In case of a conflict with the preceding rule on lifetime, the
       rule on lifetime has precedence.

NEW>
   4.  Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets
       the R Flag in the EARO of its registration(s) for which it
       requires routing services.  If the R Flag is not echoed in the
       NA, the RUL SHOULD attempt to use another 6LR.  The RUL SHOULD
       ensure that one registration succeeds before resetting the R Flag.
       In case of a conflict with the preceding rule on lifetime, the
       rule on lifetime has precedence.



...
> >
> > 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).
>
> This is bad, and the practice is that implementations always respond to the
> K. This is how we know that the route works in non-storing mode. Happy to
> add that SHOULD->MUST to the list of thing this spec updates if you think
> it is worthwhile.

I do...for whenever the time for rfc6550bis comes...no hurry, of course.



...
> > 1059 11. Protocol Operations for Multicast Addresses
...
> > [major] One Multicast Address per DAO? I think I saw a related
> > discussion on the list recently.
>
> The discussion was for multiple VIOs / TIOs. There can always be multiple
> targets. But then, since this is triggered by a message for one address, I
> expect that there will be one DAO at a time. Is there a need for a change?

The MLDv2 Report can include multiple addresses.  In any case, I guess
the behavior is the same: if multiple addresses are in the Report,
then the DAO can do the same.   I don't think we need a change.


...
> > 1230 16. New Subregistry for the RPL Non-Rejection Status values
...
> > 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.
> >
>
> Well it is really define in RFC 6550, just remapped here, but OK.

[] I meant "add" as in put both. :-)



...
> This is the deepest and probably the most useful single review I ever has
> in almost 20 years of IETF!

:-)




=== Part 2: Comments on -22 ===


...
11	Abstract

13	   This specification updates RFC6550, RFC6775, and RFC8505, to provide
14	   routing services to RPL Unaware Leaves that implement 6LoWPAN ND and
15	   the extensions therein.

[major] We usually want to see a short description of what the Update
is, in both the Abstract and the Introduction.  I like the general
statement made here, but I need you to add some more details in the
Introduction.

Perhaps add something like this before the summary of the document's
organization:

   This document updates rfc6550 by ... (Section x).

   This document updates rfc6775 by ... (Section y).

   This document updates rfc8505 by ... (Section z).

(Maybe a single paragraph can cover changes common to rfc6775/rfc8505.)

Yes, it's redundant information, but putting a summary upfront should
answer questions later.



...
489	5.1.  Support of 6LoWPAN ND
...
513	   [RFC8505] introduces error Status values in the NA(EARO) which can be
514	   received synchronously upon an NS(EARO) or asynchronously.  The RUL
515	   needs to support both cases and should refrain from using the address
516	   when the Status Value indicates a rejection (see Section 6.3).

[nit] s/support both cases and should refrain/support both cases and refrain

I believe that the rfc8505 text talks about MUST, so just trying to
avoid confusion.



...
579	6.1.  Updated RPL Target Option
...
600	   The updated format is illustrated in Figure 3.  It is backward
601	   compatible with the Target Option in [RFC6550].  It SHOULD be used as
602	   a replacement in new implementations in all MOPs in preparation for
603	   upcoming Route Ownership Validation mechanisms based on the ROVR,
604	   unless the device or the network is so constrained that this is not
605	   feasible.

[major] "SHOULD be used as a replacement in new implementations in all
MOPs in preparation for upcoming Route Ownership Validation
mechanisms..."

Even with the qualification I am uncomfortable normatively
recommending something for future use without explicitly mentioning
what that is.  It just sounds speculative.  s/SHOULD/is recommended
that the updated format



607	      0                   1                   2                   3
608	      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
609	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[nit] The numbers are not aligned: you need an extra space.


...
625	   ROVRsz (ROVR Size):  Indicates the Size of the ROVR.  It MAY be 1, 2,
626	      3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits,
627	      respectively.  A value if 0 thus denotes a legacy Target Option.

[major] s/MAY be 1, 2, 3, or 4/SHOULD be 1, 2, 3, or 4


[major] What should the receiver do if a different value is used?


[major] s/A value if 0 thus denotes a legacy Target Option./If a
legacy Target Option is used, then the value must remain 0, as
specified in rfc6500.

The other way around, saying that 0 = legacy creates possible issues
with ROVRsz = 0 and the F flag set because it clearly is not a legacy
target option.


629	   F:  1-bit flag.  Set to indicate that Target Prefix field contains an
630	      address of prefix advertiser in full.

[minor] To be consistent with the text earlier in this section:
s/contains an address of prefix advertiser in full./contains the
complete (128 bit) IPv6 address of the advertising node.




...
635	6.2.  New Flag in the RPL DODAG Configuration Option

[] Is this an Update to rfc6550?

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

[nit] It is not extremely clear, by looking at Figure 4 where the
reserved bits are.  I had to compare it with the figure in rfc6550 to
make sure.

s/As shown in Figure 4, the Option/This Option

644	      0                   1                   2                   3
645	      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
646	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
647	     |   Type = 0x04 |Opt Length = 14| |P| | |A|       ...           |
648	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     +
649	                                     <- Flags ->

651	            Figure 4: DODAG Configuration Option (Partial View)


...
663	   Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the
664	   definition of the Flags applies to Mode of Operation (MOP) values
665	   zero (0) to six (6) only.  For a MOP value of 7, the Root is expected
666	   to perform the proxy operation by default.

[major] "is expected"  Does that mean MUST/SHOULD?


668	   The RPL DODAG Configuration Option is typically placed in a DODAG
669	   Information Object (DIO) message.  The DIO message propagates down
670	   the DODAG to form and then maintain its structure.  The DODAG
671	   Configuration Option is copied unmodified from parents to children.
672	   [RFC6550] states that "Nodes other than the DODAG Root MUST NOT
673	   modify this information when propagating the DODAG Configuration
674	   option".  Therefore, a legacy parent propagates the T Flag as set by
675	   the Root, and when the T Flag is set, it is transparently flooded to
676	   all the nodes in the DODAG.

[minor] s/T Flag/'P' bit


678	6.3.  Updated RPL Status
...
726	   When building a DCO or a DAO-ACK message upon an IPv6 ND NA or a EDAC
727	   message, the RPL Root MUST copy the 6LoWPAN ND Status Code unchanged
728	   in the RPL Status Value and set the 'A' flag.  The RPL Root MUST set
729	   the 'E' flag for all rejection and unknown Status Codes.  The Status
730	   Codes in range 1-10 [RFC8505] are all considered rejections.

[nit] s/in range 1-10/in the 1-10 range

[major] What should a receiver do if the E flag is not set for Status
Codes in that range?  It almost feels like this flag is mostly
informational; IOW, if it's not set, and a node receives 1-10, it is
still a rejection.  Maybe we don't have to specify anything...


...
737	7.  Enhancements to draft-ietf-roll-efficient-npdao

739	   [EFFICIENT-NPDAO] defines the DCO message for RPL Storing Mode only,
740	   with a link-local scope.  All nodes in the RPL network are expected
741	   to support the specification since the message in processed hop by
742	   hop along the path this is being cleaned up.

[nit] s/message in processed/message is processed


...
787	9.1.  General Flow
...
806	           6LN/RUL   <-ND->   6LR   <-RPL->  Root   <-ND->     6LBR
807	              |                |              |                   |
808	              |   NS(EARO)     |              |                   |
809	              |--------------->|                                  |
810	              |                |          Extended DAR            |
811	              |                |--------------------------------->|
812	              |                |                                  |
813	              |                |          Extended DAC            |
814	              |                |<---------------------------------|

[minor] Indicating the protocol at the top is nice.  ND is used
between the 6LR and the 6LBR to start.


...
832	   ITo achieve this, the Path Sequence and the Path Lifetime in the DAO
833	   message are taken from the Transaction ID and the Address
834	   Registration lifetime in the NS(EARO) message from the 6LN.

[nit] s/ITo/To


...
923	9.2.1.  Perspective of the 6LN Acting as RUL
...
942	   3.  As stated in section 5.2 of [RFC8505], the 6LN can register to
943	       more than one 6LR at the same time.  In that case, it uses the
944	       same EARO for all of the parallel Address Registrations, with the
945	       exception of the Registration Lifetime field and the setting of
946	       the R flag that may differ.  The 6LN SHOULD send the NS(EARO), if
947	       any, that maintain a registration active (i.e., with a non-zero
948	       Registration Lifetime) and ensure that one succeeds before it
949	       sends an NS(EARO) that terminates another registration, to avoid
950	       the churn related to transient route invalidation in the RPL
951	       network.

[minor] s/The 6LN SHOULD send...transient route invalidation in the
RPL network./To avoid churn related to transient route invalidation,
the 6LN SHOULD send the NS(EARO) to maintain the registration active
(i.e., with a non-zero Registration Lifetime).


...
984	9.2.2.  Perspective of the 6LR Acting as Border Router
...
1014	   If there is no suggested RPL Instance or else if the 6LR does not
1015	   participate to the suggested Instance, it is expected that the
1016	   packets coming from the 6LN "can unambiguously be associated to at
1017	   least one RPL Instance" [RFC6550] by the 6LR.

[major] Is the intent that this paragraph applies to both the RPL
Instance in the EARO and in the RPI??  I ask because it says that the
6LR can ignore the Instance.  I have an issue with it because the text
in rfc6550 says this (from §5: RPL Instance):

   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.

   Control and data packets within RPL network are tagged to
   unambiguously identify of which RPL Instance they are a part.

This second paragraph is specific in saying that if the RPL Instance
is included in a control/data packet, then that is the unambiguous
identifier.


(1) If we're talking about the Instance in the EARO: This may be a
stretch, but I can see the argument about ND not being a RPL control
packet -- thus not covered by rfc6550.  I can of course see the other
side too: signaling RPL information in a control packet makes the text
applicable.  ??


(2) OTOH, if we're talking about the Instance in the RPI, that is in
conflict with rfc6550 (§11.2.2.1):

   If any node cannot forward a packet along the DODAG associated with
   the RPLInstanceID, then the node SHOULD discard the packet and send
   an ICMP error message.

The text only recommends discarding -- is this case (RPI from a RUL) a
valid reason to not discard?  If that is the case, then something
still needs to be done about the RPI...maybe remove or modify it.  I
looked at UseofRPLInfo but all the cases assume that the RUL doesn't
attach the RPI.  Should that document cover the RUL sending an RPI?



...
1141	   The 6LR may at any time send a unicast asynchronous NA(EARO) with the
1142	   R Flag reset to signal that it stops providing routing services, and/
1143	   or with the EARO Status 2 "Neighbor Cache full" to signal that it
1144	   removes the NCE.  It may also send a final RA, unicast or multicast,
1145	   with a Router Lifetime field of zero, to signal that it stops serving
1146	   as Router, as specified in section 6.2.5 of [RFC4861].  This may
1147	   happen upon a DCO or a DAO-ACK message indicating the path is already
1148	   removed; else the 6LR SHOULD remove the Host route to the 6LN using a
1149	   DAO message with a Path Lifetime of zero.

[major] There are other places where the 6LR has to remove the route,
but this is the only one with a SHOULD.  Why?  Is there a reason why
removal is not required here?  Note that the text says "else...", so
if we got to this point I would assume the the 6LR is required to
remove the route.


...
1216	10.  Protocol Operations for Multicast Addresses

1218	   Section 12 of [RFC6550] details the RPL support for multicast flows.
1219	   This support is not source-specific and only operates as an extension
1220	   to the Storing Mode of Operation for unicast packets.  Note that it
1221	   is the RPL model that the multicast packet is passed as a Layer-2
1222	   unicast to each of the interested children.  This remains true when
1223	   forwarding between the 6LR and the listener 6LN.

[major] Is this functionality mandatory or optional?  Should the 6LR
have an option to not "translate" the MLD reports into DAOs?

[major] The description here provides the details that §12/rfc6550
didn't; do you expect this to be a formal Update to rfc6550, or just
an extension for nodes supporting this specification?  Either way, at
least point at this section from §6.


1225	   "Multicast Listener Discovery Version 2 (MLDv2) for IPv6" [RFC3810]
1226	   provide an interface for a listener to register to multicast flows.
1227	   In the MLD model, the Router is a "querier", and the Host is a
1228	   multicast listener that registers to the querier to obtain copies of
1229	   the particular flows it is interested in.

[nit] s/provide an interface/provides an interface


...
1252	   Upon a DAO with a Target option for a multicast address, the RPL Root
1253	   checks if it is already registered as a listener for that address,
1254	   and if not, it performs its own unsolicited Report for the multicast
1255	   address as sescribed in section 5.1 of [RFC3810].  The report is
1256	   source independent, so there is no Source Address listed.

[nit] s/sescribed/described

[minor] MLDv2 includes source addresses in the Reports, but that can't
be "translated" into RPL.  What are the downsides?  I'm thinking that
a RUL can try to subscribe to a specific (S,G), but will get (*,G)
instead; if the traffic level is too high then it could overwhelm the
RUL, and even cause other issues in the rest of the LLN: potentially
high link utilization, waste of energy, etc..   It may be nice to
mention it.



1258	      6LN/RUL                6LR             Root                   6LBR
1259	         |                    |               |                       |
1260	         | unsolicited Report |               |                       |
1261	         |------------------->|               |                       |
1262	         |     <L2 ack>       |               |                       |

[minor] Please remove the "<L2 ack>".


...
1321	11.  Security Considerations
...
1368	   The Opaque field in the EARO enables the RUL to suggest a
1369	   RPLInstanceID where its traffic is placed.  This opens to attacks
1370	   where a RPL instance would be reserved for critical traffic, e.g.,
1371	   with a specific bandwidth reservation, that the additional traffic
1372	   generated by a rogue may disrupt.  This may be alleviated by
1373	   traditional access control mechanisms where the 6LR shapes the
1374	   incoming traffic from the 6LN.

[minor] "The Opaque field in the EARO enables..."  True, but it is
worst than that: the RUL can also build an RPI with the RPL Instance
in it.

And there's a combination: put one value in the Opaque field for
"normal" traffic and use the RPI for other traffic.  This would make
management of the system even harder when trying to trace where the
traffic went: the 6LN expects to put the traffic in the RPL Instance
indicated by the Opaque field, but the RPI says something else.  I
imagine this is possible.

Traffic shaping may help reduce the impact (assuming a certain amount
of traffic), but there may be actions the rogue node could take with a
relatively low number of packets.  IOW, I don't think that shaping
should be the only suggestion; we should include blocking as well.


...
1382	   [EFFICIENT-NPDAO] introduces the ability for a rogue common ancestor
1383	   node to invalidate a route on behalf of the target node.  In that
1384	   case, the RPL Status in the DCO has the 'A' flag not set, and a
1385	   NA(EARO) is returned to the 6LN with the R flag not set.  This
1386	   encourages the 6LN to try another 6LR.  If a 6LR exists that does not
1387	   use the rogue common ancestor, then the 6LN will eventually succeed
1388	   gaining reachability over the RPL network in spite of the rogue node.

[minor] s/In that case/In this case



...
1398	12.2.  Resizing the ARO Status values
...
1405	   IANA is requested modify the Address Registration Option Status
1406	   Values Registry so that the upper bound of the unassigned values is
1407	   63.  This document should be added as a reference.  The registration
1408	   procedure does not change.

[nit] s/requested modify/requested to modify


1410	12.3.  New DODAG Configuration Option Flag

1412	   This specification updates the Registry that was created for
1413	   [RFC6550] as the registry for "DODAG Configuration Option Flags" and
1414	   updated as the registry for "DODAG Configuration Option Flags for MOP
1415	   0..6" by [USEofRPLinfo], by allocating one new Flag as follows:

[major] NEW>
   IANA is requested to assign a flag from the "DODAG Configuration Option
   Flags for MOP 0..6" [USEofRPLinfo] registry as follows:



...
1425	12.4.  RPL Target Option Registry

1427	   Section 20.15 of [RFC6550] creates a Registry for the 8-bit "RPL
1428	   Target Option Flags" field.  IANA is requested to reduce the size of
1429	   the field in the Registry to 4 bits.  Section 6.1 also defines a new
1430	   entry in the Registry as follows:

[major] NEW>

   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 6.1) and should point to this document as an additional
   reference. The registration procedure doesn't change.

   Section 6.1 also defines a new entry in the Registry as follows: