Re: [6lo] AD Evaluation: draft-ietf-6lo-lowpanz

[Anders Brandt <[e-mail]>]

Brian,

Thanks for your review comments.

Please see responses inline.
A draft -06 diff is attached, outlining proposed changes from -05.



Thanks,
  Anders.

      > -----Original Message-----
      > From: Brian Haberman [mailto:[e-mail]]
      > Sent: 15. september 2014 18:01
      > To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
      > Subject: AD Evaluation: draft-ietf-6lo-lowpanz
      >
      > All,
      >      Sorry for the delay in reviewing draft-ietf-6lo-lowpanz.  It turns out that
      > there was some meta-data issues that prevented me from seeing that the
      > draft was submitted for publication.  I have several points/issues that I would
      > like to mention.  Some probably require some discussion.  Please let me
      > know if you have questions/concerns with the points raised.  Once these are
      > resolved, the draft can move to IETF Last Call.
      >
      > * Section 1.1 says that the term ABR is defined in RFC 6775, but I cannot find
      > that acronym in 6775.  I assume this should be Authoritative 6LBR.

Correct.
ABR should represent the Authoritative 6LBR. Section 1.1 will be corrected.

      > * Section 2.1
      >
      >    - Two questions related to the statement that the G.9959 network
      > controller function SHOULD be integrated in the ABR.  First, what is the
      > justification for this coupling?  That is, what ties are needed between those
      > two functions?
      > Second, why is it a SHOULD?  If there are ties needed
      > between those functions, what does an implementer risk by not following
      > the SHOULD?  Are there known situations where the SHOULD can be safely
      > ignored?

There is no coupling with regards to network functionality.
This was intended only as an implementation guidance.
The inclusion process involves assignment of link layer identifiers and security keys.
This may be done via another interface, e.g. a remote control, but most likely you
want to provide link layer management functions via a gateway so users can choose
"Add Node" via a web page or an app. This implies an IP backbone connection which
the ABR already has.

Network-wise, the "SHOULD" can always be safely ignored.
The issue is only about user convenience when adding nodes to the network.

I agree that this is not a proper use of the keyword "SHOULD".
I propose to delete the line
"The G.9959 network controller function SHOULD be integrated in the ABR."

      >    - Can the use of RFC 6282 compression be replaced with the functionality
      > specified in draft-ietf-6lo-ghc?

As Carsten Borman already responded:

       Interesting question, and rather relevant for maximizing GHC's applicability.

        (It certainly cannot be "replaced", as GHC requires RFC 6282 and plugs into it.)
       I would expect the RFC 6282 usage in lowpanz can be enhanced with GHC if the
       ND RS message of a host includes the right 6CIO option.
       With GHC, it is optional for the other node to react to that option, so nodes would
       need to keep state which of their neighbors are GHC capable and which are not.

       A radical proposal would be to *require* GHC the same way that RFC 6282 is
       required, removing the need for that state, but adding a requirement to at least
       decompress GHC for every node using that adaptation layer.
       We cannot make that decision for 802.15.4 6LoWPAN retroactively, but we can
       make it for any new 6Lo adaptation layer.
       The merits of that decision may differ between different PHY/MACs.
       I have no opinion yet whether this is something that should be done for lowpanz
       or not.

I agree in Carsten's observations. I am however reluctant making GHC a hard
requirement. Keeping state requires memory.
GHC may be a fine proposition for more capable devices in more chatty deployments,
but one deployment category of lowpanz will be for IP based home automation.
This is a highly competitive area where cost price is everything and it is not a
green field market.
Home automation products based on this work will be compared to existing systems
which feature a minimum of RAM and nonvolatile memory for cost reasons.

      >    - I don't understand the statement that a node MAY support the M flag in
      > the IPv6 RA message.  I don't see a similar statement in 6775.  At this point in
      > time, why would a node not support (i.e., understand) the M flag?

