rfc-4944

Transmission of IPv6 Packets over IEEE 802.15.4 Networks

G. Montenegro, N. Kushalnagar, J. Hui, D. Culler
date2007-09 streamIETF areaint wg6lowpan statusPROPOSED STANDARD pages30 canonicalhttps://www.rfc-editor.org/rfc/rfc4944 doi10.17487/RFC4944 errataview
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. [STANDARDS-TRACK]

updated by

Extracted elements (29)

design-rationale §4

Header compression is described as 'compelling to the point of almost being unavoidable': without it, only 33 octets remain for application data after the IPv6 header (40 bytes) and UDP header (8 bytes) are accounted for in a single 802.15.4 frame. Most applications are expected to use header compression.

ip

design-rationale §A

Mesh delivery is implemented at the LoWPAN layer (below IP) rather than using IP-layer addressing, because this enables mesh delivery for any payload (not just IPv6), allows header compression of IP addresses via layer-2 address inference, and reduces routing table size by using 16-bit or 64-bit 802.15.4 addresses instead of 128-bit IPv6 addresses.

ip, routing

interoperability-note §5.1

Non-LoWPAN protocols wishing to coexist with LoWPAN nodes should include a byte matching the NALP pattern (00xxxxxx) immediately following the 802.15.4 header. Any LoWPAN node encountering a dispatch value of 00xxxxxx shall discard the packet.

ip

normative-requirement §5.3 MUST

All link fragments for a datagram except the last one MUST be multiples of eight bytes in length, because the fragment offset field can only express multiples of eight bytes.

ip

normative-requirement §6 MUST

An IPv6 address prefix used for stateless autoconfiguration of an IEEE 802.15.4 interface MUST have a length of 64 bits. All zero addresses MUST NOT be used for either EUI-64 or short-address-derived interface identifiers.

ip

normative-requirement §2 MUST

Both source and destination addresses MUST be included in the IEEE 802.15.4 frame header for the mechanisms defined in this document. Source or destination PAN ID fields may also be included.

ip

normative-requirement §10.3.1 MUST

In a LOWPAN_HC1 compressed header, the Hop Limit (8 bits) MUST always be present and MUST always follow the encoding fields. Other non-compressed fields (address prefixes, IIDs, Traffic Class, Flow Label, Next Header) MUST follow the Hop Limit in the order implied by the HC1 encoding.

ip

normative-requirement §3 MUST

IPv6 level multicast packets MUST be carried as link-layer broadcast frames in IEEE 802.15.4 networks. The broadcast frames MUST only be heeded by devices within the specific PAN of the link in question, accomplished by including a matching PAN ID and short destination address 0xffff.

ip, multicast

normative-requirement §9 MUST

IPv6 multicast address mapping to 802.15.4 16-bit addresses (Section 9) MUST only be used in a mesh-enabled LoWPAN. An IPv6 multicast destination DST maps to the 16-bit address '100' | DST[15][bits 3-7] | DST[16].

ip, multicast

normative-requirement §2 MUST

IPv6 packets MUST be carried on IEEE 802.15.4 data frames. It is recommended (per RFC 3819) that such frames request acknowledgements to aid link-layer recovery.

ip, routing

normative-requirement §5.3 MUST

The reassembly timer MUST be set to a maximum of 60 seconds (matching the IPv6 reassembly timeout per RFC 2460). If the entire packet has not been reassembled when the timer expires, existing fragments MUST be discarded and the reassembly state MUST be flushed.

ip

normative-requirement §5.3 MUST

Upon detection of an IEEE 802.15.4 Disassociation event, fragment recipients MUST discard all link fragments of all partially reassembled datagrams, and fragment senders MUST discard all not-yet-transmitted link fragments of all partially transmitted datagrams.

ip

normative-requirement §5 MUST

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.

ip

protocol-element §5.1

Dispatch value bit patterns define: 00xxxxxx = NALP (not a LoWPAN frame, discard); 01 000001 = IPv6 (uncompressed); 01 000010 = LOWPAN_HC1 (compressed IPv6); 01 010000 = LOWPAN_BC0 (broadcast); 01 111111 = ESC (additional dispatch byte follows); 10 xxxxxx = MESH; 11 000xxx = FRAG1; 11 100xxx = FRAGN.

ip, registry

protocol-element §6 SHALL

For an interface using a 16-bit short address, the Interface Identifier is derived by constructing a pseudo 48-bit address as PAN_ID:16_zero_bits:16_bit_short_address and processing it per RFC 2464 (IPv6 over Ethernet). The U/L bit SHALL be set to zero because this is not a globally unique value.

ip

protocol-element §5.3

Fragment recipients use a four-tuple to identify all link fragments belonging to a given datagram: (1) sender's 802.15.4 source address (or Originator Address from Mesh header), (2) destination's 802.15.4 address (or Final Destination from Mesh header), (3) datagram_size, and (4) datagram_tag.

