Summary

  • draft-ietf-roll-enrollment-priority-18 defines a compact RPL option that carries a root version, urgency bit, minimum enrollment priority and approximate DODAG size; intermediate routers may increase the priority to reflect tighter local conditions.
  • A resulting value of 127 disables Join Proxy operation, but the value does not preserve which global policy, approximate measurement, hop increment, default after a capability gap, local resource limit or control-plane event produced it.
  • An enrollment-pressure receipt should keep the protocol signal small while recording the root statement, path, capability gaps, local calculation, advertised beacon, Pledge observation and eventual attempt outcome.

The device sees a preference, not a reason

A new device listens at the edge of a low-power mesh. Several nearby routers can act as Join Proxies, forwarding its enrollment traffic into a network that does not yet trust it. Their Enhanced Beacons carry priorities. Lower numbers are more attractive; a value at the maximum means the proxy function is unavailable. The device chooses what appears to be a viable entrance.

That mechanism has to be cheap. These routers operate with limited battery, bandwidth, memory and neighbour-cache space. Asking every Pledge to query a management service for a full capacity explanation would defeat the constraints the network was designed to respect. A few bits in a routing option can guide many devices away from congestion.

The resulting number is nevertheless easy to overread. It looks like the decision. In fact it is the end of a calculation distributed across several authorities and several times. A Pledge that observes priority 110 knows that a particular proxy currently advertises a weak preference. It does not know whether the root imposed a cautious base, whether an intermediate router raised it, whether the proxy lacks a Neighbor Cache Entry slot, whether an older router interrupted propagation or whether a compromised control-plane member injected the value.

Coordination can work without exposing all those facts on the air. Accountability cannot reconstruct them from the final number alone.

“Join” hides two different actions

The draft takes care with terminology. In the constrained-join architecture, a new node joins by authenticating and obtaining authorization to become a network member. In RPL, an already authorized node also “joins” when it selects a preferred parent and attaches to part of a DODAG. Revision 18 calls the first process enrollment and reserves join for the routing action, while retaining the inherited name Join Proxy.

That separation matters for failure analysis. A Pledge may fail to discover an available proxy. Its traffic may not cross the proxy. Authentication may fail under the Constrained Join Protocol. Authorization may reject the device. An enrolled device may later choose a different DODAG. Calling all of these outcomes “join failure” loses the point at which authority acted.

The proposed priority governs whether and how strongly a 6LowPAN Router offers the proxy entrance. It does not replace CoJP credentials or the authorization decision. An operational record should therefore say whether a device merely observed no attractive beacon, attempted proxy forwarding, completed authentication or reached membership authorization. A high priority is evidence about an entrance condition, not proof that the Pledge was denied membership.

A three-byte option carries a layered view

The new RPL DIO option is only three bytes. It contains an eight-bit Version Number interpreted as a lollipop counter, a T bit for an important update, a seven-bit Min Priority, a four-bit exponent and a four-bit DODAG-size value. The root generates the option. When it changes the minimum priority or size, it increments the version. If rapid propagation matters—for example, when enrollment should be closed—it sets T, so a router adopting the newer version resets its Trickle timer.

Lower Min Priority means more ability to accept children. The value 0x7f, decimal 127, represents infinity and disables Join Proxy operation. The root can use that value to announce that no new nodes are expected. Other root inputs may include DODAG size, bandwidth occupancy, root memory or an administrative decision.

As the option moves down the graph, a 6LR may increase Min Priority but not lower it. The ratchet has a sensible safety meaning: a constrained downstream path should not claim more admission capacity than the path above it offers. A would-be Join Proxy also adds local considerations, including upstream congestion and free NCE slots, and caps the result at 127. If the result remains below 127, the proxy function should be enabled and the value informs the Enhanced Beacon Join Priority from RFC 9032.

The wire value therefore combines at least two layers: a root statement and downstream restraint. It is not designed to carry a reason code for each increase. That economy is appropriate for routing. It is incomplete for an audit asking who closed enrollment and why.

Approximate size must stay approximate

DODAG size travels separately from priority because a deployment may or may not make admission policy depend on size. The option represents size as DODAGSz * 2^Exp, with only four bits for each component. A root rounds upward when an observed size falls between representable values.

Even the object being counted has a boundary. When size is inferred from DAO activity, it represents routes, not devices. The draft says the value can indicate load only where nodes advertise roughly the same number of addresses and generate roughly the same amount of traffic. A mesh in which one device announces several addresses while another announces one does not turn the route count into an exact population figure.

An operator who stores only “size 384” loses the raw exponent and mantissa, the measurement method, rounding direction, sampling time and traffic assumption. If that number later supports a policy decision, a reviewer cannot tell whether the network really grew, the address pattern changed or the encoding stepped to its next coarse bucket.

The safest public description is therefore modest: the option advertises an approximate root view. It can help balance DODAGs and guide already enrolled nodes that reconnect. It does not certify exact node count, equal traffic or future capacity.

