作者实验室更换 ISP 后需全网换址，IPv4 仅改几处 NAT 耗时几分钟，IPv6 却因全网使用全球单播地址（GUA）导致几乎所有服务配置均需修改，耗时数周。核心差异不在协议本身，而在于是否普遍部署了公网地址。
**为什么 IPv6 换址耗时数周**
实验室设备包括 Palo Alto Networks 防火墙、Fortinet FortiGate 防火墙、Dell 交换机、Cisco 路由器与交换机、Pulse Connect Secure VPN、F5 BIG-IP 负载均衡器、Cisco ESA 邮件安全网关、Perle 控制台服务器、VMware ESXi 等。更换 IPv6 前缀后，不仅要更新接口地址，还要逐一修改上述设备与虚拟设备中硬编码的 GUA：防火墙策略、负载均衡器虚拟服务器、VPN 网关、邮件网关路由、管理接口、监控系统、日志服务器等。原文未给出具体修改条目数量，但作者明确指出“几乎所有服务/设备”均涉及，且仅实验室规模已耗时数周。
**问题本质：公网地址普及而非协议缺陷**
IPv4 依赖 NAT，内网使用私有地址，换 ISP 只需更新边界 NAT 映射；IPv6 设计初衷是端到端全球可达，GUA 直接配置在服务器、网络设备、安全设备的每个服务实例中。若 IPv4 也像早期设想那样全网部署公网地址，换 ISP 同样面临全网改址。RFC 5887 第 5.3.4 节指出：管理配置文件中嵌入的 IPv6 地址是重新编号的主要障碍。作者强调这不是 IPv6 的缺陷，而是“被迫更换前缀”才暴露的运维现实——若拥有 PI（Provider-Independent）空间即可避免。
**RFC 5887 与服务器场景的特殊性**
RFC 5887 主要讨论接口地址重新编号，但也承认管理层面的配置依赖。纯客户端网络使用 SLAAC 或有状态 DHCPv6，甚至级联路由器用 DHCPv6-PD，前缀变更可自动传播，无感知。但服务器场景不同：服务绑定固定 GUA、ACL 引用具体前缀、证书绑定 IP、监控探测目标写死地址，这些都无法通过自动前缀分发解决。原文未给出自动化工具覆盖率数据，作者建议在规划阶段即评估 GUA 作用域，尽量将公网地址限制在边界与对外服务层。
对运维工程师的实际意义：申请 PI 空间是根治方案；若暂用 PA 空间，需在架构层隔离 GUA 使用范围，建立地址变更清单与自动化脚本，预留数周工时应对重新编号，避免将“换 ISP”演变成全网停机维护。
原文: APNIC Blog（2018-09-20）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog