6LoWPAN Working Group                                         C. Bormann
Internet-Draft                                   Universitaet Bremen TZI
Intended status: Standards Track                          April 13, 2013
Expires: October 15, 2013

                6LoWPAN Roadmap and Implementation Guide


   6LoWPAN is defined in RFC 4944 in conjunction with a number of
   specifications that are currently nearing completion.  The entirety
   of these specifications may be hard to understand, pose specific
   implementation problems, or be simply inconsistent.

   The present guide aims to provide a roadmap to these documents as
   well as provide specific advice how to use these specifications in
   combination.  In certain cases, it may provide clarifications or even
   corrections to the specifications referenced.

   This guide is intended as a continued work-in-progress, i.e.  a long-
   lived Internet-Draft, to be updated whenever new information becomes
   available and new consensus on how to handle issues is formed.
   Similar to the ROHC implementation guide, RFC 4815, it might be
   published as an RFC at some future time later in the maintenance
   curve of the specifications.

   This document does not describe a new protocol or attempt to set a
   new standard of any kind - it mostly describes good practice in using
   the existing specifications, but it may also document emerging
   consensus where a correction needs to be made.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Bormann                 Expires October 15, 2013                [Page 1]

Internet-Draft  6LoWPAN Roadmap and Implementation Guide      April 2013

   This Internet-Draft will expire on October 15, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Optional components of 6LoWPAN  . . . . . . . . . . . . .   3
     2.2.  6LoWPAN MIB work  . . . . . . . . . . . . . . . . . . . .   4
   3.  6LoWPAN family  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  6LoWPAN over Bluetooth Low Energy (BT-LE) . . . . . . . .   4
     3.2.  6LoWPAN over DECT Ultra Low Energy (DECT-ULE) . . . . . .   5
     3.3.  6LoWPAN over G.9959 (lowpanz) . . . . . . . . . . . . . .   5
   4.  6LoWPAN MTU . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  PAN identifiers in IPv6 addresses . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   (To be written - for now please read the Abstract.)

1.1.  Terminology

   This document is a guide.  However, it might evolve to make specific
   recommendations on how to use standards-track specifications.
   Therefore: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",

Bormann                 Expires October 15, 2013                [Page 2]

Internet-Draft  6LoWPAN Roadmap and Implementation Guide      April 2013

   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119.  They indicate requirement levels for compliant 6LoWPAN
   implementations [RFC2119].  Note that these keywords are not only
   used where a correction or clarification is intended; the latter are
   explicitly identified as such.

   The term "byte" is used in its now customary sense as a synonym for

2.  6LoWPAN

   What is a 6LoWPAN?

   The term, originally just the name of the IETF Working Group (WG)
   that created the specifications, nowadays refers to a specific way of
   building IP-connected wireless networks for embedded use cases.  The
   6LoWPAN core specifications are:

   o  [RFC4944], as updated by

   o  [RFC6282] and

   o  [RFC6775].

   While [RFC4944] defines 6LoWPAN specifically for IEEE 802.15.4
   networks, 6LoWPAN concepts have been applied to other PHY/MAC layers.

   6LoWPANs MAY use additional protocols, such as [RFC6550] for routing,
   or [I-D.ietf-core-coap] for application data transfer.  However, the
   "6LoWPANness" of a network is caused by adherence to the core

2.1.  Optional components of 6LoWPAN

   Additional sub-protocols are being discussed in the IETF that may
   become optional protocols in 6LoWPANs.

   For instance, [I-D.bormann-6lowpan-ghc] defines an extension to
   [RFC6282] that enables header compression of additional headers and
   header-like protocols, including ICMPv6 and RPL.

   One other recent proposal, in a much more nascent stage, that may be
   of interest to application designers targeting link layers with small
   frame sizes is Adaptation Layer Fragmentation Indication (ALFI),

   The present document will track these sub-protocols and be amended
   once the sub-protocols reach formal status in the IETF.

Bormann                 Expires October 15, 2013                [Page 3]

Internet-Draft  6LoWPAN Roadmap and Implementation Guide      April 2013

2.2.  6LoWPAN MIB work

   For management of 6LoWPAN networks, a MIB is being proposed in
   [I-D.schoenw-6lowpan-mib].  Besides the usual SMIv2 MIB format that
   directly enables management access via SNMP, this draft also
   demonstrates a JSON format using a version of the MIB translated into
   YANG [RFC6020] as defined in [RFC6643] and made available using the
   JSON representation defined in [I-D.lhotka-netmod-yang-json].  This
   may facilitate using CoRE protocols for management access
   [I-D.ersue-constrained-mgmt], reducing the number transfer protocols
   that need to be implemented on a constrained node.

