Re: [6lo] I-D Action: draft-ietf-6lo-rfc6775-update-04.txt

[Samita Chakrabarti <[e-mail]>]

Hi Pascal:

Thanks a lot for leading the RFC 6775 update work which has been necessary
as the time goes by and deployment/implementations bring new requirements
or change the specifications. Your lead and editorship of this work is
really appreciated.

I have gone through version 04 of the draft. Wearing both hats of co-chair
and co-author, here are my review comments for the draft. First part of
comment is on more administrative level and should not affect the progress
of this draft and the second part of the comment is editorial and missing
components which can be addressed before we forward to the next step.

Best regards,
-Samita

Draft version : draft-ietf-6lo-rfc6775-update-04


Comments from IETF98:

1) Is this draft targeting a generic update to RFC 6775 or is it a special
usecase?


Goal of rfc6775-bis should be to 'update RFC 6775'  to address the
following:

Generic extension:
* Support the indication of mobility vs retry (T-bit)

* Ease up requirement of registration for link-local addresses

* Introducting Enhanced ARO

* Permitting regitration of target address

* Clarification of support of privacy and temporary addresses
==

Conclusion:  This draft is going to update RFC 6775. Question for Gabe and
me to take up to Suresh
and WG:
Whether we need a master draft (to replace RFC 6775) which will point to
multiple drafts.

------------------------------------------------------------------------------------------

Editorial comments:  [ Mostly generalizing the enhancement for 6lowpan; in
the process
it is useful to RPL and BBR etc. as special case examples]

Abstract:

Current:
  This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to
   clarify the role of the protocol as a registration technique,
   simplify the registration operation in 6LoWPAN routers, and provide
   enhancements to the registration capabilities, in particular for the
   registration to a Backbone Router for proxy ND operations.

Suggested:
   This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to
   clarify the role of the protocol as a registration technique,
   simplify the registration operation in 6LoWPAN routers, and provide
   enhancements to the registration capabilities for different network
   configuration as well as mobility detection within a Low Power Network.


   Introduction:

2nd paragraph onwards...

CURRENT:
   The scope of this draft is an IPv6 LLN, which can be a simple star or
   a more complex mesh topology.  The LLN may be anchored at an IPv6
   Backbone Router (6BBR) [I-D.ietf-6lo-backbone-router].  The 6BBRs
   interconnect the LLNs over a Backbone Link and emulate that the LLN
   nodes are present on the Backbone using proxy-ND operations.

   This specification modifies and extends the behavior and protocol
   elements of RFC 6775 [RFC6775] to enable additional capabilities, in
   particular the registration to a 6BBR for proxy ND operations.

Suggested:
   The scope of this draft is an IPv6 Low Power Networks including
   star and mesh topologies.  This specification modifies and extends
   the behavior and protocol elements of RFC 6775 [RFC6775] to enable
   additional capabilities such as:

   * Support the indication of mobility vs retry (T-bit)

   * Ease up requirement of registration for link-local addresses

   * Introducing Enhancement to  Address Registration Option (ARO)

   * Permitting regitration of target address

   * Clarification of support of privacy and temporary addresses

   The following sections will discuss applicability of 6LoWPAN ND
registration,
   new extensions and updates to RFC 6775. Finally, we will discuss how the
   extensions of registration framework can be useful for a use case
scenario.



Section 2:

The naming of this section seems out-of-sequence right after the
introduction. Let us
change the title to fit it in this place.
 a) s/Considerations On Registration Rejection/Applicability of Address
Registration options/

 b)
CURRENT( 1st paragraph):
   The purpose of the Address Registration Option (ARO) RFC 6775
   [RFC6775] and of the Extended ARO (EARO) that is introduced in this
   document is to facilitate duplicate address detection (DAD) for hosts
   and pre-populate Neighbor Cache Entries (NCE) [RFC4861] in the
   routers to reduce the need for sending multicast neighbor
   solicitations and also to be able to support IPv6 Backbone Routers.

SUGGESTED (1st paragraph):

  The purpose of the Address Registration Option (ARO) RFC 6775
   [RFC6775] is to facilitate duplicate address detection (DAD) for hosts
   and pre-populate Neighbor Cache Entries (NCE) [RFC4861] in the
   routers  in order to reduce the need for sending multicast neighbor
   solicitations which is harmful for low-power constrained networks.


Section 3:
Termnology:
 a) Please copy the terminology from RFC 6775
 b) Remove 6tisch reference from terminology section [ This document should
work with
 any 6lo L2 including 6tisch]
 c) BBR and Backbone network terminologies are OK
 d) Add proxy ND defininition


Section 4:

