]> Instituto Metropole Digital (IMD) - UFRN

Natal RN Brazil cassius.filho.700@ufrn.edu.br

Instituto Metropole Digital (IMD) - UFRN

Natal RN Brazil ramonfontes@imd.ufrn.br

Routing Internet Engineering Task Force RPL MOP MOPex hybrid 6LoWPAN IoT LLN The Routing Protocol for Low-Power and Lossy Networks (RPL), defined in RFC 6550, enforces a single Mode of Operation (MOP) across all nodes within a DODAG. This rigidity prevents heterogeneous devices from independently selecting their forwarding behavior and creates permanent isolation between DODAGs operating with different MOPs. This document defines HyMRPL, a Hybrid Mode of Operation (MOP=6) that enables per-node functional profiles within a single DODAG. Nodes independently adopt Class-S (storing-like) or Class-N (non-storing-like) behavior without modifying RPL control message formats. Additionally, this document specifies an Inter-DODAG Bridge mechanism that uses MOP Extension (MOPex) signaling to interconnect DODAGs with different MOPs through cross-DODAG route injection. The mechanisms introduce zero additional control messages, maintain full backward compatibility via the J-flag in extended options, and have been validated with a functional implementation demonstrating 100% packet delivery ratio across MOP boundaries.

Introduction The Routing Protocol for Low-Power and Lossy Networks (RPL) organizes communication through Destination-Oriented Directed Acyclic Graphs (DODAGs) and defines four Modes of Operation (MOP) that determine how downward routes are established and maintained. The MOP is a 3-bit field in DIO messages set globally by the DODAG root and enforced uniformly across all participating nodes. This architectural constraint creates two problems in heterogeneous IoT deployments:

1. Intra-DODAG rigidity: All nodes must implement the same MOP regardless of individual capabilities. Memory-constrained devices cannot operate as Non-Storing within a Storing DODAG, and capable devices cannot maintain local routing tables within a Non-Storing DODAG.
2. Inter-DODAG isolation: DODAGs with different MOPs are completely incompatible. No mechanism exists for routing information exchange or data forwarding across MOP boundaries, creating permanently fragmented network islands.

This document addresses both problems by defining:

1. A Hybrid Mode of Operation (MOP=6) that enables per-node functional profiles (Class-S and Class-N) within a single DODAG without modifying RPL message formats.
2. An Inter-DODAG Bridge mechanism that leverages MOPex signaling to interconnect DODAGs with different MOPs through MOP masquerading and cross-DODAG route injection.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses terminology from and additionally defines:

HyMRPL:

Hybrid Mode RPL. The mechanism defined in this document enabling per-node MOP behavior within a single DODAG.

Class-S:

Storing-like profile. A node that maintains downward routing tables and performs target aggregation in DAO messages.

Class-N:

Non-storing-like profile. A node that maintains no downward state and delegates routing to the root's Source Routing Header (SRH) mechanism.

MOPex Bridge:

A node that participates in multiple DODAGs with different MOPs simultaneously, performing route translation and cross-DODAG injection.

Foreign DODAG:

A DODAG with a MOP different from the bridge's native mode, which the bridge has joined for translation purposes.

MOP Masquerading:

The technique of advertising MOP=7 (Extended) in DIO headers while carrying the real MOP value in a MOPex option, enabling backward-compatible inter-DODAG signaling.

Problem Statement RFC 6550 Section 6.3.1 specifies that the MOP field in DIO messages determines how downward routes are established for the entire DODAG. A node that does not support the advertised MOP MUST either join as a leaf (if it supports the MOP for upward routes only) or not join at all. This creates several operational challenges:

