Chapters

6 6LoWPAN Fragmentation and Reassembly

zigbee-thread
6lowpan
fragmentation

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.

6.1 Start With the Packet That Must Fit

This section: Start With the Packet That Must Fit — Picture a small field sensor sending a routine reading in one radio frame, then sending a larger fault record that no longer fits.

Prove Why the Packet Must Be Split

Picture a small field sensor sending a routine reading in one radio frame, then sending a larger fault record that no longer fits. Splitting the second message creates more work and more ways to fail. The review should first ask whether the message can stay small.

6LoWPAN is an adaptation method that carries IPv6 over constrained low-power links. IPv6 is an addressing system for networked devices. A payload means the useful content inside a message. Record the original size, available frame space, split identifier, part order, waiting limit, and memory owner before approving the larger path.

Drop the first part, drop a later part, change the order, repeat one part, and delay completion. Check that parts from different messages never mix, incomplete work expires, memory remains bounded, and the sender or operator sees a useful failure state.

This test does not prove every radio or large-message use. The deeper sections show the split headers, offsets, reassembly rules, loss cost, and cases where smaller messages or a different path are safer.

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.

6.2 In 60 Seconds

This section: 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.

6.3 Learning Objectives

This section: 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 and destination 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.

6.4 Quick Check: 6LoWPAN Fragmentation

This section: Quick Check: 6LoWPAN Fragmentation

6.5 Prerequisites

This section: Prerequisites

This chapter assumes you have already reviewed:

6.6 Fragmentation Claim

This section: 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.

6.7 Packet-Fit Decision

This section: Packet-Fit Decision — Use Figure 6.1 to compare the 220 B compressed diagnostic with the approximately 80 B usable frame budget, then inspect the FRAG1 and FRAGN fields that must be visible in capture.

Use Figure 6.1 to compare the 220 B compressed diagnostic with the approximately 80 B usable frame budget, then inspect the FRAG1 and FRAGN fields that must be visible in capture.

Worked 6LoWPAN fragmentation review showing a 220-byte compressed IPv6/UDP/CoAP diagnostic exceeding an approximately 80-byte usable frame budget, FRAG1 size and tag fields, FRAGN size, tag and offset fields, and reassembly checks by source, size, tag and offset.
Figure 6.1: 6LoWPAN fragmentation: packet fit to wire evidence.

Read Figure 6.1 from “Prove the packet does not fit” to “Reassembly check.” Compression has already been applied: the 220 B diagnostic is larger than one constrained-frame budget, so the design must either prove the fragmented path with captured size, tag, offset, matching, timeout, and cleanup evidence or change the application so the constrained link carries smaller chunks.

6.8 Fragmentation Process Walkthrough

This section: Fragmentation Process Walkthrough — The mechanism is simple, but the review cost is real.

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 link-layer source and destination (or mesh originator and final destination), size, and datagram tag, places later payloads by offset, and discards incomplete state when the timer expires.

Illustrative 6LoWPAN datagram split according to the measured usable IEEE 802.15.4 frame budget, with FRAG1 size and tag, FRAGN offset placement, acceptable out-of-order arrival, bounded receiver state, missing-range timeout and whole-datagram discard.
Figure 6.2: 6LoWPAN fragmentation from measured frame budget through FRAG1 and FRAGN fields to bounded offset-based reassembly.

Imagine a sleepy sensor sends an IPv6/UDP/CoAP diagnostic response whose uncompressed IPv6 datagram is 220 bytes. Assume the link can carry 80 bytes of datagram payload per IEEE 802.15.4 frame after MAC, mesh, security, and fragmentation overheads. The response can use three radio frames covering reconstructed bytes 0-79, 80-159, and 160-219. The first frame carries a compressed header, so its on-air datagram bytes are fewer than the 80 bytes they reconstruct. 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.

6.9 What FRAG1 Proves

This section: What FRAG1 Proves — FRAG1 is the first fragment of a datagram.

FRAG1 is the first fragment of a datagram. It carries the start of the datagram, including any compressed header, but a receiver may create a reassembly record when a later fragment arrives first.

Start evidence FRAG1 tells the receiver that this datagram is fragmented and identifies its first piece.
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 and destination, timer, and expected byte coverage when the first fragment arrives.

6.10 What FRAGN Proves

This section: What FRAGN Proves — FRAGN carries later pieces of the same datagram.

FRAGN carries later pieces of the same datagram. Its review evidence is about matching and placement.

