Re: [6lo] Last Call: <draft-ietf-6lo-6lobac-06.txt> (Transmission of IPv6 over MS/TP Networks) to Proposed Standard

[Kerry Lynn <[e-mail]>]

Dale,

Thanks for your thorough review of draft-ietf-6lo-6lobac.  Sorry that it
has taken
so long to get back to you.  Can you take a look at the new version and see
if
it addresses your concerns?  Comments inline...

On Sun, Nov 13, 2016 at 2:26 PM, Dale R. Worley <[e-mail]> wrote:

> Comments on draft-ietf-6lo-6lobac-06
>
> (This is probably the best-written Internet-Draft that I have ever
> read.)
>
> Technical issues:
>
> 6.  Stateless Address Autoconfiguration
>
>    This section defines how to obtain an IPv6 Interface Identifier.  The
>    general procedure for creating a MAC-address-derived IID is described
>    in [RFC4291] Appendix A, "Creating Modified EUI-64 Format Interface
>    Identifiers", as updated by [RFC7136].
>
>    The IID SHOULD NOT embed an [EUI-64] or any other globally unique
>    hardware identifier assigned to a device (see Section 12).
>
> <kel>
Section 6 has been reworked to more clearly distinguish between two types
of IIDs: "MAC-address-derived" and "semantically opaque".  The first is
recommended for link-local addresses because it enables maximum IPv6
header compression efficiency.  Since MS/TP is used primarily as a field
bus, I expect most installations will only ever involve link-local traffic
between
an MS/TP device and a local controller.

For applications where the MS/TP device is a client or server with routable
addresses, the spec strongly recommends generating a semantically opaque
IID, with 64 bits of entropy, for each global address.
</kel>

> I have a hard time correlating these two paragraphs.  At first read,
> the first paragraph describes how an IID is to be constructed from a
> MAC address, and the second one specifies that the IID should not
> contain a MAC address.  Reading more carefully, it seems that the
> intention is to refer to one of the methods of constructing IIDs that
> are listed in section 2 of RFC 7136 which construct IIDs *from* MAC
> addresses but the IIDs do not directly contain them:
>
> <kel>
The recommended method of generating IIDs from the 8-bit node address
is described, so the reference to EUI-64 has been removed as it was
confusing (and MS/TP devices don't typically have static 48- or 64-bit
hardware addresses.)
</kel>

>    In addition to IIDs formed from IEEE EUI-64 addresses, various new
>    forms of IIDs have been defined, including temporary addresses
>    [RFC4941], Cryptographically Generated Addresses (CGAs) [RFC3972]
>    [RFC4982], Hash-Based Addresses (HBAs) [RFC5535], and ISATAP
>    addresses [RFC5214].
>
> Though, strctily speaking, those formats aren't introduced due to RFC
> 7136 updating RFC 4291, but rather by RFC 4941 etc. doing so.
>
> But if my understanding is correct, it would help greatly if this text
> was revised to point more directly to the text that is relevant, as my
> reflexive behavior is to read Appendix A of RFC 4291, which only
> discusses embedding MAC addresses in IIDs.
>
> It would also help to explain what the important difference is between
> "MAC-address-derived" and "embed an [EUI-64] or other globally unique
> hardware identifier" -- I think the critical distinction is that with
> the former, knowing the MAC address is not sufficient for an attacker
> to guess the IID, but I'm left to guess that.
>
> Editorial issues:
>
> 1.  Introduction
>
>    a) MS/TP devices typically have a continuous source of power
>
> I think this isn't quite how you want to phrase it, since a battery is
> a "continuous source of power".  Perhaps "typically have mains power".
>
> 1.4.  Goals and Constraints
>
>    The primary goal of this specification is to enable IPv6 directly on
>    wired end devices in building automation and control networks by
>    leveraging existing standards to the greatest extent possible.  A
>    secondary goal is to co-exist with legacy MS/TP implementations.
>
> This doesn't seem to be as clear as it could be in a number of ways.
>
> One issue is the distinction between "primary goal" and "secondary
> goal".  Naively it seems to me that both are necessary for success,
> but as written it sounds like coexistence has in some way been
> sacrificed or compromised in order to achieve the primary goal.  But
> it seems that draft-ietf-6lo-6lobac provides for complete coexistence.
>
>    Only the minimum changes necessary to support IPv6 over MS/TP were
>    specified in BACnet [Addendum_an] (see Section 1.3).
>
> This sentence seems to mean that Addendum_an contains just enough
> changes to MS/TP to allow draft-ietf-6lo-6lobac to be written.  But
> it's hard to tell what the significance of that is -- if Addendum_an
> is *only* to support draft-ietf-6lo-6lobac, then the partitioning of
> changes between Addendum_an and draft-ietf-6lo-6lobac is arbitrary,
> and Addendum_an could have been made smaller by shifting some of its
> content into draft-ietf-6lo-6lobac.  And that contradicts the claim
> that Addendum_is "minimum".
>
> It seems that what is really meant is that Addendum_an support is
> necessary for draft-ietf-6lo-6lobac support, or perhaps that the only
> use of Addendum_an is to support draft-ietf-6lo-6lobac.
>
>    In order to co-exist with legacy devices, no changes are permitted to
>    the MS/TP addressing modes, frame header format, control frames, or
>    Master Node state machine as specified in BACnet [Clause9].
>
> Another issue is that there are three "levels", as it were, that a
> device can be designed to:
>     1. Clause9 alone
>     2. Clause9 with Addendum_an
>     3. Clause9, Addendum_an, and draft-ietf-6lo-6lobac
> I assume that the three levels are upward compatible, in that you can
> mix devices designed to all three levels on one network, and then any
> two devices will interoperate at the highest level that they share.
> But it seems that this could be stated much more clearly by just
> saying that draft-ietf-6lo-6lobac is upward-compatible with devices
> designed to Clause9 and with devices designed to Clause9 with
> Addendum_an.
>
> <kel>
ANSI/ASHRAE Standard 135-2016 was published late last year.  This
version integrates the changes that were standardized in 135-2012
Addendum an, so there's no longer any jumping back and forth between
references.

