摘要

  • 6man 草案提出在 IPv6 逐跳选项中携带四字节 NRP Selector ID；支持它的节点据此选择本地资源，不支持的节点可以忽略后继续转发。
  • 第 16 版首次明确：观察该编号可能暴露业务等级，途中篡改则可能换队列、损害 SLA 或服务隔离。
  • 9 月 6 日公布的 shepherd write-up 认为文档可继续推进，却同时记录“没有已登记的实现状态”。程序共识与运行路径证据不是一回事。

草案把 Option Type 的最高两位设为 00。按 第 16 版 的含义，不认识 NR 选项的节点应跳过它，而不是当然丢包。这个设计有利于兼容，却也制造了最容易被误读的结果：报文到了终点，资源处理可能早已在某一跳降为普通转发。

入口节点先按本地规则分类，再选择 NRP、增加外层 IPv6 头并写入选择器。能以线速处理该选项的中间节点，以目的地址决定下一跳和出口接口，再以选择器决定接口上的带宽、缓存、队列或虚拟通道。相同编号只有在各节点能力、映射表和资源状态一致时，才可能形成连续含义。

S 位处理的是“会读但匹配不到”的情况。S=1 必须丢弃；S=0 必须按默认资源继续转发，仿佛选项不存在。它不能约束根本不识别该选项的设备。草案把严格模式用于 OAM 的例子很有价值：特定测试报文抵达，可以检验特定路径上的配置。但普通业务报文抵达仍不证明延迟、吞吐或隔离达标。

第 15 版 对新增安全风险的表述过宽。当前 XML 源文档 增加了两个具体威胁：旁观者可从选择器推断低时延或高吞吐业务并定向干扰；能篡改选择器的人可把流量送入另一队列。草案建议只在运营商控制的可信域中使用并按选项存在性过滤。可信域是运维边界，不是报文自带的身份、完整性或逐跳回执。

9 月 6 日的新闻来自进程，而非新版本上传。Datatracker 条目 与历史记录显示 shepherd 获任并提交 write-up。文件记录十一人支持、一人提出六项关联疑问；一度讨论替代编码，随后主席确认不作该改动而推进。一封邮件暗示部署意向，但 write-up 没把它升级为公开实现清单。

RFC 8200、RFC 7045、RFC 9098、RFC 9099与 RFC 9673共同说明 IPv6 扩展头处理的现实差异。RFC 9543、RFC 9732与 NRP 可扩展性草案给出资源分区背景；IANA IPv6 参数表仍是拟申请的登记面，而不是部署证明。

Heng Lu 的最小初始规范允许把共同格式做窄，把分类、编号和资源留给本地运营者；现实层要求区分符号与队列动作；运行代码优先则要求公开版本、配置和观测。选择器表达请求，不替路径签字。