7 6LoWPAN RPL Routing

7.1 Start With One Packet Path

This section: Start With One Packet Path — Picture orchard sensors that send frost readings through nearby devices to a field bridge.

Break One Route Before Trusting the Tree

Picture orchard sensors that send frost readings through nearby devices to a field bridge. A route drawn on a screen may look stable while one weak relay is already losing messages. The release test must show how the path changes and what reaches the receiver.

Internet Protocol means the addressing rules used to move network packets. IPv6 means version 6 of those rules. 6LoWPAN means a way to carry IPv6 over small low-power radios. Routing Protocol for Low-Power and Lossy Networks (RPL) means rules for choosing paths in such a network. A directed acyclic graph means a set of one-way links with no loop back to the start. A gateway means the bridge to a wider network. Telemetry is the sensor reading and device status that this IPv6 mesh must carry to its destination.

Send one reading, weaken its preferred relay, remove that relay, repeat the reading, and restore the link. Record every parent change, delay, lost result, and duplicate seen at the gateway.

This runway does not prove that the best path stays best. The deeper sections explain ranks, parents, control messages, repairs, and the evidence needed for route acceptance.

Start with one packet path through 6LoWPAN RPL Routing. Name the sender, the next hop, the parent or router decision, and the evidence that proves the packet arrived for the reason the design expected.

Then widen the review. Mesh protocols fail at boundaries: sleepy children, route repair, parent changes, multicast, retries, and gateway custody. The chapter is easier to read when every detail is tied back to that first path.

7.2 In 60 Seconds

This section: In 60 Seconds

• RPL creates a destination-oriented directed acyclic graph, usually rooted at the border router.
• Route-over means each forwarding node acts at the IPv6 layer, so route evidence must match IPv6 next-hop behavior.
• DIO, DIS, and DAO records explain how nodes discover the DODAG, request updates, and advertise reachability.
• Parent and rank evidence should be reviewed with packet outcomes, not as isolated numbers.
• Upward telemetry and downward commands need separate evidence because they use different route state.
• Route repair evidence should include the trigger, before-and-after parent state, DODAG version or local repair notes, and the application result.
• A clean RPL decision states what direction, route class, node set, and evidence window were actually reviewed.

7.3 Learning Objectives

This section: Learning Objectives

By the end of this chapter, you will be able to:

• Review RPL route-over behavior using DODAG, parent, rank, DAO, packet, and border-router records.
• Distinguish evidence for upward, downward, point-to-point, discovery, diagnostic, and repair traffic.
• Explain how parent and rank records support routing claims without turning example values into universal design rules.
• Identify missing border-router, prefix, queue, or packet evidence before approving a 6LoWPAN routing result.
• Write a bounded RPL review decision with retest triggers and open evidence items.

7.4 Quick Check: 6LoWPAN Routing

This section: Quick Check: 6LoWPAN Routing

7.5 Prerequisites

This section: Prerequisites

This chapter assumes you have reviewed:

• 6LoWPAN Architecture Review Evidence, for stack-boundary and border-router custody.
• 6LoWPAN Header Compression Evidence, for packet reconstruction evidence.
• 6LoWPAN Fragmentation and Reassembly Evidence, for packet-size and reassembly boundaries.
• 6LoWPAN Lab Evidence Review, for capture plans and lab limits.
• 6LoWPAN Evidence Review Assessment, for evidence-bound assessment decisions.

7.6 RPL Review Claim

This section: RPL Review Claim — The claim is intentionally scoped.

Use a claim that can be tested against route evidence:

The claim is intentionally scoped. Evidence that proves upward telemetry reaches the root does not automatically prove downward commands, point-to-point control, repair behavior, or sleep-window delivery. Each traffic claim needs its own route evidence.

7.7 RPL Evidence Path

This section: RPL Evidence Path — Use Figure 7.1 to move from route formation to review decision.

Use Figure 7.1 to move from route formation to review decision.

Before RPL Evidence Path, inspect Figure 7.1 to compare “Packet Proof” with “Rank evidence”. Their juxtaposition makes RPL routing evidence path visible.

+

Read Figure 7.1 from “Packet Proof” to “Rank evidence”. Taken together, “Packet Proof” and “Rank evidence” express RPL routing evidence path. For RPL Evidence Path, the observed relationship between “Packet Proof” and “Rank evidence” is evidence that “Packet Proof” carries into the next decision.

The path prevents a common review failure: approving the routing design because a topology diagram looks tree-shaped. The review should tie the DODAG picture to records from the nodes, the border router, the packet capture, and the application result.

7.8 DODAG, Rank, and Root Model

