摘要

  • ROLL 工作组草案第 03 版申请把 0x0B 和 0x0C 用作 Response Spreading 与 DIO Option Request；IANA 现行 RPL 选项登记表却已按 RFC 9854 把它们分给 RREQ、RREP。第 02 版也提出同样申请，冲突不是第 03 版新写出来的。
  • 草案的 N 位让收到组播 DIS 的邻居不重启 Trickle 定时器，而是明确发出一次 DIO。安全章节同时指出，反复发送 DIS、恶意约束和旧节点沿用原规则，仍能耗费电量、无线时隙与处理资源。

一个选项值，不能在同一本账里做两份工

RPL 控制消息的选项类型靠数字告诉接收者，后面的字节该怎样理解。RFC 9854把 0x0B 指定给 RREQ、0x0C 指定给 RREP；IANA 当前公开登记表逐项照录。草案第 7.2 节却要求把这两个值重新给 Response Spreading 和 DIO Option Request。草案可以提出编号，不能靠提出就抹掉已经分配的含义。它自己也注明，建议值仍待 IANA 确认。

这不是排版小错。选项类型是解析开关，收件方必须知道 0x0B 后面究竟是路由请求还是回应错开时间的参数。把两个意义写进同一数值空间，标准文本就给了实现者两套相冲的读法。眼下没有具名网络因这组编号发生报文事故的公开证据；要让新选项落地，下一版需要选择可用编号或明确另一种编码办法。第 02 版草案已如此申请，因此第 03 版的问题是延续未改，而非刚刚制造。

草案要解决的网络成本是真实的协议问题。RFC 6550允许节点向附近路由器组播 DIS。刚要入网的叶节点不知道谁属于目标 DODAG，往往只能广发。匹配的邻居把组播请求视为“不一致”，重启 Trickle 定时器，随后一段时间更频繁地发送 DIO。提问者得到路由信息，更多发送、接收和碰撞风险却落在周围设备身上。草案把多余 DIO 明确列为耗电和拥塞来源。

新规则试图把账单缩小。组播 DIS 带 N 位时，匹配路由器不得重启 Trickle，而要主动回一个 DIO；这是一回合的明确回应，不是一段加速公告。T 位可以让它单播给提问者，免得其他邻居也得接收。Response Spreading 可以把多个回应散开，减少同时抢占信道。R 位与 DIO Option Request 又能限定回应里带哪些选项。每一项都针对一个可见成本：持续广播、无关接收、同时碰撞和无用字节。

一次性回应，挡不住无限次敲门

草案的安全章节没有把省电写成万能结论。N 位只能约束合规路由器收到一条 DIS 后的动作；攻击者仍可反复发 DIS。伪造或改动的请求会要求更多 DIO、触发度量约束计算、操纵回应时间；恶意约束还可能让有用回应被压掉，拖慢入网。混用旧节点时，旧设备即使收到扩展请求，仍可能按 RFC 6550 重启 Trickle。草案并未发明新的身份认证或完整性保护，而是要求考虑已有 RPL 安全机制、选项校验、资源上限和限速。

这里暴露出一个朴素的权力分配：一个节点决定什么时候问，很多邻居承担回答成本。新位元可以让单次提问更节制，却不能自动授予提问者反复消耗邻居电池的权力。编号登记也是同一类约束：写草案的人可以希望某个数字空着，接收报文的设备只能依赖已经公开且唯一的分配。

IETF Datatracker仍将第 03 版列为工作组 Internet-Draft，尚非 RFC。下一版的修正编号，以及新旧节点在重复 DIS 下的发送与耗电记录，才会把这套省电设计从纸面带到可核验的网络。

来源