'Extending RFC 7400' seems out-of-context here.

Q1 : Should extension of RFC 7400 belong in this document?
Q2:  If Q1 is yes, then move this section after section 7. POssibly provide
a diagram to
     show the format change


Section 5:
   a) Clarify T-bit usage a bit on detection of mobility. This is going to
be very useful
      feature in general for other link-layers too. Please describe it
without giving a
      specific scenario.  Mobility detection is missing in RFC 6775.


Section 5.2:
    a) Please remove all reference of RPL in this section. One does not
need to understand RPL
       mechanism or deploy RPL mechanism in order to use T-bit in
6LOWPAN-ND.
       Please describe usage of T-bit in context of 6lo networks in
general. I understand that
       we want to introduce it in RFC 6775 in order to detect mobility of
the 6LN as opposed to
       retrying.

Section 5.5 : s/Link-Local Address Registration/Link-Local Address
Registration Change/

     a) Please shrink the texts in this section and provide a gist of
change in either
         first or 2nd paragraph. Please try to reduce the texts into 4-5
paragraphs.

Section 5.6:
        Remove reference for RPL networks (RFC 6550) please. This draft
does not/should not
        depend on one particular routing protocol or configuration


Section 7:
       Backward Compatibility:

       a) Please move up the 7.2 -7.4 ( all legacy nodes behavior)  in the
begining of the section.
       b) Current 7.1 section should follow after the legacy behavior
       c) Please add some text about backward compatibility of legacy nodes
(6LN,6LR and 6LBR in
          any combination) right below section 7.
          Q: How does EARO modification, target address registration and
link-local registration change
              ensure that they are transparent to a legacy 6LBR or legacy
6LR or legacy 6LN ?
       d) It is best to organize section 7 with two main sub-headings and
then insert the appropriate
           sub sub-headings underneath. The suggested two sub headings
could be:
                  7.1  Legacy nodes behavior due to changes in this draft
                  7.2  Backward compatibility with legacy devices


**  Change in 6CIO format
    Please Add RFC 7400 related changes section here. I'd actually prefer a
meaningful heading on RFC 7400
    changes rather than " Extending RFC7400"

** Privacy
   Please add a section on 'Privacy Considerations' for 6LoWPAN address
configuration. We can take a look
   at 6loBAC document or RFC 7668 and RFC 8105 and Privacy consideration
RFC 8065 to form a text
   to provide guidance on privacy compliant and temporary address formation
pros and cons here.
   We should use a short parapgraph and point to the relevnt sections of
relevant documents here.



Section 8: Security Connsiderations:

   "As indicated in section Section 2, this protocol does not aim at
   limiting the number of IPv6 addresses that a device can form, either.
   A host should be able to register any address that is topologically
   correct in the subnet(s) advertised by the 6LR/6LBR."

==> Should this document add a one line that the implmentation may consider
    limiting registration requests by using different techniques.

   On the other hand, the registration mechanism may be used by a rogue
   node to attack the 6LR or the 6LBR with a Denial-of-Service attack
   against the registry.  It may also happen that the registry of a 6LR
   or a 6LBR is saturated and cannot take any more registration, which
   effectively denies the requesting a node the capability to use a new
   address.  In order to alleviate those concerns, Section 5.6 provides
   a number of recommendations that ensure that a stale registration is
   removed as soon as possible from the 6LR and 6LBR.

===> Does the recommendation in 5.6 alleviate the DOS attack in 6LR and
6LBR?
     The above paragraph is scary. If 5.6 recommendations are useful against
     DOS attack, we must have stronger statement in security.

     Let us revisit the security section and see if we can make it less
vulnerable.


*** Add a section " Example scenario of EARO":
      Here, a section can be added to point to the BBR scenario and proxy
ND operation.
       The text should be only a flavor to provide ideas [ < 10 lines or so
]


On Mon, May 1, 2017 at 11:45 PM, <[e-mail]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over Networks of
> Resource-constrained Nodes of the IETF.
>
>         Title           : An Update to 6LoWPAN ND
>         Authors         : Pascal Thubert
>                           Erik Nordmark
>                           Samita Chakrabarti
>         Filename        : draft-ietf-6lo-rfc6775-update-04.txt
>         Pages           : 29
>         Date            : 2017-05-01
>
> Abstract:
>    This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to
>    clarify the role of the protocol as a registration technique,
>    simplify the registration operation in 6LoWPAN routers, and provide
>    enhancements to the registration capabilities, in particular for the
>    registration to a Backbone Router for proxy ND operations.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-04
> https://datatracker.ietf.org/doc/html/draft-ietf-6lo-rfc6775-update-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-rfc6775-update-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
>