4 6LoWPAN Architecture: Addressing and Forwarding Decisions

zigbee-thread

6lowpan

architecture

6LoWPAN is the adaptation architecture that lets IPv6 packets cross IEEE 802.15.4 radio links. It does not replace IPv6, and it does not make constrained radios behave like Ethernet. It gives a constrained network a disciplined way to compress headers, decide when a packet must be fragmented, carry neighbor-discovery evidence, and hand packets between low-power devices and ordinary IPv6 networks.

This chapter treats the fundamentals as an architecture review. A good 6LoWPAN explanation names the layer boundary, shows which fields can be reconstructed, keeps fragmentation as an exception path, identifies the router roles, and records the evidence a later reviewer would need before calling the design ready.

4.1 Start With the Decision

A constrained node can rebuild an IPv6 address from link context. The network must then choose who forwards each packet and where.

4.2 Route Overview

This is part 2 of 2. Review 6LoWPAN Architecture: Compression and Fragmentation for the preceding evidence.

4.3 Learning Objectives

Reconstruct IPv6 addresses from 6LoWPAN context.
Compare route-over and mesh-under forwarding.

4.4 Chapter Roadmap

Stateless Address Reconstruction
Forwarding Roles
Route-Over And Mesh-Under
Thread Relationship
Worked Architecture Reviews
Building Telemetry
Commissioning And Discovery
Diagnostic Payload
Common Mistakes
Release Checklist
Encapsulation Header Formats
Fragment and Mesh Header Fields
Summary
Key Takeaway
Concept Relationships
What’s Next
Knowledge Check: Architecture Role
Knowledge Check: Fragmentation Boundary
Concept Match
Architecture Order

4.5 Stateless Address Reconstruction

6LoWPAN keeps configuration low by deriving IPv6 interface identifiers from IEEE 802.15.4 identities when the deployment context permits it. A node can form a link-local address from the link-local prefix plus an interface identifier derived from its 64-bit extended address, or from a configured short address under controlled assumptions. The architecture review should name which method is used and where uniqueness is checked.

This derivation also explains why IPHC can remove so many bytes. If the receiver already knows the link-layer source, link-layer destination, prefix context, and compression mode, it can reconstruct omitted IPv6 address fields instead of receiving two full 128-bit addresses in every packet. The saving is not cosmetic: omitting address fields can recover dozens of bytes in a frame whose useful payload budget may be only tens of bytes.

The risk is context drift. If a prefix, short-address assignment, commissioning state, or border-router context changes without a matching capture or log record, a packet can still decode but mean the wrong thing. Good architecture evidence therefore pairs every compression assumption with ownership, rollout, and retest rules.

4.6 Forwarding Roles

Use Figure 4.1 to separate device roles from protocol slogans.

Before forwarding Roles, inspect Figure 4.1 to compare “6LR” with “meter node”. Their juxtaposition makes 6LoWPAN node and router roles visible.

6LoWPAN architecture roles showing 6LoWPAN nodes, a 6LoWPAN router, a border router, and an IPv6 service, with evidence records for compression context, neighbor state, route state, fragment state, and border-router custody. — Figure 4.1: 6LoWPAN node and router roles.

Read Figure 4.1 from “6LR” to “meter node”. Taken together, “6LR” and “meter node” express 6LoWPAN node and router roles. For forwarding Roles, the observed relationship between “6LR” and “meter node” is evidence that “6LR” carries into the next decision.

The same radio technology can appear in several roles. A sleepy sensor may only originate or receive application traffic. A router forwards traffic for other nodes and needs stable power, route state, and monitoring. A border router connects the constrained network to the larger IPv6 domain and becomes an operations boundary.

6LoWPAN node Produces or consumes IPv6 traffic on the constrained link. Evidence: payload shape, sleep behavior, address, compression context, and failure status.

6LoWPAN router Forwards traffic inside the constrained network. Evidence: route state, neighbor stability, queue pressure, retry behavior, and power availability.

6LoWPAN border router Bridges the constrained domain and the ordinary IPv6 network. Evidence: prefix advertisement, firewall boundary, monitoring, logging, failover, and support ownership.

4.7 Route-Over And Mesh-Under

Forwarding can be described as route-over or mesh-under. The review should avoid treating either phrase as automatically better.

Route-over means IPv6 routing decisions are made at the network layer, often with RPL in a low-power and lossy network. It keeps per-hop routing evidence visible and is common in Thread-style architectures. Mesh-under means the adaptation or link layer hides mesh forwarding beneath IPv6. It can simplify the IPv6 view but can make fragment handling and per-hop evidence harder to inspect.

Use these decision checks:

Evidence visibility Can the operator see the route or only infer it from end-to-end symptoms?

Fragment handling Where are fragments forwarded, buffered, reassembled, or discarded?

Recovery behavior What happens when a relay node disappears, the border router changes, or a link becomes unstable?

The routing chapter examines RPL behavior in more detail. At the fundamentals level, the important point is that forwarding mode is an architecture boundary, not a label to add after the network is already built.