This section: DODAG, Rank, and Root Model — RPL, defined in RFC 6550, organizes a low-power IPv6 mesh as a destination-oriented directed acyclic graph.

RPL, defined in RFC 6550, organizes a low-power IPv6 mesh as a destination-oriented directed acyclic graph. In most 6LoWPAN route-over reviews, that graph is rooted at the border router because the border router is also the custody point for prefix, ingress, egress, queue, and route-state records.

Before DODAG, Rank, and Root Model, inspect Figure 7.2 to compare “R:300” with “R:80”. Their juxtaposition makes RPL DODAG rank assignment and lowest-rank parent selection visible.

+

Read Figure 7.2 from “R:300” to “R:80”. Taken together, “R:300” and “R:80” express RPL DODAG rank assignment and lowest-rank parent selection. For DODAG, Rank, and Root Model, the observed relationship between “R:300” and “R:80” is evidence that “R:300” carries into the next decision.

Rank is not a score that can be copied across implementations. It is an implementation record derived from the objective function, link metrics, and parent set active during the review window. The practical evidence question is whether rank decreased toward the approved root for the packets being claimed, and whether any alternate parent choices were explained by the same metric policy.

7.9 Evidence Families

This section: Evidence Families — RPL review needs several evidence families.

RPL review needs several evidence families. A missing family usually means the decision should stay open.

7.10 Route-Over Boundary

This section: Route-Over Boundary — In route-over forwarding, each forwarding node is an IPv6 router for the constrained network.

In route-over forwarding, each forwarding node is an IPv6 router for the constrained network. That boundary matters for review. A compressed frame on one hop is not proof of the full route. The reviewer needs to know how the packet was reconstructed, which IPv6 next hop was selected, and whether the next link forwarded the same traffic class.

Mesh-under evidence is different because forwarding happens below the IPv6 layer. This chapter is focused on RPL route-over evidence. If a deployment mixes route-over and link-layer forwarding, the review should name the boundary where responsibility changes and avoid claiming that one evidence set proves both layers.

7.11 RPL And LOADng Boundary

This section: RPL And LOADng Boundary — RPL is the default route-over routing topic in this chapter because it is the common IPv6 routing protocol for low-power and lossy networks.

RPL is the default route-over routing topic in this chapter because it is the common IPv6 routing protocol for low-power and lossy networks. Some constrained designs, however, are reviewed against a reactive family such as LOADng, the Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation. That difference changes the evidence. RPL evidence is usually about DODAG root custody, rank, objective function, DAO state, and repair timing. LOADng evidence is about route requests, forwarding of those requests, route replies from the destination, route errors after breakage, sequence numbers, and whether optimized flooding reduced overhead without hiding a failed path.

Do not mix the two records. A LOADng-style route discovery trace can prove that one destination was discovered when traffic was needed, but it does not prove RPL parent stability. An RPL DODAG can prove a maintained route-over topology, but it does not prove an on-demand route request and reply policy. The review should name which routing family is active before accepting mesh routing inside the PAN or between the PAN and the wider IPv6 domain.

7.12 DODAG and Root Evidence

This section: DODAG and Root Evidence — The DODAG root is often the border router, but the review should still prove that role.

The DODAG root is often the border router, but the review should still prove that role. Root evidence should include:

• The RPL instance and DODAG ID used by the reviewed nodes.
• The root identity and whether it is grounded for the traffic being approved.
• The prefix and context information tied to the constrained network.
• The objective function or metric policy used for parent selection.
• The timing of root restarts, version changes, or global repair events.
• The border-router ingress and egress records for the same route claim.

The important question is not whether a root exists. It is whether the reviewed nodes are attached to the expected root, using the expected route policy, during the same packet window that produced the application result.

7.13 Parent and Rank Evidence

This section: Parent and Rank Evidence — Parent and rank records help explain path choice and loop avoidance, but they are not sufficient alone.

Parent and rank records help explain path choice and loop avoidance, but they are not sufficient alone. A strong review records preferred parent, candidate parents, rank, metric source, and whether the data path followed the parent choice.

Rank values should be treated as evidence from an implementation and configuration, not as a universal formula detached from the objective function. If a chapter or lab uses example numbers, the review should still ask what those numbers prove in the actual run.

7.14 Control Messages and Parent Choice

This section: Control Messages and Parent Choice — RPL control messages explain how route state forms before a data packet can prove the claim.

RPL control messages explain how route state forms before a data packet can prove the claim. The review should preserve the message role, direction, and observed result rather than listing acronyms in isolation.

A joining node listens for DIO records, computes its candidate rank through each viable parent, and selects the parent that gives the approved route toward the root under the configured objective function. If the review claims parent stability, it should name the candidate set and metric window. If it claims repair, it should show why the new parent was selected and whether the application traffic recovered.

