5 6LoWPAN Fragmentation and Reassembly
6LoWPAN fragmentation, 6LoWPAN reassembly, FRAG1 FRAGN, constrained IPv6 fragmentation, 6LoWPAN packet fit
6LoWPAN fragmentation is the adaptation-layer mechanism that lets an IPv6 packet cross a radio link whose frames are much smaller than ordinary IPv6 packets. It is useful, but it is not free. Every fragment adds state, airtime, loss exposure, buffer pressure, and troubleshooting work.
This chapter treats fragmentation as evidence to review. A good design shows when fragmentation is avoided, when it is unavoidable, how FRAG1 and FRAGN headers are matched, where reassembly happens, how incomplete datagrams are discarded, and what the operator sees when a large packet path is degraded.
5.1 Start With the Packet That Must Fit
Start with the packet pressure behind 6LoWPAN Fragmentation and Reassembly: IPv6 semantics have to survive on a small, lossy, low-power frame. The useful question is not which field is shortened first, but what evidence proves the adaptation still carries the right meaning.
Follow one payload from the original packet to the constrained link and back to the review record. Compression, fragmentation, reassembly, and retries make sense when they are tied to that visible journey.
5.2 In 60 Seconds
- Fragmentation is a gate, not a feature to assume. A design should prove why the packet cannot stay in a single constrained frame.
- FRAG1 starts a fragmented datagram with size and tag evidence. FRAGN carries matching tag evidence plus an offset so the receiver can place later pieces.
- Reassembly consumes memory and time. The receiver must keep enough state to match fragments, detect completion, and discard incomplete work.
- One missing fragment can invalidate the whole datagram. The release review should test loss, timeout, retry, and degraded-status behavior.
- Large diagnostics, discovery responses, security handshakes, and update traffic should usually be chunked above 6LoWPAN rather than hidden inside link fragmentation.
5.3 Learning Objectives
By the end of this chapter, you will be able to:
- Explain why constrained radio frames create a packet-fit decision before a 6LoWPAN design is approved.
- Distinguish FRAG1 evidence from FRAGN evidence without treating header diagrams as proof of implementation behavior.
- Review reassembly state, timeout, memory pressure, tag matching, source matching, and incomplete-datagram cleanup.
- Decide when to avoid 6LoWPAN fragmentation through smaller payloads, application-layer chunking, or a different network path.
- Build a release checklist that separates evidence-supported fragmentation from review-required large-packet behavior.
5.4 Quick Check: 6LoWPAN Fragmentation
5.5 Prerequisites
This chapter assumes you have already reviewed:
- 6LoWPAN Overview, for the constrained IPv6 adaptation goal.
- 6LoWPAN Header Compression, for the packet-size reduction that should happen before fragmentation is considered.
- 6LoWPAN Deployment Evidence Framework, for packet policy, border-router custody, and release gates.
- 6LoWPAN Routing with RPL, for multi-hop behavior and recovery evidence.
5.6 Fragmentation Claim
Use a claim that can be tested:
Fragmentation claim: The design handles only the named large-packet paths through 6LoWPAN fragmentation, with captured FRAG1 and FRAGN evidence, bounded reassembly state, timeout behavior, loss handling, operator status, and retest triggers.
This claim avoids two common drifts: saying “6LoWPAN supports IPv6 so large packets are fine,” or saying “fragmentation is bad so it must never exist.” The useful review question is narrower: which large packet path exists, why it exists, and what evidence shows it is safe enough for this application.
Named traffic Identify whether the packet is telemetry, command, diagnostic, discovery, security, update, or support traffic.
Packet fit Show the ordinary packet and the largest expected packet after compression and security overhead are considered.
Release boundary State whether the path is release-ready, release-with-limits, or review-required.
5.7 Packet-Fit Decision
Use Figure 5.1 to keep the review focused on evidence rather than arithmetic shortcuts.
The gate starts with packet evidence. Compression should be applied and verified first. If the packet still does not fit the constrained path, the design either proves a bounded fragmentation path or changes the application behavior so the constrained link carries smaller chunks.
5.8 Fragmentation Process Walkthrough
The mechanism is simple, but the review cost is real. The sender splits one large datagram into a first fragment and later fragments. The receiver groups them by source, size, and datagram tag, places later payloads by offset, and discards incomplete state when the timer expires.
Imagine a sleepy sensor sends a compressed IPv6/UDP/CoAP diagnostic response that is 220 bytes after header compression. If the link can carry about 80 bytes of datagram payload per IEEE 802.15.4 frame after MAC, mesh, security, and fragmentation overheads, the response becomes three radio frames: bytes 0-79, bytes 80-159, and bytes 160-219. That is not just one bigger packet. It is three airtime events, three collision opportunities, and one reassembly record that must stay alive until the last piece arrives.
Split The sender breaks the datagram into frame-sized fragments only after compression and payload shaping still cannot keep it single-frame.
Tag and offset Each fragment carries a datagram tag, and later fragments carry offsets so the receiver can place bytes in the right part of the reassembly buffer.
Reassemble or discard The receiver rebuilds the original datagram only after every expected byte range arrives; otherwise it times out and cleans up the partial state.
5.9 What FRAG1 Proves
FRAG1 is the first fragment of a datagram. It starts the reassembly record and carries the evidence the receiver needs to create the right context.
Start evidence FRAG1 tells the receiver that this datagram is fragmented and begins a new reassembly context.
Size evidence The datagram size lets the receiver know how much complete packet data must eventually be reconstructed.
Tag evidence The datagram tag lets the receiver group later fragments with the same original packet.
Header evidence FRAG1 often carries compressed IPv6 and transport header material needed by the final reconstructed packet.
A page should not treat FRAG1 as just a label in a figure. The review should show how the implementation records size, tag, source, timer, and expected byte coverage when the first fragment arrives.
5.10 What FRAGN Proves
FRAGN carries later pieces of the same datagram. Its review evidence is about matching and placement.
Match evidence FRAGN must match the original context by tag, size, and source boundary before it is accepted.
Offset evidence The offset tells the receiver where this payload belongs in the reassembly buffer.
Duplicate evidence The receiver should handle repeated or overlapping fragments without corrupting the reconstructed packet.
Late evidence Fragments that arrive after timeout or after cleanup should be discarded and logged as a reviewable condition.
FRAGN evidence is especially important when packets cross multiple hops. A reviewer should know whether fragments are forwarded as fragments, where reassembly happens, and which node owns the timeout and cleanup decision.
5.11 Header Field Ledger
The fragment fields are small, so every field has to earn its place in the review record.
Datagram size The total reassembled length tells the receiver when the byte coverage is complete and prevents a shorter partial packet from being delivered upward.
Datagram tag The tag groups fragments from the same original datagram. It is meaningful only with the source boundary and size evidence.
Datagram offset Later fragments use the offset, in 8-byte units, to show where their payload belongs in the reassembly buffer.
For the 220-byte diagnostic example, FRAG1 might carry bytes 0-79 and announce datagram_size=220 with tag 0x34a1. The next fragment repeats the size and tag and uses datagram_offset=10, because byte 80 starts after ten 8-byte units. A third fragment uses datagram_offset=20 for byte 160 and completes the final 60 bytes. A fragment with the same tag but the wrong source, an offset that overlaps existing bytes, or a duplicate that arrives after timeout cleanup should not be quietly merged into the buffer.
5.12 Reassembly Custody
Reassembly is a custody problem. The receiver holds incomplete packet state until the datagram is complete or the reviewable timeout path discards it.
Use Figure 5.3 as a compact review record.
Context identity Record source boundary, datagram tag, datagram size, first-fragment time, and accepted offsets.
Memory boundary Record how many incomplete datagrams can be held and what happens when no reassembly context is available.
Completion boundary Record how the implementation knows all expected byte ranges have arrived without overlap or gaps.
Cleanup boundary Record timeout, stale-fragment discard, duplicate-fragment handling, and operator-visible degraded status.
The cleanup boundary is not optional. Without it, a rare lost fragment can become a memory leak, a hidden failure, or a confusing intermittent bug.
5.13 Loss and Retry Evidence
The core reliability problem is simple: reassembly needs every required piece. If one required fragment does not arrive, the packet cannot be handed to IPv6 as complete.
Loss test Drop or block one middle fragment during a pilot and verify that the receiver does not deliver a partial packet.
Timeout test Verify that incomplete state is discarded after the configured timeout and that late fragments are rejected.
Retry test Show which layer retries the message and whether it resends the whole datagram or a smaller application chunk.
Status test Show what a learner, operator, or lab report sees when a large-packet path is degraded.
Avoid presenting a single delivery probability as the whole story. The stronger evidence is behavioral: what happens when a fragment is missing, late, duplicated, or retried.
5.14 Loss Amplification and Buffer Cost
Fragmentation has an all-or-nothing reliability property: every fragment required for one datagram must arrive, or the datagram is discarded. On a link where each frame is delivered 90% of the time, a five-fragment datagram succeeds with 0.90^5 = 0.59. The datagram loss rate is therefore about 1 - 0.59 = 0.41, even though the per-frame loss rate is only 10%.
That loss amplification combines with memory pressure. Three in-flight 1280-byte reassembly buffers consume 3 x 1280 = 3840 bytes before allocator overhead, timers, link-layer queues, routing tables, and application state are counted. On a small node, one noisy neighbor can force timeout or buffer eviction for unrelated traffic.
Use this arithmetic to bound the release decision. Robust designs cap concurrent reassemblies, expire partial buffers quickly, expose timeout status, and prefer application chunks such as CoAP block-wise transfer when the application can tolerate chunk-level acknowledgement and progress state.
5.15 Multicast Boundary
Fragmented multicast is a special risk because different receivers can miss different pieces, and the sender may not have a practical per-receiver recovery path.
Multicast boundary: Use multicast only when the payload and recovery model are explicitly safe for the constrained link. If the message may fragment, redesign the message, use smaller application chunks, or use a unicast recovery path.
This rule should be written as a boundary, not as a slogan. Some small multicast control messages can be useful. Large multicast payloads need stronger evidence or a different design.
5.16 Alternatives to Fragmentation
When the fragmentation gate fails, the design can often be improved without abandoning 6LoWPAN.
Smaller payload Use compact encoding, remove verbose fields, send deltas, or move rarely needed data out of the constrained path.
Application chunks Use application-layer chunking so each chunk has its own acknowledgement, retry, and progress state.
Border-router boundary Keep the constrained side small, and let the border router translate or aggregate for less constrained networks.
Different bearer Use another network path when the core requirement is large data movement rather than constrained IPv6 telemetry.
The best alternative is the one that matches the traffic type. Diagnostics, logs, security exchanges, and updates may each need a different chunking, retry, or offload plan.
5.17 Worked Review: Diagnostic Log Upload
Suppose a sensor sometimes uploads a diagnostic log after a fault. Steady telemetry fits the constrained path, but the diagnostic response is much larger.
Keep The chapter can keep the diagnostic use case if it labels the large path separately from ordinary telemetry.
Revise Do not claim the diagnostic path is reliable just because the telemetry path works. Test loss, timeout, retry, and operator status.
Better design Chunk the diagnostic data above 6LoWPAN, send only the needed fields, or retrieve the log through a less constrained maintenance path.
The release decision can approve telemetry while keeping diagnostics review-required. This is better than hiding a weak large-packet path behind a successful small-packet demo.
5.18 Worked Review: Security Handshake or Update Traffic
Security handshakes and updates can create bursty or large messages. They should not be treated like ordinary sensor readings.
Handshake evidence Show the largest message in the exchange, whether it fragments, and which side owns retry and timeout behavior.
Update evidence Show whether update chunks are bounded, individually acknowledged, resumable, and visible to operations.
Release label Use release-with-limits or review-required until the large-message path is tested under loss and restart conditions.
Large-message security and update paths are not just packet-size problems. They can also affect power, recovery time, operational visibility, and field support.
5.19 Common Fragmentation Mistakes
Compression confusion Assuming header compression guarantees single-frame delivery without checking the largest real payload.
Diagram-only proof Showing FRAG1 and FRAGN diagrams without captures, logs, or implementation records.
Hidden reassembly state Ignoring memory limits, timeout cleanup, duplicate fragments, and stale contexts.
Multicast overreach Sending large multicast messages without a per-receiver recovery plan.
Wrong retry layer Expecting 6LoWPAN to selectively retransmit one missing fragment when the actual retry behavior belongs elsewhere.
Telemetry-only testing Approving a network after small telemetry passes while diagnostics, security, and update traffic remain untested.
5.20 Release Checklist
Before approving a fragmentation path, verify these checks:
Packet evidence Ordinary and largest expected packets are identified after compression and security overhead are considered.
FRAG evidence FRAG1, FRAGN, tag, size, offset, source matching, and duplicate handling are visible in capture or logs.
Reassembly evidence Memory, timeout, completion, stale-fragment, and no-context behavior are documented.
Failure evidence Missing, late, duplicated, and restarted-fragment paths have been tested.
Alternative evidence The design explains why smaller payloads, application chunks, border-router offload, or another bearer are not better.
Learning evidence Assessments test packet-fit and reassembly decisions, not code syntax or fragile arithmetic.
5.21 Knowledge Check: FRAG1 and FRAGN Evidence
5.22 Knowledge Check: Fragmentation Release Decision
5.23 Interactive Review: Match Fragmentation Evidence to Risk
5.24 Interactive Review: Order the Fragmentation Review
5.25 Summary
6LoWPAN fragmentation makes large IPv6 packets possible over constrained links, but it also creates a release gate. The reviewer should prove packet fit, FRAG1 and FRAGN matching, reassembly custody, memory and timeout behavior, loss response, multicast boundaries, and alternatives. Strong chapters do not rely on big formulas, code snippets, or optimistic tables. They show what traffic is proven, what is limited, and what must be retested.
5.26 Key Takeaway
6LoWPAN Fragmentation and Reassembly Evidence should verify MTU pressure, fragmentation, reassembly loss, timeout behavior, and deployment evidence before relying on constrained IPv6 links.
5.27 Concept Relationships
Header compression Reduces packet size before the fragmentation decision. It helps avoid fragmentation, but only when context and payload assumptions are verified.
Fragmentation Splits a datagram for constrained forwarding. It enables larger packets, but adds reassembly state and loss exposure.
Reassembly Depends on tag, size, source, offset, memory, and timeout behavior. It enables packet reconstruction, but creates custody and cleanup risk.
Application chunking Moves large-message control above 6LoWPAN. It can improve retry visibility, but adds application complexity and progress tracking.
5.28 What’s Next
- 6LoWPAN Routing with RPL: Review how multi-hop forwarding and recovery affect constrained packet paths.
- 6LoWPAN Deployment Evidence Framework: Place fragmentation policy into the wider deployment release record.
- 6LoWPAN Pitfalls: Review common mistakes that turn fragmentation into hidden production risk.
- 6LoWPAN Lab Simulation: Practice capture-based review of constrained packet behavior.
- 6LoWPAN Comprehensive Review: Combine fragmentation with compression, routing, border-router, and validation evidence.