摘要

  • draft-ietf-6man-ipv6-neighbor-discovery-yang-08 的 IETF 最后征求意见期将于 2026 年 9 月 16 日结束；其中可写的 auto-resolve 开关可触发记录、丢弃邻居发现报文和封禁主机三种动作。
  • 9 月 5 日完成的 INTDIR 评审把草案评为“有问题但已就绪”，并指出安全章节似乎没有把 enhanced-dad/auto-resolve 列入敏感可写节点，尽管它能自动封禁主机。
  • 草案提供的是接口级汇总计数器，并未在标准模型中定义逐次封禁凭据或解封动作。部署方应在启用前补足归因、分步结果、有效期和回退路径。

模型验证通过，不等于处置边界已经说清

这份草案试图补齐 IPv6 邻居发现的标准化管理接口。它覆盖地址解析、重定向、代理邻居通告、邻居不可达检测，以及普通和增强型重复地址检测。Datatracker 显示第 08 版处于最后征求意见阶段，目标是建议标准；YANG 检查结果为零错误、零警告。这些信息说明模型在语法和结构上已经成熟，却不能替代对某个配置项后果的审查。

INTDIR 评审正好抓住了这个差别。评审者 Carlos Pignataro 认为，草案的安全注意事项遗漏了 enhanced-dad/auto-resolve 这一敏感可写节点。草案已经要求安全传输、相互认证，并提示可用 NACM 控制访问。但“谁能打开开关”只是权限的一半；另一半是设备后来封了谁、依据什么、持续多久，以及谁能把它恢复。

记录、丢包与封禁不是同一等级的动作

auto-resolve 的语义来自 RFC 7527。它设想一种特定信任结构：受信任的路由器为不受信任的 IPv6 终端提供接入。在文档给出的有线宽带例子里，接入汇聚设备若发现与自身暂定地址或乐观地址真正重复，应记录管理消息、丢弃收到的 ND 报文，并依据二层业务标识封禁对应调制解调器。

这是一条有明确场景的建议，不是所有网络遇到重复地址时都应自动封禁。RFC 7527 对其他环境的措辞更谨慎，而 RFC 4862 的基线做法是不给重复的暂定地址完成分配，并记录错误。YANG 叶节点虽然保留了“受信任路由器”和“不受信任主机”的语境，却作为可复用的接口级布尔配置出现。部署配置因此必须另行证明：这里是否真的存在同样的信任边界，二层标识能否稳定对应到应承担后果的接入主体。

三项动作还会出现不同的部分失败。日志可能写入失败而封禁成功；报文可能已丢弃，但主机归因仍不确定；封禁也可能在冲突消失后继续存在。一个开关能表达“允许自动处理”，却不能表达每一步是否成功，更不能说明哪种组合需要自动回滚或人工接管。

重复地址信号并非身份裁决

增强型 DAD 加入 nonce，是为了解决本机发出的邻居发现探测被网络环回后，看起来像另一台设备正在使用同一地址的问题。接收端比对 nonce，可以把自身回送的探测与其他消息区分开。这改善了判断，却没有把协议观察变成不可伪造的身份凭证。

RFC 4862 明确说重复地址检测并非完全可靠。RFC 7527 进一步指出，恶意节点可以改变 nonce，也可以用伪造的邻居通告回应探测；文档为此建议 SEND，并提到 SAVI 提供的保护。只要攻击者仍有机会制造触发信号，自动封禁就必须保存从“收到什么”到“认定是谁”的归因链。

有线宽带场景中的二层业务标识承担了这座桥梁。在共享介质、虚拟接入或标识频繁变化的环境中，这座桥可能并不存在。若系统只留下 IPv6 地址和一个累计丢包数，事后就很难回答被封主体为何等同于触发报文的发送者。

汇总计数器不能处理一次申诉

第 08 版列出了相当丰富的接口级统计量，包括各类 ND 报文的收发数量、丢弃数量和若干丢弃原因。它们适合观测趋势，也能帮助定位某个接口正在发生异常。但计数器不会告诉运维人员，哪一次判断造成哪一个接入主体被封。

草案展示的标准树中，没有把报文类型、接口、被声称的地址、二层归因、策略版本、三项动作结果和解除条件串成一条逐事件记录；也没有标准化的 unblock 操作或自动过期字段。这不等于厂商不能提供日志、通知或恢复命令，而是说启用同一个标准开关，并不会自动得到同样的审计与恢复能力。

合理的部署门槛应是一张“决定凭据”。它至少记录检测分类和时间、接口与目标地址、归因方式、配置来源、策略版本，以及记录、丢包、封禁各自的执行结果。封禁还应有范围、有效期、原因码和经过演练的解除路径。否则，一个便于编排的布尔值会把最难追责的部分留到故障之后。

来源