7.15 Check: Parent Selection Evidence

This section: Check: Parent Selection Evidence

7.16 Upward Traffic Evidence

This section: Upward Traffic Evidence — Many 6LoWPAN workloads are dominated by upward telemetry from leaf nodes to the border router.

Many 6LoWPAN workloads are dominated by upward telemetry from leaf nodes to the border router. Upward evidence should include:

• Node membership in the expected DODAG.
• Preferred parent and rank during the packet window.
• Data packets moving toward the root through the expected next hops.
• Border-router ingress records for the same packets.
• Application receipt, deduplication, and timing records.
• Any packet class excluded from the claim.

Upward success is often the easiest RPL claim to prove. It is also easy to overstate. A clean upward telemetry run does not prove that commands can flow back down, that point-to-point node traffic is efficient, or that repair has been tested.

7.17 Downward Traffic Evidence

This section: Downward Traffic Evidence — Downward traffic needs separate review because it depends on route reachability from the root toward nodes.

Downward traffic needs separate review because it depends on route reachability from the root toward nodes. The evidence differs by mode and implementation, but the review question stays the same: can the root or intermediate routers forward the command to the reviewed node during the tested window?

Use Figure 7.3 to check whether the evidence matches the traffic direction.

Before downward Traffic Evidence, inspect Figure 7.3 to compare “telemetry” with “rank state”. Their juxtaposition makes RPL upward and downward route evidence map visible.

+

Read Figure 7.3 from “telemetry” to “rank state”. Taken together, “telemetry” and “rank state” express RPL upward and downward route evidence map. For downward Traffic Evidence, the observed relationship between “telemetry” and “rank state” is evidence that “telemetry” carries into the next decision.

For downward claims, look for DAO or equivalent route-state evidence, root route entries or source-route state, queue and drop records, command delivery at the node, and application acknowledgment. If the node sleeps, the claim also needs evidence for the delivery window or buffering behavior.

7.18 Storing and Non-Storing Route State

This section: Storing and Non-Storing Route State — Downward RPL evidence changes depending on where route state is stored.

Downward RPL evidence changes depending on where route state is stored. In storing mode, intermediate routers keep routing entries for nodes in their sub-tree, so a packet can turn downward at a common ancestor. In non-storing mode, the root holds the topology and source-routes packets down the recorded path. Both modes can support downward delivery, but they leave different evidence trails.

For storing mode, look for router table capacity, sub-tree entries, stale entries after repair, and queue/drop records at intermediate routers. For non-storing mode, look for root topology state, source-route header behavior, path length, fragmentation pressure, and the border-router record that ties the source route to the command being reviewed.

7.19 Check: Downward Route-State Mode

This section: Check: Downward Route-State Mode

7.20 Repair and Version Evidence

This section: Repair and Version Evidence — Route repair evidence should explain both the trigger and the result.

Route repair evidence should explain both the trigger and the result. A parent switch after a restart can be healthy, but it is not automatically proof of resilience. Review the before state, the change event, the after state, and the application outcome.

If the DODAG version changed, preserve that record with the reason if known. If only local repair occurred, record which node repaired and which traffic class was affected. Avoid using a single recovered ping or one successful message as proof that all route directions recovered.

7.21 Border-Router and Prefix Custody

This section: Border-Router and Prefix Custody — The border router is both an IPv6 edge and an RPL root in many 6LoWPAN deployments.

The border router is both an IPv6 edge and an RPL root in many 6LoWPAN deployments. Reviewers should treat it as a custody point, not just a gateway icon.

Border-router evidence should answer:

• Which prefix and context information were active for the constrained network?
• Which DODAG root state and route mode were active during the test?
• Which packets arrived from the constrained side and which packets left toward the wider IP network?
• Which downward commands entered the constrained side and where were they queued, dropped, or delivered?
• Which logs, captures, and application records share the same timestamps?

A server-side success message is not enough if the border-router constrained-side record is missing. The review should show that the route claim was true on both sides of the border.

7.22 Capture and Lab Evidence

This section: Capture and Lab Evidence — Packet captures are most useful when the capture plan is tied to a route question.

Packet captures are most useful when the capture plan is tied to a route question. A good RPL capture plan names the node set, traffic direction, route control messages, data packets, and application marker that will prove or disprove the claim.

7.23 Worked Review: Clean Upward Telemetry

This section: Worked Review: Clean Upward Telemetry — Scenario: ten leaf nodes publish temperature readings through a 6LoWPAN route-over network.

Scenario: ten leaf nodes publish temperature readings through a 6LoWPAN route-over network. The review packet window shows the expected DODAG ID, each node has a preferred parent, and the border router receives each message ID once. The application confirms receipt for the same message IDs.

