diff options
Diffstat (limited to 'doc/rfc/rfc4944.txt')
| -rw-r--r-- | doc/rfc/rfc4944.txt | 1683 |
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc4944.txt b/doc/rfc/rfc4944.txt new file mode 100644 index 0000000..57a5513 --- /dev/null +++ b/doc/rfc/rfc4944.txt @@ -0,0 +1,1683 @@ + + + + + + +Network 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. + +5. LoWPAN Adaptation Layer and Frame Format + + The encapsulation formats defined in this section (subsequently + referred to as the "LoWPAN encapsulation") are the payload in the + IEEE 802.15.4 MAC protocol data unit (PDU). The LoWPAN payload + (e.g., an IPv6 packet) follows this encapsulation header. + + All LoWPAN encapsulated datagrams transported over IEEE 802.15.4 are + prefixed by an encapsulation header stack. Each header in the header + stack contains a header type followed by zero or more header fields. + Whereas in an IPv6 header the stack would contain, in the following + order, addressing, hop-by-hop options, routing, fragmentation, + destination options, and finally payload [RFC2460]; in a LoWPAN + header, the analogous header sequence is mesh (L2) addressing, hop- + by-hop options (including L2 broadcast/multicast), fragmentation, and + finally payload. These examples show typical header stacks that may + be used in a LoWPAN network. + + A LoWPAN encapsulated IPv6 datagram: + + +---------------+-------------+---------+ + | IPv6 Dispatch | IPv6 Header | Payload | + +---------------+-------------+---------+ + + A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram: + + +--------------+------------+---------+ + | HC1 Dispatch | HC1 Header | Payload | + +--------------+------------+---------+ + + A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that + requires mesh addressing: + + +-----------+-------------+--------------+------------+---------+ + | Mesh Type | Mesh Header | HC1 Dispatch | HC1 Header | Payload | + +-----------+-------------+--------------+------------+---------+ + + A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that + requires fragmentation: + + +-----------+-------------+--------------+------------+---------+ + | Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload | + +-----------+-------------+--------------+------------+---------+ + + + + +Montenegro, et al. Standards Track [Page 6] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + + A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that + requires both mesh addressing and fragmentation: + + +-------+-------+-------+-------+---------+---------+---------+ + | M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload | + +-------+-------+-------+-------+---------+---------+---------+ + + A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that + requires both mesh addressing and a broadcast header to support mesh + broadcast/multicast: + + +-------+-------+-------+-------+---------+---------+---------+ + | M Typ | M Hdr | B Dsp | B Hdr | HC1 Dsp | HC1 Hdr | Payload | + +-------+-------+-------+-------+---------+---------+---------+ + + When more than one LoWPAN header is used in the same packet, they + MUST appear in the following order: + + Mesh Addressing Header + + Broadcast Header + + Fragmentation Header + + All protocol datagrams (e.g., IPv6, compressed IPv6 headers, etc.) + SHALL be preceded by one of the valid LoWPAN encapsulation headers, + examples of which are given above. This permits uniform software + treatment of datagrams without regard to the mode of their + transmission. + + The definition of LoWPAN headers, other than mesh addressing and + fragmentation, consists of the dispatch value, the definition of the + header fields that follow, and their ordering constraints relative to + all other headers. Although the header stack structure provides a + mechanism to address future demands on the LoWPAN adaptation layer, + it is not intended to provided general purpose extensibility. This + format document specifies a small set of header types using the + header stack for clarity, compactness, and orthogonality. + + + + + + + + + + + + + +Montenegro, et al. Standards Track [Page 7] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + +5.1. Dispatch Type and Header + + The dispatch type is defined by a zero bit as the first bit and a one + bit as the second bit. The dispatch type and header are shown here: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 1| Dispatch | type-specific header + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Dispatch 6-bit selector. Identifies the type of header + immediately following the Dispatch Header. + + type-specific header A header determined by the Dispatch Header. + + Figure 1: Dispatch Type and Header + + The dispatch value may be treated as an unstructured namespace. Only + a few symbols are required to represent current LoWPAN functionality. + Although some additional savings could be achieved by encoding + additional functionality into the dispatch byte, these measures would + tend to constrain the ability to address future alternatives. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Montenegro, et al. Standards Track [Page 8] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + + Pattern Header Type + +------------+-----------------------------------------------+ + | 00 xxxxxx | NALP - Not a LoWPAN frame | + | 01 000001 | IPv6 - Uncompressed IPv6 Addresses | + | 01 000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6 | + | 01 000011 | reserved - Reserved for future use | + | ... | reserved - Reserved for future use | + | 01 001111 | reserved - Reserved for future use | + | 01 010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast | + | 01 010001 | reserved - Reserved for future use | + | ... | reserved - Reserved for future use | + | 01 111110 | reserved - Reserved for future use | + | 01 111111 | ESC - Additional Dispatch byte follows | + | 10 xxxxxx | MESH - Mesh Header | + | 11 000xxx | FRAG1 - Fragmentation Header (first) | + | 11 001000 | reserved - Reserved for future use | + | ... | reserved - Reserved for future use | + | 11 011111 | reserved - Reserved for future use | + | 11 100xxx | FRAGN - Fragmentation Header (subsequent)| + | 11 101000 | reserved - Reserved for future use | + | ... | reserved - Reserved for future use | + | 11 111111 | reserved - Reserved for future use | + +------------+-----------------------------------------------+ + + Figure 2: Dispatch Value Bit Pattern + + NALP: Specifies that the following bits are not a part of the LoWPAN + encapsulation, and any LoWPAN node that encounters a dispatch + value of 00xxxxxx shall discard the packet. Other non-LoWPAN + protocols that wish to coexist with LoWPAN nodes should include a + byte matching this pattern immediately following the 802.15.4. + header. + + IPv6: Specifies that the following header is an uncompressed IPv6 + header [RFC2460]. + + LOWPAN_HC1: Specifies that the following header is a LOWPAN_HC1 + compressed IPv6 header. This header format is defined in + Figure 9. + + LOWPAN_BC0: Specifies that the following header is a LOWPAN_BC0 + header for mesh broadcast/multicast support and is described in + Section 11.1. + + ESC: Specifies that the following header is a single 8-bit field for + the Dispatch value. It allows support for Dispatch values larger + than 127. + + + + +Montenegro, et al. Standards Track [Page 9] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + +5.2. Mesh Addressing Type and Header + + The mesh type is defined by a one bit and zero bit as the first two + bits. The mesh type and header are shown here: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1 0|V|F|HopsLft| originator address, final address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Mesh Addressing Type and Header + + Field definitions are as follows: + + V: This 1-bit field SHALL be zero if the Originator (or "Very first") + Address is an IEEE extended 64-bit address (EUI-64), or 1 if it is + a short 16-bit addresses. + + F: This 1-bit field SHALL be zero if the Final Destination Address is + an IEEE extended 64-bit address (EUI-64), or 1 if it is a short + 16-bit addresses. + + Hops Left: This 4-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 zero. + The value 0xF is reserved and signifies an 8-bit Deep Hops Left + field immediately following, and allows a source node to specify a + hop limit greater than 14 hops. + + Originator Address: This is the link-layer address of the + Originator. + + Final Destination Address: This is the link-layer address of the + Final Destination. + + Note that the 'V' and 'F' bits allow for a mix of 16 and 64-bit + addresses. This is useful at least to allow for mesh layer + "broadcast", as 802.15.4 broadcast addresses are defined as 16-bit + short addresses. + + A further discussion of frame delivery within a mesh is in + Section 11. + + + + + + + + +Montenegro, et al. Standards Track [Page 10] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + +5.3. Fragmentation Type and Header + + If an entire payload (e.g., IPv6) datagram fits within a single + 802.15.4 frame, it is unfragmented and the LoWPAN encapsulation + should not contain a fragmentation header. If the datagram does not + fit within a single IEEE 802.15.4 frame, it SHALL be broken into link + fragments. As the fragment offset can only express multiples of + eight bytes, all link fragments for a datagram except the last one + MUST be multiples of eight bytes in length. The first link fragment + SHALL contain the first fragment header as defined 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1 1 0 0 0| datagram_size | datagram_tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: First Fragment + + The second and subsequent link fragments (up to and including the + last) SHALL contain a fragmentation header that conforms 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1 1 1 0 0| datagram_size | datagram_tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |datagram_offset| + +-+-+-+-+-+-+-+-+ + + Figure 5: Subsequent Fragments + + datagram_size: This 11-bit field encodes the size of the entire IP + packet before link-layer fragmentation (but after IP layer + fragmentation). The value of datagram_size SHALL be the same for + all link-layer fragments of an IP packet. For IPv6, this SHALL be + 40 octets (the size of the uncompressed IPv6 header) more than the + value of Payload Length in the IPv6 header [RFC2460] of the + packet. Note that this packet may already be fragmented by hosts + involved in the communication, i.e., this field needs to encode a + maximum length of 1280 octets (the IEEE 802.15.4 link MTU, as + defined in this document). + + 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 + + + +Montenegro, et al. Standards Track [Page 11] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + + 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. + + 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 + 65535 back to zero. This field is 16 bits long, and its initial + value is not defined. + + datagram_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 datagram_offset in the first link fragment is zero. This + field is 8 bits long. + + The recipient of link fragments SHALL use (1) the sender's 802.15.4 + source address (or the Originator Address if a Mesh Addressing field + is present), (2) the destination's 802.15.4 address (or the Final + Destination address if a Mesh Addressing field is present), (3) + datagram_size, and (4) datagram_tag to identify all the link + fragments that belong to a given datagram. + + Upon receipt of a link fragment, the recipient starts constructing + the original unfragmented packet whose size is datagram_size. It + uses the datagram_offset field to determine the location of the + individual fragments within the original unfragmented packet. For + example, it may place the data payload (except the encapsulation + header) within a payload datagram reassembly buffer at the location + specified by datagram_offset. The size of the reassembly buffer + SHALL be determined from datagram_size. + + If a link fragment that overlaps another fragment is received, as + identified above, and differs in either the size or datagram_offset + of the overlapped fragment, 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 datagram_offset from the + encapsulation header and "Frame Length" from the 802.15.4 Physical + Layer Protocol Data Unit (PPDU) packet header. + + Upon detection of a IEEE 802.15.4 Disassociation event, fragment + recipients MUST discard all link fragments of all partially + + + +Montenegro, et al. Standards Track [Page 12] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + + reassembled payload datagrams, and fragment senders MUST discard all + not yet transmitted link fragments of all partially transmitted + payload (e.g., IPv6) datagrams. Similarly, when a node first + receives a fragment with a given datagram_tag, it starts a reassembly + timer. When this time expires, if the entire packet has not been + reassembled, the existing fragments MUST be discarded and the + reassembly state MUST be flushed. The reassembly timeout MUST be set + to a maximum of 60 seconds (this is also the timeout in the IPv6 + reassembly procedure [RFC2460]). + +6. Stateless Address Autoconfiguration + + This section defines how to obtain an IPv6 interface identifier. + + The Interface Identifier [RFC4291] for an IEEE 802.15.4 interface may + be based on the EUI-64 identifier [EUI64] assigned to the IEEE + 802.15.4 device. In this case, 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 16-bit short + addresses (Section 3 and Section 12) are also possible. In these + cases, a "pseudo 48-bit address" is formed as follows. First, the + left-most 32 bits are formed by concatenating 16 zero bits to the 16- + bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits may be + used). This produces a 32-bit field as follows: + + 16_bit_PAN:16_zero_bits + + Then, these 32 bits are concatenated with the 16-bit short address. + This produces a 48-bit address as follows: + + 32_bits_as_specified_previously:16_bit_short_address + + The interface identifier is formed from this 48-bit address as per + the "IPv6 over Ethernet" specification [RFC2464]. However, in the + resultant interface identifier, the "Universal/Local" (U/L) bit SHALL + be set to zero in keeping with the fact that this is not a globally + unique value. For either address format, all zero addresses MUST NOT + be used. + + 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. + + An IPv6 address prefix used for stateless autoconfiguration [RFC4862] + of an IEEE 802.15.4 interface MUST have a length of 64 bits. + + + +Montenegro, et al. Standards Track [Page 13] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + +7. IPv6 Link Local Address + + The IPv6 link-local address [RFC4291] 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 6 + +8. Unicast Address Mapping + + The address resolution procedure for mapping IPv6 non-multicast + addresses into IEEE 802.15.4 link-layer addresses follows the general + description in Section 7.2 of [RFC4861], unless otherwise specified. + + 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, et al. Standards Track [Page 14] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + + 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 7 + + 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. + + IEEE 802.15.4 Address: The 64-bit IEEE 802.15.4 address, or the 16- + bit short address (as per the format in Section 9), in canonical + + + +Montenegro, et al. Standards Track [Page 15] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + + 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. + +9. Multicast Address Mapping + + The functionality in this section MUST only be used in a mesh-enabled + LoWPAN. An IPv6 packet with a multicast destination address (DST), + consisting of the sixteen octets DST[1] through DST[16], is + transmitted to the following 802.15.4 16-bit multicast address: + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1 0 0|DST[15]* | DST[16] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8 + + Here, DST[15]* refers to the last 5 bits in octet DST[15], that is, + bits 3-7 within DST[15]. The initial 3-bit pattern of "100" follows + the 16-bit address format for multicast addresses (Section 12). + + This allows for multicast support within 6LoWPAN networks, but the + full specification of such support is out of the scope of this + document. Example mechanisms are: flooding, controlled flooding, + unicasting to the PAN coordinator, etc. It is expected that this + would be specified by the different mesh routing mechanisms. + +10. 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 a very simple and low-context flavor of + header compression. Whereas this works independently of flows + (potentially several), it does not use any context specific to any + flow. Thus, it cannot achieve as much compression as schemes that + build a separate context for each flow to be compressed. + + Given the very limited packet sizes, it is highly desirable to + integrate layer 2 with layer 3 compression, something + traditionally not done (although now changing due to the ROHC + (RObust Header Compression) working group). + + + + +Montenegro, et al. Standards Track [Page 16] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + + 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. + + Any new packet formats required by header compression reuse the basic + packet formats defined in Section 5 by using different dispatch + values. + + Header compression may result in alignment not falling on an octet + boundary. Since hardware typically cannot transmit data in units + less than an octet, padding must be used. Padding is done as + follows: First, the entire series of contiguous compressed headers is + laid out (this document only defines IPv6 and UDP header compression + schemes, but others may be defined elsewhere). Then, zero bits + SHOULD be added as appropriate to align to an octet boundary. This + counteracts any potential misalignment caused by header compression, + so subsequent fields (e.g., non-compressed headers or data payloads) + start on an octet boundary and follow as usual. + +10.1. Encoding of IPv6 Header Fields + + By virtue of having joined the same 6LoWPAN network, devices share + some state. This makes it possible to compress headers without + explicitly building any compression context state. Therefore, + 6LoWPAN header compression does not keep any flow state; instead, it + relies on information pertaining to the entire link. The following + IPv6 header values are expected to be common on 6LoWPAN networks, so + the HC1 header has been constructed to efficiently compress them from + the onset: Version is IPv6; both IPv6 source and destination + addresses are link local; the IPv6 interface identifiers (bottom 64 + bits) for the source or destination addresses can be inferred from + the layer two source and destination addresses (of course, this is + only possible for interface identifiers derived from an underlying + 802.15.4 MAC address); the packet length can be inferred either from + layer two ("Frame Length" in the IEEE 802.15.4 PPDU) or from the + "datagram_size" field in the fragment header (if present); 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 10.3.1). This common IPv6 header (as mentioned above) can + be compressed to 2 octets (1 octet for the HC1 encoding and 1 octet + + + +Montenegro, et al. Standards Track [Page 17] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + + for the Hop Limit), instead of 40 octets. Such a packet is + compressible via the LOWPAN_HC1 format by using a Dispatch value of + LOWPAN_HC1 followed by a LOWPAN_HC1 header "HC1 encoding" field (8 + bits) to encode the different combinations as shown below. This + header may be preceded by a fragmentation header, which may be + preceded by a mesh header. + + 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 9: 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 10.3). + + The address fields encoded by "HC1 encoding" are interpreted as + follows: + + PI: Prefix carried in-line (Section 10.3.1). + + PC: Prefix compressed (link-local prefix assumed). + + II: Interface identifier carried in-line (Section 10.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 11), the corresponding link-layer address is that + found in the "Mesh Addressing" field (Section 5.2). + + The "HC1 encoding" is shown below (starting with bit 0 and ending at + bit 7): + + IPv6 source address (bits 0 and 1): + + 00: PI, II + + 01: PI, IC + + 10: PC, II + + 11: PC, IC + + + + + +Montenegro, et al. Standards Track [Page 18] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + + 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). + +10.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 10) + 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 + + + +Montenegro, et al. Standards Track [Page 19] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + + 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 + (Section 10.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 10: 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 10.3.2) + + 1: Compressed to 4 bits. The actual 16-bit source port is + obtained by calculating: P + short_port value. The value of + P is the number 61616 (0xF0B0). The short_port is expressed + as a 4-bit value which is carried "in-line" (Section 10.3.2) + + UDP destination port (bit 1): + + 0: Not compressed, carried "in-line" (Section 10.3.2) + + 1: Compressed to 4 bits. The actual 16-bit destination port is + obtained by calculating: P + short_port value. The value of + P is the number 61616 (0xF0B0). The short_port is expressed + as a 4-bit value which is carried "in-line" (Section 10.3.2) + + Length (bit 2): + + 0: not compressed, carried "in-line" (Section 10.3.2) + + 1: compressed, length computed from IPv6 header length + information. The value of the UDP length field is equal to + the Payload Length from the IPv6 header, minus the length of + any extension headers present between the IPv6 header and + the UDP header. + + Reserved (bit 3 through 7) + + + +Montenegro, et al. Standards Track [Page 20] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + +10.3. Non-Compressed Fields + +10.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. + + Uncompressed IPv6 addressing is described by a dispatch type + containing an IPv6 dispatch value followed by the uncompressed IPv6 + header. This dispatch type may be preceded by additional LoWPAN + headers. + + 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 9), 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 10.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. + +10.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. + If either the source or destination ports are in "short_port" + notation (as indicated in the compressed UDP header), then instead of + taking 16 bits, the inline port numbers take 4 bits. + +11. 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, + + + +Montenegro, et al. Standards Track [Page 21] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + + 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 including a Mesh Addressing header prior + to any other headers of the LoWPAN encapsulation (Section 5), an + unfragmented and fragmented header; a full-blown IPv6 header; or a + compressed IPv6 header as per Section 10 or any others defined + elsewhere. + + If a node wishes to use a default mesh forwarder to deliver a packet + (i.e., because it does not have direct reachability to the + destination), it MUST include a Mesh Addressing header 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 a Mesh Addressing header, + it must look at the Mesh Addressing 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. + + + +Montenegro, et al. Standards Track [Page 22] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + +11.1. LoWPAN Broadcast + + Additional mesh routing functionality is encoded using a routing + header immediately following the Mesh header. In particular, a + broadcast header consists of a LOWPAN_BC0 dispatch followed by a + sequence number field. The sequence number is used to detect + duplicate packets (and hopefully suppress them). + + 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0|1|LOWPAN_BC0 |Sequence Number| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 11: Broadcast Header + + Field definitions are as follows: + + Sequence Number: This 8-bit field SHALL be incremented by the + originator whenever it sends a new mesh broadcast or multicast + packet. Full specification of how to handle this field is out of + the scope of this document. + + Further implications of such mesh-layer broadcast, e.g., whether it + maps to a controlled flooding mechanism or its role in, say, topology + discovery, is out of the scope of this document. + + Additional mesh routing capabilities, such as specifying the mesh + routing protocol, source routing, and so on may be expressed by + defining additional routing headers that precede the fragmentation or + addressing header in the header stack. The full specification of + such mesh routing capabilities are out of the scope of this document. + +12. IANA Considerations + + This document creates two new IANA registries, as discussed below. + Future assignments in these registries 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 creates a new IANA registry for the Dispatch type field + shown in the header definitions in Section 5. This document defines + the values IPv6, LOWPAN_HC1 header compression, BC0 broadcast and two + escape patterns (NALP to indicate not a LOWPAN frame and ESC to allow + additional dispatch bytes). This document defines this field to be 8 + bits long. The values 00xxxxxx being reserved and not used, allows + for a total of 192 different values, which should be more than + + + +Montenegro, et al. Standards Track [Page 23] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + + enough. If header compression formats in addition to HC1 are defined + or if additional TCP, ICMP HC2 formats are defined, it is expected + that these will use reserved dispatch values following LOWPAN_HC1. + If additional mesh delivery formats are defined these will use + reserved values following LOWPAN_BC0. + + This document creates a new IANA registry for the 16-bit short + address fields as used in 6LoWPAN packets. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 16-bit short Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 12 + + This registry MUST include the addresses 0xffff (16-bit broadcast + address accepted by all devices currently listening to the channel) + and 0xfffe as defined in [ieee802.15.4]. Additionally, within + 6LoWPAN networks, 16-bit short addresses MUST follow this format + (referring to bit fields in the order from 0 to 7), where "x" is a + place holder for an unspecified bit value: + + Range 1, 0xxxxxxxxxxxxxxx: The first bit (bit 0) SHALL be zero if + the 16-bit address is a unicast address. This leaves 15 bits for + the actual address. + + Range 2, 100xxxxxxxxxxxxx: Bits 0, 1, and 2 SHALL follow this + pattern if the 16-bit address is a multicast address (see + Section 9). This leaves 13 bits for the actual multicast address. + + Range 3, 101xxxxxxxxxxxxx: This pattern for bits 0, 1, and 2 is + reserved. Any future assignment shall follow the policy mentioned + above. + + Range 4, 110xxxxxxxxxxxxx: This pattern for bits 0, 1, and 2 is + reserved. Any future assignment shall follow the policy mentioned + above. + + Range 5, 111xxxxxxxxxxxxx: This pattern for bits 0, 1, and 2 is + reserved. Any future assignment shall follow the policy mentioned + above. + + + + + + + + +Montenegro, et al. Standards Track [Page 24] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + +13. 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 stated 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 + may rely quite strongly on the mechanisms defined at the link layer + by IEEE 802.15.4. The latter, however, only defines the Advanced + Encryption Standard (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 the 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). + +14. 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, Samita Chakrabarti, Vipul Gupta, + Carsten Bormann, Ki-Hyung Kim, Mario Mao, Phil Levis, Magnus + Westerlund, and Jari Arkko. + + + + + +Montenegro, et al. Standards Track [Page 25] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + +15. References + +15.1. Normative References + + [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, 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. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. + Soliman, "Neighbor Discovery for IP version 6 + (IPv6)", RFC 4861, September 2007. + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 + Stateless Address Autoconfiguration", RFC 4862, + September 2007. + + [ieee802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2003", + October 2003. + +15.2. Informative References + + [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) + REGISTRATION AUTHORITY", IEEE http:// + standards.ieee.org/regauth/oui/tutorials/EUI64.html. + + [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. + + + + + +Montenegro, et al. Standards Track [Page 26] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + + [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 + Neighbor Discovery (ND) Trust Models and Threats", + RFC 3756, May 2004. + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Montenegro, et al. Standards Track [Page 27] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + +Appendix A. Alternatives for Delivery of Frames in a Mesh + + Before settling on the mechanism finally adopted for delivery in a + mesh (Section 11), 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 fragment (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 11) creates + a mesh at the LoWPAN layer (below layer 3). Accordingly, the 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 5). 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 10. 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 + 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 + + + +Montenegro, et al. Standards Track [Page 28] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + + address at layer 3 (and vice versa). Such complete specification is + outside the scope of this document. + +Authors' Addresses + + Gabriel Montenegro + Microsoft Corporation + + EMail: gabriel.montenegro@microsoft.com + + + Nandakishore Kushalnagar + Intel Corp + + EMail: nandakishore.kushalnagar@intel.com + + + Jonathan W. Hui + Arch Rock Corp + + EMail: jhui@archrock.com + + + David E. Culler + Arch Rock Corp + + EMail: dculler@archrock.com + + + + + + + + + + + + + + + + + + + + + + + + +Montenegro, et al. Standards Track [Page 29] + +RFC 4944 IPv6 over IEEE 802.15.4 September 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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. + + 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, THE IETF TRUST 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. + +Intellectual Property + + 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. + + + + + + + + + + + + +Montenegro, et al. Standards Track [Page 30] + |