3.  6LoWPAN family

   In addition to the support for IEEE 802.15.4 provided by [RFC4944],
   additional PHY/MAC layers outside IEEE 802.15.4 (or even 802.15) are
   being addressed by 6LoWPAN technology.

   E.g., [I-D.ietf-6lowpan-btle] applies 6LoWPAN technology to Bluetooth
   Low Energy ("Bluetooth Smart").  As this has passed both 6LoWPAN
   Working-Group and IETF Last Call and has received one round of IESG
   consideration (now waiting for the allocation of a number from the
   BT-SIG), it is becoming part of the "6LoWPAN family" as a companion
   specification to [RFC4944], if not part of the (IEEE 802.15.4
   focused) term 6LoWPAN itself.

   At an earlier stage of work, [I-D.mariager-6lowpan-v6over-dect-ule]
   aims to define 6LoWPAN technology for DECT ULE (Ultra Low Energy),
   which might become another companion spec to [RFC4944].  Similarly,
   [I-D.brandt-6man-lowpanz] is a first draft defining 6LoWPAN
   technology for the ITU-T G.9959 radio.

   In the further evolution of the 6LoWPAN family, we have to be careful
   what changes apply to all members of the family, and which are PHY/
   MAC specific.

3.1.  6LoWPAN over Bluetooth Low Energy (BT-LE)

   [I-D.ietf-6lowpan-btle] similarly specifies the combination of

   o  [RFC4944], as updated by

   o  [RFC6282] and

   o  [RFC6775].

   as the basis for IPv6 over BT-LE, removing a couple of features from
   [RFC4944] as they are covered by or become unnecessary in BT-LE:

Bormann                 Expires October 15, 2013                [Page 4]

Internet-Draft  6LoWPAN Roadmap and Implementation Guide      April 2013

   o  Mesh header

   o  Fragmentation

3.2.  6LoWPAN over DECT Ultra Low Energy (DECT-ULE)

   [I-D.mariager-6lowpan-v6over-dect-ule] is stabilizing in parallel to
   the base documents that are maturing within ETSI.  While silicon is
   already available, complete systems with final firmware (and thus
   stable specs) are expected within 2012.

3.3.  6LoWPAN over G.9959 (lowpanz)

   [I-D.brandt-6man-lowpanz] was recently discussed at IETF86 in Orlando
   and will soon receive an update based on this discussion.  The G.9959
   radio used in this specification operates in various regionally
   available frequencies around 900 MHz ("sub-GHz") and is best known
   for its use in the Z-Wave suite of products.  As with BT-LE, this MAC
   layer already defines a Segmentation and Reassembly (SAR) layer, so
   packets larger than the G.9959 MAC PDU can be transmitted without the
   need for [RFC4944] fragmentation.  Similarly, MAC layer mesh
   forwarding is available for G.9959 already.


   IPv6 defines a minimal value for the "Minimum Transmission Unit",
   MTU, of 1280 bytes.  This means that every IPv6 network must be able
   to transfer a packet of at least 1280 bytes of IPv6 headers and data
   without requiring fragmentation.

   A common Internet MTU is 1500 bytes (motivated by the Ethernet MTU).
   The gap between 1280 and 1500 allows tunneling protocols to insert
   headers on the way from the source of a packet to a destination
   without breaking the overall MTU of the path.  As various tunneling
   protocols do indeed insert bytes, it is unwise to simply assume an
   end-to-end MTU of 1500 bytes even with the current dominance of
   Ethernet.  Path MTU discovery [RFC1981] [RFC4821] has been defined to
   enable transport protocols to find an MTU value better than 1280
   bytes, but still reliably within the MTU of the path being used.
   Path MTU discovery places, however, additional strain on constrained
   nodes, which therefore may want to stick with an MTU of 1280 bytes
   for all IPv6 applications.

   6LoWPAN was designed as a stub network, not requiring any tunneling.
   As IEEE 802.15.4 packets are rather small (127 bytes maximum at the
   physical layer, minus MAC/security and adaptation layer overhead),
   1280 bytes was already considered a somewhat large packet size.
   Therefore, the 6LoWPAN network MTU was simply set at the minimum size

Bormann                 Expires October 15, 2013                [Page 5]

