6LoWPAN Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track March 26, 2012
Expires: September 27, 2012
6LoWPAN Roadmap and Implementation Guide
draft-bormann-6lowpan-roadmap-01
Abstract
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 acceptance curve
of the specifications.
This document does not describe a new protocol or attempts 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.
The current version -01 of this document is an early draft that is
intended to spark the further collection of relevant information.
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
Bormann Expires September 27, 2012 [Page 1]
Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2012
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 27, 2012.
Copyright Notice
Copyright (c) 2012 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.
Bormann Expires September 27, 2012 [Page 2]
Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Optional components of 6LoWPAN . . . . . . . . . . . . . . 5
3. 6LoWPAN family . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. 6LoWPAN over Bluetooth Low Energy (BT-LE) . . . . . . . . 6
3.2. 6LoWPAN over DECT Ultra Low Energy (DECT-ULE) . . . . . . 6
4. 6LoWPAN MTU . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. PAN identifiers in IPv6 addresses . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Bormann Expires September 27, 2012 [Page 3]
Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2012
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 specification.
Therefore: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"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
"octet".
Bormann Expires September 27, 2012 [Page 4]
Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2012
2. 6LoWPAN
What is a 6LoWPAN?
The term, originally just the name of the IETF 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 [I-D.ietf-6lowpan-nd].
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 [I-D.ietf-roll-rpl]
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 specifications.
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.
This document will track these sub-protocols and be amended once the
sub-protocols reach formal status in the IETF.
Bormann Expires September 27, 2012 [Page 5]
Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2012
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 6LoWPAN Working-
Group Last-Call and is nearing IESG consideration, 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].
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 [I-D.ietf-6lowpan-nd].
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:
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.
Bormann Expires September 27, 2012 [Page 6]
Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2012
4. 6LoWPAN MTU
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
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 [I-D.ietf-roll-rpl] 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
document.]
Bormann Expires September 27, 2012 [Page 7]
Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2012
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
6LoWPAN.
(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
well.)
Bormann Expires September 27, 2012 [Page 8]
Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2012
6. IANA Considerations
This document has no actions for IANA.
Bormann Expires September 27, 2012 [Page 9]
Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2012
7. Security Considerations
(None so far; this section will certainly grow as additional security
considerations beyond those listed in the base specifications become
known.)
Bormann Expires September 27, 2012 [Page 10]
Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2012
8. Acknowledgements
(The concept for this document is borrowed from [RFC4815], which was
invented by Lars-Erik Jonsson. Thanks!)
Bormann Expires September 27, 2012 [Page 11]
Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2012
9. References
9.1. Normative References
[I-D.ietf-6lowpan-btle]
Nieminen, J., Patil, B., Savolainen, T., Isomaki, M.,
Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets
over Bluetooth Low Energy", draft-ietf-6lowpan-btle-06
(work in progress), March 2012.
[I-D.ietf-6lowpan-nd]
Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
Discovery Optimization for Low Power and Lossy Networks
(6LoWPAN)", draft-ietf-6lowpan-nd-18 (work in progress),
October 2011.
[I-D.mariager-6lowpan-v6over-dect-ule]
Mariager, P. and J. Petersen, "Transmission of IPv6
Packets over DECT Ultra Low Energy",
draft-mariager-6lowpan-v6over-dect-ule-01 (work in
progress), October 2011.
[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.
9.2. Informative References
[I-D.bormann-6lowpan-ghc]
Bormann, C., "6LoWPAN Generic Compression of Headers and
Header-like Payloads", draft-bormann-6lowpan-ghc-03 (work
in progress), October 2011.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-09 (work in progress), March 2012.
[I-D.ietf-roll-rpl]
Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P.,
Levis, P., Struik, R., Kelsey, R., Clausen, T., and T.
Bormann Expires September 27, 2012 [Page 12]
Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2012
Winter, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011.
[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.
Bormann Expires September 27, 2012 [Page 13]
Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2012
Author's Address
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Fax: +49-421-218-7000
Email: cabo@tzi.org
Bormann Expires September 27, 2012 [Page 14]