Summary

  • The current ROLL draft asks IANA for RPL control-message option values 0x0B and 0x0C for Response Spreading and DIO Option Request. The live IANA registry already assigns those values to RREQ and RREP under RFC 9854. Revision 02 made the same request; this is an unresolved conflict in the current text, not a newly introduced change.
  • The draft's N flag would make a multicast solicitation elicit an explicit, one-shot DIO without resetting the neighbours' Trickle timers. Its security section says repeated solicitations, maliciously chosen constraints and legacy nodes can still consume energy, airtime and processing or delay useful replies.

The socket is occupied

The RPL Control Message Options registry is the small ledger that tells an implementation what a numeric option type means. RFC 9854 records 0x0B as RREQ and 0x0C as RREP in that namespace; IANA's current table agrees. Section 7.2 of the 28 October draft asks for the same two values under new names. A draft can request a number. It cannot make an existing assignment disappear by putting the request in a table. The draft itself says the proposed values are to be confirmed by IANA.

That discrepancy has a practical shape. An option type is not commentary attached to a packet; it tells a receiver how to parse the following bytes. In one shared registry, a receiver cannot be given both “RREQ” and “Response Spreading” as the meaning of 0x0B, or both “RREP” and “DIO Option Request” as the meaning of 0x0C, without a disambiguating change. No published packet collision is documented here. The next valid revision needs different available code points or another explicit encoding decision before implementers can rely on the new options. Revision 02 already used these requests, so revision 03 did not create the collision; it carried it forward.

The numbers matter because the proposed mechanism has a real job. Under RFC 6550, a node can multicast a DODAG Information Solicitation, or DIS, when it does not know which neighbouring routers belong to the routing graph it wants. Matching neighbours treat that multicast as an inconsistency and reset their Trickle timers. DODAG Information Objects, or DIOs, then go out more often for a while. A joining leaf gets the information it needs, but the bill is distributed among routers that did not ask the question. The draft describes the surplus replies as energy use and possible congestion in a low-power network.

The proposed No Inconsistency, or N, flag changes that accounting. A router receiving a multicast DIS with N set must leave its matching Trickle timers alone and send an explicit DIO. That is a one-shot answer rather than a trigger for a period of faster timer-driven announcements. The T flag can make that answer unicast rather than multicast, reducing what unrelated neighbours must receive. A Response Spreading option can spread those one-shot answers across a chosen interval so they do not all collide on the channel. The R flag and DIO Option Request can select which DIO options the reply carries.

These are concrete ways to make a discovery request more precise and cheaper for everyone around it.

One answer is not a spending limit

The draft's security section supplies the uncomfortable second half. The N flag limits what a compliant router does after one solicitation; it does not stop an attacker from transmitting many solicitations. A forged or altered DIS can make neighbours send additional replies, evaluate routing metrics or schedule work. Constraints crafted to reject everyone can suppress useful responses and delay joining. An older router may still apply RFC 6550's Trickle reset even when a newer solicitor asked for the one-shot treatment.

The draft adds no new authentication or integrity mechanism; it calls for existing RPL protections, option validation, bounded resource use and consideration of rate limiting.

That is the institutional problem in miniature. The node that requests an answer controls the ask, while other nodes pay the radio and battery cost. The specification can narrow the request's effects, but an option bit is no substitute for control over who may send repeated requests and how mixed implementations behave. Nor can a draft borrow a code point because the new use feels more efficient. The registry has already made a promise to another protocol operation.

The Datatracker lists revision 03 as an active working-group Internet-Draft, not an RFC. A corrected code-point request and a trace from mixed old and new nodes under repeated DIS traffic would establish whether this design achieves its intended savings outside the document.

Sources