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

From: Brian Haberman <[email-masked]>
Date: Mon, 15 Sep 2014 12:00:42 -0400

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.

* 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?

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

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

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

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

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

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

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

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

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

Regards,
Brian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 15 Sep 2014 18:34:13 +0200

> functionality specified in draft-ietf-6lo-ghc?

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.

Grüße, Carsten

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 16 Sep 2014 00:28:24 +0200

On Monday, September 15, 2014, Carsten Bormann wrote:

> On 15 Sep 2014, at 18:00, Brian Haberman <[email-masked]
> <javascript:;>> wrote:
>

 I think it is better to have GHC maximised for 6Lo, so that it can
consider that future technology work. As how can we fit this work in future
maximised applicability.

AB

---

From: Anders Brandt <[email-masked]>
Date: Wed, 17 Sep 2014 14:04:38 +0000

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:[email-masked]]
      > Sent: 15. september 2014 18:01
      > To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
      > 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.

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

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

      > Brian

Again, thanks for the comments,
  Anders

---

From: Brian Haberman <[email-masked]>
Date: Wed, 17 Sep 2014 11:36:23 -0400

Hi Anders,
     I have snipped all the pieces where we have a way forward...

> which feature a minimum of RAM and nonvolatile memory for cost reasons.

Is it worthwhile to mention that the stateless nature of 6282 is
preferable in some deployment scenarios?  That should prevent other
reviewers from asking the same question (especially since GHC is in IESG
review right now).

> while fully capable nodes can still be used in cost optimized deployments.

Ok, I understand the logic now, but think it can be said differently.
In reality, the M bit is understood, but is not honored.  Given that, it
may be better to say that some deployments do not support stateful
address assignments and implementations may optimize by cost and omit
stateful addressing protocols.

> I see no need for changing any text (?)

Actually, a simple sentence pointing out that G.9959 does not support
link-layer multicast would clarify things nicely.

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

I did not realize it was taken directly out of 4944.  I am fine with
leaving it as is then.

Regards,
Brian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Sep 2014 17:51:49 +0200

On 17 Sep 2014, at 17:36, Brian Haberman <[email-masked]> wrote:

>> I am however reluctant making GHC a hard

GHC is completely stateless, for this very reason.

(On the memory front: Decompression requires additional *temporary* memory.
Even with mandatory support for GHC, a node is at liberty how much memory it wants to spend on compression, including none at all by simply never compressing at all.)

>> which feature a minimum of RAM and nonvolatile memory for cost reasons.

(Anders, we are in complete agreement here.
Can I ask you to go to the ACE WG and repeat this once a week or so? :-)

