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

[[e-mail] (Dale R. Worley)]

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).

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:

   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.

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?

2.  MS/TP Mode for IPv6

Must all nodes that support IPv6 be master nodes?

   ... 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?

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%.

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.

Dale