6LoWPAN (RFC 4944 and RFC 6282)
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks" — IETF Standards Track, September 2007 — plus its successor RFC 6282, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", September 2011. Together they are the adaptation layer that lets an IPv6 network run on a radio that cannot carry an IPv6 packet.
Growth edge 2, closed on its second choice. The edge asked for IEEE 802.15.4, a Thread
specification or LoRa Alliance TS001, and all three are gated: IEEE sells 802.15.4, (corrected 2026-10-04: it does not — IEEE's
listing gives the PDF "at no cost compliments of the IEEE GET program"; see ieee-802-15-4) the LoRa Alliance
puts TS001 behind a resource hub, and the Connectivity Standards Alliance routes the Matter and Thread
specifications through a download-request form. The IETF does not gate anything. These two RFCs sit
one layer above 802.15.4 and specify the part that matters to a device, which is how an IP packet
crosses that link. So the spoke now holds a read specification for the network tier rather than a
description of one.
The arithmetic that forces the whole design
Two numbers, both quoted from RFC 4944, and everything else follows from the gap between them:
- IEEE 802.15.4's "maximum frame size at the media access control layer is 102 octets", and less once link-layer security is on.
- "The MTU size for IPv6 packets over IEEE 802.15.4 is 1280 octets" — because IPv6 requires every link to carry at least that.
"Since IPv6 requires support of packet sizes much larger than the largest IEEE 802.15.4 frame size, an adaptation layer is defined." An uncompressed IPv6 header alone is 40 octets, 39% of the frame before any payload, and a UDP header takes 8 more.
This corrects the spoke's own second-hand figure. iot-protocols says 6LoWPAN exists so IPv6 can cross a "127-byte frame." 127 octets is the PHY maximum; what a packet actually gets is the 102-octet MAC payload, and less with security enabled. The looser number understates the squeeze by a quarter. That is the sort of thing reading the primary is for.
What the two RFCs actually define
RFC 4944 supplies fragmentation and reassembly (a fragment header carrying datagram size, tag and offset), so a 1280-octet IPv6 packet can be split across frames, plus mesh addressing and the first compression scheme, LOWPAN_HC1, which squeezes a common IPv6 header from 40 octets to 2 (one for the encoding, one for the hop limit) and UDP from 8 to 4.
RFC 6282 obsoletes that compression scheme, and its reasons are worth recording because they are a compact account of how a standard fails in the field rather than on paper:
- "LOWPAN_HC1 is most effective for link-local unicast communication" — and link-local addresses "are usually not used for application-layer data traffic, so the actual value of this compression mechanism is limited." It optimised the traffic nobody sends.
- For routable addresses it "requires 64 bits for the IID when carried in-line and cannot be shortened even when it is derived from the IEEE 802.15.4 16-bit short address" — it refused to use information the link had already given it.
- "When the destination is an IPv6 multicast address, LOWPAN_HC1 requires the full 128-bit address to be carried in-line."
The replacement, LOWPAN_IPHC, reaches the same 2 octets for link-local and, the part that matters, 7 octets for a multi-hop routable packet, plus UDP checksum elision. RFC 6282's verdict on its predecessor is one line: "Implementation of Section 10 of [RFC4944] is now NOT RECOMMENDED."
What it gives the spoke
The first read specification here, and the floor moves again. zephyr broke the zero-T1 floor in August but is project documentation; this is a standards-track document with normative language and an errata trail. The synthesis's standing caution — that specs in this corpus are claims relayed by vendors — no longer covers the network tier.
It is also the independent re-examination the spoke keeps failing to find. RFC 6282 is one group of engineers reporting that an earlier group's mechanism does not work in the deployed case: in public, in the venue that published the original, with the reasons stated and the old text formally deprecated. That is the shape of the hub's standing "nobody re-runs anybody's numbers" item, four years after the fact and with no product at stake. Growth edge 1 still stands — nobody has checked a vendor's TOPS figure — but the field is not uniformly unaudited.
And it explains the fragmentation iot-protocols describes. Thread, ZigBee IP and Wi-SUN all sit on 802.15.4 and all need this adaptation layer; what they disagree about is everything above it. The one tier with a free, open, standards-track specification is the one nobody competes on.
Related
iot-protocols · zephyr · embedded-systems · device-reachability · synthesis