Network Working Group G. Montenegro
Internet-Draft Microsoft Corporation
Expires: April 27, 2006 N. Kushalnagar
Intel Corp
October 24, 2005
Transmission of IPv6 Packets over IEEE 802.15.4 Networks
draft-ietf-6lowpan-format-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
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 & Kushalnagar Expires April 27, 2006 [Page 1]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
1.2. Terms used . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IEEE 802.15.4 mode for IP . . . . . . . . . . . . . . . . . . 3
3. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 4
4. LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . . 5
4.1. Link Fragmentation . . . . . . . . . . . . . . . . . . . . 5
4.2. Reassembly . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Stateless Address Autoconfiguration . . . . . . . . . . . . . 9
6. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 10
7. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 10
8. Header Compression . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Encoding of IPv6 Header Fields . . . . . . . . . . . . . . 12
8.2. Encoding of UDP Header Fields . . . . . . . . . . . . . . 14
8.3. Non-Compressed Fields . . . . . . . . . . . . . . . . . . 15
8.3.1. Non-Compressed IPv6 Fields . . . . . . . . . . . . . . 15
8.3.2. Non-Compressed and partially compressed UDP fields . . 16
9. Frame Delivery in a Link-Layer Mesh . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Alternatives for Delivery of Frames in a Mesh . . . . 21
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Montenegro & Kushalnagar Expires April 27, 2006 [Page 2]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
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. Likewise, the provisions required for packet
delivery in IEEE 802.15.4 meshes is defined. However, a full
specification of mesh routing (the specific protocol used, the
interactions with neighbor discovery, etc) is out of scope of this
document.
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
Montenegro & Kushalnagar Expires April 27, 2006 [Page 3]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
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
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.
IEEE 802.15.4 defines several addressing modes. 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.
IEEE 802.15.4 allows the use of either IEEE 64 bit extended addresses
or (after an association event) 16 bit addresses unique within the
PAN. This document supports both 64 bit extended addresses, and 16
bit short addresses.
This document assumes that a PAN maps to a specific IPv6 link, hence
it implies a unique prefix. Knowledge of the 16-bit PAN ID (e.g., by
including it in the IEEE 802.15.4 headers would enable automatically
mapping it to the corresponding IPv6 prefix. One possible method is
to concatenate the 16 bits of PAN ID to a /48 in order to obtain the
64-bit link prefix. Whichever method is used, the assumption in this
document is that a given PAN ID maps to a unique IPv6 prefix. 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 in IEEE 802.15.4. Hence, IPv6 level multicast packets MUST
be carried as link-layer broadcast frames in IEEE 802.15.4 networks.
As usual, hosts learn IPv6 prefixes via router advertisements
([I-D.ietf-ipv6-2461bis]).
3. 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
Montenegro & Kushalnagar Expires April 27, 2006 [Page 4]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
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 4.
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 IPv6
requirements of 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
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
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 8.
4. LoWPAN Adaptation Layer and Frame Format
4.1. Link Fragmentation
All IP datagrams transported over IEEE 802.15.4 are prefixed by an
encapsulation header with one of the formats illustrated below. The
encapsulation header size is either 2 octets (in the common
'unfragmented' case) or 4 octets (in the 'fragmented' case). The
encapsulation formats defined in this section, (subsequently referred
to as the "LowPAN encapsulation") are the payload in the IEEE
Montenegro & Kushalnagar Expires April 27, 2006 [Page 5]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
802.15.4 MAC protocol data unit (PDU). The LoWPAN payload (e.g., an
IPv6 packet) follows this encapsulation header. Alternatively, if
the 'M' bit is on, a "Mesh Delivery" field will be present
(Section 9) before the LoWPAN payload.
If an entire payload (e.g., IPv6) datagram fits within a single
802.15.4 frame, it is unfragmented and the LoWPAN encapsulation SHALL
conform to the format illustrated below.
NOTE: The field marked "rsv" SHALL be set to zero upon transmission,
and ignored upon reception.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LF| prot_type |M| rsv |Payload (or Mesh Delivery Hdr)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: LoWPAN unfragmented encapsulation header format
Field definitions are as follows:
LF: This 2 bit field SHALL be zero.
prot_type: This 8 bit field SHALL indicate the nature of the datagram
that follows. In particular, the prot_type for IPv6 is 1
hexadecimal. The value 2 hexadecimal is defined below for header
compression (Section 8). Other protocols may use this
encapsulation format, but such use is outside the scope of this
document. Subsequent assignments are to be handled by IANA
(Section 10).
M: This bit is used to signal whether there is a "Mesh Delivery"
field as used for ad hoc or mesh routing. If set to 1, a "Mesh
Delivery" field precedes the payload (e.g., IPv6) packet
(Section 9).
If the datagram does not fit within a single IEEE 802.15.4 frame, it
SHALL be broken into link fragments. The first link fragment SHALL
conform to the format shown below.
Montenegro & Kushalnagar Expires April 27, 2006 [Page 6]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LF| prot_type |M| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (or Mesh Delivery Hdr)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: LoWPAN first fragment encapsulation header format
The second and subsequent link fragments (up to and including the
last) SHALL conform to the format shown below.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LF|datagram_offset|M| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (or Mesh Delivery Hdr)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: LoWPAN subsequent fragment(s) encapsulation header format
Field definitions are as follows:
LF: This 2 bit field SHALL specify the relative position of the link
fragment within the payload datagram, as encoded by the following
table.
LF Position
+-------------------------------------------+
| 00 | Unfragmented (Figure 1) |
| 01 | First Fragment (Figure 2) |
| 10 | Last Fragment (Figure 3) |
| 11 | Interior Fragment (Figure 3) |
+-------------------------------------------+
Figure 4: Link Fragment Bit Pattern
datagram_size: This 11 bit field encodes the size of the entire
payload datagram. The value of datagram_size SHALL be the same
for all link fragments of a payload datagram. For IPv6, this
SHALL be 40 octets more (the size of the IPv6 header) than the
value of Payload Length in the IPv6 header [RFC2460]. Typically,
this field needs to encode a maximum length of 1280 (IEEE 802.15.4
link MTU as defined in this document), and as much as 1500 (the
default maximum IPv6 packet size if IPv6 fragmentation is in use).
Montenegro & Kushalnagar Expires April 27, 2006 [Page 7]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
Therefore, this field is 11 bits long, which works in either case.
NOTE: This field does not need to be in every packet, as one could
send it with the first fragment and elide it subsequently.
However, including it in every link fragment eases the task of
reassembly in the event that a second (or subsequent) link
fragment arrives before the first. In this case, the guarantee of
learning the datagram_size as soon as any of the fragments arrives
tells the receiver how much buffer space to set aside as it waits
for the rest of the fragments. The format above trades off
simplicity for efficiency.
prot_type: This 8 bit field is present only in the first link
fragment. For possible values, see Section 10.
M: This bit present to allow delivery of link fragment in a mesh. If
set to 1, a "Mesh Delivery" field is present as per Section 9.
fragment_offset: This field is present only in the second and
subsequent link fragments and SHALL specify the offset, in
increments of 8 octets, of the fragment from the beginning of the
payload datagram. The first octet of the datagram (e.g., the
start of the IPv6 header) has an offset of zero; the implicit
value of fragment_offset in the first link fragment is zero. This
field is 8 bits long.
datagram_tag: The value of datagram_tag (datagram tag) SHALL be the
same for all link fragments of a payload (e.g., IPv6) datagram.
The sender SHALL increment datagram_tag for successive, fragmented
datagrams. The incremented value of datagram_tag SHALL wrap from
1023 back to zero. This field is 10 bits long, and its initial
value is not defined.
All protocol datagrams (e.g., IPv6) SHALL be preceded by one of the
LoWPAN encapsulation headers described above. This permits uniform
software treatment of datagrams without regard to the mode of their
transmission.
4.2. Reassembly
The recipient of an payload datagram transmitted via more than one
802.15.4 packet SHALL use both the sender's 802.15.4 source address
and datagram_tag to identify all the link fragments from a single
datagram.
Upon receipt of a link fragment, the recipient may place the data
Montenegro & Kushalnagar Expires April 27, 2006 [Page 8]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
payload (except the encapsulation header) within a payload datagram
reassembly buffer at the location specified by fragment_offset. The
size of the reassembly buffer SHALL be determined from datagram_size.
If a link fragment is received that overlaps another fragment
identified by the same source address and datagram_tag, the
fragment(s) already accumulated in the reassembly buffer SHALL be
discarded. A fresh reassembly may be commenced with the most
recently received link fragment. Fragment overlap is determined by
the combination of fragment_offset from the encapsulation header and
data_length from the 802.15.4 packet header.
Upon detection of a IEEE 802.15.4 Disassociation event, fragment
recipients SHOULD discard all link fragments of all partially
reassembled payload datagrams, and fragment senders SHOULD discard
all not yet transmitted link fragments of all partially transmitted
payload (e.g., IPv6) datagrams. Similarly, a reassembly timer is
started upon reception of the first fragment in a packet. If after
15 seconds the entire packet has not been reassembled, the existing
fragments SHOULD be discarded and the reassembly state SHOULD be
flushed.
5. Stateless Address Autoconfiguration
This section defines how to obtain an IPv6 interface identifier based
on either of the two possible address types: EUI-64, or 16-bit short
addresses.
The Interface Identifier [RFC3513] for an IEEE 802.15.4 interface is
based on the EUI-64 identifier [EUI64] assigned to the IEEE 802.15.4
device. The Interface Identifier is formed from the EUI-64 according
to the "IPv6 over Ethernet" specification [RFC2464].
All 802.15.4 devices have an IEEE EUI-64 address, but sometimes the
16-bit short addresses are used instead. In these cases, first, a
"pseudo 48-bit address" is formed by concatenating 32 zero bits, with
the 16-bit short address. This produces a 48-bit address as follows:
32_zero_bits:16-bit_short_address. The interface identifier is
formed from this 48-bit address as per the "IPv6 over Ethernet"
specification. However, in the resultant interface identifier, the
"Universal/Local" (U/L) bit SHALL be set to 0, in keeping with the
fact that this is not a globally unique value.
A different MAC address set manually or by software MAY be used to
derive the Interface Identifier. If such a MAC address is used, its
global uniqueness property should be reflected in the value of the
U/L bit.
Montenegro & Kushalnagar Expires April 27, 2006 [Page 9]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
An IPv6 address prefix used for stateless autoconfiguration
[I-D.ietf-ipv6-rfc2462bis] of an IEEE 802.15.4 interface MUST have a
length of 64 bits.
6. IPv6 Link Local Address
The IPv6 link-local address [RFC3513] for an IEEE 802.15.4 interface
is formed by appending the Interface Identifier, as defined above, to
the prefix FE80::/64.
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Figure 5
7. Unicast Address Mapping
The procedure for mapping IPv6 unicast addresses into IEEE 802.15.4
link-layer addresses is described in [I-D.ietf-ipv6-2461bis].
The Source/Target Link-layer Address option has the following forms
when the link layer is IEEE 802.15.4 and the addresses are EUI-64 or
16-bit short addresses, respectively.
Montenegro & Kushalnagar Expires April 27, 2006 [Page 10]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- IEEE 802.15.4 -+
| EUI-64 |
+- -+
| |
+- Address -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Padding -+
| |
+- (all zeros) -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-bit short Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Padding -+
| (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
Option fields:
Type:
1: for Source Link-layer address.
2: for Target Link-layer address.
Length: This is the length of this option (including the type and
length fields) in units of 8 octets. The value of this field is 2
if using EUI-64 addresses, or 1 if using 16-bit short addresses.
Montenegro & Kushalnagar Expires April 27, 2006 [Page 11]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
IEEE 802.15.4 Address: The 64 bit IEEE 802.15.4 address, or the 16-
bit short address, in canonical bit order. This is the address
the interface currently responds to. This address may be
different from the built-in address used to derive the Interface
Identifier, because of privacy or security (e.g., of neighbor
discovery) considerations.
8. Header Compression
There is much published and in-progress standardization work on
header compression. Nevertheless, header compression for IPv6 over
IEEE 802.15.4 has differing constraints summarized as follows:
Existing work assumes that there are many flows between any two
devices. Here, we assume that most of the time there will be only
one flow, and this allows a very simple and low context flavor of
header compression.
Given the very limited packet sizes, it is highly desirable to
integrate layer 2 with layer 3 compression, something typically
not done.
It is expected that IEEE 802.15.4 devices will be deployed in
multi-hop networks. However, header compression in a mesh departs
from the usual point-to-point link scenario in which the
compressor and decompressor are in direct and exclusive
communication with each other. In an IEEE 802.15.4 network, it is
highly desirable for a device to be able to send header compressed
packets via any of its neighbors, with as little preliminary
context-building as possible.
Preliminary context is often required. If so, it is highly
desirable to allow building it by not relying exclusively on the
in-line negotiation phase. For example, if we assume there is
some manual configuration phase that precedes deployment (perhaps
with human involvement), then one should be able to leverage this
phase to set up context such that the first packet sent will
already be compressed.
Any new packets formats required by header compression reuse the
basic packet formats defined in Section 4 by using different values
for the prot_type (defined below).
8.1. Encoding of IPv6 Header Fields
However, it is possible to use header compression even in advance of
Montenegro & Kushalnagar Expires April 27, 2006 [Page 12]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
setting up the customary state. Thus, the following common IPv6
header values may be compressed from the onset: Version is IPv6, both
IPv6 source and destination are link local, the IPv6 bottom 64 bits
can be inferred from the layer two source and destination, the packet
length can be inferred from the layer two, both the Traffic Class and
the Flow Label are zero, and the Next Header is UDP, ICMP or TCP.
The only field in the IPv6 header that always needs to be carried in
full is the Hop Limit (8 bits). Depending on how closely the packet
matches this common case, different fields may not be compressible
thus needing to be carried "in-line" as well (Section 8.3.1). This
common IPv6 header (as mentioned above) can be compressed to 2 octets
(1 octet for the HC1 encoding and 1 octet for the Hop Limit), instead
of 40 octets. Such a packet is compressible via the LOWPAN_HC1
format (assigned a prot_type value of 2 hexadecimal). It uses the
"HC1 encoding" field (8 bits) to encode the different combinations as
shown below.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC1 encoding | Non-Compressed fields follow... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: LOWPAN_HC1 (common compressed header encoding)
As can be seen below (bit 7), an HC2 encoding may follow an HC1
octet. In this case, the non-compressed fields follow the HC2
encoding field Section 8.3.
The address fields encoded by "HC1 encoding" are interpreted as
follows:
PI: Prefix carried in-line (Section 8.3.1).
PC: Prefix compressed (link-local prefix assumed).
II: Interface identifier carried in-line (Section 8.3.1).
IC: Interface identifier elided (derivable from the corresponding
link-layer address). If applied to the interface identifier of
either the source or destination address when routing in a mesh
(Section 9), the corresponding link-layer address is that found
in the "Mesh Delivery" field (Figure 9).
The "HC1 encoding" is shown below (starting with bit 0 and ending at
bit 7):
Montenegro & Kushalnagar Expires April 27, 2006 [Page 13]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
IPv6 source address (bits 0 and 1):
00: PI, II
01: PI, IC
10: PC, II
11: PC, IC
IPv6 destination address (bits 2 and 3):
00: PI, II
01: PI, IC
10: PC, II
11: PC, IC
Traffic Class and Flow Label (bit 4):
0: not compressed, full 8 bits for Traffic Class and 20 bits
for Flow Label are sent
1: Traffic Class and Flow Label are zero
Next Header (bits 5 and 6):
00: not compressed, full 8 bits are sent
01: UDP
10: ICMP
11: TCP
HC2 encoding(bit 7):
0: No more header compression bits
1: HC1 encoding immediately followed by more header compression
bits per HC2 encoding format. Bits 5 and 6 determine which
of the possible HC2 encodings apply (e.g., UDP, ICMP or TCP
encodings).
8.2. Encoding of UDP Header Fields
Bits 5 and 6 of the LOWPAN_HC1 allows compressing the Next Header
field in the IPv6 header (for UDP, TCP and ICMP). Further
compression of each of these protocol headers is also possible. This
section explains how the UDP header itself may be compressed. The
HC2 encoding in this section is the HC_UDP encoding, and it only
applies if bits 5 and 6 in HC1 indicate that the protocol that
follows the IPv6 header is UDP. The HC_UDP encoding (Figure 8)
allows compressing the following fields in the UDP header: source
port, destination port and length. The UDP header's checksum field
is not compressed and is therefore carried in full. The scheme
defined below allows compressing the UDP header to 4 octets instead
of the original 8 octets.
The only UDP header field whose value may be deduced from information
available elsewhere is the Length. The other fields must be carried
in-line either in full or in a partially compressed manner
Montenegro & Kushalnagar Expires April 27, 2006 [Page 14]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
(Section 8.3.2).
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|HC_UDP encoding| Fields carried in-line follow... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: HC_UDP (UDP common compressed header encoding)
The "HC_UDP encoding" for UDP is shown below (starting with bit 0 and
ending at bit 7):
UDP source port (bit 0):
0: Not compressed, carried "in-line" (Section 8.3.2)
1: Compressed to 4 bits. The actual 16-bit source port is
obtained by calculating: P + short_port value. P is a
predetermined port number with value TBD. The short_port is
expressed as a 4-bit value which is carried "in-line"
(Section 8.3.2)
UDP destination port (bit 1):
0: Not compressed, carried "in-line" (Section 8.3.2)
1: Compressed to 4 bits. The actual 16-bit destination port is
obtained by calculating: P + short_port value. P is a
predetermined port number with value TBD. The short_port is
expressed as a 4-bit value which is carried "in-line"
(Section 8.3.2)
Length (bit 2):
0: not compressed, carried "in-line" (Section 8.3.2)
1: compressed, length computed from IPv6 header length
information (similar to how the length of the header is
calculated in TCP
Reserved (bit 3 through 7)
Note: TCP, ICMP HC2 formats TBD.
8.3. Non-Compressed Fields
8.3.1. Non-Compressed IPv6 Fields
This scheme allows the IPv6 header to be compressed to different
degrees. Hence, instead of the entire (standard) IPv6 header, only
non-compressed fields need to be sent. The subsequent header (as
specified by the Next Header field in the original IPv6 header)
immediately follows the IPv6 non-compressed fields.
Montenegro & Kushalnagar Expires April 27, 2006 [Page 15]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
The non-compressed IPv6 field that MUST be always present is the Hop
Limit (8 bits). This field MUST always follow the encoding fields
(e.g., "HC1 encoding" as shown in Figure 7), perhaps including other
future encoding fields). Other non-compressed fields MUST follow the
Hop Limit as implied by the "HC1 encoding" in the exact same order as
shown above (Section 8.1): source address prefix (64 bits) and/or
interface identifier (64 bits), destination address prefix (64 bits)
and/or interface identifier (64 bits), Traffic Class (8 bits), Flow
Label (20 bits) and Next Header (8 bits). The actual next header
(e.g., UDP, TCP, ICMP, etc) follows the non-compressed fields.
8.3.2. Non-Compressed and partially compressed UDP fields
This scheme allows the UDP header to be compressed to different
degrees. Hence, instead of the entire (standard) UDP header, only
non-compressed or partially compressed fields need to be sent.
The non-compressed or partially compressed fields in the UDP header
MUST always follow the IPv6 header and any of its associated in-line
fields. Any UDP header in-line fields present MUST appear in the
same order as the corresponding fields appear in a normal UDP header
[RFC0768], e.g., source port, destination port, length and checksum.
9. Frame Delivery in a Link-Layer Mesh
Even though 802.15.4 networks are expected to commonly use mesh
routing, the IEEE 802.15.4-2003 specification [ieee802.15.4] does not
define such capability. In such cases, Full Function Devices (FFDs)
run an ad hoc or mesh routing protocol to populate their routing
tables (outside the scope of this document). In such mesh scenarios,
two devices do not require direct reachability in order to
communicate. Of these devices, the sender is known as the
"Originator", and the receiver is known as the "Final Destination".
An originator device may use other intermediate devices as forwarders
towards the final destination. In order to achieve such frame
delivery using unicast, it is necessary to include the link-layer
addresses of the originator and final destinations, in addition to
the hop-by-hop source and destination.
This section defines how to effect delivery of layer 2 frames in a
mesh, given a target "Final Destination" link-layer address.
Mesh delivery is enabled by setting the 'M' bit present in all
variations of the LoWPAN encapsulation (Section 4). If the 'M' bit
is set, there is a "Mesh Delivery" field included in the frame
immediately following the LoWPAN header. More precisely, in all
variations of the LoWPAN encapsulation (unfragmented and fragmented),
Montenegro & Kushalnagar Expires April 27, 2006 [Page 16]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
the "Mesh Delivery" field immediately precedes the LoWPAN payload
(e.g., a full-blown IPv6 header, a compressed IPv6 header as per
Section 8, or any others defined elsewhere).
If a node wishes to use a forwarder to deliver a packet (i.e.,
because it does not have direct reachability to the destination), it
MUST set the 'M' bit, and include a "Mesh Delivery" field with the
originator's link-layer address set to its own, and the final
destination's link-layer address set to the packet's ultimate
destination. It sets the source address in the 802.15.4 header to
its own link-layer address, and puts the forwarder's link-layer
address in the 802.15.4 header's destination address field. Finally,
it transmits the packet.
Similarly, if a node receives a frame with the 'M' bit set, it must
look at the "Mesh Delivery" header's "Final Destination" field to
determine the real destination. If the node is itself the final
destination, it consumes the packet as per normal delivery. If it is
not the final destination, the device then reduces the "Hops Left"
field, and if the result is zero, discards the packet. Otherwise,
the node consults its link-layer routing table, determines what the
next hop towards the final destination should be, and puts that
address in the destination address field of the 802.15.4 header.
Finally, the node changes the source address in the 802.15.4 header
to its own link-layer address and transmits the packet.
Whereas a node must participate in a mesh routing protocol to be a
forwarder, no such requirement exists for simply using mesh
forwarding. Only "Full Function Devices" (FFDs) are expected to
participate as routers in a mesh. "Reduced Function Devices" (RFDs)
limit themselves to discovering FFDs and using them for all their
forwarding, in a manner similar to how IP hosts typically use default
routers to forward all their off-link traffic. For an RFD using mesh
delivery, the "forwarder" is always the appropriate FFD.
The "Mesh Delivery" field is defined as follows:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Hops Left | Originator Address, followed by...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Final Destination Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Mesh Delivery Field
Field definitions are as follows:
Montenegro & Kushalnagar Expires April 27, 2006 [Page 17]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
S: This 1-bit field SHALL be zero if using IEEE extended 64 bit
address format (EUI-64), or 1 if using short 16-bit addresses.
Hops Left: This 7-bit field SHALL be decremented by each forwarding
node before sending this packet towards its next hop. The packet
is not forwarded any further if Hops Left is decremented to 0.
Originator Address: This is the link-layer address of the Originator.
Final Destination Address: This is the link-layer address of the
Final Destination.
10. IANA Considerations
This document creates a new IANA registry for the prot_type (Protocol
Type) field shown in the packet formats in Section 4. This document
defines the values 1 and 2 hexadecimal for IPv6 and the LOWPAN_HC1
header compression format, respectively. Future assignments in this
field are to be coordinated via IANA under the policy of
"Specification Required" [RFC2434]. It is expected that this policy
will allow for other (non-IETF) organizations to more easily obtain
assignments. This document defines this field to be 8 bits long.
The value 0 being reserved and not used, this allows for a total of
254 different values, which should be more than enough.
11. Security Considerations
The method of derivation of Interface Identifiers from EUI-64 MAC
addresses is intended to preserve global uniqueness when possible.
However, there is no protection from duplication through accident or
forgery.
Neighbor Discovery in IEEE 802.15.4 links may be susceptible to
threats as detailed in [RFC3756]. Mesh routing is expected to be
common in IEEE 802.15.4 networks. This implies additional threats
due to ad hoc routing as per [KW03]. IEEE 802.15.4 provides some
capability for link-layer security. Users are urged to make use of
such provisions if at all possible and practical. Doing so will
alleviate the threats referred to above.
A sizeable portion of IEEE 802.15.4 devices is expected to always
communicate within their PAN (i.e., within their link, in IPv6
terms). In response to cost and power consumption considerations,
and in keeping with the IEEE 802.15.4 model of "Reduced Function
Devices" (RFDs), these devices will typically implement the minimum
set of features necessary. Accordingly, security for such devices
Montenegro & Kushalnagar Expires April 27, 2006 [Page 18]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
may rely quite strongly on the mechanisms defined at the link-layer
by IEEE 802.15.4. The latter, however, only defines the AES modes
for authentication or encryption of IEEE 802.15.4 frames, and does
not, in particular, specify key management (presumably group
oriented). Other issues to address in real deployments relate to
secure configuration and management. Whereas such a complete picture
is out of scope of this document, it is imperative that IEEE 802.15.4
networks be deployed with such considerations in mind. Of course, it
is also expected that some IEEE 802.15.4 devices (the so-called "Full
Function Devices", or "FFDs") will implement coordination or
integration functions. These may communicate regularly with off-link
IPv6 peers (in addition to the more common on-link exchanges). Such
IPv6 devices are expected to secure their end-to-end communications
with the usual mechanisms (e.g., IPsec, TLS, etc).
12. Acknowledgements
Thanks to the authors of RFC 2464 and RFC 2734, as parts of this
document are patterned after theirs. Thanks to Geoff Mulligan for
useful discussions which helped shape this document. Erik Nordmark's
suggestions were instrumental for the header compression section.
Also thanks to Shoichi Sakane and Samita Chakrabarti.
13. References
13.1. Normative References
[EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
REGISTRATION AUTHORITY", IEEE http://standards.ieee.org/
regauth/oui/tutorials/EUI64.html.
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-05 (work in progress),
October 2005.
[I-D.ietf-ipv6-rfc2462bis]
Thomson, S., "IPv6 Stateless Address Autoconfiguration",
draft-ietf-ipv6-rfc2462bis-08 (work in progress),
May 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
Montenegro & Kushalnagar Expires April 27, 2006 [Page 19]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
October 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[ieee802.15.4]
IEEE Computer Society, "IEEE Std. 802.15.4-2003",
October 2003.
13.2. Informative References
[I-D.ietf-ipngwg-icmp-v3]
Conta, A., "Internet Control Message Protocol (ICMPv6) for
the Internet Protocol Version 6 (IPv6) Specification",
draft-ietf-ipngwg-icmp-v3-07 (work in progress),
July 2005.
[I-D.ietf-ipv6-node-requirements]
Loughney, J., "IPv6 Node Requirements",
draft-ietf-ipv6-node-requirements-11 (work in progress),
August 2004.
[KW03] Karlof, Chris and Wagner, David, "Secure Routing in Sensor
Networks: Attacks and Countermeasures", Elsevier's AdHoc
Networks Journal, Special Issue on Sensor Network
Applications and Protocols vol 1, issues 2-3,
September 2003.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission
of IP datagrams over IEEE 802 networks", STD 43, RFC 1042,
February 1988.
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, December 2002.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
Montenegro & Kushalnagar Expires April 27, 2006 [Page 20]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004.
Appendix A. Alternatives for Delivery of Frames in a Mesh
Before settling on the mechanism finally adopted for delivery in a
mesh (Section 9), several alternatives were considered. In addition
to the hop-by-hop source and destination link-layer addresses,
delivering a packet in a LoWPAN mesh requires the end-to-end
originator and destination addresses. These could be expressed
either as layer 2 or as layer 3 (i.e., IP ) addresses. In the latter
case, there would be no need to provide any additional header support
in this document (i.e., within the LoWPAN header itself). The link-
layer destination address would point to the next hop destination
address while the IP header destination address would point to the
final destination (IP) address (possibly multiple hops away from the
source), and similarly for the source addresses. Thus, while
forwarding data, the single-hop source and destination addresses
would change at each hop (always pointing to the node doing the
forwarding and the "best" next link-layer hop, respectively), while
the source and destination IP addresses would remain unchanged.
Notice that if an IP packet is fragmented, the individual fragments
may arrive at any node out of order. If the initial frament (which
contains the IP header) is delayed for some reason, a node that
receives a subsequent fragment would lack the required information.
It would be forced to wait until it receives the IP header (within
the first fragment) before being able to forward the fragment any
further. This imposes some additional buffering requirements on
intermediate nodes. Additionally, such a specification would only
work for one type of LoWPAN payload: IPv6. In general, it would have
to be adapted for any other payload, and would require that payload
to provide its own end-to-end addressing information.
On the other hand, the approach finally followed (Section 9) creates
a mesh at the LoWPAN layer (below layer 3). Accordingly, link-layer
originator and final destination address are included within the
LoWPAN header. This enables mesh delivery for any protocol or
application layered on the LoWPAN adaptation layer (Section 4). For
IPv6 as supported in this document, another advantage of expressing
the originator and final destinations as layer 2 addresses is that
the IPv6 addresses can be compressed as per the header compression
specified in Section 8. Furthermore, the number of octets needed to
maintain routing tables is reduced due to the smaller size of
802.15.4 addresses (either 64 bits or 16 bits) as compared to IPv6
addresses (128 bits). A disadvantage is that applications on top of
Montenegro & Kushalnagar Expires April 27, 2006 [Page 21]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
IP do not address packets to link-layer destination addresses, but to
IP (layer 3) destination addresses. Thus, given an IP address, there
is a need to resolve the corresponding link-layer address.
Accordingly, a mesh routing specification needs to clarify the
Neighbor Discovery implications, although in some special cases, it
may be possible to derive a device's address at layer 2 from its
address at layer 3 (and viceversa). Such complete specification is
outside the scope of this document.
Appendix B. Changes
Changes from version draft-ietf-6lowpan-format-00.txt to version
draft-ietf-6lowpan-format-01.txt are as follows:
Added a reassembly timeout of 15 sec.
Added support for 16-bit "short" addresses.
datagram tag now at 10 bits protocol_type and datagram offset both
went from 11 to 8 bits (which is still enough for the format, and
which implies counting offset in units of 8 octets for the
latter).
Addition of the originator's link-layer source address to the
"Mesh Delivery" header.
Changed name of "Final Destination" header to "Mesh Delivery"
header.
Further clarification on mesh delivery.
Sundry editorial changes.
Changes from version
draft-montenegro-lowpan-ipv6-over-802.15.4-02.txt to version
draft-ietf-6lowpan-format-00.txt are as follows:
The LoWPAN encapsulation was modified to allow 11 bits of protocol
type (prot_type field). Because of this, the minimum overhead
grew from 1 octet to 2 octets. This was done in order to allow
more protocol types as the previous format started with a field
only 5 bits wide. Whereas growing it to 7 bits was possible in
the future, this would always entail 2 octets of overhead for the
longer protocol types to be used.
Montenegro & Kushalnagar Expires April 27, 2006 [Page 22]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
The 'M' bit had been left out of the 3rd packet format (for
subsequent fragments). Corrected this oversight. This means that
the fragment tag lost one bit.
Sundry editorial changes.
Montenegro & Kushalnagar Expires April 27, 2006 [Page 23]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
Authors' Addresses
Gabriel Montenegro
Microsoft Corporation
Email: gabriel_montenegro_2000@yahoo.com
Nandakishore Kushalnagar
Intel Corp
Email: nandakishore.kushalnagar@intel.com
Montenegro & Kushalnagar Expires April 27, 2006 [Page 24]
Internet-Draft IPv6 over IEEE 802.15.4 October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Montenegro & Kushalnagar Expires April 27, 2006 [Page 25]
