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, <internet-dra...@ietf.org> 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 > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo >
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo