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

Kerry Lynn <> Mon, 27 February 2017 22:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DBBB129447; Mon, 27 Feb 2017 14:53:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oThYxHMz-KRa; Mon, 27 Feb 2017 14:53:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8813E129443; Mon, 27 Feb 2017 14:53:31 -0800 (PST)
Received: by with SMTP id 62so46503920oih.2; Mon, 27 Feb 2017 14:53:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rnZvXipBZIXrYjhUdgEqkSTJdVXttaMKH3lWdSkRW5M=; b=a8lPX1/9klVmTyI29z1n7b+/zHJul40ca84Iaa0/419n5SRbLB2fTCiSc8YXga00Yz GeeDxHwXcRzgsrTaHsm7EzLIpyncW6cZlZtffCk5pRoTjZxuECbKA+PjBb+ry0chMaDz iUC+r8hSDrjAskyKuqpKjS+SUsrGo7UHm7iTEdPXa/nAMSxORNCuySVPYJKQe7dSSRie Z/IRP7ABQ9elD2lHxbfrsEjrmGNUzY5hIbw5x8THWc0JxrzFTyL0irnPjPrk0Kac0xBx fBkxBUSpn+QqytnMARs/luXvbAn2OGCUt3yx219pvjT6oYYrxrEm/KXoie6vcyxJMa9g 2Auw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rnZvXipBZIXrYjhUdgEqkSTJdVXttaMKH3lWdSkRW5M=; b=YnyVQT+JkGIrZTFhZxF6X9Xi4z2MzUwq2iZpcUqWB73y7oi3dOj9PmBCmYXcfmNj2/ 8fMuiRguFHTGX4aPlLkW9BRG+Z+TGMcCqm52Prf1TRjkKUUCVfyE8+ctLCJ6whXrDEe5 Cu2BC78XZyh9GVgn4e8Zg3jBrs6ltTdN6gZsGIrtDpDfFCaR3YWnQYNARJSwjV7wbmjQ nX3g2qSqm46JADqdjdzTty8BMai4w+IVW4lrp6h23/ooLzs6iFnkK8Ip4d/xYzBBjNEa 2M+Q+wp4fy+h8xmeB/KGKXpV/KjwfcPyirL+aYndoZSnAidm0CEJfehfi239xyWGcowv PAiA==
X-Gm-Message-State: AMke39nb94rk1jHxJ9YtaFyGaJ+qk4e6IDvjPKEcZWIK+h1wn4veCxjSRJ4ijVDKFfocFB6K62BFKNi0h5Ce2g==
X-Received: by with SMTP id t126mr9008838oih.52.1488236010763; Mon, 27 Feb 2017 14:53:30 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 27 Feb 2017 14:53:30 -0800 (PST)
In-Reply-To: <>
References: <>
From: Kerry Lynn <>
Date: Mon, 27 Feb 2017 17:53:30 -0500
X-Google-Sender-Auth: bHPr6Q-HSgDQnUXrhFNgiWyrin4
Message-ID: <>
Subject: Re: [6lo] Last Call: <draft-ietf-6lo-6lobac-06.txt> (Transmission of IPv6 over MS/TP Networks) to Proposed Standard
To: "Dale R. Worley" <>
Content-Type: multipart/alternative; boundary="001a1149526cc37c9b05498af2a2"
Archived-At: <>
Cc:,, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Feb 2017 22:53:34 -0000


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
it addresses your concerns?  Comments inline...

On Sun, Nov 13, 2016 at 2:26 PM, Dale R. Worley <> 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
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.

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

>    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

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.

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.

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

>    ... 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,
Standard 135-2016.

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

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
overhead for a 1500-byte MTU, but maybe I need to say that explicitly.

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

Thanks again, Kerry

> Dale