4.8 Thread Relationship

Thread uses IEEE 802.15.4 and 6LoWPAN concepts to support IPv6 in a managed low-power mesh. It also adds requirements and behavior above the raw 6LoWPAN adaptation layer, including commissioning, mesh-link management, security model, role behavior, and integration expectations for modern smart-home ecosystems.

That means the relationship should be stated carefully:

Shared foundation Thread depends on constrained IPv6 adaptation, header compression, and low-power mesh assumptions.

Added system rules Thread adds commissioning, security, role management, and operational behavior that raw 6LoWPAN does not define by itself.

Review consequence A Thread product review must inspect both the 6LoWPAN foundation and the Thread-specific controls above it.

This distinction keeps the course from mixing Zigbee, Thread, 6LoWPAN, Matter, and generic IEEE 802.15.4 into one vague “short-range mesh” category.

4.9 Worked Architecture Reviews

The following reviews show how to apply the fundamentals without turning the chapter into brittle packet arithmetic.

4.10 Building Telemetry

Scenario: Battery-powered room sensors report temperature, humidity, and occupancy status to a building controller through a border router.

Review: The design is a strong 6LoWPAN candidate only if ordinary reports stay small after security and compression overhead, the border router owns prefix and monitoring evidence, and route changes do not create hidden data gaps. Fragmented support logs should be treated as a maintenance path, not normal telemetry.

Decision: Release normal telemetry only after packet captures, neighbor-state snapshots, route recovery tests, and border-router health alerts are available.

4.11 Commissioning And Discovery

Scenario: A new device joins a constrained IPv6 mesh and needs address configuration, service discovery, and security setup.

Review: Joining traffic is not the same as steady-state telemetry. It may involve larger exchanges, more multicast-like behavior, temporary credentials, and route changes. The architecture must show how the network avoids discovery storms and how failed joins are visible to operators.

Decision: Treat commissioning as a named traffic class with its own timeout, retry, security, and operator-status evidence.

4.12 Diagnostic Payload

Scenario: A support engineer wants a node to upload a diagnostic record after repeated route failures.

Review: A diagnostic record may be larger than steady telemetry. The design should first ask whether it can be summarized or chunked at the application layer. If the constrained link must carry it, fragmentation evidence and reassembly limits belong in the release record.

Decision: Approve only the bounded diagnostic path, not a general assumption that large support payloads are safe.

4.13 Common Mistakes

Calling it a gateway protocol 6LoWPAN is an adaptation layer used by nodes on the constrained link, not only a function inside a border router.

Assuming best-case compression Compression depends on context. Global prefixes, multicast, security, diagnostics, and unusual ports may require more bytes.

Normalizing fragmentation Fragmentation support does not mean large packets are healthy traffic for a constrained mesh.

Hiding route evidence If the operator cannot inspect neighbor and route state, root cause analysis becomes guesswork.

Confusing Zigbee and Thread Both can use IEEE 802.15.4 radios, but their network, security, and application architectures are not the same.

Ignoring operations ownership The border router, prefix policy, firewall boundary, metrics, and firmware update path need named owners.

4.14 Release Checklist

Before accepting a 6LoWPAN architecture, require evidence for each item:

Traffic classes named Normal, commissioning, diagnostic, control, and maintenance traffic are separated.

Packet fit captured Representative packets show compression behavior and identify the paths that still need fragmentation.

Context controlled Address, prefix, hop-limit, UDP, and security context assumptions are documented and retestable.

Roles assigned Node, router, border-router, support, monitoring, and failure-response duties are explicit.

Recovery tested Neighbor churn, route repair, packet loss, fragment timeout, and border-router restart are observed.

Boundaries stated The record says what this 6LoWPAN network is not approved to carry.

4.15 Encapsulation Header Formats

6LoWPAN uses a chain of small, orthogonal headers rather than one fixed adaptation header. Read the chain from the IEEE 802.15.4 payload inward. A header is present only when that frame needs its job.

Delivery case	Adaptation-layer order	What is deliberately absent
One link hop, one frame	LOWPAN_IPHC dispatch/encoding, optional LOWPAN_NHC, application payload	Mesh and fragmentation headers
Mesh-under, one frame	Mesh addressing, LOWPAN_IPHC, optional LOWPAN_NHC, payload	Fragmentation header
One link hop, fragmented	FRAG1 then compressed datagram start in the first frame; FRAGN then the appropriate datagram slice in later frames	Mesh header
Mesh-under and fragmented	Mesh addressing first, then FRAG1 or FRAGN, then that fragment’s datagram content	Nothing: both optional jobs are needed

The ordering matters. A mesh-under forwarder must see originator, final destination, and hops left before interpreting the fragment. A reassembly endpoint must see datagram identity before interpreting the compressed IPv6 content. Only the first fragment begins the compressed header chain; later fragments carry continuing pieces of the datagram rather than restarting IPHC.

The dispatch bits at the front of each present header identify what parser comes next. For fragmentation, the first five bits distinguish the two forms:

