[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Updated by: 6282, 6775, 8025, 8066, 8931 Errata ExistNetwork Working Group G. Montenegro
Request for Comments: 4944 Microsoft Corporation
Category: Standards Track N. Kushalnagar
Intel Corp
J. Hui
D. Culler
Arch Rock Corp
September 2007
Transmission of IPv6 Packets over IEEE 802.15.4 Networks
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document describes the frame format for transmission of IPv6
packets and the method of forming IPv6 link-local addresses and
statelessly autoconfigured addresses on IEEE 802.15.4 networks.
Additional specifications include a simple header compression scheme
using shared context and provisions for packet delivery in IEEE
802.15.4 meshes.
Montenegro, et al. Standards Track [Page 1]
RFC 4944 IPv6 over IEEE 802.15.4 September 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IEEE 802.15.4 Mode for IP . . . . . . . . . . . . . . . . . . 3
3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . . 4
4. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 5
5. LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . . 6
5.1. Dispatch Type and Header . . . . . . . . . . . . . . . . . 8
5.2. Mesh Addressing Type and Header . . . . . . . . . . . . . 10
5.3. Fragmentation Type and Header . . . . . . . . . . . . . . 11
6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 13
7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 14
8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 14
9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 16
10. Header Compression . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Encoding of IPv6 Header Fields . . . . . . . . . . . . . . 17
10.2. Encoding of UDP Header Fields . . . . . . . . . . . . . . 19
10.3. Non-Compressed Fields . . . . . . . . . . . . . . . . . . 21
10.3.1. Non-Compressed IPv6 Fields . . . . . . . . . . . . . 21
10.3.2. Non-Compressed and Partially Compressed UDP Fields . 21
11. Frame Delivery in a Link-Layer Mesh . . . . . . . . . . . . . 21
11.1. LoWPAN Broadcast . . . . . . . . . . . . . . . . . . . . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
15.1. Normative References . . . . . . . . . . . . . . . . . . . 26
15.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Alternatives for Delivery of Frames in a Mesh . . . . 28
1. Introduction
The IEEE 802.15.4 standard [ieee802.15.4] targets low-power personal
area networks. This document defines the frame format for
transmission of IPv6 [RFC2460] packets as well as the formation of
IPv6 link-local addresses and statelessly autoconfigured addresses on
top of IEEE 802.15.4 networks. Since IPv6 requires support of packet
sizes much larger than the largest IEEE 802.15.4 frame size, an
adaptation layer is defined. This document also defines mechanisms
for header compression required to make IPv6 practical on IEEE
802.15.4 networks, and the provisions required for packet delivery in
IEEE 802.15.4 meshes. However, a full specification of mesh routing
(the specific protocol used, the interactions with neighbor
discovery, etc) is out of the scope of this document.
Montenegro, et al. Standards Track [Page 2]
RFC 4944 IPv6 over IEEE 802.15.4 September 2007
1.1. Requirements Notation
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 [RFC2119].
1.2. Terms Used
AES: Advanced Encryption Scheme
CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance
FFD: Full Function Device
GTS: Guaranteed Time Service
MTU: Maximum Transmission Unit
MAC: Media Access Control
PAN: Personal Area Network
RFD: Reduced Function Device
2. IEEE 802.15.4 Mode for IP
IEEE 802.15.4 defines four types of frames: beacon frames, MAC
command frames, acknowledgement frames, and data frames. IPv6
packets MUST be carried on data frames. Data frames may optionally
request that they be acknowledged. In keeping with [RFC3819], it is
recommended that IPv6 packets be carried in frames for which
acknowledgements are requested so as to aid link-layer recovery.
IEEE 802.15.4 networks can either be nonbeacon-enabled or beacon-
enabled [ieee802.15.4]. The latter is an optional mode in which
devices are synchronized by a so-called coordinator's beacons. This
allows the use of superframes within which a contention-free
Guaranteed Time Service (GTS) is possible. This document does not
require that IEEE networks run in beacon-enabled mode. In nonbeacon-
enabled networks, data frames (including those carrying IPv6 packets)
are sent via the contention-based channel access method of unslotted
CSMA/CA.
In nonbeacon-enabled networks, beacons are not used for
synchronization. However, they are still useful for link-layer
device discovery to aid in association and disassociation events.
This document recommends that beacons be configured so as to aid
these functions. A further recommendation is for these events to be
Montenegro, et al. Standards Track [Page 3]
RFC 4944 IPv6 over IEEE 802.15.4 September 2007
available at the IPv6 layer to aid in detecting network attachment, a
problem being worked on at the IETF at the time of this writing.
The specification allows for frames in which either the source or
destination addresses (or both) are elided. The mechanisms defined
in this document require that both source and destination addresses
be included in the IEEE 802.15.4 frame header. The source or
destination PAN ID fields may also be included.
3. Addressing Modes
IEEE 802.15.4 defines several addressing modes: it allows the use of
either IEEE 64-bit extended addresses or (after an association event)
16-bit addresses unique within the PAN [ieee802.15.4]. This document
supports both 64-bit extended addresses, and 16-bit short addresses.
For use within 6LoWPANs, this document imposes additional constraints
(beyond those imposed by IEEE 802.15.4) on the format of the 16-bit
short addresses, as specified in Section 12. Short addresses being
transient in nature, a word of caution is in order: since they are
doled out by the PAN coordinator function during an association
event, their validity and uniqueness is limited by the lifetime of
that association. This can be cut short by the expiration of the
association or simply by any mishap occurring to the PAN coordinator.
Because of the scalability issues posed by such a centralized
allocation and single point of failure at the PAN coordinator,
deployers should carefully weigh the tradeoffs (and implement the
necessary mechanisms) of growing such networks based on short
addresses. Of course, IEEE 64-bit extended addresses may not suffer
from these drawbacks, but still share the remaining scalability
issues concerning routing, discovery, configuration, etc.
This document assumes that a PAN maps to a specific IPv6 link. This
complies with the recommendation that shared networks support link-
layer subnet [RFC3819] broadcast. Strictly speaking, it is multicast
not broadcast that exists in IPv6. However, multicast is not
supported natively in IEEE 802.15.4. Hence, IPv6 level multicast
packets MUST be carried as link-layer broadcast frames in IEEE
802.15.4 networks. This MUST be done such that the broadcast frames
are only heeded by devices within the specific PAN of the link in
question. As per Section 7.5.6.2 in [ieee802.15.4], this is
accomplished as follows:
1. A destination PAN identifier is included in the frame, and it
MUST match the PAN ID of the link in question.
2. A short destination address is included in the frame, and it MUST
match the broadcast address (0xffff).
Montenegro, et al. Standards Track [Page 4]
RFC 4944 IPv6 over IEEE 802.15.4 September 2007
Additionally, support for mapping of IPv6 multicast addresses per
Section 9 MUST only be used in a mesh configuration. A full
specification of such functionality is out of the scope of this
document.
As usual, hosts learn IPv6 prefixes via router advertisements as per
[RFC4861].
4. Maximum Transmission Unit
The MTU size for IPv6 packets over IEEE 802.15.4 is 1280 octets.
However, a full IPv6 packet does not fit in an IEEE 802.15.4 frame.
802.15.4 protocol data units have different sizes depending on how
much overhead is present [ieee802.15.4]. Starting from a maximum
physical layer packet size of 127 octets (aMaxPHYPacketSize) and a
maximum frame overhead of 25 (aMaxFrameOverhead), the resultant
maximum frame size at the media access control layer is 102 octets.
Link-layer security imposes further overhead, which in the maximum
case (21 octets of overhead in the AES-CCM-128 case, versus 9 and 13
for AES-CCM-32 and AES-CCM-64, respectively) leaves only 81 octets
available. This is obviously far below the minimum IPv6 packet size
of 1280 octets, and in keeping with Section 5 of the IPv6
specification [RFC2460], a fragmention and reassembly adaptation
layer must be provided at the layer below IP. Such a layer is
defined below in Section 5.
Furthermore, since the IPv6 header is 40 octets long, this leaves
only 41 octets for upper-layer protocols, like UDP. The latter uses
8 octets in the header which leaves only 33 octets for application
data. Additionally, as pointed out above, there is a need for a
fragmentation and reassembly layer, which will use even more octets.
The above considerations lead to the following two observations:
1. The adaptation layer must be provided to comply with the IPv6
requirements of a minimum MTU. However, it is expected that (a)
most applications of IEEE 802.15.4 will not use such large
packets, and (b) small application payloads in conjunction with
the proper header compression will produce packets that fit
within a single IEEE 802.15.4 frame. The justification for this
adaptation layer is not just for IPv6 compliance, as it is quite
likely that the packet sizes produced by certain application
exchanges (e.g., configuration or provisioning) may require a
small number of fragments.
2. Even though the above space calculation shows the worst-case
scenario, it does point out the fact that header compression is
compelling to the point of almost being unavoidable. Since we
Montenegro, et al. Standards Track [Page 5]
RFC 4944 IPv6 over IEEE 802.15.4 September 2007
expect that most (if not all) applications of IP over IEEE
802.15.4 will make use of header compression, it is defined below
in Section 10.