Match evidence For an existing reassembly context, FRAGN must match tag, size, source, and destination before its offset is placed. If FRAGN arrives first, the receiver may create a bounded context from those fields.
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 After verifying timeout cleanup, test and document whether a later fragment is rejected or begins a fresh bounded context.

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.

6.11 Header Field Ledger

This section: Header Field Ledger — The fragment fields are small, so every field has to earn its place in the review record.

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 source, destination, 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 uncompressed IPv6 datagram example, FRAG1 can reconstruct bytes 0-79 and announce datagram_size=220 with tag 0x34a1. Its compressed header occupies fewer bytes on the air than the header it reconstructs. The next fragment repeats the size and tag and uses datagram_offset=10, because byte 80 starts after ten 8-byte units in the reconstructed datagram. 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 or destination, an offset that overlaps existing bytes, or a duplicate that arrives after timeout cleanup should not be quietly merged into the buffer.

6.12 Reassembly Custody

This section: Reassembly Custody — Reassembly is a custody problem.

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 6.3 as a compact review record.

6LoWPAN reassembly evidence record showing FRAG1 start, FRAGN matching, buffer state, missing fragment, timeout cleanup, loss status, and application alternative.
Figure 6.3: 6LoWPAN reassembly evidence record.
Context identity Record source and destination, datagram tag, datagram size, first-arrival 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.

6.13 Loss and Retry Evidence

This section: Loss and Retry Evidence — The core reliability problem is simple: reassembly needs every required piece.

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; test and document whether a later fragment is rejected or begins a fresh bounded context.
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.

6.14 Loss Amplification and Buffer Cost

This section: 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.

Fragmentation has an all-or-nothing reliability property: every fragment required for one datagram must arrive, or the datagram is discarded. If each frame is delivered independently with 90% probability, 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.

6.15 Multicast Boundary

This section: 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.

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.

6.16 Alternatives to Fragmentation

This section: Alternatives to Fragmentation — When the fragmentation gate fails, the design can often be improved without abandoning 6LoWPAN.

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.

6.17 Worked Review: Diagnostic Log Upload

This section: Worked Review: Diagnostic Log Upload — Suppose a sensor sometimes uploads a diagnostic log after a fault.

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.

6.18 Worked Review: Security Handshake or Update Traffic

This section: Worked Review: Security Handshake or Update Traffic — Security handshakes and updates can create bursty or large messages.

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.

6.18.1 Interactive: Find the Security-Overhead Fragment Boundary

Use the security-boundary preset below before approving the handshake or update record. It holds the application payload and link assumptions visible while adding the teaching security overhead that crosses the 802.15.4 frame boundary. Step through encapsulation, compression, fragmentation, and transmission so the extra fragment is tied to bytes rather than to a vague claim that security is expensive.

Carry the fragment count, total air bytes, and delivery-probability change into the release label. The result explains why a secure maintenance exchange can need a different chunk, retry, or recovery policy from routine telemetry.

6.19 Common Fragmentation Mistakes

This section: 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.

6.20 Release Checklist

This section: 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 and destination 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.

6.21 Knowledge Check: FRAG1 and FRAGN Evidence

This section: Knowledge Check: FRAG1 and FRAGN Evidence

6.22 Knowledge Check: Fragmentation Release Decision

This section: Knowledge Check: Fragmentation Release Decision

6.23 Interactive Review: Match Fragmentation Evidence to Risk

This section: Interactive Review: Match Fragmentation Evidence to Risk

6.24 Interactive Review: Order the Fragmentation Review

This section: Interactive Review: Order the Fragmentation Review

6.25 Summary

This section: Summary — 6LoWPAN fragmentation makes large IPv6 packets possible over constrained links, but it also creates a release gate.

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.

6.26 Key Takeaway

This section: 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.

6LoWPAN Fragmentation and Reassembly Evidence should verify MTU pressure, fragmentation, reassembly loss, timeout behavior, and deployment evidence before relying on constrained IPv6 links.

6.27 Concept Relationships

This section: 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, destination, 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.

6.28 What’s Next

This section: What’s Next

Find help

3 reviewed answers.

Where should I start in a module?

Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.

Modules and paths

Reviewed

What can I try when a project does not work?

Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.

When you are stuck

Reviewed

How do interactive examples work?

Use the interactive guide to check how examples and simulations work before changing your project.

Interactive examples guide

Reviewed