Efficient Route Invalidation
Extracted elements (28)
A DelayDCO timer value of 1 second is recommended (mirroring the default DelayDAO timer) so that the common ancestor can collect updated DAOs from all preferred parents before initiating a DCO, reducing unnecessary DCO control overhead in multi-parent topologies.
NPDAO and regular DAO may race: the NPDAO can successfully remove the old route while the new DAO is lost in transit, causing route downtime for downstream traffic. The DCO mechanism ties route invalidation to receipt of a successful DAO at the common ancestor, avoiding this race condition.
NPDAO originates at the switching node and must travel upstream via the failing link to the previous parent, which may not be reachable. DCO instead originates at the common ancestor node and flows downstream along the old path, removing the dependency on the broken link.
RFC 6550 NPDAO only invalidates the route for the switching node itself; dependent nodes in the subDAG have no mechanism to invalidate their routes through the old path, leaving stale entries until route lifetime expiry. DCO allows the common ancestor to propagate cleanup downstream to all dependent nodes.
NPDAO (RFC 6550) and DCO can coexist in the same network and even in the same node. If non-DCO-capable 6LRs are in the DCO's path, route invalidation may fail or be partial. As a fallback, a node may send an NPDAO if it does not receive a DCO targeting itself within a deployment-specific time limit.
A 6LR that receives a DCO with a Path Sequence that is not newer than its stored Path Sequence for the target MUST NOT remove its current routing state and MUST NOT forward the DCO downstream. If the stored Path Sequence is as new as or newer, the DCO MUST be dropped (DCO Base Rule 5).
A node receiving a unicast DCO with its own address in the RPL Target option MUST strip off that Target option. If that Target option is the only one in the DCO, the DCO message MUST be dropped.
A node receiving a unicast DCO with the K flag set SHOULD respond with a DCO-ACK. The DCO-ACK SHOULD be sent as a unicast packet. A sender that sets the K flag but does not receive a DCO-ACK MAY reschedule the DCO, and a node that does not set the K flag SHOULD NOT retry the DCO.
If the DCO is generated in response to a DAO, the Transit Information option in the DCO MUST use the Path Sequence value from the newest Transit Information option received by the common parent for that target. When propagated by an intermediate 6LR, the Path Sequence MUST be copied from the received DCO.
In RPL's Preinstalled and Authenticated security modes, secure versions of DCO and DCO-ACK messages MUST be used. Secure DCO/DCO-ACK follow the RFC 6550 secure message format wrapping the DCO/DCO-ACK base objects.
The D flag MUST be set when a local RPLInstanceID is used, and the DODAGID field MUST be present when the D flag is set and MUST NOT be present when the D flag is not set. This applies to both the DCO and DCO-ACK messages.
The DCO message MUST carry at least one RPL Target option and one Transit Information option. The Transit Information option MUST carry a lifetime of 0x00000000 to indicate loss of reachability. The DCO MAY also carry Pad1, PadN, and RPL Target Descriptor options.
The RPLInstanceID and DODAGID fields of a DCO message MUST have the same values as those in the DAO message in response to which the DCO is generated on the common ancestor node.
Upon receiving a DAO with a Transit Information option having the 'I' flag set, and as a delayed response removing a routing adjacency to the indicated target, the common ancestor node SHOULD generate a DCO to the next hop associated with that adjacency.
When DCO retry limits are not known, an implementation MUST NOT retry a DCO more than once in 3 seconds and MUST NOT retry more than three times total.
An unsolicited DCO may be generated by a 6LR to proactively clean up entries on route expiry or when a full routing table requires eviction. An unsolicited DCO intended to discard all state regardless of Path Sequence MUST use a Path Sequence value of 240.
The DCO-ACK (code 0x08) is a unicast acknowledgment message for DCO. It includes RPLInstanceID, D flag, DCOSequence (echoed from DCO), and a DCO-ACK Status field based on the RPL Status Format. A StatusValue of 0 with U=0 indicates success; StatusValue of 1 with U=1 indicates 'No routing entry'.
The Destination Cleanup Object (DCO) is a new ICMPv6 RPL control message (code 0x07) that originates at a common ancestor node and travels downstream along the old path to proactively clean up routing state for a target node and its dependents. Unlike NPDAO which flows upstream, DCO flows downstream using link-local unicast addresses.
The 'I' (Invalidate previous route) flag is added to the Transit Information option (bit 1). The target node sets this flag in its regular DAO to signal the common ancestor node to generate a DCO for the previous route. Setting the flag is not counterproductive even when no previous route exists.
A new value is added to the 'RPL Rejection Status' subregistry: Value 1 = 'No routing entry', used in DCO-ACK Status to indicate the responding node did not find a routing entry for the indicated target.
Four new RPL Control Codes are allocated: 0x07 (DCO), 0x08 (DCO-ACK), 0x87 (Secure DCO), 0x88 (Secure DCO-ACK). Bit 1 of the Transit Information Option Flags registry is allocated for the 'I' (Invalidate previous route) flag.
Two new IANA registries created under the RPL registry: 'Destination Cleanup Object (DCO) Flags' (8-bit field; bit 0 = K/DCO-ACK request, bit 1 = D/DODAGID present; new allocations require IETF Review) and 'Destination Cleanup Object (DCO) Acknowledgment Flags' (8-bit field; bit 0 = D/DODAGID present).
A rogue common ancestor node can unilaterally initiate DCO-based route invalidation for any target in its routing table, since it already possesses the required state (Target Address and Path Sequence). This is mitigated by RPL's credential-based network membership but remains a risk in non-secure RPL deployments.
The 'I' flag in the Transit Information option can be spoofed by a malicious intermediate 6LR, which could forge a DAO with the 'I' flag set to trigger unauthorized route invalidation for a child node. This attack is constrained by Path Sequence freshness requirements and is comparable in risk to existing NPDAO spoofing in RFC 6550. The RPL Status field in a DCO could also be used as a one-time covert channel.
DCO propagation state: upon receiving a DCO, a 6LR compares the DCO's Path Sequence against its stored value for the target. If DCO Path Sequence is newer: invalidate routing entry and forward DCO downstream. If not newer: drop DCO and retain routing state. If the node itself is the target: strip the Target option and drop if it was the only one.
DCO-ACK Base Object: 32-bit aligned header with RPLInstanceID (8 bits), D flag (DODAGID present), 7-bit reserved Flags (zero), DCOSequence (8 bits, echoed from DCO), DCO-ACK Status (8 bits), followed by optional 128-bit DODAGID.
DCO Base Object: 32-bit aligned header with RPLInstanceID (8 bits), K flag (request DCO-ACK), D flag (DODAGID present), 6-bit reserved Flags (zero), RPL Status (8 bits), DCOSequence (8 bits), followed by optional 128-bit DODAGID and DCO Options.
Updated Transit Information Option adds the 'I' (Invalidate previous route) flag as bit 1 in the Flags octet (alongside existing E flag), with format: Type=0x06, Option Length, E|I|Flags, Path Control, Path Sequence, Path Lifetime. Parent Address MUST NOT be included in DCO Transit Information options.