Internet-Draft  6LoWPAN Roadmap and Implementation Guide      April 2013

   allowable by IPv6, 1280 bytes, although the 6LoWPAN fragmentation
   mechanism is able to support packets with total lengths (including
   the initial IPv6 header) of up to 2047 bytes.

   As a more recent development, some modes of operation of the RPL
   protocol [RFC6550] do indeed operate by tunneling data packets
   between RPL routers.  Maintaining the MTU visible to applications at
   1280 therefore requires making a larger MTU available to the tunnels.

   6LoWPAN routers that employ RPL therefore MUST support a more
   appropriate MTU between routers that make use of tunneling between
   them.  [The specific MTU value is TBD, to be chosen between 1280 and
   2047 based on RPL considerations that need to be added to this

5.  PAN identifiers in IPv6 addresses

   [RFC4944] incorporates PAN identifiers in IPv6 addresses created from
   16-bit MAC addresses, in a somewhat awkward way (one of the 16 bits
   needs to be cleared to enable the U/L bit.).

   As the use of PAN identifiers in 6LoWPAN networks has since become
   less and less meaningful, [RFC6282] provides specific support only
   for interface IDs of the form 0000:00ff:fe00:XXXX, i.e.  PAN
   identifiers of zero.  (Other forms can be supported by creating
   sufficiently long pieces of compression context information for each
   non-zero PAN identifier; however there is a limited number of context
   elements and each consumes space in all nodes of a 6LoWPAN.)

   It is therefore RECOMMENDED to employ a PAN identifier of zero with

   (While this discussion is specific to IEEE 802.15.4 networks, the
   recommendation to build short addresses in a way that enables
   [RFC6282] compression may apply to other PHY/MAC technologies as

6.  IANA Considerations

   This document has no actions for IANA.

7.  Security Considerations

   (None so far; this section will certainly grow as additional security
   considerations beyond those listed in the base specifications become

Bormann                 Expires October 15, 2013                [Page 6]

Internet-Draft  6LoWPAN Roadmap and Implementation Guide      April 2013

8.  Acknowledgements

   (The concept for this document is borrowed from [RFC4815], which was
   invented by Lars-Erik Jonsson.  Thanks!)

9.  References

9.1.  Normative References

              Brandt, A. and J. Buron, "Transmission of IPv6 packets
              over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-00
              (work in progress), February 2013.

              Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
              Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets
              over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12
              (work in progress), February 2013.

              Mariager, P. and J. Petersen, "Transmission of IPv6
              Packets over DECT Ultra Low Energy", draft-mariager-
              6lowpan-v6over-dect-ule-02 (work in progress), May 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [RFC6282]  Hui, J. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              September 2011.

   [RFC6775]  Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
              "Neighbor Discovery Optimization for IPv6 over Low-Power
              Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
              November 2012.

9.2.  Informative References

              Bormann, C., "6LoWPAN Generic Compression of Headers and
              Header-like Payloads", draft-bormann-6lowpan-ghc-06 (work
              in progress), March 2013.

Bormann                 Expires October 15, 2013                [Page 7]

Internet-Draft  6LoWPAN Roadmap and Implementation Guide      April 2013

              Bormann, C., "Adaptation Layer Fragmentation Indication",
              draft-bormann-intarea-alfi-03 (work in progress), March

              Ersue, M., Romascanu, D., and J. Schoenwaelder,
              "Management of Networks with Constrained Devices: Problem
              Statement, Use Cases and Requirements", draft-ersue-
              constrained-mgmt-03 (work in progress), February 2013.

              Shelby, Z., Hartke, K., and C. Bormann, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-14
              (work in progress), March 2013.

              Lhotka, L., "Modeling JSON Text with YANG", draft-lhotka-
              netmod-yang-json-01 (work in progress), April 2013.

              Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou,
              "Definition of Managed Objects for IPv6 over Low-Power
              Wireless Personal Area Networks (6LoWPANs)", draft-
              schoenw-6lowpan-mib-03 (work in progress), February 2013.

   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
              for IP version 6", RFC 1981, August 1996.

   [RFC4815]  Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer,
              "RObust Header Compression (ROHC): Corrections and
              Clarifications to RFC 3095", RFC 4815, February 2007.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, March 2007.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC6550]  Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
              Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
              Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
              Lossy Networks", RFC 6550, March 2012.

   [RFC6643]  Schoenwaelder, J., "Translation of Structure of Management
              Information Version 2 (SMIv2) MIB Modules to YANG
              Modules", RFC 6643, July 2012.

Bormann                 Expires October 15, 2013                [Page 8]

Internet-Draft  6LoWPAN Roadmap and Implementation Guide      April 2013

Author's Address

   Carsten Bormann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359

   Phone: +49-421-218-63921
   Email: cabo@tzi.org

Bormann                 Expires October 15, 2013                [Page 9]