> On 20 Feb 2018, at 14:34, Pascal Thubert (pthubert) <[email protected]> > wrote: > > Hello Tim > > Thanks a bunch again. I think we are all set now, and I will publish the > result as -12.
Great! > 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? TC> Either works for me. > ******************** > > >> 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. TC> Then perhaps just say that when compression is not critical to have, then RFC 8064 should be followed, which recommends use of RFC 7217. >> ********************** > >> >> 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. No problem. Best wishes, Tim > > >> 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 >> > > _______________________________________________ > 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