ip

protocol-element §11.1

The LOWPAN_BC0 broadcast header, used for mesh broadcast/multicast support, consists of the LOWPAN_BC0 dispatch value followed by an 8-bit Sequence Number that SHALL be incremented by the originator whenever it sends a new mesh broadcast or multicast packet, used to detect and suppress duplicate packets.

ip, multicast

protocol-element §4

The MTU for IPv6 packets over IEEE 802.15.4 is 1280 octets. The maximum 802.15.4 physical frame is 127 octets; after MAC overhead (25 bytes) and maximum AES-CCM-128 link-layer security overhead (21 bytes), only 81 octets remain, far below the IPv6 minimum, necessitating a fragmentation and reassembly adaptation layer.

ip

registry §12

This document creates an IANA registry for 16-bit short addresses used in 6LoWPAN packets. Defined ranges: 0xxxxxxxxxxxxxxx (unicast), 100xxxxxxxxxxxxx (multicast), 101-111xxxxxxxxxxxxx (reserved); 0xffff (broadcast) and 0xfffe are reserved per IEEE 802.15.4. Future assignments require 'Specification Required'.

ip, registry

registry §12

This document creates an IANA registry for the LoWPAN Dispatch type field (8-bit). Initial values defined are: NALP (00xxxxxx), IPv6 (01 000001), LOWPAN_HC1 (01 000010), LOWPAN_BC0 (01 010000), ESC (01 111111), MESH (10 xxxxxx), FRAG1 (11 000xxx), FRAGN (11 100xxx). Future assignments require 'Specification Required' per RFC 2434.

ip, registry

security-consideration §13

Interface Identifiers derived from EUI-64 MAC addresses have no protection from duplication through accident or forgery. Neighbor Discovery is susceptible to the threats in RFC 3756. Mesh routing introduces additional ad hoc routing threats per Karlof & Wagner. Users are urged to use IEEE 802.15.4 link-layer AES security (authentication or encryption), though key management is not specified by 802.15.4. FFDs communicating with off-link IPv6 peers should use end-to-end security (IPsec, TLS, etc.).

security, ip, routing

wire-format §5.3

Subsequent fragment headers (FRAGN) use pattern '11100' in bits 0-4, the same 11-bit datagram_size and 16-bit datagram_tag as FRAG1, plus an 8-bit datagram_offset expressing the fragment offset in units of 8 octets from the start of the payload datagram.

ip

wire-format §5.3

The first fragment header (FRAG1) uses pattern '11000' in bits 0-4, an 11-bit datagram_size field encoding the total uncompressed IP packet size, and a 16-bit datagram_tag identifying all fragments of a datagram.

ip

wire-format §10.2

The HC_UDP encoding byte (HC2 for UDP) compresses: source port (bit 0, compressed to 4-bit offset from 61616/0xF0B0), destination port (bit 1, same scheme), and length (bit 2, derivable from IPv6 Payload Length). The UDP checksum is always carried in full. The compressed UDP header takes 4 octets instead of 8.

ip, udp

wire-format §7

The IPv6 link-local address for an IEEE 802.15.4 interface is formed by appending the 64-bit Interface Identifier to the prefix FE80::/64 (10 bits '1111111010', 54 zero bits, then the IID).

ip

wire-format §5.1

The LoWPAN Dispatch header is 8 bits: bits 0-1 identify the type (01 for dispatch), and bits 2-7 are the 6-bit Dispatch selector identifying the header type that immediately follows.

ip

wire-format §10.1

The LOWPAN_HC1 compressed header consists of a single 8-bit 'HC1 encoding' byte followed by non-compressed inline fields. The encoding byte encodes: source address prefix/IID compression (bits 0-1), destination address prefix/IID compression (bits 2-3), Traffic Class and Flow Label (bit 4), Next Header type (bits 5-6: 00=inline, 01=UDP, 10=ICMP, 11=TCP), and HC2 present flag (bit 7). In the common case, an IPv6 header compresses from 40 octets to 2 octets.

ip

wire-format §5.2

The Mesh Addressing header begins with bits '10', followed by V (1 bit, 1 if originator uses 16-bit address), F (1 bit, 1 if final destination uses 16-bit address), HopsLft (4 bits, decremented at each hop; 0xF signals an 8-bit Deep Hops Left field follows), then originator and final destination link-layer addresses.

ip, routing

wire-format §8

The NDP Source/Target Link-layer Address option for 802.15.4 uses Type 1/2, Length=2 (16 octets) for EUI-64 addresses with zero padding, or Length=1 (8 octets) for 16-bit short addresses with zero padding. The IEEE 802.15.4 address is in canonical bit order.

ip