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 <wor...@ariadne.com> 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 >
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
