Early Review of draft-ietf-6lo-6lobac-05

Request Review of draft-ietf-6lo-6lobac
Requested rev. no specific revision (document currently at 08)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2016-09-15
Requested 2016-08-03
Authors Kerry Lynn, Jerry Martocci, Carl Neilson, Stuart Donaldson
Draft last updated 2016-09-15
Completed reviews Genart Last Call review of -06 by Orit Levin (diff)
Intdir Early review of -05 by Tim Chown (diff)
Intdir Early review of -05 by Brian Haberman (diff)
Opsdir Last Call review of -06 by Mahesh Jethanandani (diff)
Assignment Reviewer Tim Chown
State Completed
Review review-ietf-6lo-6lobac-05-intdir-early-chown-2016-09-15
Reviewed rev. 05 (document currently at 08)
Review result Ready
Review completed: 2016-09-15



I am an assigned INT directorate reviewer for this draft. These comments were written primarily for the benefit of the Internet Area Directors. Document editors
 and shepherds should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details of the INT directorate, see <




This document defines the mechanisms for delivering IPv6 over Master-Slave/Token Passing (MS/TP), which is a MAC protocol commonly used in building automation
 networks. It includes the frame format for transmitting IPv6 packets,  as well as the method for forming link-local and statelessly auto-configured IPv6 addresses.

I was not familiar with the work prior to reading it, but found the text to be well-written and easy to read, with it following a similar structure to other IETF
 IPv6-over-foo documents.

Some specific points of note regards MS/TP are that it has 8-bit MAC addresses, it has no multicast (so multicast packets are sent to the 8-bit broadcast destination
 address (255), it can support MTUs of 1280-1500 (and above), and, as a wired protocol, it runs at around 115Kbit/s up to 1000m.


The introduction says that the “general approach is to adapt elements of the 6LoWPAN specifications, RFC4944, RFC6282 and RFC6775”.  This is understandable given
 the constrained nature of nodes in building automation scenarios. There are however places in the document where it’s not clear where specifically these specifications are being drawn upon and are to be used. Some more explicit pointers might be helpful.  

 example of this lies in Section 8, which says unicast address mapping follows Section 7.2 of RFC4861, but one might expect RFC6775 (on ND optimisation) to be used, e.g. wrt solicited node multicast.

Section 2 has some “musts” that might be MUSTs, given RFC2119 language is defined in Section 1.1.

In Section 3 it says that all multicast packets SHOULD be broadcast at the MAC layer. Why is this a SHOULD, and not a MUST? One would assume unicasting multicast
 messages would be expensive in this type of constrained network and given the token passing mechanism where the token is passed after sending so many packets.

The introduction says header compression support as per RFC6282 is REQUIRED, but Section 5 does not explicitly say that the compression mechanism described there MUST be implemented.
 I’d suggest rewriting the first sentence of Section 5 to say something like “Due to the relatively low data rates of MS/TP, the header compression mechanism described in this section MUST be implemented on all nodes.” 

Perhaps before Section 6, or at the start of it, there should be text stating which addresses are formed, and which multicast groups are joined. Further, perhaps
 we can draw on 

draft-ietf-6man-default-iids-13, which is now very close to publication, and refer to the recommendations in Section 3 there, e.g. that RFC7217 SHOULD be used, and

 that you SHOULD NOT embed a stable link-layer address in the IID


It seems the text is saying that RFC7217 is not to be used for link-local IIDs; rather the text suggests using a SLAAC-style address (with the last 8 bits being the MAC address) to allow for efficient
 header compression. Perhaps some explicit text here would help (i.e. SHOULD use RFC7217 for global scope addresses, but RECOMMENDED that you use the SLAAC-a-like mechanism for link-local addresses for header compression efficiency). 

The text RECOMMENDING use of a privacy IID does not mention RFC4941, presumably because RFC4941 targets IIDs with embedded IEEE MAC addresses, but the principle for generating the privacy address is the
 same.  As it stands, the text does not define how a 64-bit privacy address is generated (I think we assume it’s as per RFC4941, but be specific?). 

One assumes RFC6724-based address selection is followed, in which case privacy addresses would be preferred over public addresses, and thus for all communications initiated by the device, it would be using
 non-compression friendly addresses. Is this a concern?  Or might you explicitly say here only use privacy addresses for global scope prefixes, again for efficiency.

Section 8 should clarify which elements of RFC6775 are used. As it’s written, I assume none, but that’s at odds with the introduction text.

Section 12 (like Section 6, now I notice it) refers to “forwardable addresses”. Do you mean global scope addresses (which would include ULAs, if used)? If so,
 I’d suggest using that terminology.

Scanning attacks where embedded 8-bit MAC addresses are used for the last 8-bits would be quite trivial.  I think the text here that basically says “you SHOULD
 use RFC7217" (for local scope addresses) should be emphasised in Section 6; it doesn’t need to be here, or if it is mentioned, refer to Section 6.  I’m not sure of the relevance of DHCPv6 here(?), while CGAs and hash-based addresses are not (I believe) in
 common use. 

Are such wired networks not liable to casual snopping? What happens if I unplug a device and plug my own in, using a master node MAC? Presumably the MS/TP protocol
 defines mechanisms for protection against such attacks, that you could cite?

You might add in Section 12 that ULAs may be appropriate for building management systems where the communications are all intra-site.  If external communications
 are needed, an additional ISP-based prefix could be used. Though I appreciate ULAs can be a contentious subject, so if you want to publish quickly you might choose to not say anything on the subject (but it will come up… :)