Intra-DODAG Heterogeneity In a network where some nodes have sufficient memory for routing tables (suitable for Storing mode) while others are severely constrained (suitable for Non-Storing mode), the administrator must choose a single MOP. Choosing Storing (MOP=2) wastes the memory-constrained nodes' resources on routing tables they cannot adequately maintain. Choosing Non-Storing (MOP=1) wastes the capable nodes' resources by not utilizing their local forwarding ability, increasing latency for paths that could be resolved locally. No mechanism exists in RFC 6550 for individual nodes to independently select their forwarding behavior based on their own resource constraints within a single DODAG.

Inter-DODAG Isolation When a network contains multiple DODAGs with different MOPs (e.g., a Storing DODAG for sensor nodes and a Non-Storing DODAG for actuators), no mechanism exists for:

• Advertising routes from one DODAG into another
• Translating DAO messages between different MOP formats
• Forwarding data packets across MOP boundaries

This creates permanent isolation between MOP domains with no recovery mechanism defined in the protocol.

HyMRPL: Hybrid Mode of Operation (MOP=6)

Overview HyMRPL defines MOP=6 as a Hybrid Mode of Operation. When the DODAG root advertises MOP=6 in DIO messages, each node in the DODAG independently selects one of two functional profiles based on its own capabilities:

• Class-S (Storing-like): The node maintains downward routing tables, installs routes via the operating system's routing subsystem, and aggregates child targets in DAO messages sent toward the root.
• Class-N (Non-storing-like): The node maintains no downward routing state. It forwards DAO messages without modification toward the root, which maintains full topology visibility and installs Source Routing Header (SRH) routes for paths traversing Class-N nodes.

No modification is introduced to DIO, DAO, or DIS message formats. The hybrid logic operates entirely at the behavioral level within the RPL implementation.

Class Selection A node operating under MOP=6 MUST select either Class-S or Class-N upon joining the DODAG. The selection mechanism is implementation-specific but SHOULD consider:

• Available memory for routing table entries
• Energy budget and expected lifetime
• Link stability to parent node
• Administrative policy (static configuration)

This document defines an adaptive selection model in that computes a composite score from multiple metrics. A node MAY change its class at runtime without requiring DODAG reconstruction. The class change takes effect at the next DAO transmission cycle. No DIO is emitted upon class change, and no global signaling is required.

DAO Processing Under MOP=6 Under MOP=6, DAO processing is class-dependent:

Root Behavior The DODAG root under MOP=6 MUST:

1. Accept DAO messages from all nodes regardless of their class.
2. Maintain a complete source routing tree (as in Non-Storing mode) enabling SRH-based forwarding for any path containing at least one Class-N node.
3. Install SRH lightweight tunnel routes via the operating system's routing interface for paths that require source routing.

Class-S Node Behavior A Class-S node receiving a DAO from a child MUST:

1. Install a downward route for each target in the DAO via the local routing table (as in Storing mode).
2. Aggregate the child's targets into its own DAO message sent toward the parent AND the root (dual-DAO).

The dual-DAO mechanism ensures the root always maintains complete topology visibility (enabling SRH for any Class-N path) while Class-S nodes simultaneously maintain local hop-by-hop routes for immediate descendants.

Class-N Node Behavior A Class-N node receiving a DAO from a child MUST:

1. NOT install any downward route locally.
2. Forward the DAO without modification toward the preferred parent (and/or root).

This behavior is identical to Non-Storing mode processing at intermediate nodes.

Downward Forwarding Behavior Three forwarding patterns emerge within a MOP=6 DODAG:

1. Purely storing paths: All nodes in the downward path are Class-S. Forwarding is hop-by-hop via locally installed routes. No SRH is needed.
2. Purely non-storing paths: At least one node in the path is Class-N. The root uses SRH (RFC 6554 ) to route packets through the complete path.
3. Mixed paths: Class-S segments forward hop-by-hop until reaching a Class-N segment, at which point the root's SRH takes over for the remainder.

Adaptive Class Selection Model This document defines an OPTIONAL adaptive model for automatic class selection. The model computes a composite score S_i for node i: S_i = w_pdr * (PDR_i / 100) + w_energy * (E_i / 100) + w_stab * I[parent_stable] Where:

• w_pdr = 0.4 (weight for packet delivery ratio)
• w_energy = 0.3 (weight for remaining energy)
• w_stab = 0.3 (weight for parent stability indicator)
• PDR_i = sliding window DAO-ACK success ratio
• E_i = battery level (0-100, EMA smoothed)
• I[parent_stable] = 1 if parent stable, 0 otherwise

If S_i >= 0.75 (threshold), the node selects Class-S. Otherwise, it selects Class-N. A hysteresis of 3 consecutive evaluation cycles prevents oscillation. Implementations MAY use different scoring functions, weights, or thresholds appropriate to their deployment scenario. The specific model defined here is RECOMMENDED as a baseline.

Runtime Class Switching A node operating under MOP=6 MAY switch its class at runtime. The switch:

• MUST NOT trigger emission of new DIO messages
• MUST NOT cause DODAG reconstruction
• MUST take effect at the next DAO cycle
• MUST be reversible

The switching mechanism is implementation-specific. This document recommends a secure command interface with authentication (e.g., HMAC-SHA256), replay protection (monotonic nonce), and rate limiting (maximum 3 switches per minute, minimum 10 seconds between switches) to prevent abuse.

Inter-DODAG Bridge Mechanism

Overview The Inter-DODAG Bridge mechanism enables connectivity between DODAGs operating with different MOPs. A bridge node participates in multiple DODAGs simultaneously, translating routing information and enabling data forwarding across MOP boundaries. The bridge leverages MOPex signaling to advertise its presence using MOP=7 (Extended) in DIO headers, with the real MOP carried in the extended option. This ensures backward compatibility: legacy nodes receiving MOP=7 DIOs will join as leaf per RFC 6550 Section 6.3.1 handling of unknown MOP values.

Wire Format The bridge uses MOP=7 in the DIO header's MOP field (bits 5-3 of the mopprf byte) and appends a 4-byte Extended RPL Control Option per :

Field descriptions:

X bit (MSB of Option Type):

Set to 1, yielding Option Type = 0x80. This marks the option as an Extended RPL Control Option.

Option Length:

2 (covers Flags + MOPex Value fields).

Option Flags:

• J (bit 7): Join as leaf only. MUST be set to 1 by bridge nodes to ensure legacy nodes that do not understand MOPex do not become routers in the bridge's DODAG.
• C (bit 6): Copy option in forwarded DIOs. Set to 0 by default.
• I (bit 5): Ignore entire message if option not understood. Set to 0 by default.
• Bits 4-0: Reserved, set to 0.

MOPex Value:

The actual Mode of Operation implemented by this node. For HyMRPL bridge nodes, this is 6 (Hybrid). Other values follow the MOPex Value Registry defined in .

Bridge Architecture A MOPex Bridge node operates with five components:

MOP Masquerading When building DIO messages, a bridge node MUST:

1. Set the MOP field in the DIO header to 7 (Extended).
2. Append the Extended RPL Control Option (type 0x80) containing the node's native MOP value and the J flag set to 1.

This allows MOPex-capable receivers to determine the bridge's true mode while legacy receivers see MOP=7 (unknown) and apply the behavior specified in RFC 6550 Section 6.3.1 for unknown MOP values (join as leaf if possible, or do not join).

Foreign DODAG Registration When a bridge node receives a DIO from a DODAG with a MOP different from its native mode, it MUST:

1. Verify that it can support the foreign MOP (implementation-specific capability check).
2. Register the foreign DODAG in a local table, recording the RPL Instance ID, DODAGID, original MOP, and MOPex value (if MOP=7).
3. Join the foreign DODAG as a router (if capable) or leaf, creating a local DAG structure for participation in that DODAG's routing protocol.