Also, I didn't make it clear (outside of 6lo wg) that I can provide a copy
of [BACnet] Clause 9 to anyone who wants to reference it in the course
of reviewing the ID.
</kel>

It's not really clear what the phrase "no changes are permitted to"
> applies to -- is it a description of draft-ietf-6lo-6lobac, or a
> warning that there are certain constraints on devices that aren't
> stated in this document?
>
> <kel>
This is a statement on how to achieve co-existence.  Hopefully the
context is clearer in the current version of the ID.
</kel>


> 2.  MS/TP Mode for IPv6
>
> Must all nodes that support IPv6 be master nodes?
>
> <kel>
Yes, slave nodes cannot initiate async transmission.  MS/TP nodes
are designed to ignore frames they don't understand (e.g. 6LoBAC).
</kel>


>    ... implement the Receive Frame state machine specified in
>    [Clause9] as extended by BACnet [Addendum_an].
>
> There seems to be an alternative use of "BACnet [Clause9]"
> vs. "[Clause9]", and also "BACnet [Addendum_an]" vs. "[Addendum_an]".
> The usage should be made consistent, and also aligned with the
> definition:
>
>    BACnet:  An ISO/ANSI/ASHRAE Standard Data Communication Protocol
>             for Building Automation and Control Networks
>
> Does "BACnet" mean just Clause9 or Clause9 plus Addendum_an, or is it
> a generic that applies to both sets of specifications?
>
> <kel>
Due to the update to the base spec, these references have all been converted
to [BACnet] Clause 9.  There is a single reference to [Addendum_an] for any
historians in the audience.  [BACnet] refers to the latest version,
ANSI/ASHRAE
Standard 135-2016.
</kel>

5.  LoBAC Adaptation Layer
>
>    Implementations MAY also support Generic Header Compression (GHC)
>    [RFC7400] for transport layer headers.  A node implementing [RFC7400]
>    MUST probe its peers for GHC support before applying GHC.
>
> This would probably read better if the second "[RFC7400]" was written
> "GHC".
>
> 6.  Stateless Address Autoconfiguration
>
>    concatenating a node's' 8-bit MS/TP MAC address to the seven octets
>
> s/node's'/node's/
>
> 9.  Multicast Address Mapping
>
>    When represented as
>    a 16-bit address in a compressed header (see Section 10), it MUST be
>    formed by padding on the left with a zero:
>
> This would read more smoothly if "it" was "the broadcast link address"
> and "a zero" was "a zero octet".
>
> 10.  Header Compression
>
>    When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short
>    address") it MUST be formed by padding the MS/TP address to the left
>    with a zero:
>
> Similarly, this would read more smoothly if "a zero" was "a zero
> octet".
>
> Appendix B.  Consistent Overhead Byte Stuffing [COBS]
>
>    The minimum overhead of COBS is one octet per encoded field.  The
>    worst-case overhead in long fields is bounded to one octet per 254,
>    or less than 0.4%, as described in [COBS].
>
> This could be more informative as:
>
>    The minimum overhead of COBS is one octet per encoded field, and
>    the maximum overhead is ceiling(length/254) octets.  In the limit
>    for very long fields, the overhead is less than 0.4%.  For 1280
>    octet fields, the overhead is 0.47% and for 1500 octet fields, the
>    overhead is 0.39%.
>

<kel>
I punted on calculating percentages, assuming the reader could do the math.
I guessing it varies discretely between 50% for a 1-byte field and 0.39% for
a 254 byte field.  The salient fact is the overhead is bounded to six bytes
of
overhead for a 1500-byte MTU, but maybe I need to say that explicitly.
</kel>

>
> Appendix C.  Encoded CRC-32K [CRC32K]
>
>    BACnet [Addendum_an] specifies the CRC-32K (Koopman) polynomial.
>
> "CRC-32K" is not bound at this point.  Perhaps
>
>    BACnet [Addendum_an] specifies one of these, the CRC-32K (Koopman)
>    polynomial.
>
> <kel>
I'm pretty sure I incorporated all of your editorial changes.
</kel>

Thanks again, Kerry


> Dale
>