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

From: Samita Chakrabarti <[email-masked]>
Date: Sat, 21 Dec 2013 01:38:50 +0000

This email initiates a 6lo WG Last Call for:

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.

Due to the holiday season, we have extended the Last call time period; this last call ends on January 15, 2014.

Thanks,
-Samita Chakrabarti

---

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Dec 2013 16:36:55 -0500

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

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

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

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

>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 would like section 5.4.2 to be split into multiple paragraphs/points for
the various requirements.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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