Decision: accept the upward telemetry claim for the tested node set and packet class. Keep downward command delivery, route repair, and larger payload behavior open unless separate evidence covers them.

Retest trigger: repeat the review after firmware changes to RPL policy, prefix changes, border-router replacement, node relocation, or a measured increase in parent churn.

7.24 Worked Review: Downward Command Gap

This section: Worked Review: Downward Command Gap — Scenario: the border router sends actuator commands to three leaf nodes.

Scenario: the border router sends actuator commands to three leaf nodes. The server log shows commands accepted, but the constrained-side capture shows route state for only one node. Two commands are queued and later dropped. The node logs do not show application acknowledgments.

Decision: reject the downward readiness claim. Upward telemetry evidence may still be valid, but the command path is not proven. The next review needs route-state evidence, border-router constrained-side queue records, command delivery captures, and node acknowledgment records.

7.25 Worked Review: Parent Repair After Restart

This section: Worked Review: Parent Repair After Restart — Scenario: a parent router restarts during a lab run.

Scenario: a parent router restarts during a lab run. Five child nodes select new parents, then two return to the original parent after it rejoins. Telemetry resumes for all five nodes, but one node reports delayed command acknowledgment.

Decision: accept repair for the tested upward telemetry path after the restart. Keep downward command recovery open for the delayed node until the route-state, queue, and acknowledgment evidence explain the delay.

7.26 Common Mistakes

This section: Common Mistakes

7.27 RPL Review Checklist

This section: RPL Review Checklist

Before approving a 6LoWPAN RPL claim, confirm:

• The reviewed traffic direction and packet class are named.
• The DODAG root, instance, prefix, and route policy match the expected design.
• Preferred parent and rank evidence covers the reviewed nodes during the packet window.
• DAO or route-state evidence supports any downward claim.
• Packet captures and application records use the same message IDs or timestamps.
• Border-router ingress, egress, queue, and drop records are included when relevant.
• Repair evidence includes before, trigger, after, and decision records.
• The final decision says what is accepted, what remains open, and what must be retested.

7.28 Knowledge Check 1

This section: Knowledge Check 1

7.29 Knowledge Check 2

This section: Knowledge Check 2

7.30 Match the Evidence

This section: Match the Evidence

7.31 Order the Review

This section: Order the Review — Walk the first-packet cost and subsequent repair in the diagram Figure 7.4.

Walk the first-packet cost and subsequent repair in the diagram Figure 7.4.

+

In the diagram Figure 7.4, rREQ 41 is forwarded from A until G can return an RREP along A→B→D→G. When a next hop breaks, RERR informs the originator and the new path A→C→G demonstrates the latency-for-idle-state exchange of reactive routing.

7.32 Summary

This section: Summary — RPL review is a direction-specific routing evidence task.

RPL review is a direction-specific routing evidence task. The reviewer checks DODAG root custody, parent and rank records, route state, packet captures, border-router behavior, application outcomes, repair records, and lab boundaries before approving a claim.

The safest decision is bounded. Accept upward telemetry only when upward evidence proves it. Accept downward commands only when downward route state and delivery evidence prove them. Accept repair only when the before, trigger, after, and outcome records support the recovered traffic class.

7.33 Key Takeaway

This section: Key Takeaway — 6LoWPAN RPL Routing Evidence should validate RPL routing with parent choice, rank stability, control overhead, repair behavior, security, and deployment evidence.

6LoWPAN RPL Routing Evidence should validate RPL routing with parent choice, rank stability, control overhead, repair behavior, security, and deployment evidence.

7.34 Concept Relationships

This section: Concept Relationships

• 6LoWPAN Architecture Review Evidence explains the stack and border-router boundary that RPL depends on.
• 6LoWPAN Lab Evidence Review shows how to capture route evidence without overstating a lab run.
• 6LoWPAN Review Analysis Evidence provides the broader decision framework for accepting, rejecting, or retesting 6LoWPAN claims.
• 6LoWPAN Pitfall Debugging Evidence applies the same evidence logic to routing and packet failures.
• Thread Network Architecture shows how Thread builds a managed mesh using related constrained IPv6 ideas.

7.35 What’s Next

This section: What’s Next — Next, review 6LoWPAN Deployment Evidence Framework to connect route evidence with deployment decisions, then use 6LoWPAN Evidence Review Assessment to check whether the complete 6LoWPAN review can stay evidence-bound.

Next, review 6LoWPAN Deployment Evidence Framework to connect route evidence with deployment decisions, then use 6LoWPAN Evidence Review Assessment to check whether the complete 6LoWPAN review can stay evidence-bound.