Subject: Re: [6lo] WG last call for draft-ietf-6lo-lowpanz-00

From: Anders Brandt <[email-masked]>
Date: Thu, 2 Jan 2014 12:51:45 +0000

Hi Michael

Thanks for taking your time to review this draft.
Please see my replies inline.

A diff file has been attached to outline the changes.
I will consult the chairs whether I should upload a new I-D at this time during the last call.

Thanks,
  Anders

> -----Original Message-----
> From: 6lo [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: 23. december 2013 22:37
> To: [email-masked]
> Subject: Re: [6lo] WG last call for draft-ietf-6lo-lowpanz-00
> 
> 
> Samita Chakrabarti <[email-masked]> wrote:
>     > http://tools.ietf.org/html/draft-ietf-6lo-lowpanz-00
> 
>     > Please comment to the list as to the suitability of this draft for publication
>     > as a standards track  RFC from 6lo WG.
> 
> I read it before 6lo was chartered, and I've re-read it.
> I have a few questions:
> 
> > G.9959 networks may implement mesh routing between nodes below the
> IP
> > layer.  Mesh routing is out of scope of this document.
> 
> I'm unclear if, in a G.9959 network that implements mesh-under,
> if this document applies.   I.e. is it that mesh-under networks
> are not in scope, or that the mesh-under specification itself is out of scope?
> Later parts of the document seem to have mesh-under in scope.

The correct interpretation is that the mesh-under specification itself is out of scope.
The draft definitely applies to direct range, mesh-under as well as route-over
deployments.

Ambiguities have been removed.

> >3.3.  G.9959 MAC PDU size and IPv6 MTU
> >
> >...
> >   G.9959 provides Segmentation And Reassembly for payloads up to 1350
> >   octets.  Segmentation however adds further overhead.  It is therefore
> >   desirable that datagrams can fit into a single G.9959 MAC PDU.  IPv6
> >   Header Compression [RFC6282] improves the chances that a short IPv6
> >   packet can fit into a single G.9959 frame.
> 
> I think that this says that HC is MUST, but I could read it the other way too.

Section 4 is very clear on this:
Quote: "IPv6 header compression [RFC6282]  MUST be supported by implementations of this specification."
I added a clarifying line to this section:

" Therefore, section 4 specifies that [RFC6282] MUST be supported."

> >3.5.  Transmission security
> >
> >   Implementations claiming conformance with this document MUST enable
> >   G.9959 shared network key security.
> 
> Is a per-node pair key possible?
> I understand that this document is neither mandating it, nor describing, but I
> am curious to understand if it can be done... I think I read that G.9959
> networks are never more than one layer deep.

You are right. G.9959 only describes direct range transmission.
The specification does however define a "Routed" frame type which allows
the MAC layer to forward such frames to a mesh-under routing layer.
Thus, G.9959 networks can definitely be deeper than one hop.

With regards to security, this draft borrows a lot from RFC4944; also 
security considerations.
The purpose of requiring shared network key security is to establish a
basic level of protection against general wireless intrusion. It is not precluding
additional security for critical applications (like door locks).
Thus, node-to-node security key pairs are definitely possible.

> Section 4: is there any value in having a unique dispatch value for G.9959 vs
> 15.4?

There is no unique dispatch value for G.9959. To maintain the highest
possible re-use from RFC4944, we use the dispatch codes of RFC4944 -
except for the deprecated ones.
The dispatch header format does however represent one of the few
differences from RFC4944:

RFC4944 assumes that 6LoWPAN networks are created from scratch
and that other technologies added to the 802.15.4 network at a later stage
have to detect the "NLAP" dispatch value.

LoWPANz capable nodes may be added to existing G.9959 networks. 
The additional "6LoWPAN CmdCls" octet allows legacy G.9959 nodes
to ignore LoWPANz payload. It may be regarded as an inverted NLAP.

> >5.4.  On the use of Neighbor Discovery technologies
> >
> >   [RFC4861] specifies how IPv6 nodes may resolve link layer addresses
> >   from IPv6 addresses via the use of link-local IPv6 multicast.
> >   [RFC6775] is an optimization of [RFC4861], specifically targeting
> >   6LoWPAN networks.  [RFC6775] defines how a 6LoWPAN node may
> register
> >   IPv6 addresses with an authoritative border router (ABR).  Generally,
> >   nodes SHOULD NOT use [RFC6775] address registration.  However,
> >   address registration MUST be used if the first 6 bytes of the IID do
> >   not comply with the format defined in Figure 3.
> >
> >   In route-over environments, IPv6 hosts MUST use [RFC6775] address
> >   registration.  [RFC6775] Duplicate Address Detection (DAD) SHOULD NOT
> >   be used, since the link-layer inclusion process of G.9959 ensures
> >   that a NodeID is unique for a given HomeID.
> 
> Should the first paragraph say instead:
> 
> In mesh-under networks, nodes SHOULD NOT use [RFC6775] address
> registration.
> However, address registration MUST be used if the first 6 bytes of the IID do
> not comply with the format defined in Figure 3.
> 
> It seems like paragraph would otherwise make it less "generally".

I agree in your proposal.

> I would like section 5.4.2 to be split into multiple paragraphs/points for the
> various requirements.

Agreed. This text is a bit massive.

The text has been split into more paragraphs.

> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
> -= IPv6 IoT consulting for hire =-
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 10 Jan 2014 21:33:08 +0000

Hello All:

Happy new year!  

We are ending LC for this document in January 15th (next week).

Please comment on this draft by Jan 15th after which Anders will have a revised draft for the next set of reviews.

Best regards,
-Samita

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Anders Brandt
Sent: Thursday, January 02, 2014 4:52 AM
To: Michael Richardson; [email-masked]
Subject: Re: [6lo] WG last call for draft-ietf-6lo-lowpanz-00

Hi Michael

Thanks,
  Anders

The correct interpretation is that the mesh-under specification itself is out of scope.
The draft definitely applies to direct range, mesh-under as well as route-over deployments.

> I understand that this document is neither mandating it, nor 
> describing, but I am curious to understand if it can be done... I 
> think I read that G.9959 networks are never more than one layer deep.

You are right. G.9959 only describes direct range transmission.
The specification does however define a "Routed" frame type which allows the MAC layer to forward such frames to a mesh-under routing layer.
Thus, G.9959 networks can definitely be deeper than one hop.

With regards to security, this draft borrows a lot from RFC4944; also security considerations.
The purpose of requiring shared network key security is to establish a basic level of protection against general wireless intrusion. It is not precluding additional security for critical applications (like door locks).
Thus, node-to-node security key pairs are definitely possible.

> Section 4: is there any value in having a unique dispatch value for 
> G.9959 vs 15.4?

There is no unique dispatch value for G.9959. To maintain the highest possible re-use from RFC4944, we use the dispatch codes of RFC4944 - except for the deprecated ones.
The dispatch header format does however represent one of the few differences from RFC4944:

RFC4944 assumes that 6LoWPAN networks are created from scratch and that other technologies added to the 802.15.4 network at a later stage have to detect the "NLAP" dispatch value.

LoWPANz capable nodes may be added to existing G.9959 networks. 
The additional "6LoWPAN CmdCls" octet allows legacy G.9959 nodes to ignore LoWPANz payload. It may be regarded as an inverted NLAP.

> However, address registration MUST be used if the first 6 bytes of the 
> IID do not comply with the format defined in Figure 3.
> 

> I would like section 5.4.2 to be split into multiple paragraphs/points 
> for the various requirements.