APNIC 博客介绍一份新互联网草案，针对 IPv6 邻居发现协议在前缀变更时的脆弱性提出改进方案。由于缺乏 NAT，住宅网络依赖提供商可聚合地址空间，前缀变更频繁导致陈旧前缀未废弃，引发通信失败。
前缀持久化落地困境
RIPE-690 建议运营商分配持久 IPv6 前缀，但实际部署中多因素导致前缀频繁变更：用户接入电路迁移至不同 BRAS 或 CMTS、CPE MAC 地址变更、运营商内部重新编址、运维与计费系统缺乏支持。结果是用户获得"非持久"前缀，变更通过 SLAAC 或 DHCPv6 通知，SLAAC 场景下常表现为新增前缀而非替换，设备持有多个有效地址。
陈旧前缀引发通信故障机制
当设备同时持有多个 Prefix Information Options (PIOs) 来源的地址时，所有地址均被视为有效源地址候选。若选用非当前有效 PIO 的地址发包，因源地址与路由表不匹配导致通信失败，表现为服务降级或完全中断。根因包括：CPE 突然重载无法发送弃用通知、二层交换设备（如 Wi-Fi 扩展器）阻断媒介丢失检测、CPE WAN 侧重启未影响 LAN 侧运行导致前缀变更未同步。
草案提出的增强措施
原文未给出具体数据。草案建议在邻居发现层面引入机制：要求路由器通告携带前缀生命周期管理字段、强制 CPE 在前缀变更前主动弃用旧 PIO、引入主机侧前缀有效性快速验证流程、利用 DHCPv6 租约同步机制作为补充。这些变更旨在减少陈旧地址被选为源地址的概率，降低前缀切换期间的业务中断时长。
对网络工程师而言，理解前缀变更在二层拓扑下的传播盲区至关重要。部署时需确保 CPE 支持优雅前缀切换，排查 Wi-Fi 扩展器等中间设备对 RA 抑制的影响，并在监控中增加源地址选取失败率指标，提前发现邻居发现层面的鲁棒性缺陷。
原文: APNIC Blog（2022-01-18）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog