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, <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/6lo
>
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
