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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 2 Mar 2020 08:46:03 +0000

Hello Alissa and Michael

(chair hat on)

Please keep in mind that this draft does not have vocation to update RFC 4944. 6TiSCH does not have that vocation either. If something was needed, it would belong to 6lo. 
Arguably the art of 6LoWPAN allows a node to apply RFC 8064/8065 if it likes. I expect it will become more common as larger MTUs arise. 

Using short addresses and deriving IPv6 addresses from them is how RFC 4944 enabled IPv6 in some environments where it was not applied before (because IPv6 was deemed impossible with a MTU of 127 bytes or below).  IEEE std 802.15.4 short addresses can be renewed, which will cause the IPv6 addresses that are derived from them will change too. If short addresses are chosen pseudo-randomly and renewed periodically, privacy can be improved at the expense of complexity, a trade off that each use case will have to make.

As most of the 6TiSCH standard track work, this draft operates at the interface between IETF and IEEE. A spec that modifies IEEE beacons is probably not the best place to discuss address allocation.
The draft does not make a "recommendation" on which mechanism to use, it  just enables to signal which of the existing mechanisms is used. 

All in all, I believe that the DISCUSS should be removed; point taken to discuss this more at 6lo, though.

Take care,

Pascal

> -----Original Message-----
> From: Michael Richardson <[email-masked]>
> Sent: jeudi 20 février 2020 19:35
> To: Alissa Cooper <[email-masked]>
> Cc: The IESG <[email-masked]>; Pascal Thubert (pthubert)
> <[email-masked]>; [email-masked]; [email-masked]; draft-ietf-
> [email-masked]
> Subject: Re: [6tisch] Alissa Cooper's Discuss on draft-ietf-6tisch-enrollment-
> enhanced-beacon-13: (with DISCUSS and COMMENT)
> 
> 
> Alissa Cooper via Datatracker <[email-masked]> 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.
> 
> 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  [
> ]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 18 Mar 2020 15:07:26 -0400

Hi Michael,

> On Feb 20, 2020, at 1:34 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> 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

> Michael Richardson <[email-masked]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
>