Again, this is about cost. In the most cost optimized deployments, mesh-under routing
is used and IP addresses are derived from the link layer address.
Without IP routing and DHCP address assignment, the memory requirement can be
lowered significantly.
The option allows for deployments with the full addressing flexibility provided by DHCP
while fully capable nodes can still be used in cost optimized deployments.

      >    - This section contains a warning for application developers about the
      > stability of the NodeID and HomeID values.  Is this directed towards user-
      > level application developers or infrastructure (e.g., NDP) application
      > developers.  Some clarification would be good since I don't think user-level
      > application developers will be reading this document.

Good point.
I propose rewording this line:
"...suggests that deployers of high-reliability applications should carefully consider
adding redundancy to the network controller
function."

so that it becomes:

"...suggests that high-reliability network deployments may benefit from a redundant
network controller function."

      > * Section 2.2 - How would routing protocols support subnet-wide multicast
      > forwarding if packets are encoded as broadcast messages?

This one relates to G.9959 addressing.
G.9959 does not have the concept of multicast group memberships at the link layer.

The text says
" Subnet-wide
   multicast may be provided by an IP routing protocol or a mesh routing
   protocol operating below the 6LoWPAN layer.  Routing protocol
   specifications are out of scope of this document. "

and
"IPv6 multicast packets MUST be carried via G.9959 broadcast.".

Thus, text just says that the IP stacks of all nodes in direct range have to be reached
via G.9959 broadcast addressing.

I see no need for changing any text (?)

      > * Section 2.3 - I will note that RFC 2460 does not say "IPv6 packets may be up
      > to 1280 octets".  What it does say is that a link MTU must support at least
      > 1280 octets and if it does not, link-specific fragmentation must be supported.

It is proposed to change the text from:

"[RFC2460] specifies that IPv6 packets may be up to 1280 octets."

To:

"[RFC2460] specifies that any link that cannot convey a 1280-octet
   packet in one piece, must provide link-specific fragmentation and reassembly
at a layer below IPv6."

      > * Section 3 - The naming of the headers when discussing their order of
      > appearance is confusing.  Why refer to the "addressing header" when 2460
      > calls that the "IPv6 header".  I will also note that 2460 only provides a
      > recommended (not mandatory) order of the headers.

I cannot find a single instance of "addressing header" in the draft (?)

I suppose this is the offending line:
" An IPv6 header
   stack may contain, in the following order, addressing, hop-by-hop
   options, routing, fragmentation, destination options, and finally
   payload [RFC2460]."

This one was copied directly from RFC4944 and I do not know how I should improve it.

      > * Section 3.1 - I think it would be clearer if the document explicitly stated that
      > the Command Class ID value of 0x4F is/was assigned by the ITU (or whoever
      > manages that field within G.9959 spec).

It is proposed to change this:

" The value specifies that the
   following bits are a 6LoWPAN encapsulated datagram."

to this:

" The value is assigned by the ITU-T and specifies that the
   following bits are a 6LoWPAN encapsulated datagram."

      > * Section 4 - As you are probably aware, there has been a lot of attention
      > focused on the privacy characteristics of IPv6 addresses.  I think it would be
      > good to mention any security/privacy issues with the IID generation
      > approach described in this section.  I would suggest looking at RFC 7217 and
      > draft-ietf-6man-ipv6-address-generation-privacy
      > for guidance.

It was mainly to address privacy concerns that the 'M' flag option was introduced.
Section 8. Privacy Considerations contains a comprehensive discussion on this issue already.

I propose that this introductory text:

"IPv6 addresses are autoconfigured from IIDs which are again
   constructed from link-layer address information to save memory in
   devices and to facilitate efficient IP header compression as per
   [RFC6282]."

to this:

"IPv6 addresses may be autoconfigured from IIDs which may again
   be constructed from link-layer address information to save memory in
   devices and to facilitate efficient IP header compression as per
   [RFC6282]."

and further adding:

"Link-layer-derived addresses have a static nature and may involuntarily
expose private usage data on public networks. Refer to section 8."

      > * Section 4.4 - How does a node know if route-over or mesh-under is in use
      > when managing prefixes and CIDs?

That is a design/commisioning decision.
It is not the intention that a node implements multiple routing protocols.
A firmware update can change that, however.

      > Regards,
      > Brian


Again, thanks for the comments,
  Anders