On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network
Extracted elements (26)
Fragment forwarding requires all fragments of a datagram to follow the same path as the first fragment because subsequent fragments carry no IP header for routing; this is a fundamental caveat labeled 'No Per-Fragment Routing' that precludes per-fragment multipath.
Per-hop reassembly is avoided because it causes additive latency at every hop (each node must wait for all fragments before re-forming and forwarding the IPv6 packet) and exhausts scarce reassembly buffers on constrained nodes, leading to packet drops when multiple flows compete.
The MPLS label-swapping concept is leveraged to forward 6LoWPAN fragments that have no network-layer header (since fragmentation occurs below IP). The Datagram_Tag acts analogously to an MPLS label, enabling forwarding without examining IP headers in non-first fragments.
VRB entries store only a minimal amount of state (predecessor/successor addresses, tag swap values, and a few bytes of fragment remainder) rather than the full 1280-byte datagram, making the memory footprint roughly two orders of magnitude smaller than per-hop reassembly buffers.
Fragment forwarding reduces the benefit of 6LoWPAN header compression (RFC 6282) at intermediate hops because intermediate nodes forward compressed fragments without decompressing and recompressing; in exchange, memory usage is distributed along the path.
Node A must use the same link-layer address to send all fragments of the same datagram to node B, because node B correlates fragments using the sender's link-layer address combined with the Datagram_Tag.
VRB can be implemented without any change to RFC 4944 message formats, making it backward compatible with existing 6LoWPAN deployments that use RFC 4944 fragmentation headers.
A firewall SHOULD NOT forward fragments but instead should recompose the IP packet, check it in uncompressed form, and then forward it again as fragments if necessary. The firewall MUST drop the whole packet if overlapping fragments result in different data at the same offset.
An implementation MUST protect itself to keep the number of VRBs within capacity and to ensure that old VRBs are protected by a timer of a reasonable duration for the technology and destroyed upon timeout.
Consecutive fragments of the same datagram MUST be separated with an inter-frame gap that allows one fragment to progress beyond the next hop and beyond the interference domain before the next shows up, to avoid hidden terminal problems on half-duplex radios.
Since the Datagram_Tag is uniquely associated with the source link-layer address, the forwarding node MUST assign a new Datagram_Tag from its own namespace for the next hop and rewrite the fragment header of each fragment with that Datagram_Tag.
The Datagram_Tag SHOULD be assigned pseudorandomly in order to reduce the risk of attacks based on predictable fragment identification values.
To keep operation simple and consistent with RFC 4944, the first fragment MUST always be sent first.
Upon receiving a first fragment, a forwarding node that does fragment forwarding MUST attempt to create a state and forward the fragment as an atomic operation; if the first fragment cannot be forwarded, the state MUST be removed.
When a forwarding node receives a fragment other than a first fragment, it MUST look up state based on the source link-layer address and the Datagram_Tag; if no such state is found, the fragment MUST be dropped; otherwise, the fragment MUST be forwarded using the information in the state found.
6LoWPAN Fragment Forwarding (6LFF) is a technique whereby an intermediate node forwards a fragment without reassembling if the next hop is a similar 6LoWPAN link. The routing decision is made on the first fragment, which carries the IPv6 routing information, and state is stored to forward subsequent fragments along the same path.
6LoWPAN Fragment Forwarding Endpoints (6LFF endpoints) are the first and last nodes in an unbroken string of 6LFF nodes and are the only points where fragmentation and reassembly operations take place.
Datagram_Tag is an identifier of a datagram that is locally unique to the Layer 2 sender; combined with the sender's link-layer address, it becomes a globally unique identifier for the datagram within the duration of its transmission.
The 6LFF conceptual forwarding state at an intermediate node contains: the incoming Datagram_Tag and associated interface/link-layer address of the predecessor, the node's own source link-layer address for forwarding, the next-hop interface and link-layer address resolved on the first fragment, a locally allocated outgoing Datagram_Tag, an optional remainder buffer, and a stale-state timer.
The Virtual Reassembly Buffer (VRB) is a 6LFF implementation that stores per-flow state containing: predecessor and successor link-layer addresses, the incoming Datagram_Tag, the locally assigned outgoing Datagram_Tag, an optional buffer for fragment remainder bytes, and a timeout timer. It can be implemented without changes to RFC 4944.
A DoS resource-exhaustion attack is possible: an attacker sends many bogus first fragments without subsequent fragments, filling the VRB table. Implementations MUST limit VRB table size and enforce a timeout to destroy stale entries. This attack can be performed remotely on all nodes along a path simultaneously.
Attacks based on predictable Datagram_Tag values are possible because only a limited number of values exist and an authenticated network insider can guess valid tags. Pseudorandom Datagram_Tag assignment is RECOMMENDED, and larger tag sizes reduce both guessing probability and accidental reuse.
NIDS evasion via fragment reassembly ambiguity is largely mitigated in this context because fragmentation occurs within the LLN and an attacker would need to already be inside the network; NIDS systems are typically deployed at the exterior edge rather than within the LLN.
Overlapping fragment attacks are possible with 6LoWPAN fragments. Firewalls SHOULD NOT forward fragments and MUST drop a packet if overlapping fragments contain different data at the same offset. Overlapping fragments with identical payload are acceptable.
On receiving a first fragment: create forwarding state and forward (atomic); if forwarding fails, remove state. On receiving a non-first fragment: look up state by source link-layer address + Datagram_Tag; if state found, forward; if no state found, drop. State is destroyed on timer expiry.
Each 6LoWPAN fragment carries a fragmentation header (defined in Section 5.3 of RFC 4944) that includes a 16-bit Datagram_Tag, a Datagram_Size field indicating total packet length, and for non-first fragments a datagram-offset field. The first fragment has a distinct header format from subsequent fragments.