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

[Michael Richardson <[e-mail]>]

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.

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 =-