Hello Tim
Thanks a bunch again. I think we are all set now, and I will publish the result
as -12.
Please see below:
>
>> new updated proposed text:
>
> "
> <t> The IPv6 address of the 6LN in the IPv6 header can be compressed
> statelessly Interface Identifier in the IPv6 address can be derived
> from
>TC> Insert "where the" after statelessly?
PT> "when the" in fact, no?
********************
> the Lower Layer address. When it is not critical to benefit from that
> compression, e.g. the address can be compressed statefully, or it is rarely
> used and/or it is used only over one hop, then the best practice of forming
> privacy addresses should be considered:
> </t>
> <t> <xref target="RFC7217">"A Method for Generating Semantically Opaque
> Interface Identifiers with IPv6 Stateless Address Autoconfiguration
> (SLAAC)"
> </xref> is the recommended method for generating Interface Identifiers to
> be used in SLAAC at the time of this writing.
> </t>
>TC> I'd be careful referring to privacy addresses and then implying RFC7217
>gives a privacy address, given a node could have an RFC7217 address and a
>RFC4941 privacy address, or potentially just a privacy address.
PT> Sorry Tim I do not know what action I can take here. This goes probably
beyong the scope of this document, which does not standardize the address
generation anyway.
> **********************
>
> p.22
> What trust model?
>
>> Should I add words? Those networks are always protected at Layer 2. But
>> really, we'd like to see a draft that enables a 6LBR to prove it has that
>> capacity and is entitled to play the role for the network. This is beyond
>> the scope of this particular draft and should be done in a security related
>> 6LoWPAN draft.
TC> OK, perhaps just explicitly state the presence / assumption of L2
protection in the security section.
PT> Added:
" This trust model could be
at a minimum based on a Layer-2 access control, or could provide role
validation as well (see Req5.1 in <xref target="Req5"/>).
"
> **********************
>
>
> p.4
> Section 2 last para - "their" rather than "his"
>
>> sorry I do not see this ? the "his" refers to the network admin.
TC> In more politically correct British English, you'd say "their" as a gender
neutral term, not "his". In the case "their" can be singular.
PT> oh, got you.
> Thanks a bunch again for your deep review Tim!
TC> It was a good read, and very interesting.
Take care,
Pascal
-----Original Message-----
From: Tim Chown [mailto:[email protected]]
Sent: mardi 20 février 2018 12:33
To: Pascal Thubert (pthubert) <[email protected]>
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [Int-dir] [6lo] Intdir early review of
draft-ietf-6lo-rfc6775-update-11
Hi Pascal,
> On 20 Feb 2018, at 10:13, Pascal Thubert (pthubert) <[email protected]>
> wrote:
>
>
> Reviewer: Tim Chown
>
> Thanks a bunch Tim!
>
> I answered with a prefix >
>
> There are specific questions back to you down there. Please feel free to
> remove all Q/As for which we found an agreement already.
>
> General comments:
> --------------------------------------
>
> The document could use a glossary of terms: LLN, 6LN, 6LBR, 6LR, BBR, etc.
>
>> Done in appendix
>
>
> *******************
>
> The introduction could talk of other new added features, like avoiding DAD
> for link locals.
>
>> You'll note that it is not avoided. But it is scoped in the relationship
>> between the 6LN and the 6LR. One 6LR may accept to talk to a 6LN LN_A seen
>> as LLA Addr_A and then later another 6LR may refuse that same Addr_A because
>> from its standpoint Addr_A duplicates a LLA used by another device that is
>> also talking to. The draft does not change what a LLA can be used for in
>> route over, that is one radio hop; mostly, it reduces the illusion that a
>> link local address can be DAD'ed in a network that is not fully and
>> permanently connected.
TC> OK, thanks for the clarification.
>> Added:
> "
> <t> Simplify the registration flow for link-local addresses </t>
> "
> as a clarification instead of:
> "
> <t> Reduce requirement of registration for link-local addresses
> </t> "
TC> OK.
> 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?
>
>> added:
>
> "
> <t> <xref target="RFC7217">"A Method for Generating Semantically Opaque
> Interface Identifiers with IPv6 Stateless Address Autoconfiguration
> (SLAAC)"
> </xref> is the recommended method for generating Interface Identifiers to
> be used in SLAAC at the time of this writing.
> </t>
> "
>
>
> **********************
>
>
>
> 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.
>
>> fact is, a typical IEEE802.15.4-based network will compress the IPv6 address
>> based on the MAC address. But it does not have to be so, and it does not
>> apply to all types of networks.
>
>> new updated proposed text:
>
> "
> <t> The IPv6 address of the 6LN in the IPv6 header can be compressed
> statelessly Interface Identifier in the IPv6 address can be derived
> from
TC> Insert "where the" after statelessly?
> the Lower Layer address. When it is not critical to benefit from that
> compression, e.g. the address can be compressed statefully, or it is rarely
> used and/or it is used only over one hop, then the best practice of forming
> privacy addresses should be considered:
> </t>
> <t> <xref target="RFC7217">"A Method for Generating Semantically Opaque
> Interface Identifiers with IPv6 Stateless Address Autoconfiguration
> (SLAAC)"
> </xref> is the recommended method for generating Interface Identifiers to
> be used in SLAAC at the time of this writing.
> </t>
TC> I'd be careful referring to privacy addresses and then implying RFC7217
gives a privacy address, given a node could have an RFC7217 address and a
RFC4941 privacy address, or potentially just a privacy address.
> "
> this is followed by existing text:
> "
> <t>
> <xref target="RFC8065">
> "Privacy Considerations for IPv6 Adaptation-Layer Mechanisms"</xref>
> explains why privacy is important and how to form such addresses. All
> implementations and deployment must consider the option of privacy
> addresses in their own environment. Also future specifications
> involving 6LoWPAN Neighbor Discovery should consult
> <xref target="RFC8064">
> "Recommendation on Stable IPv6 Interface Identifiers"</xref>
> for default interface identification.
> </t>
> "
>
>
>
>
> **********************
>
>
>
>
>
> Specific comments:
> --------------------------------------
>
> p.3
> Section 2, para 2 - should ND cache exhaustion attacks be included in the
> list here?
>
>> If the method is used as a full replacement of reactive ND, then there can
>> be some control. e.g. we'd be immune from NCE DOS attack from a remote
>> party. But it's a touchy space. In the one hand, we never block from using
>> both, IOW classical (reactive) ND in conjunction with the new (proactive)
>> registration. Also a local node could still attack the cache by performing
>> tons of registrations, forging MAC addresses as it goes if need be. It will
>> take separate work to address all the security requirements (AP-ND
>> https://tools.ietf.org/html/draft-ietf-6lo-ap-nd and more).
TC> OK, so leave as is.
>
> **********************
>
>
>
> p.4
> Section 3 - Add RFC 7217 to RFC 4862? It's recommended by RFC 8064.
>
>> This is a terminology section. Are there terms we need from RFC 7217? Note
>> that this specification does not dictate how to form address, just manages
>> them. Still it places recommendation to the protocol developers coming next
>> (e.g. for a particular link layer) to consider privacy. Text related to RFC
>> 7217 is added in section 9 per your other comment.
TC> OK, leave as is then.
>
>
> **********************
>
>
>
> 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?
>
>> You are correct. There is no enumeration process; 6LRs are discovered as
>> described in RFC 6775 sections 5.2 and 5.3. by sending out mcast RS. This
>> document updates RFC 6775 but we avoided paraphrasing it as much as we
>> could, considering that this doc is already quite thick.
> Still I added the first line of the text below:
> "
> <t> Section 5 of <xref target="RFC6775"/> specifies how a 6LN bootstraps an
> interface and locates available 6LRs; a Registering Node SHOULD prefer
> registering to a 6LR that is found to support this specification, as
> discussed in <xref target="dsc"/>, over a legacy one.
> </t>
TC> OK.
> "
>
>
> **********************
>
>
>
>
> 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?
>
>> I see where you're coming from and htat makes sense to me. But the WG never
>> went that far. Note that this is not a subfield in an address; as it goes
>> the message is not not supposed to leak outside. RFC 6775 forced the UID to
>> be a MAC address in the EUI-64 form. This specification does not deprecate
>> the legacy behavior and it allows for something else. But it recommends
>> (section 8) to use a privacy technique such as AP-ND instead. Once AP-ND is
>> standard, we can deprecate the legacy behavior if the WG finds it relevant,
>> e.g. when we apply it to networks that are more sensitive to privacy.
TC> OK, thanks for explaining it; that sounds reasonable. I suspect this point
will come up again in IESG review though!
>
>
>
> **********************
>
>
>
>
> p.9
> Section 4.2, point 4 - I find this quite para quite hard to read.
>
>> Agreed, it is inlined from RFC 6550 as opposed to referenced per WG and
>> shepherd decision. I simplified to:
> "
> If two sequence numbers are determined to be not comparable,
> i.e. the results of the comparison are not defined, then a node
> should give precedence to the sequence number that was most
> recently
> incremented. Failing this, the node should select the sequence number
> in order to minimize the resulting changes to its own state.
>
> "
TC> OK.
>
>
> **********************
>
>
>
> 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?
>
>> It could be many things but collisions should be avoided. It should not be
>> an interface ID since this is to complement the DAD of the IID. AP-ND builds
>> it on cryptography. Your point is excellent, unsure if this doc should be
>> the vessel for it. At this stage, we never argued deprecation before, just
>> extension. It will take WG work to define possible replacements and this doc
>> may be too advanced for that I guess, but I'll ask.
TC> OK.
>
>
>
> **********************
>
>
>
> 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?
>
>> This specification (including RFC 6775) does not have a router preference
>> (whether they have a same or different LLA) beyond RFC 4191. RPL does, based
>> on Rank and the upcoming enrollment specification will also hint on that.
>> And apparently yes to your other point, cleaning up.
TC> OK.
>
> **********************
>
>
>
> p.12
> Section 4.6 - again, is the recommendation to use an (expected to be) unique
> LL address in keeping with RFC 8064?
>
>> There is a chicken and an egg problem with the first registration of the
>> first LLA. It is better that it does not fail. RFC6775 stipulates that
>> MAC-derived LLA do not need DAD. This message flies over one hop, between a
>> node and its nearby router. The node may then form as many privacy LL and
>> GUA as it likes.
TC> OK.
>
>
> **********************
>
>
>
> 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?
>
>> Agreed. That single mechanism is DAR/DAC. I removed the "an alternate
>> protocol"; what was meant is now separately drafted in
>> draft-thubert-roll-unaware-leaves. This is where using RPL to proxy the
>> registration is described. Unsure about which MIP attack you have in mind?
TC> Never mind; I saw other AP-ND comments that clarified it.
>
>
> **********************
>
>
>
>
> p.15
> OUI is a confusing choice of term, given OUIs in MAC addresses; I guess this
> is now baked into RFC 6775 though.
>
>> Actually no. RFC 6775 uses EUI-64 throughout. We picked that term to
>> generalize the EUI-64, so I guess we can still change that name. I changed
>> it to Registration Unique ID (RUID) but that does not sound so right; would
>> you have suggestions?
>> I'll take that question to the WG separately.
TC> I saw that, thanks. I don't have a specific suggestion, just that OUI has a
very well known application elsewhere.
> **********************
>
>
>
> p.16
> I don't think codes 5 and 10 are explained/defined in any detail here? How
> is the challenge made?
>
>> This is used in a freference spec. I clarified that by adding 3 lines at the
>> end of the text in the RUID (ex OUID) section which now reads:
>
> " The Registration Unique ID in <xref target="RFC6775"/>
> is a EUI-64 globally unique address configured at a Lower Layer,
> under the assumption that duplicate EUI-64 addresses are avoided.
> With this specification, the Registration Unique ID is allowed to be
> extended to different types of identifier, as long as the type is clearly
> indicated. For instance, the type can be a cryptographic string and
> used to prove the ownership of the registration as discussed in
> <xref target="I-D.ietf-6lo-ap-nd">
> "Address Protected Neighbor Discovery for Low-power and Lossy Networks"
> </xref>. In order to support the flows related to the proof of
> ownership,
> this specification introduces new status codes "Validation Requested" and
> "Validation Failed" in the EARO.
TC> OK.
>
>
> **********************
>
>
>
> p.16
> The registration lifetime is in minutes; why not in seconds?
>
>> RFC 6775 is missing a way to express the time unit (RPL has one).
> We used minutes because a typical LLN operates at a very slow pace, and a
> typical device is like a three-toed sloth that would sleep more than a cat.
> We even had a requirement to produce an 'infinite' lifetime for the likes of
> light bulbs but never took it that slow. We could change the format but that
> would not be backward compatible.
>> I'll take that question to the WG separately
TC> :)
> **********************
>
>
>
> 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.
>
>> fixed, it was a MUST :)
TC> OK.
> **********************
>
>
>
> 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.
>
>> RFC 6775 used the registered address (LL or GUA) as source and the target
>> was not really important. With this specification, register the target of
>> the NS, and there is no point remembering the source address of the
>> registration NS after the NA was sent back. A 6LR can talk to the registered
>> address using the registered address.
TC> OK.
>
> **********************
>
>
>
> 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.
>
>> I turned the text into:
>
> " After detecting a legacy 6LR, an updated 6LN SHOULD attempt to find
> an
> alternate 6LR that is updated for a reasonable time that depends on
> the
> type of device and the expected deployment.
> "
TC> OK.
> **********************
>
>
>
> p.21
> Section 8, para 3 - recommends using privacy techniques, but uses EUI64?
>
>> RFC 6775 uses EUI. AP-ND uses a cryptographically generated token instead.
>> This section effectively recommends AP-ND or whatever else cmes next that
>> has privacy concerns.
TC> OK.
>
>
> **********************
>
>
>
> 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?
>
>> We applied wisdom from RFC9734 and removed text that indicated that an
>> administrator could be on the path of accepting an address or not. I know
>> for having coded it that yes, (at least some) vendors provide a protection
>> in the number of addresses that can be registered or snooped from a given
>> device wen there is a limit for the overall resources to serve the network.
>> A classical NCE is a cache but a 6LR NCE is really a hard state that the
>> registrar guarantees to maintain for a given lifetime. The fact that a
>> protection can be configured does not force a user in a particular
>> deployment to use that protection. I agree that there is a need for NCE
>> attack mitigation for both classical ND and 6LoWPAN ND. But till that spec
>> exists, we cannot force the 6LR device to drop all protection against a
>> misbehaving 6LN. A 6LR is an IOT device and it might easily be pushed beyond
>> capacity.
TC> OK. It might be something to raise in 6man, to see if there's interest in
documenting algorithm(s).
> **********************
>
>
>
> p.22
> What trust model?
>
>> Should I add words? Those networks are always protected at Layer 2. But
>> really, we'd like to see a draft that enables a 6LBR to prove it has that
>> capacity and is entitled to play the role for the network. This is beyond
>> the scope of this particular draft and should be done in a security related
>> 6LoWPAN draft.
TC> OK, perhaps just explicitly state the presence / assumption of L2
protection in the security section.
> **********************
>
>
>
> p.22
> Section 9 - EUI64, or not EUI64? Inconsistent.
> Does anyone really use SeND? Especially in 6LoWPAN networks?
>
>> There are 2 uses of EUI that must be differentiated. The OUID (now RUID) is
>> a unique ID for the device to correlate registrations for DAD between honest
>> people. This section ere talks about IID in the IPv6 address. The text
>> explains that no, SEND cannot be used in that space. This is why we do AP-ND
>> instead. With AP-ND, the OUID is used to prove cryptographically the
>> ownership of the registered address a bit like CGA does, but it is not part
>> of the address. It is stored upon the first registration f an address and
>> used later to validate that the new registration comes from the same guy.
TC> Aaah, right, thanks.
> **********************
>
>
>
> p.24
> Section 10.3 - statuses 5 and 10 are not detailed in the draft?
>
>> Added text upon your point earlier
TC> OK.
> **********************
>
>
>
> p.30
> The multicast issues text could cite the new mboned draft on this topic.
> "Plague" is maybe strong!
>
>> done the ref. Added draft-perkins as well. replaced "plague" with "affect
>> the operation of"
TC> OK.
> **********************
>
>
>
> p.30
> Appendix B - can we have a table showing WHICH requirements have been met by
> the draft?
>
>> added
>
> <t>
> Note to RFC Editor: please replace "This" by the RFC number for this
> specification once it is attributed.
> <t>
>
> <texttable anchor="reqadd" title="Addressing requirements">
> <preamble>I-drafts/RFCs addressing requirements</preamble>
> <ttcol align="left"> Requirement</ttcol>
> <ttcol align="left"> Document </ttcol>
>
> <c>Req1.1</c> <c><xref
> target="I-D.ietf-6lo-backbone-router"/></c>
> <c>Req1.2</c> <c><xref target="RFC6775"/></c>
> <c>Req1.3</c> <c><xref target="RFC6775"/></c>
> <c>Req1.4</c> <c>This</c>
>
> <c>Req2.1</c> <c>This</c>
> <c>Req2.2</c> <c>This</c>
> <c>Req2.3</c> <c></c>
>
> <c>Req3.1</c> <c>Technology Dependant</c>
> <c>Req3.2</c> <c>Technology Dependant</c>
> <c>Req3.3</c> <c>Technology Dependant</c>
> <c>Req3.4</c> <c>Technology Dependant</c>
>
> <c>Req4.1</c> <c>This</c>
> <c>Req4.2</c> <c>This</c>
> <c>Req4.3</c> <c><xref target="RFC6775"/></c>
>
> <c>Req5.1</c> <c></c>
> <c>Req5.2</c> <c><xref target="I-D.ietf-6lo-ap-nd"/></c>
> <c>Req5.3</c> <c></c>
> <c>Req5.4</c> <c></c>
> <c>Req5.5</c> <c><xref target="I-D.ietf-6lo-ap-nd"/></c>
> <c>Req5.6</c> <c><xref
> target="I-D.struik-lwip-curve-representations"/></c>
> <c>Req5.7</c> <c><xref target="I-D.ietf-6lo-ap-nd"/></c>
> <c>Req5.8</c> <c> </c>
> <c>Req5.9</c> <c><xref target="I-D.ietf-6lo-ap-nd"/></c>
>
> <c>Req6.1</c> <c>This</c>
> <c>Req6.2</c> <c>This</c>
>
> </texttable> <!-- end table "Addressing requirements" -->
>
>
TC> OK.
> **********************
>
>
>
> Nits:
> --------------------------------------
>
> p.4
> Section 2 - "form and use multiple addresses" (add multiple)
>
>> done
>
>
> **********************
>
>
>
> p.4
> Section 2 last para - "their" rather than "his"
>
>> sorry I do not see this ? the "his" refers to the network admin.
TC> In more politically correct British English, you'd say "their" as a gender
neutral term, not "his". In the case "their" can be singular.
> **********************
>
>
>
> p.6
> "provides new" -> "provide new"
>
>> done
>
> **********************
>
>
>
> p.10
> "route-over mesh" - add to definitions section
>
>> added reference to RFC 6606 in the terminology section
>
>
>
> **********************
>
>
>
> p.12
> First line of last para needs rewriting - "If the registry in the 6LBR is be
> saturated, in which case the LBR".
>
>> I had spoted that one too : ) fixed as
>
> "
> If the registry in the 6LBR is saturated, the
> LBR cannot guarantee that a new address is effectively not a duplicate.
> "
>
>
> **********************
>
>
>
> p.13
> Could forward reference the summary of error codes in 6.1 or 10.3 here?
>
>> done
>
> **********************
>
>
>
> p.14
> "removes silently" -> "silently removes"
> "LLNs meshes" -> "LLN meshes"
>
>> done
>
>
> **********************
>
>
>
> p.15
> Code 3; change tense to past tense, e.g. "fails" to "failed"
>
>> done
>
>
> **********************
>
>
>
> p.19
> "capabilities" -> "capabilities is"
> "such address" -> "such an address"
> "in a" -> "in"
> "6LB" -> "6LN" ?
>
>> done.
>
>
> **********************
>
>
>
> p.21
> "amlways" -> "always"
> "to using" -> "using"
> Missing close bracket for See Section 9.
>
>
>
> **********************
>
>
>
> p.30
> Do you mean "sequence"?
> "serves" -> "serves the"
>
>> changed to
> " This specification extends 6LoWPAN ND to provide a sequence number to
> the
> registration and ...
> "
>
> **********************
>
>
>
>
> p.31
> "timely" -> "in a timely fashion" ?
> B.1 last req - reword this.
> The BIER Architecture is now an RFC I think?
>
>> will fix the reference to RFC 8279
TC> All the nit comments / resolutions are fine.
> Thanks a bunch again for your deep review Tim!
TC> It was a good read, and very interesting.
Best wishes,
Tim
>
> Pascal
>
>
>
> -----Original Message-----
> From: 6lo [mailto:[email protected]] On Behalf Of Tim Chown
> Sent: vendredi 16 février 2018 20:03
> To: [email protected]
> Cc: [email protected]; [email protected]
> Subject: [6lo] Intdir early review of draft-ietf-6lo-rfc6775-update-11
>
> Reviewer: Tim Chown
> Review result: Almost Ready
>
> 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?
>
>
> _______________________________________________
> 6lo mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6lo
>
> _______________________________________________
> Int-dir mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/int-dir
>
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
