IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery
updates
- rfc-4944 — Transmission of IPv6 Packets over IEEE 802.15.4 Networks
Extracted elements (28)
Fragment forwarding uses an MPLS-like label-switching model derived from RFC 8930: the Datagram_Tag serves as the label, swapped at each hop as the source L2 address changes. This avoids per-hop datagram reassembly, which RFC 4944's original store-and-forward design required and which caused excessive memory, latency, and battery drain in multi-hop LLNs.
Refragmentation at intermediate nodes (allowed by RFC 8930) is explicitly prohibited here because fragments are recovered end-to-end based on their Sequence number; splitting a fragment mid-path would corrupt the sequence-to-offset mapping. Instead, the fragmenting endpoint is required to leave slack in the first fragment to absorb expansion at intermediate hops.
The Sequence number and Fragment_Offset are kept as separate independent fields rather than deriving offset as Sequence × Fragment_Size. This design enables retrying a long fragment (e.g., Sequence 5) as multiple smaller fragments (e.g., Sequences 13 and 14) when the path MTU decreases, without disrupting the reassembly buffer layout.
When the reassembling endpoint has the complete datagram, it sends an RFRAG-ACK with a FULL bitmap (all bits set) rather than a partial bitmap reflecting only received fragments. This allows intermediate nodes to unambiguously recognize datagram completion and clean up VRB state, even when fragment splitting and reassignment of sequence numbers occurred.
This specification requires an incremental transition via a 'flag day': deployments are expected to be managed and homogeneous. The new RFRAG and RFRAG-ACK dispatch types are incompatible with the RFC 4944 fragmentation sub-layer, and mixing nodes from both specifications on the same path is not supported.
When used with RFC 8138 (6LoWPAN Routing Header), consumed hops in a Source Routing Header reduce the first fragment's size en route. Intermediate nodes must adjust Datagram_Size and Fragment_Offset accordingly (Section 4.4), making this specification the required companion to RFC 8138 for fragment forwarding in route-over meshes.
For consistent fragmentation compression, any header that cannot fit within the first fragment MUST NOT be compressed when using this specification's fragmentation mechanism, per the requirement in RFC 6282 Section 2.
Fragments MUST be sent in round-robin fashion: the sender MUST send all fragments for a first time before retrying any lost fragment, and lost fragments MUST be retried in sequence, oldest first. This enables the receiver to acknowledge delayed fragments before they are retried.
If a router receives a non-zero Sequence fragment and the VRB lookup fails, it MUST NOT forward the fragment; instead it builds a NULL bitmap RFRAG-ACK abort and sends it back to the previous hop. If the reverse LSP for an RFRAG-ACK is not found, the router MUST silently drop the RFRAG-ACK.
If an intermediate node modifies the size of the first fragment (e.g., consuming a Routing Header), it MUST adapt the Datagram_Size (Fragment_Size field) and MUST save the difference in the VRB to add it as a correction to Fragment_Offset of all subsequent forwarded fragments.
Secure joining and link-layer security are REQUIRED to protect against on-path attacks, as the RFRAG fragmentation protocol does not include any native security mechanisms.
The ARQ process MUST be protected by a Retransmission Timeout (RTO) timer, with the fragment carrying the 'X' flag retried upon timeout for a configurable number of times (default MaxFragRetries=3, RECOMMENDED) with exponential backoff.
The Fragment_Size MUST be tailored to fit the minimal MTU along the path; refragmentation is not allowed since fragments are recovered end-to-end based on sequence number. The first fragment MUST have enough slack to accommodate less-efficient compression at next hops within the Link MTU.
The IPv6 header MUST be placed in the first fragment in full to enable routing decisions. The first fragment is routed and creates the LSP; subsequent fragments are label-switched along that LSP and cannot follow an alternate route.
The reassembling endpoint of a fragment with the 'E' (ECN) flag set MUST echo that information at most once by setting the 'E' flag in the next RFRAG-ACK. Upon receiving an 'E' flag, the window SHOULD be reduced at least by 1 and at most to 1.
Upon receipt of an acknowledgment with a NULL bitmap, the fragmenting endpoint MUST abort the transmission of the fragmented datagram, with the single exception that for the first fragment it MAY decide to retry via an alternate next hop.
When the reassembling endpoint receives a fragment with the Ack-Request ('X') flag set, it MUST send an RFRAG-ACK back to the originator to confirm receipt of all fragments received so far. The Ack-Request MUST be set on the last fragment if the fragmenting endpoint wishes to perform ARQ for the datagram.
Window_Size MUST be at least 1 and less than 33 (maximum 32). MaxFragmentSize MUST be less than 512 bytes when the PHY-layer unit is the byte. The management system SHOULD be capable of providing all protocol parameters, and an implementation MUST abide by configured minimum and maximum boundaries.
The Datagram_Tag is an 8-bit identifier locally unique to the link-layer sender of a fragment. It functions as an MPLS-like label that is swapped at each hop as the source link-layer address changes, enabling label switching of fragments without reassembly at intermediate nodes.
The Recoverable Fragment (RFRAG) is a new 6LoWPAN fragment type that carries a Sequence number (0–31), an Ack-Request ('X') flag, an ECN ('E') flag, a Datagram_Tag (8 bits), a Fragment_Size (10 bits), and a dual-use Fragment_Offset field (16 bits). The first fragment is identified by Sequence=0 and carries the Datagram_Size in the Fragment_Offset field; all subsequent fragments carry the byte offset of the fragment.
The RFRAG Acknowledgment Bitmap is a 32-bit field included in RFRAG-ACK messages. Each bit position maps one-to-one to a Sequence number; a set bit confirms receipt of that fragment. This enables selective recovery of individual lost fragments without retransmitting the entire datagram.
This document allocates four dispatch values from the '6LoWPAN Dispatch Type Field' registry (created by RFC 4944, reformatted by RFC 8025): bit pattern 11 10100x on Page 0 for RFRAG (Recoverable Fragment), and bit pattern 11 10101x on Page 0 for RFRAG-ACK (RFRAG Acknowledgment). Pages 1–14 for both patterns are Unassigned; Page 15 is Reserved for Experimental Use per RFC 8025.
An on-path attacker can prematurely end the transmission of a datagram by sending a forged RFRAG-ACK to the fragmenting endpoint, or cause extra fragment retransmissions by resetting bits in the RFRAG-ACK Bitmap, or force unnecessary acknowledgments by setting the Ack-Request bit in forwarded fragments. Link-layer security is required to mitigate these threats.
The VRB state required at intermediate routers exposes them to DoS attacks, as an attacker can exhaust router state by initiating many fragmented flows. The 8-bit Datagram_Tag wraps faster than RFC 4944's tag, but the ACK mechanism enables rapid state cleanup once a datagram is fully transmitted or aborted, mitigating lingering state exhaustion.
An abort condition is signaled on the forward path by a pseudo-fragment with Fragment_Offset=0. Each intermediate router forwards the abort along the VRB and destroys its state. The reassembling endpoint cleans up resources and, if an ACK was requested, responds with a NULL bitmap RFRAG-ACK that flows back to the fragmenting endpoint cleaning up all intermediate state.
Upon receiving the first fragment (Sequence=0), an intermediate router creates a VRB and forward LSP indexed by (incoming interface, previous-hop L2 address, Datagram_Tag), plus a reverse LSP for RFRAG-ACK return. Subsequent fragments are label-switched along this LSP. On FULL bitmap receipt, the router arms a short timer and destroys the VRB and LSP states on expiry.
The RFRAG-ACK header is 6 bytes: 7-bit dispatch (1110101), 1-bit E (ECN echo) flag, 8-bit Datagram_Tag, and a 32-bit RFRAG Acknowledgment Bitmap where bit offset x=1 means fragment with Sequence x was received. A NULL bitmap (all zeros) signals abort; a FULL bitmap (all ones) signals datagram fully received.
The RFRAG header is 4 bytes long: 7-bit dispatch (1110100), 1-bit E flag, 8-bit Datagram_Tag, 1-bit X (Ack-Request), 5-bit Sequence, 10-bit Fragment_Size, and 16-bit Fragment_Offset. Fragment_Offset encodes Datagram_Size when Sequence=0 and byte offset otherwise; Fragment_Offset=0 signals an abort condition.