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 and destination 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
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
Fragmentation Process Walkthrough
The mechanism is simple, but the review cost is real.
- 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.
Major section
Fragmentation Process Walkthrough (continued)
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.
- 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.
Major section
What FRAG1 Proves · What FRAGN Proves
A page should not treat FRAG1 as just a label in a figure.
- 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.
- FRAGN carries later pieces of the same datagram.
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 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.
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.
- 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%.
- 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
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 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.
Try it: Release Checklist · Interactive Review: Match Fragmentation Evidence to Risk in the chapter
Major section
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: 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 mechanism is simple, but the review cost is real.
- The response can use three radio frames covering reconstructed bytes 0-79, 80-159, and 160-219.
- A page should not treat FRAG1 as just a label in a figure.
- The fragment fields are small, so every field has to earn its place in the review record.
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 missing fragment prevents delivery of the IPv6 datagram; without recovery, incomplete reassembly state expires.
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, destination, 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.
Q4If frames are lost independently, why 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 missing fragment prevents delivery of the IPv6 datagram; without recovery, incomplete reassembly state expires.
- 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, destination, 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.