A bridge node SHOULD support up to 4 simultaneous foreign DODAGs. If the foreign DODAG table is full, the bridge MUST NOT join additional foreign DODAGs. The bridge MUST handle re-registration (updates to existing entries) when receiving subsequent DIOs from already-registered foreign DODAGs, and MUST remove entries when a foreign DODAG becomes unreachable (parent timeout or explicit notification).

Cross-DODAG Route Injection The core mechanism enabling inter-DODAG connectivity. When the bridge processes a DAO from DODAG X containing targets T_1 through T_n, it MUST:

1. For each other DODAG Y (where Y != X) that the bridge participates in:
   1. Add each target T_i as a child entry in the bridge's local DAG structure for DODAG Y, with the bridge's own address as the next-hop.
2. Include the injected targets in the bridge's next periodic DAO message toward the root of DODAG Y.

This causes the root of DODAG Y to install routes for T_1 through T_n via the bridge, enabling data forwarding from DODAG Y to nodes in DODAG X. Route injection MUST include deduplication: before adding a target to DODAG Y, the bridge MUST check if an identical prefix is already present. Duplicate entries MUST NOT be added. The bridge SHOULD maintain a maximum of 32 injected routes per foreign DODAG to prevent unbounded table growth.

DAO Translation When translating DAOs between DODAGs with different MOPs, the bridge performs format conversion:

Storing to Non-Storing Translation A Storing-mode DAO contains RPL Target options without Transit Information (the DAO sender is the implicit next-hop). When translating to a Non-Storing DODAG, the bridge MUST:

1. Copy all RPL Target options unchanged.
2. Add a Transit Information option with the bridge's own address in the "parent" field, indicating to the Non-Storing root that packets for these targets should be routed via the bridge.

Non-Storing to Storing Translation A Non-Storing DAO contains RPL Target options with Transit Information carrying the full source routing path. When translating to a Storing DODAG, the bridge MUST:

1. Copy all RPL Target options unchanged.
2. Strip the Transit Information option (Storing mode does not use it; the DAO sender is the implicit next-hop).
3. The receiving root in the Storing DODAG will interpret the bridge as the next-hop for all contained targets.

Hybrid (MOP=6) Translation MOP=6 DODAGs use a dual-DAO mechanism where DAOs are sent toward both the parent and the root. The bridge MUST handle both Storing-style DAOs (with aggregated targets from Class-S subtrees) and Non-Storing-style DAOs (with Transit Information from Class-N paths) using the appropriate translation rules above based on the target DODAG's MOP.

Data Forwarding Once routes are injected and propagated via standard DAO mechanisms, cross-DODAG data forwarding requires no special handling at the bridge. The bridge acts as a regular intermediate hop:

• Packets from DODAG A addressed to prefixes in DODAG B are forwarded by root A toward the bridge (which has advertised those prefixes via DAO).
• The bridge receives the packet and forwards it into DODAG B using its routes in that domain (either via hop-by-hop routing for Storing or via SRH for Non-Storing).

No encapsulation, tunneling, or special packet marking is required for cross-DODAG data transit.

DIO Option Processing A bridge node receiving a DIO MUST scan all options in the DIO options area to locate the Extended RPL Control Option (type 0x80), regardless of option ordering. The bridge MUST NOT assume the destination prefix option (type 0x03) is always the first option after the DIO base header. If a DIO carries MOP=7 in the header:

1. The bridge MUST parse the MOPex option to determine the real MOP value.
2. If the MOPex option is not found, the bridge MUST treat the DIO as having an unknown MOP and MUST NOT join as a router.
3. If an unknown extended option is encountered with the I flag set, the bridge MUST ignore the entire DIO message.

Backward Compatibility The J flag (Join as leaf only) in the MOPex option ensures incremental deployability:

• Existing RPL implementations that receive MOP=7 DIOs will not understand the MOP and, per RFC 6550 Section 6.3.1, will either join as leaf nodes or not join at all.
• The J=1 flag explicitly signals that nodes not understanding the MOPex option SHOULD join only as leaf.
• Only bridge nodes require MOPex-aware firmware. All other nodes can run standard RPL implementations.

