Subject: [6lo] Comments on draft-ietf-6man-default-iids-01.txt

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Mon, 27 Oct 2014 18:03:38 +0000

I have a few comments on the new rev of draft-ietf-6man-default-iids.  This message is posted to the 6man WG mailing list, with a bcc to the 6lo WG mailing list.  The draft is of interest to the 6lo WG; please post responses to the 6man WG mailing list.

In this document, I think it is important to be explicit about the considerations that might lead to a decision not to follow the RFC 2119 language recommendations in this document.  My immediate concern is the 6LoWPAN standards, which use IIDs based on hardware addresses as a method for IPv6 header compression.

I also think that some of the wording is too strong, which may lead to confusion in the cases where the recommendations in this document are not followed.

In particular, I think the wording in the "Future Work" section is too strong, and does not allow for continued use of IIDs based on hardware addresses in 6LoWPAN and similar standards.

As an editorial detail, the document lists the various RFCs that are update, but does not explicitly state what is to be updated in those documents.  While the updates could be reasonably inferred, seems to me an explicit statement about what is to be updated would be good.

With those comments in mind, I'll suggest the following text changes:

In section 1, add this paragraph before the "NOTE":

  In some network technologies and adaptation layers, the use of an
  IID based on a hardware address offers some advantages.  For
  example, the IP-over-IEEE802.15.4 standard in RFC6775 allows for
  compression of IPv6 addresses when the IID the address is based
  on the corresponding hardware address.  The design and engineering
  tradeoffs between security and privacy, and network efficiency
  should be considered in any decision about the use of an IID based
  on a hardware address.

Replace section 3 with:

  It is RECOMMENDED by this document that nodes implement and employ
  RFC 7217 as the default scheme for generating stable IPv6 addresses
  with SLAAC.  Some specifications MAY use a an IID based on a node's
  hardware address if design and engineering considerations warrant.

  It is RECOMMENDED by this document that nodes do not employ IPv6
  address generation schemes that embed the underlying hardware
  address in the Interface Identifier.  In particular, this document
  RECOMMENDS that nodes do not generate Interface Identifiers with
  the schemes specified in [RFC2464], [RFC2467], [RFC2470],
  [RFC2491], [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572],
  [RFC4338], [RFC4391], [RFC5121], and [RFC5072], and updates those
  documents with this recommendation.

  It is RECOMMENDED by this document that future specifications no
  not specify IPv6 address generation schemes that embed the
  underlying hardware address in the Interface Identifier. Future
  specifications MAY use a an IID based on a node's hardware address
  if design and engineering considerations warrant.

In section 4, replace the last paragraph with:

  Future revisions or updates of these documents should take the
  issues of privacy and security mentioned in section 1 and explain
  any design and engineering considerations that lead to the use of
  IIDs based on a node's hardware address.

I hope this input is helpful.

- Ralph