Skip to main content

Early Review of draft-ietf-6lo-rfc6775-update-11
review-ietf-6lo-rfc6775-update-11-intdir-early-chown-2018-02-16-00

Request Review of draft-ietf-6lo-rfc6775-update
Requested revision No specific revision (document currently at 21)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2018-02-16
Requested 2018-01-31
Requested by Suresh Krishnan
Authors Pascal Thubert , Erik Nordmark , Samita Chakrabarti , Charles E. Perkins
I-D last updated 2018-02-16
Completed reviews Intdir Early review of -11 by Tim Chown (diff)
Iotdir Early review of -11 by Dave Thaler (diff)
Opsdir Telechat review of -11 by Jürgen Schönwälder (diff)
Secdir Telechat review of -11 by Chris M. Lonvick (diff)
Genart Telechat review of -14 by Peter E. Yee (diff)
Rtgdir Telechat review of -13 by Adrian Farrel (diff)
Genart Telechat review of -16 by Peter E. Yee (diff)
Secdir Telechat review of -16 by Chris M. Lonvick (diff)
Assignment Reviewer Tim Chown
State Completed
Request Early review on draft-ietf-6lo-rfc6775-update by Internet Area Directorate Assigned
Reviewed revision 11 (document currently at 21)
Result Almost ready
Completed 2018-02-16
review-ietf-6lo-rfc6775-update-11-intdir-early-chown-2018-02-16-00
Hi,

I have performed an early review of draft-ietf-6lo-rfc6775-update-11.

This draft updates and enhances the mechanisms defined in RFC6775 to support
IPv6 operation over low power networks (6LoWPAN ND).

Overall the draft is well-written and structured.

General comments:
--------------------------------------

The document could use a glossary of terms: LLN, 6LN, 6LBR, 6LR, BBR, etc.

The introduction could talk of other new added features, like avoiding DAD for
link locals.

The document includes RFC 7217 in the references, but doesn't include
discussion of it in the main body of the text.  Shouldn't RFC 7217 be
considered the norm here rather than address generation as per RFC 4862? 
Related, RFC 8064 "recommends against embedding stable link-layer addresses in
IPv6 Interface Identifiers".  The document is inconsistent - it talks of using
EUI64, then in Section 9 not using EUI64.

Specific comments:
--------------------------------------

p.3
Section 2, para 2 - should ND cache exhaustion attacks be included in the list
here?

p.4
Section 3 - Add RFC 7217 to RFC 4862?  It's recommended by RFC 8064.

p.6
Section 4 - for a node to prefer registering to a 6LR that supports the spec,
it would need to enumerate all available 6LRs; should the process for this be
described here, or is it included in sufficient detail in RFC 6775?

p.7
Section 4.1 - "not required to be a MAC address" - as per my general comment
above, with current IETF thinking, should this not be stronger, e.g. "SHOULD
NOT be a MAC address"?  Section 9 says this?

p.9
Section 4.2, point 4 - I find this quite para quite hard to read.

p.9
Section 4.3, para 1 - again, is using EUI-64 desirable?  Is the point to allow
header compression as per RFC4944?  Discuss the tradeoff? Section 4.3 para 2 -
so a different type of identifier could be an RFC 7217 generated identifier?

p.11
Section 4.6 - in the case of two 6LRs with the same link-layer addresses, does
it matter which a 6LN chooses?  Is the choice algorithmic? Section 4.6 - the
last para on p.11 seems to be repeated in the first para on p.12?

p.12
Section 4.6 - again, is the recommendation to use an (expected to be) unique LL
address in keeping with RFC 8064?

p.13
Para 4 - a Moved message SHOULD be used, yet elsewhere a node MUST clean up its
stale state?  Consistent? What about MIPv6-like spoofing security issues? You
say "an alternate protocol" - isn't this a little hand-wavy; shouldn't a single
mechanism be defined rather than multiple (undefined) mechanisms?

p.15
OUI is a confusing choice of term, given OUIs in MAC addresses; I guess this is
now baked into RFC 6775 though.

p.16
I don't think codes 5 and 10 are explained/defined in any detail here?  How is
the challenge made?

p.16
The registration lifetime is in minutes; why not in seconds?

p.18
Section 6.3 - SHOULD set the E flag; why not a MUST?  Why would you support the
spec, but not advertise that you do?  In contrast, on the next page in Section
7.1.1 you say nodes MUST set it.

p.19
Section 7.1.2 para 2 - would a LL address generally be used here as source? 
Should that be a SHOULD?  Using a temporary address is probably not ideal.

p.20
Section 7.3 para 4 - is this consistent with p.19 last para saying a 6LN MUST
use the updated spec once it knows it's supported? The last two paras here are
a bit vague/loose.

p.21
Section 8, para 3 - recommends using privacy techniques, but uses EUI64?

p.22
Limit the number of addresses?  What about RFC 7934?
The type of algorithm described here might be better defined generically for
6LoWPAN and 'real' IPv6?  I don't think anything has been defined for ND cache
exhaustion attack mitigation - would a separate draft be beneficial? I suspect
current solutions are vendor specific?

p.22
What trust model?

p.22
Section 9 - EUI64, or not EUI64?  Inconsistent.
Does anyone really use SeND?  Especially in 6LoWPAN networks?

p.24
Section 10.3 - statuses 5 and 10 are not detailed in the draft?

p.30
The multicast issues text could cite the new mboned draft on this topic.
"Plague" is maybe strong!

p.30
Appendix B - can we have a table showing WHICH requirements have been met by
the draft?

Nits:
--------------------------------------

p.4
Section 2 - "form and use multiple addresses" (add multiple)

p.4
Section 2 last para - "their" rather than "his"

p.6
"provides new" -> "provide new"

p.10
"route-over mesh" - add to definitions section

p.12
First line of last para needs rewriting - "If the registry in the 6LBR is be
saturated, in which case the LBR".

p.13
Could forward reference the summary of error codes in 6.1 or 10.3 here?

p.14
"removes silently" -> "silently removes"
"LLNs meshes" -> "LLN meshes"

p.15
Code 3; change tense to past tense, e.g. "fails" to "failed"

p.19
"capabilities" -> "capabilities is"
"such address" -> "such an address"
"in a" -> "in"
"6LB" -> "6LN" ?

p.21
"amlways" -> "always"
"to using" -> "using"
Missing close bracket for See Section 9.

p.30
Do you mean "sequence"?
"serves" -> "serves the"

p.31
"timely" -> "in a timely fashion" ?
B.1 last req - reword this.
The BIER Architecture is now an RFC I think?