Security Considerations

Class Switching Authentication Runtime class switching (Section 3.6) introduces a control plane interface that could be exploited by an attacker to force nodes into suboptimal classes, degrading network performance. Implementations providing external class switching interfaces MUST implement:

• Authentication of switch commands (e.g., HMAC-SHA256 with a pre-shared key).
• Replay protection using monotonically increasing nonces.
• Rate limiting (RECOMMENDED: maximum 3 switches per minute, minimum 10 seconds between consecutive switches).

Bridge Route Injection Security The cross-DODAG route injection mechanism (Section 4.3.3) creates a potential attack vector: a malicious bridge could advertise false routes between DODAGs, redirecting traffic through an attacker-controlled node (route poisoning). Mitigations:

• Bridge nodes SHOULD be administratively authorized. Implementations MAY require explicit configuration (e.g., a "mopex_bridge=true" flag) to prevent arbitrary nodes from acting as bridges.
• Route injection SHOULD be limited to prefixes actually learned from the foreign DODAG's DAO messages. A bridge MUST NOT inject routes for prefixes it has not received via legitimate DAO processing.
• The maximum number of injected routes per foreign DODAG SHOULD be bounded (this document recommends 32) to limit the blast radius of a compromised bridge.
• Implementations MAY support RPL security modes (RFC 6550 Section 10) to authenticate DAO messages between the bridge and DODAG roots.

MOP=7 Spoofing An attacker could emit DIOs with MOP=7 and a forged MOPex option to attract nodes. The J flag mitigates this by ensuring that nodes not understanding MOPex join only as leaf, limiting the attacker's ability to attract routing traffic. However, MOPex-capable nodes could still be deceived. Deployments operating in adversarial environments SHOULD use RPL security mode (authenticated DIOs per RFC 6550 Section 10) in addition to the mechanisms defined here.

IANA Considerations

Mode of Operation Registry This document requests IANA to assign the following value in the "RPL Mode of Operation" registry defined by RFC 6550:

Value	Description	Reference
6	Hybrid Mode (HyMRPL): Per-node Class-S/Class-N profiles within a single DODAG	[This Document]

Note: MOP value 7 is defined by as "Extended MOP" and is not requested by this document. This document defines the semantics for MOPex Value = 6 in the MOPex Value Registry.

MOPex Value Registry This document requests IANA to assign the following value in the "MOPex Value" registry defined by :

Value	Description	Reference
6	Hybrid Mode of Operation (HyMRPL)	[This Document]

Implementation Status [Note to RFC Editor: This section is to be removed before publication as an RFC. It is present per RFC 7942 .]

rpld Implementation Organization: Instituto Metropole Digital, UFRN, Brazil Implementation Name: rpld-hymrpl Description: Extension of rpld (user-space RPL daemon for Linux) implementing both HyMRPL (MOP=6) and the MOPex bridge mechanism. The implementation adds approximately 1000 lines of C code to rpld. Maturity Level: Experimental Coverage: This implementation covers the full specification defined in this document including:

• MOP=6 announcement in DIO messages
• Class-S and Class-N per-node behavior
• Dual-DAO processing
• Adaptive class selection model
• Secure runtime class switching via FIFO with HMAC
• MOPex option building and parsing (type 0x80)
• MOP masquerading (MOP=7 in DIO header)
• Foreign DODAG registration (up to 4)
• Cross-DODAG route injection with deduplication
• DAO translation between Storing and Non-Storing