> reviewers from asking the same question (especially since GHC is in IESG

Again, GHC is not about additional state, it just requires additional processing beyond that already implied by RFC 6282, which imposes a temporary memory requirement only.

But in the end I agree that mandatory GHC is maybe a bit much for the very low-end devices we are seeing lowpanz on.
Just not for the reason that GHC somehow needs state.

Grüße, Carsten

---

From: Anders Brandt <[email-masked]>
Date: Thu, 18 Sep 2014 09:18:38 +0000

Hi Brian,

(inserted a few of Carsten's comments where relevant)

Please see comments inline.
The attached draft2 files contain the changes proposed in this mail.

Cheers,
  Anders

> Sent: 17. september 2014 17:36
> To: Anders Brandt; [email-masked]; [email-masked]
> Subject: Re: AD Evaluation: draft-ietf-6lo-lowpanz
> 
> Hi Anders,
<snip>
> > I agree in Carsten's observations. I am however reluctant making GHC a
> > hard requirement. 
<snip>
> Is it worthwhile to mention that the stateless nature of 6282 is preferable in
> some deployment scenarios?  That should prevent other reviewers from
> asking the same question (especially since GHC is in IESG review right now).

Inserted by Anders Brandt:
> (Carsten Borman wrote:							)
> (But in the end I agree that mandatory GHC is maybe a bit much for the very	)
> (low-end devices we are seeing lowpanz on.                                 			)
> (Just not for the reason that GHC somehow needs state.			)

Section 3.  "6LoWPAN Adaptation Layer and Frame Format" says:

"IPv6 header compression [RFC6282] MUST be supported by
implementations of this specification."

I propose adding

"Further, implementations MAY support Generic Header Compression (GHC) 
[TBD_RFC_GHC]. A node implementing [TBD_RFC_GHC] MUST probe its peers 
for GHC support before applying GHC compression."

> >       >    - I don't understand the statement that a node MAY support the M
<snip>
> > 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.
> 
> In reality, the M bit is understood, but is not honored.  Given that, it may be
> better to say that some deployments do not support stateful address
> assignments and implementations may optimize by cost and omit stateful
> addressing protocols.

The existing text says:

"A node interface MAY support the M flag of the RA message for the
construction of routable IPv6 addresses. "

It is proposed to append this text:

"A cost optimized node implementation may save memory by skipping
support for the M flag."

> multicast
<snip>
> Actually, a simple sentence pointing out that G.9959 does not support link-
> layer multicast would clarify things nicely.

The existing text says:

" G.9959 supports direct-range IPv6 multicast while subnet-
   wide multicast is not supported natively by G.9959. "

I see no need for a change (?)

> >       > appearance is confusing.  Why refer to the "addressing header" when
<snip>
> I did not realize it was taken directly out of 4944.  I am fine with leaving it as is
> then.
> 
> Regards,
> Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 18 Sep 2014 08:48:01 -0400

Hi Anders,
     These changes look good.  Go ahead and submit this update and I
will move it along to IETF Last Call.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Fri, 19 Sep 2014 10:44:52 -0400

Hi Anders,
     I should have caught this yesterday... Are there changes needed in
section 5 to deal with the "MAY support GHC" clause in section 3?

Brian

---

From: mat nizam <[email-masked]>
Date: Fri, 19 Sep 2014 23:01:12 +0800

On 17 Sep 2014 23:52, "Carsten Bormann" <[email-masked]> wrote:

On 17 Sep 2014, at 17:36, Brian Haberman <[email-masked]> wrote:

>> I am however reluctan...

(On the memory front: Decompression requires additional *temporary* memory.
Even with mandatory support for GHC, a node is at liberty how much memory
it wants to spend on compression, including none at all by simply never
compressing at all.)

>> but one de...

> preferable in some deployment ...
Again, GHC is not about additional state, it just requires additional
processing beyond that already implied by RFC 6282, which imposes a
temporary memory requirement only.

But in the end I agree that mandatory GHC is maybe a bit much for the very
low-end devices we are seeing lowpanz on.
Just not for the reason that GHC somehow needs state.

Grüße, Carsten

_______________________________________________
6lo mailing list
[email-masked]
https...

---

From: Anders Brandt <[email-masked]>
Date: Mon, 22 Sep 2014 08:59:38 +0000

Brian,

>      I should have caught this yesterday... 

So should I, I guess...

> Are there changes needed in section 
> 5 to deal with the "MAY support GHC" clause in section 3?

I think they are not strictly needed, but for completeness, I have changed this text

"IPv6 header compression MUST be implemented according to [RFC6282].
This section will simply identify substitutions that should be made
when interpreting the text of [RFC6282]."

to this text:

"IPv6 header compression [RFC6282] MUST be implemented and
[RFC_TBD_GHC] compression for higher layers MAY be implemented.
This section will simply identify substitutions that should be made
when interpreting the text of [RFC6282] and [RFC_TBD_GHC]."

A new draft-draft is attached.
Please let me know if I should submit it as -07.

Thanks,
  Anders

> Sent: 19. september 2014 16:45
>      I should have caught this yesterday... Are there changes needed in section
> 5 to deal with the "MAY support GHC" clause in section 3?
> 
> Brian
> 
> 
> >>>> I agree in Carsten's observations. I am however reluctant making
> >>>> GHC a hard requirement.
> >> <snip>
> >>> (Carsten Borman wrote:
> 	)
> >> "Further, implementations MAY support Generic Header Compression
> >> (GHC) [TBD_RFC_GHC]. A node implementing [TBD_RFC_GHC] MUST
> probe its
> >> peers for GHC support before applying GHC compression."
> >>
> >>>>       >    - I don't understand the statement that a node MAY support the
> M
> >>>>       > flag in
> >> <snip>
> >>>> 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.
> >>>
> >>> In reality, the M bit is understood, but is not honored.  Given
> >>> that, it may be better to say that some deployments do not support
> >>> stateful address assignments and implementations may optimize by
> >>> cost and omit stateful addressing protocols.
> >>
> >> The existing text says:
> >>
> >>> Actually, a simple sentence pointing out that G.9959 does not
> >>> support link- layer multicast would clarify things nicely.
> >>
> >> The existing text says:
> >>

---

From: Brian Haberman <[email-masked]>
Date: Mon, 22 Sep 2014 08:39:24 -0400

Hi Anders,
    Looks good to me. Go ahead and submit it.

Regards,
Brian