Header	Leading bits and fields	Total size
First fragment, FRAG1	`11000` + 11-bit Datagram Size + 16-bit Datagram Tag	4 octets
Later fragment, FRAGN	`11100` + 11-bit Datagram Size + 16-bit Datagram Tag + 8-bit Datagram Offset	5 octets

The 11-bit size can represent the IPv6 minimum MTU of 1280 octets. Under the RFC 6282 compression rules, Datagram Size describes the IPv6 datagram before header compression, so the receiver can allocate the final reassembly buffer. Datagram Tag is selected by the sender and, together with link origin, destination, and size, separates interleaved datagrams. It is not a global message identifier and can wrap.

4.16 Fragment and Mesh Header Fields

Datagram Offset is absent from FRAG1 because the first fragment begins at offset zero. FRAGN encodes the offset in units of eight octets:

\text{byte offset}=8\times\text{Datagram Offset}.

For an uncompressed teaching example, if the first fragment carries the first 80 octets of the datagram, the next fragment uses offset $80/8=10=\mathtt{0x0A}$ . Every fragment except the last must end on an 8-octet boundary so that a following offset is representable. An arbitrary 11-bit byte offset is therefore replaced by an 8-bit count of eight-byte blocks. Reject overlapping slices, inconsistent sizes, impossible offsets, and reassembly timeouts rather than handing ambiguous bytes to IPv6.

Mesh addressing begins with this one-octet control field:

bits:       7 6 | 5 | 4 | 3 2 1 0
meaning:    1 0 | V | F | Hops Left

V=0 means the originator address is an extended 64-bit address; V=1 means it is a short 16-bit address. F applies the same choice to the final destination. The shortest base mesh header is therefore $1+2+2=5$ octets, and the longest is $1+8+8=17$ octets. Mixed modes give 11 octets. If the four-bit Hops Left field is 0xF, an extra Deep Hops Left octet follows the control byte, extending those sizes by one.

Each mesh-under forwarder decrements Hops Left before forwarding. If the result is zero, it drops the frame. Link-layer source and destination addresses can change at every radio hop, while the mesh originator and final-destination fields remain the endpoints of the layer-2 mesh path. That distinction is what lets reassembly use a stable datagram identity across forwarders.

Work the overhead before choosing fragmentation. With 16-bit originator and final addresses, FRAGN adds a 5-octet mesh header plus a 5-octet fragmentation header: 10 octets before compressed datagram bytes, in addition to the 802.15.4 MAC overhead and any security fields. With both extended addresses, that adaptation overhead rises to 22 octets. Short addresses save airtime, but only if address assignment and lifecycle remain trustworthy.

4.17 Summary

6LoWPAN is best understood as a constrained IPv6 architecture, not as a single compression trick. It sits between IPv6 and IEEE 802.15.4, compresses fields that can be reconstructed, fragments packets only when necessary, adapts neighbor discovery to a low-power mesh, and relies on clear node, router, and border-router responsibilities.

The architecture is strong when the evidence is visible: packet captures, context rules, route state, neighbor state, fragment behavior, border-router custody, and recovery tests. It is weak when it relies on slogans such as “native IP,” “low power mesh,” or “Thread uses it” without showing the operating record.

4.18 Key Takeaway

6LoWPAN Fundamentals and Architecture Evidence should connect IPv6 adaptation, compression, fragmentation, routing, security, constrained-device limits, and deployment evidence.

4.19 Concept Relationships

6LoWPAN and IPHC IPHC is the compression mechanism that makes many IPv6 packets practical on constrained frames.

6LoWPAN and RPL RPL is commonly used to route IPv6 traffic through low-power and lossy networks, especially in route-over designs.

6LoWPAN and Thread Thread uses constrained IPv6 foundations but adds its own managed mesh, commissioning, and security behavior.

6LoWPAN and Zigbee Zigbee shares the IEEE 802.15.4 radio family but uses a different network and application stack than IPv6-based 6LoWPAN or Thread.

4.20 What’s Next

Continue with these chapters:

6LoWPAN Header Compression, to inspect IPHC and compressed UDP behavior in detail.
6LoWPAN Fragmentation, to review FRAG1, FRAGN, reassembly, timeout, and large-packet policy.
6LoWPAN Routing with RPL, to study route-over mesh behavior and recovery evidence.
6LoWPAN Deployment Evidence Framework, to turn the architecture into a deployable plan.
Thread Introduction, to see how Thread builds a managed product network on constrained IPv6 foundations.

4.21 Knowledge Check: Architecture Role

4.22 Knowledge Check: Fragmentation Boundary

4.23 Concept Match

Match each 6LoWPAN architecture concept with the evidence it should provide.

4.24 Architecture Order

Place the architecture review steps in the strongest order.

4.25 Continue Your Route

This final part closes the route from Stateless Address Reconstruction through Architecture Order. Return to 6LoWPAN Architecture: Compression and Fragmentation or continue from the zigbee-thread module index.