摘要

  • RFC 6164 只对“恰好两台路由器、没有主机、按点到点方式运行”的链路建议 /127，并要求两端在该前缀上停用 Subnet-Router anycast。
  • IPAM、接口标签和规范符合性声明都不能单独证明这组条件；它们分别属于配置层、分类层和承诺层，仍需由现场拓扑与运行行为补齐证据。

两个地址不等于两个参与者

运维系统很容易产生一种视觉错觉：看到 /127，便以为链路天然只有两端。地址空间确实只剩两个值，但承载它的以太网服务、隧道或虚拟交换结构仍可能允许第三个参与者加入。配置限制了地址选择，没有锁住物理和逻辑介质。

RFC 6164 的适用范围因此写得很窄。它面向路由器之间的点到点链路，链路上只能有两台路由器，不能有主机。以太网可以进入这个范围，但必须被配置为点到点。路由器到主机、路由器与主机混合的网络不在范围内，链路本地地址也不是这份建议讨论的对象。

这些不是附加说明，而是规范成立的输入。把一条多点服务标成 point-to-point，不会让第三个接入能力消失；给接口配置 /127，也不会让对端实现自动遵守相同规则。规范能定义兼容集合，不能把设备写进集合。

2003 年的冲突是真实的

RFC 3627 的警告来自一个精确场景。/127 中只有偶数和奇数两个地址。假如 Router A 使用奇数地址，IPv6 地址架构还可能要求它把接口标识全为零的偶数地址作为 Subnet-Router anycast 接收。此时 Router B 再把偶数地址配置为单播，重复地址检测就可能失败。

文档承认，两台路由器之间几乎没有使用这种 anycast 的必要。它也承认，大规模网络里尚未明显观察到问题，原因可能是实现并没有普遍启用这项功能。但这恰恰令配置者无法放心：旧设备没做，不代表替换后的设备也没做；一端做、另一端不做，就会让同一地址承担两种身份。

所以当时的建议并不荒唐。它优先选择 /64，也列出 /126、两个 /128、/112 或 /120 等方案。核心是避免把可运行性押在一个无法从配置表验证的实现差异上。

RFC 6164 后来明确说，早期分析是正确的。新证据不是证明冲突不存在，而是说明可以通过更小的运行合同把冲突拿掉。

新合同同时修改两个条件

RFC 6164 的第一个强制要求是：路由器必须支持在路由器间点到点链路上配置 /127。第二个强制要求紧随其后：使用 /127 时，必须对该前缀停用 Subnet-Router anycast。

两条必须一起读。第一条让两个地址都能成为端点单播；第二条阻止其中的全零值再被另一端以 anycast 身份抢占。新规范不是靠标题压倒旧问题，而是改变产生旧问题的实现条件。

它也没有把整个父地址空间宣布为自由区。如果多个 /127 从同一个 /64 切出，低 64 位全零的值不应分配成单播；最高的 128 个接口标识也不应使用，因为 RFC 2526 为其他子网 anycast 用途保留了它们。局部停用一项语义，不等于抹去邻近的保留规则。

因此合规证据至少有三层：链路只有两个路由器；两端实现都支持 /127 并停用相应 anycast；地址规划没有踩进父前缀中的保留值。掩码只覆盖最后一层的一部分。

空地址也会消耗资源

为什么要推翻原来的运维建议？IPv6 地址节约不是最重要的答案。一个 /64 很大，但“大量未使用”并不总是无成本。

在运行 Neighbor Discovery 的以太网链路上，发往未分配 on-link 地址的数据包会让路由器建立 INCOMPLETE 邻居缓存项、发送 Neighbor Solicitation 并启动计时器。攻击者不需要占有那些地址，只需不断让设备尝试解析。RFC 6164 指出，在扣除两台路由器和 Subnet-Router anycast 后，仍有 2^64 - 3 个未分配值可供这种负载扩散。

速率限制和缓存回收能降低 CPU 与内存压力，却不一定能让合法 BGP 会话在攻击持续时重新建立。链路故障导致原有缓存过期后，两个真实端点的解析可能与海量伪目标竞争。/127 把前缀内两个值都交给端点，从结构上消除这组未分配目标。

另一类问题出现在不使用 Neighbor Discovery 的某些点到点介质。较短前缀覆盖了空地址，错误转发可能让数据包在两台路由器之间来回弹跳。RFC 4443 要求路由器不得把这种包送回同一条点到点链路，并建议返回 ICMPv6 不可达；RFC 6164 仍把 /127 视为删除多余目的地址的直接防线，尤其能约束遗留行为。

风险排序由此改变。2003 年的主要风险是 anycast 与单播冲突。2011 年的新合同在本地关闭 anycast，再把邻居缓存耗尽和 ping-pong 提到前面。这是运行证据对控制面边界的重新定价。

Historic 只改变当前指路牌

RFC 6547 在 2012 年把 RFC 3627 移到 Historic，并说明 Standards Track 的 RFC 6164 在冲突处应当优先。这个动作解决的是读者今天该跟随哪份指导。

它没有让 2003 年的重复地址检测场景消失，也没有否定当时对实现差异的担忧。RFC 3627 的已验证勘误仍然有效：其中一个引用标签应从 ICMPv3 改为 ICMPv6。档案里的具体修订与现实中的处方权是两条不同流程。

这是规范治理值得保留的品质。旧证据可以继续说明为何新合同需要第二个 MUST，新文件则负责说明哪些条件下可以做不同选择。把旧文件改成 Historic，不是删除事实；把新文件放进 Standards Track，也不是赋予它创造拓扑的能力。

运行链路需要自己的收据

决定采用 /127 之前，运维方应当保存：服务提供方或本地交换结构对双端点范围的证明、现场参与者观测、两端软件版本与能力、anycast 停用验证、父前缀保留值检查、Neighbor Discovery 或 ICMPv6 行为测试，以及故障与回退结果。

邻接建立只证明控制会话在某个时刻成功。路由进入 FIB 只证明本地计算与安装。探测包抵达只证明一次数据平面结果。任何一项都不能倒推其他状态永久正确。

真正需要防止的，是资产系统把“配置了 /127”压缩成“这是一条安全的点到点链路”。一旦以后链路被改成多点、隧道平台改变接入模型或一端换成不同实现，旧标签还会留在表里，而适用条件已经离开现实。

规范反转的正确含义

RFC 3627 到 RFC 6164 的价值不在于机构承认“以前错了”。更重要的是，它展示了如何在不销毁历史的前提下移动权威：承认旧分析，限定新范围，修改导致冲突的实现规则，记录新的攻击面，再用 RFC 6547 把状态关系明确连起来。

所以不能把“避免 /127”换成“强制所有链路使用 /127”。两者都忽略了兼容集合。新规则的力量，来自每个条件都能被本地检查，也能在条件失效时退出。

配置可以提出主张，规范可以给出判定方法。只有运行中的链路能为这个主张签字。

来源