Licensing: Open source (available at https://github.com/CassiusClayB/rpld_hymrpl) Implementation Experience:

• Tested on Linux kernel 6.11.0 with CONFIG_IPV6_RPL_LWTUNNEL for native SRH support.
• Validated using Mininet-WiFi with 6LoWPAN over virtual IEEE 802.15.4 (mac802154_hwsim) in topologies from 5 to 50 nodes.
• Over 100 independent experiment runs across 12 test categories demonstrate 100% PDR for intra-DODAG paths and 100% PDR for cross-DODAG paths through the bridge.
• Packet captures confirm MOP=7 visible on the wire with the 4-byte extended option (type 0x80, J=1, value=6).
• 10,266 data packets captured transiting through the bridge between DODAGs in a single experiment run.
• Convergence time for HyMRPL is up to 35% faster than Storing mode at 20 nodes.
• Under intermediate node failure, the dual reconvergence mechanism achieves 87.2% PDR vs. 64.1% for pure Non-Storing (23 percentage point advantage).

Contact: Cassius Clay B. Silva Filho <cassius.filho.700@ufrn.edu.br>

Operational Considerations

Overhead The mechanisms defined in this document introduce minimal overhead:

Aspect	HyMRPL (MOP=6)	MOPex Bridge
DIO size increase	0 bytes	+4 bytes (MOPex option)
Additional control messages	0	0
Memory per node	+1 byte (class field)	~2 KB (bridge state)
Code size	~300 lines	~700 lines

Scalability The convergence advantage of MOP=6 over pure Storing mode grows superlinearly with network size (observed: 23% at 5 nodes to 35% at 20 nodes). This is because MOP=6 avoids the distributed routing table maintenance overhead that limits Storing mode scalability. The bridge mechanism scales with the number of foreign DODAGs (bounded at 4) and the number of injected routes per foreign DODAG (bounded at 32). Deployments requiring more capacity may increase these bounds at the cost of additional memory on the bridge node.

Deployment Guidance Recommended deployment patterns:

• Single DODAG with mixed capabilities: Use MOP=6 with Class-S for capable routers and Class-N for constrained sensors. This requires only the root and participating nodes to support MOP=6.
• Multiple existing DODAGs: Deploy a bridge node with physical connectivity to both DODAGs. Only the bridge requires MOPex support; all other nodes continue operating with their existing MOP.
• Gradual migration: Start with MOP=6 for new deployments. Add bridge nodes when interconnection with legacy MOP=2 or MOP=1 DODAGs is needed. The J flag ensures no disruption to existing networks.

References Normative References &RFC2119; &RFC6550; &RFC6554; &RFC8174; Informative References &RFC7942;

Example Configurations

MOP=6 Root Configuration

MOPex Bridge Configuration

Inter-DODAG Topology Example

Root A -> Bridge -> Root B -> Node B1 ]]>

Experimental Results Summary The following results were obtained from the rpld-hymrpl implementation running on Mininet-WiFi with 6LoWPAN over mac802154_hwsim (Linux kernel 6.11.0).

Static Topology (5 nodes, 10 runs)

Metric	Storing	Non-Storing	HyMRPL
Convergence (s)	12.63	9.81	9.77
PDR 1-3 hop	100%	100%	100%
Latency 3-hop (ms)	0.21	0.29	0.29
DIO count (15s)	33	45	45

MOPex Bridge (5 nodes, 3 runs)

Metric	Value
Bridge MOPex DIOs emitted	18+ per run
Foreign DODAGs registered	2
Cross-DODAG injections	18 per run
Cross-DODAG PDR	100%
Cross-DODAG latency	0.3 ms
Data packets through bridge	10,266
Convergence time	~15 s

Mesh Resilience (15 nodes, node failure)

Mode	PDR under failure
Storing	79.5%
Non-Storing	64.1%
HyMRPL (MOP=6)	87.2%

The dual reconvergence mechanism (centralized SRH + local hop-by-hop) provides a 23 percentage point advantage over Non-Storing under intermediate node failure.

Acknowledgements The authors thank the developers of rpld for providing the base RPL daemon implementation, and the Mininet-WiFi team for the 6LoWPAN emulation framework used in experimental validation.