The priority rises through a path it does not name

Each supporting router adopts the option from its selected parent. Older versions are ignored under the lollipop ordering. An increase from the parent is treated as inconsistent for Trickle purposes and therefore propagates quickly; a decrease may trigger the same reaction or may wait under the redundancy rule. The design naturally favours rapid restraint without requiring an equally urgent relaxation.

That asymmetry is operationally defensible. Opening too quickly can invite traffic a recovering network cannot handle. But it also means two subtrees may display different valid versions for a time. The observed priority needs its option Version, T state, selected parent and local receive time before a reviewer can compare it with the root's intent.

The local ratchet introduces another ambiguity. A value of 96 at the leaf could be the root's 96, a root value of 64 raised once, or a chain of smaller increases. A later node cannot lower the value even if its own battery and NCE capacity are ample. The number communicates the strongest accumulated restraint; it does not identify its source.

A causal receipt need not publish topology. It can use event-scoped router digests and coarse reason classes such as root policy, root capacity, upstream congestion, local memory, NCE availability or security override. The essential property is the ordered join: which version entered the path, where the value rose, and which local addition produced the advertised result.

Mixed firmware creates a silent boundary

The draft is candid about incremental deployment. RPL has not historically supplied a management protocol for these settings. Defaults may require a custom firmware image or a proprietary mechanism, both costly choices for devices intended to onboard without individual touch. Even a single-vendor fleet can have feature skew while firmware rolls out.

A router that does not understand the option neither acts on it nor propagates it. The subtree below that router stops receiving the root's DODAG size and minimum priority. A supporting router that receives no option uses 0x40, the midpoint, as its base Join Priority and falls back to local information.

Midpoint is a compromise, not proof of moderate capacity. If it is too low, the subtree may attract enrollment traffic that should have been deflected. If it is too high, it may refuse or redirect traffic unnecessarily. Several unsupported nodes can create alternating pockets that accept and reject. More seriously, a root's 127 shutdown cannot cross the gap.

This is a deployment boundary, not a defect that can be wished away. The receipt should state whether the base came from a root option or the absence default, and preserve a capability-path observation. Otherwise the same visible 0x40 can be mistaken for an intentional root policy when it actually marks missing propagation.

A protected control plane still has insiders

The option may be carried in RPL control messages protected at layer 2 or with Secure DIO methods. That prevents an outsider from simply becoming part of the control plane. It does not make every enrolled router honest forever.

Revision 18 notes two insider risks. A malicious member can observe the minimum priority and tell a confederate when the network is most open to enrollment traffic. It can also send DIOs with a different priority. A lower value can cause downstream routers to accept more Pledges than expected; a higher value can stall enrollment. RFC 9031's re-keying provisions give an operator a way to remove a compromised node, but the interval before removal still matters.

An audit should distinguish a validly protected message from an authorized policy statement. It needs the control-plane security context, source relationship, option version, anomaly result, quarantine or re-key event and the time when the route stopped influencing descendants. Confidentiality of the radio frame is not causal provenance.

Build an enrollment-pressure receipt

The receipt begins at the root: DODAG and root identity, option version, T, base Min Priority, root policy version, and the inputs the operator can actually prove. For size, it stores Exp, DODAGSz, calculated approximation, measurement method, rounding and the assumption used to relate routes to load. Unknown inputs remain unknown.

The path section records selected-parent changes, receive time, capability support and gaps, and each observed increment using a privacy-safe router digest and coarse reason class. The local section records the resource snapshot used by the prospective Join Proxy, the computed priority, whether proxy service was enabled, the value advertised in the Enhanced Beacon and its expiry.

The Pledge section stays narrow: an event-scoped identifier, beacon observed, selected proxy, attempt time and the last completed phase—discovery, forwarding, authentication or authorization. It should not expose device secrets or turn a public log into a stable map of the mesh. Operator policy, exception authority, reopening trigger, correction path and review time complete the record.

This is not a request to expand the three-byte option. Low-power coordination benefits from a strict common minimum. The receipt belongs in the operator's evidence system, where future deployment choices can remain local while the decision chain remains testable. Protocol restraint and institutional accountability are complementary when their boundary is explicit.

The document is still changing

At the research cutoff, revision 18 was an active ROLL working-group Internet-Draft intended for Proposed Standard, dated 21 July 2026 and expiring 22 January 2027. Datatracker showed “Submitted to IESG for Publication” and IESG Evaluation::Revised I-D Needed, with five DISCUSS positions, three more YES or NO OBJECTION positions needed and no telechat date. The page showed a later status update on 20 August.

Those details should not be compressed into “approved” or “deployed.” They show a mature proposal under active review. Implementations, firmware coverage, priority distributions, attack frequency and admission outcomes remain unknown unless a deployment publishes evidence for them.

Sources