Re: [6tisch] Alissa Cooper's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

Hi Michael,

> On Feb 20, 2020, at 1:34 PM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Alissa Cooper via Datatracker <[e-mail]> wrote:
>> == Section 2 ==
> 
>> "If this field is not present, then IID is derived from the layer-2
>> address of the sender as per SLAAC ({?RFC4662})."
> 
>> RFC 8064 recommends that the default IID generation scheme for use with
>> SLAAC is not to use the layer-2 address, but to use the mechanism
>> specified in RFC 7217. Is there a reason this specification is making a
>> different recommendation?
> 
> Yes.
> We have this conversation pretty much every single time that 802.15.4 is discussed.

I’m a human being and I forget things. Forgive me.

Alissa


> 
> 1) 6lowpan compression depends upon the layer-3 address being derived from
>   the layer-2 address so that the usless bytes are not transmitted every
>   single time.
> 
> 2) however, 802.15.4 beacons are always sent using the 64-bit EUI64 L2 source
>   addresses.  The device does not have to use IEEE OUI assigned addresses,
>   but could use IEEE randomized MAC addresses if the firmware decides to do
>   this.
> 
> 3) 802.15.4 prefers to use assign 2-byte short addresses (and to derive the
>   L3 address from that short-address).
>   The recently approved 6tisch-minimal-security CoJP protocol includes
>   assignment of 2-byte address using a central process.  As such, during
>   normal operation neither the L2 and L3 addresses have manufacturer
>   specific OUI content.
> 
> I believe that other documents have said this already, so I don't think there
> needs to be any further repeating.  Let me know if you feel differently.
> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
> 
>> == Section 1.3 ==
> 
>> This sentence is not comprehensible:
> 
>> "Although However, even in this case, a unicast RS may be transmitted
>> in response[RFC6775] reduces the amount of multicast necessary to do
>> address resolution via Neighbor Solicitation (NS) messages, it still
>> requires multicast of either RAs or RS."
> 
>> == Section 2 ==
> 
>> s/({?RFC4662})/[RFC4862]
> 
> both already fixed.
> 
>> == Section 4 ==
> 
>> A network doesn't have privacy considerations. The draft might want to
>> discuss how this specification reveals information about network
>> topology, but that isn't a privacy consideration.
> 
> I think that every single draft should have privacy considerations.
> If you have a LLN as part of your household automation, then being able to
> map the extent of the LLN reveals which parts of the building belong to you.
> 
> If I had a house with many pieces (parking spot, storage in the basement,
> etc) and I had active nodes in those places, I would want to consider whether
> or not I want to use the same subnet (with backbone), or whether I'd want to
> split things up.
> 
>> DODAGID needs to be expanded on first use and needs a citation to be
>> provided.
> 
> DODAG was previously expanded. DODAG expands to DODAG-Identity.
> I will cite RFC6550 here.
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
>