Zigbee, Thread & Matter · Study deck
6LoWPAN Fragmentation and Reassembly
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.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
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.
Major section
Start With the Packet That Must Fit · In 60 Seconds · Fragmentation Claim
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.
- Reassembly consumes memory and time.
Major section
Packet-Fit Decision · Fragmentation Process Walkthrough
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.
- The mechanism is simple, but the review cost is real.
Major section
What FRAG1 Proves · What FRAGN 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.
- Size evidence: The datagram size lets the receiver know how much complete packet data must eventually be reconstructed.
- A page should not treat FRAG1 as just a label in a figure.
Major section
Header Field Ledger
The fragment fields are small, so every field has to earn its place in the review record.
- 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.
- A third fragment uses datagram_offset=20 for byte 160 and completes the final 60 bytes.
Major section
Reassembly Custody · Loss and Retry Evidence
Reassembly is a custody problem.
- 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.
- The core reliability problem is simple: reassembly needs every required piece.
Major 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.
- 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%.
- 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.
Major section
Multicast Boundary · Alternatives to Fragmentation · Worked Review: Diagnostic Log Upload
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.
Major section
Worked Review: Security Handshake or Update Traffic · Common Fragmentation Mistakes
Security handshakes and updates can create bursty or large messages.
- They should not be treated like ordinary sensor readings.
- Large-message security and update paths are not just packet-size problems.
- The result explains why a secure maintenance exchange can need a different chunk, retry, or recovery policy from routine telemetry.
Major section
Release Checklist · Interactive Review: Match Fragmentation Evidence to Risk
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.
Try it: Release Checklist · Interactive Review: Match Fragmentation Evidence to Risk in the chapter
Major section
Interactive Review: Order the Fragmentation Review · Interactive: 6LoWPAN Fragmentation and Reassembly · 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.
Try it: Interactive Review: Order the Fragmentation Review · Interactive: 6LoWPAN Fragmentation and Reassembly · Summary in the chapter
Major section
Key Takeaway · Concept Relationships
It enables larger packets, but adds reassembly state and loss exposure.
- 6LoWPAN Fragmentation and Reassembly Evidence should verify MTU pressure, fragmentation, reassembly loss, timeout behavior, and deployment evidence before relying on constrained IPv6 links.
- It helps avoid fragmentation, but only when context and payload assumptions are verified.
- It enables packet reconstruction, but creates custody and cleanup risk.
Deck summary
Key takeaways
Splitting the second message creates more work and more ways to fail.
- The gate starts with packet evidence.
- FRAG1 is the first fragment of a datagram.
- The fragment fields are small, so every field has to earn its place in the review record.
- Reassembly is a custody problem.
Retrieval practice
Recall check 1 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q1In 6LoWPAN, what happens to an IPv6 datagram if a single fragment is lost in transit?
Show answer
Answer: A One lost fragment forces the whole 6LoWPAN datagram to be retransmitted, since reassembly needs every fragment.
Retrieval practice
Recall check 2 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q2Why does 6LoWPAN fragmentation exist?
Show answer
Answer: A 6LoWPAN fragmentation is needed when a compressed IPv6 datagram is still larger than the usable payload of a constrained 802.15.4 frame.
Retrieval practice
Recall check 3 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q3How does a 6LoWPAN receiver decide whether a FRAGN payload belongs in an active reassembly buffer?
Show answer
Answer: A The receiver should accept FRAGN only when source, size, tag, and offset match an active reassembly context.
Retrieval practice
Recall check 4 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q4Why can a five-fragment datagram see about 41% loss on a link with 10% per-frame loss?
Show answer
Answer: A Reassembly needs all fragments, so per-frame loss compounds across the whole datagram.
Retrieval practice
Recall check 5 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q5A capture shows one FRAG1 frame followed by several FRAGN frames. What evidence must match before the receiver should place a FRAGN payload into the reassembly buffer?
Show answer
Answer: A FRAGN review is about safe matching and placement into an active reassembly context.
Retrieval practice
Recall check 6 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q6A lab page proves that small telemetry packets work, but a larger diagnostic response may fragment and has not been tested for missing fragments or timeout cleanup. What is the safest release label?
Show answer
Answer: A Fragmentation review can approve the proven traffic class while keeping untested large-packet behavior behind a gate.
Print reference
Answers 1 of 2
Answer key.
- A · One lost fragment forces the whole 6LoWPAN datagram to be retransmitted, since reassembly needs every fragment.
- A · 6LoWPAN fragmentation is needed when a compressed IPv6 datagram is still larger than the usable payload of a constrained 802.15.4 frame.
- A · The receiver should accept FRAGN only when source, size, tag, and offset match an active reassembly context.
- A · Reassembly needs all fragments, so per-frame loss compounds across the whole datagram.
Print reference
Answers 2 of 2
Answer key.
- A · FRAGN review is about safe matching and placement into an active reassembly context.
- A · Fragmentation review can approve the proven traffic class while keeping untested large-packet behavior behind a gate.