摘要

  • RFC 1900 区分了两种完全不同的能力：有权更换地址，不等于能够发现并更新所有引用该地址的系统。
  • 域名把名称与地址的绑定推迟到使用时，因而可以减少硬编码；但它不能证明缓存已经失效、应用已经重新解析、ACL 已经修改，或外部管理者已经配合。
  • 后续 RFC 把重编号展开成一份跨越路由器、DNS、DHCP、安全关联、管理工具、应用接口和外部依赖的清单；完成迁移必须靠多层证据拼合，而不是靠新前缀本身。

一纸变更令看不见自己的依赖

RFC 1900 列出的起因并不神秘：主机换到另一个子网，拥挤的子网被拆分，机构重做地址规划。更深的压力来自 CIDR。服务商可以把许多客户路由聚合成一个大前缀，减少全球路由表的负担；客户离开时若继续保留旧聚合块中的一小段，更具体的路由就可能把本地选择的成本扩散给整个互联网。重编号是在本地迁移成本与全球聚合收益之间做交换。

然而，能够分配新前缀、撤销旧前缀，并不意味着存在一个可以“完成迁移”的统一控制器。运营者可以改接口和路由，却不会自动知道某位工程师多年前把旧地址写进了防火墙规则、监控目标、打印机配置、许可证文件，或合作伙伴的白名单。

“重编号”这个词掩盖的正是这种不对称：决定很集中，引用图谱却分散且未必可枚举。分配记录只能说明谁可以使用一个号码；路由状态说明前缀在哪里传播；设备配置说明某台设备准备做什么；服务探测说明一次真实交互得到什么结果。它们彼此有关，却没有任何一种记录能包办其余三种事实。

RFC 1900 把当时的工作称为昂贵、乏味且容易出错，并指出工具和成体系经验都很少。这不仅是早期软件尚不成熟。它暴露的是知识边界：找不到的引用就无法更新，而地址分配机构并不拥有一份由所有独立系统共同维护的引用索引。

DNS 改变绑定，却不能替所有使用者完成迁移

RFC 1900 最耐久的建议，是不要把名称与地址混为一谈。DNS 名称空间独立于地址空间。名称通常表达主机或服务的相对稳定功能；地址则把接口放在具体拓扑与路由结构中。配置若保存名称，并在使用时解析，就可以把变化集中到权威 DNS，而不必复制到每个文件。

但这种解耦只是减少状态，并未消灭状态。权威 DNS 管自己的记录；递归解析器在有效期内保留答案；应用决定是否再次查询，还是继续握着昨天的结果；反向解析可能归服务商管理；安全产品可能把解析结果固化成 ACL；外部伙伴也可能把号码复制进运营者无权查看的系统。

动态更新同样不是魔法。RFC 1900 认可主机通告新地址的需要，同时强调认证，以及某些系统无法传播变化的现实。它主张尽量避免地址字面量，适合时使用 FQDN，并利用 DHCP、路由器发现、服务定位和经过认证的动态 DNS；还明确反对把软件许可证绑定到 IP。对于遗留配置，更好的方向是从可控数据源生成文件，而非四处手工替换。DNS 的价值在于缩小耦合面，不在于为迁移签发完成证书。

安全关联另有边界。一个连接或安全状态只有在建立它的条件仍然成立时才可信。地址发生变化，不能自动推出既有会话、IPsec 策略或基于来源的身份判断仍然代表同一件事。

后来的 RFC 把警告变成盘点表

RFC 2071 将抽象警告带进操作现场：清点设备、DNS、SNMP、过滤器和访问列表，并为切换保留宽限期。RFC 2072 进一步扩大规划范围，说明一张网络不仅由路由器组成，服务、管理系统与操作程序同样携带地址。

RFC 4192 提出的“先建立、后拆除”，让 IPv6 站点可以在一段时间内同时使用新旧前缀。这种重叠降低了中断风险，却不能证明每个引用都已迁移。DNS TTL、管理边界，以及少数只能容纳一套配置的设备仍会形成例外。双前缀是一段执行窗口，而不是结束证明。

到 2010 年，RFC 5887 的标题仍然是“重编号仍需改进”。一台静态配置的主机就可能阻住迁移；地址可能藏在只读介质、URL、Cookie、代理、套接字 API、许可证和专有软件里；某些缓存甚至没有可预测的清除时刻。它在 257 份规范中找到 34 项显式依赖，证明标准文本里确有问题，却不代表已经统计了全部在用软件。私有实现中还藏着多少，外部观察者无法知道。

RFC 6879 再次强调 FQDN、服务发现、参数化和系统化 DNS。RFC 7010 则把自动化分成配置供应、发现、配置变更和监控四类，却仍找不到一种“一站式更新”。它还指出，有些日志收集器直接把源 IP 当作设备身份：网络一换号，连续的运维历史就可能被拆成两个“对象”。

这段历史给出的结论很具体。重编号不是把字符串 A 换成字符串 B，而是在所有相关控制面上替换引用，并证明服务、安全与可观测性仍然成立。新地址只证明迁移具备可能性；逐项盘点与实测结果，才证明组织真的离开了旧地址。

来源