Re: [Int-dir] [6lo] Intdir early review of draft-ietf-6lo-rfc6775-update-11

["Pascal Thubert (pthubert)" <[e-mail]>]

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:[e-mail]] 
Sent: mardi 20 février 2018 12:33
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
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) <[e-mail]> 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:[e-mail]] On Behalf Of Tim Chown
> Sent: vendredi 16 février 2018 20:03
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
> 
> _______________________________________________
> Int-dir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-dir
>