Early Review of draft-ietf-6lo-rfc6775-update-11

Request Review of draft-ietf-6lo-rfc6775-update
Requested rev. 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
Other Reviews 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 Lonvick (diff)
Genart Telechat review of -14 by Peter Yee (diff)
Rtgdir Telechat review of -13 by Adrian Farrel (diff)
Genart Telechat review of -16 by Peter Yee (diff)
Secdir Telechat review of -16 by Chris Lonvick (diff)
Review State Completed
Reviewer Tim Chown
Review review-ietf-6lo-rfc6775-update-11-intdir-early-chown-2018-02-16
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/meE70bKqe7RIK3pHXQWsXz8w5g4
Reviewed rev. 11 (document currently at 21)
Review result Almost Ready
Draft last updated 2018-02-16
Review completed: 2018-02-16



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:

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

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

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?

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?

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

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?

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?

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

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?

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

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

The registration lifetime is in minutes; why not in seconds?  

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.

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.

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.

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

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?

What trust model?

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

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

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

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


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

Section 2 last para - "their" rather than "his"

"provides new" -> "provide new"

"route-over mesh" - add to definitions section

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

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

"removes silently" -> "silently removes"
"LLNs meshes" -> "LLN meshes"

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

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

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

Do you mean "sequence"?
"serves" -> "serves the"

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