摘要

  • RFC 1481 把 CIDR 定位为缓解近期地址与路由表压力的过渡策略，同时明确长期方案仍在讨论之中。
  • 地址分配和路由聚合必须同步推进，但 IAB、IANA/InterNIC 与注册机构、路由器厂商、网络运营者分别控制不同环节；前一环节的文件不能充当后一环节的运行回执。

“支持”究竟改变了哪一层

RFC 1481 写道，IAB 支持 CIDR 架构及其实施，并支持 IANA、InterNIC、路由器厂商和网络运营者采取的行动。这是一项真实的制度行为：它公开降低了方向不确定性，让资源管理者有理由调整政策，让厂商有理由安排研发，让运营者有理由准备升级。

但文件没有把这些主体合并成一个执行机关。它自称向互联网社区提供信息，并不规定互联网标准。今天的 RFC Editor 记录 将其列为 Historic，那是后来对文献状态的归档，不是 1993 年某台设备的运行证据。

因此，IAB 的表态能证明 IAB 的表态。它不能证明一个地址块已按拓扑分配，不能证明某个二进制已经理解无类别前缀，不能证明运营者已配置汇总，也不能证明全球无默认路由表的增长已经放缓。准确划界并不会削弱文件的价值，反而能看清它真正完成的是协调。

这座桥从来不是终点

RFC 1481 称 CIDR 为“近期策略”，目的是延长现有 32 位 IP 地址空间的寿命；同一句话又假定技术社区正在处理适当的长期方案。文件没有宣称一项技术可以同时消除全部危机。

RFC 1338 把压力拆成三项：B 类网络号耗尽、路由表增长到软件和人员难以管理、32 位地址空间最终耗尽。CIDR 优先处理前两项，为第三项争取时间。RFC 1380 则把这项过渡工作放进 ROAD 的多时间尺度讨论。

“争取时间”有双重效应。它可以避免眼前故障，为长期选择保留空间；如果效果足够好，也会降低继续解决根本限制的紧迫感。因此，历史叙述必须同时保留两个时钟：CIDR 多快要启动，长期架构还剩多少未完成决策。

后来 RFC 1752 记录了 IPng 推荐。那份较晚的选择不能倒灌进 RFC 1481。1993 年 7 月，长期目的地仍是开放问题。

两条轨道，错开就可能恶化问题

RFC 1481 把 CIDR 的基本构件归纳为两项：管理互联网地址空间的分配，以及提供路由信息聚合机制。它们不是可以单独验收的两个好点子，而是互相提供条件。

分配侧把许多小网络放进连续、与提供商或地域拓扑相符的地址块。路由侧再用一个前缀代表这些网络，减少核心路由器需要保存的独立项目。如果仍然零散分配，路由器没有整齐的结构可聚合；如果只大量发放 C 类块而路由协议还不会聚合，表项反而会爆炸。

RFC 1481 明确写出后一风险。RFC 1338 更进一步：地址计划可以几乎立即开始，但有效聚合需要修改域间路由协议。在两者部署错位的时期，路由表可能快速增长。支持无类别目的地的协议若没有新分配计划，也无法产生有效汇总。

所以，“CIDR 已启用”不是一个有用的单值状态。地址政策版本、软件能力、配置生效和对外传播各有时间戳。两条轨道之间的差值本身就是风险指标。

注册机构塑造可被聚合的原料

RFC 1466 描述了 IANA、Internet Registry 与区域注册机构的职责，要求区域机构具有广泛认可和中立性，并让 C 类地址块的分配适应地域聚合。RFC 1367 给出了地址管理指南的计划日程。

行政决定因此进入了路由结构。一个组织从哪个提供商或区域的块获得地址，会决定它以后能否被某个聚合覆盖，也会决定更换提供商时是否需要重编号或长期保留一条更具体路由。

不过，政策、计划和执行必须分别留档。指南证明当时想采用什么规则；日程证明预期顺序；带日期的登记记录证明哪个块实际分给了谁。它们都不能证明某台路由器曾发送对应前缀。

CIDR 还把技术效率与机构正当性放在同一系统中。谁有资格分配、如何避免偏袒、如何判断需要，是掩码本身无法回答的问题。路由聚合依赖这些治理决定，却不能取代它们。

厂商掌握从文本到可执行物的关口

RFC 1481 单独提到路由器厂商，说明架构发表后仍有实质性工程债务。设备必须停止从最高位推断地址类别，能够保存地址加掩码，执行最长前缀匹配，在协议中携带无类别可达性，并在形成聚合时保留必要例外。

RFC 1518 的记录 和 RFC 1519 的记录 保存了后来正式发表的地址分配架构与 CIDR 策略。规范更完整，并不等于代码已经存在。要证明实现，还需要版本化源码或构建物、测试范围、硬件限制与缺陷记录。

厂商说“支持 CIDR”，至多证明某个发布物声称具备能力。它不能证明客户已下载，更不能证明生产配置真正调用了该能力。

运营者决定理想层级在哪里开洞

网络运营者要选择版本、承担升级风险、编写策略，并为每个邻居决定发送什么。相同的软件在两个网络中可以产生完全不同的路由表面。

RFC 1338 已经预见到层级不可能绝对整齐。多宿主组织为了保持多条连接，常需由不同提供商发送更具体路由。组织更换提供商时，若暂不重编号，新提供商就要用更具体前缀在旧聚合上“打洞”。连续运营、冗余和商业迁移自由，都可能增加路由状态。

RFC 1482 的记录 指向 NSFNET 环境中的具体 CIDR 计划，包括数据库和聚合责任。它是局部实施证据的入口，不是全网同步部署的证明。

要证明运营层发生过什么，至少需要安装版本、配置修订、候选与活动路由、转发表、对每个邻居发出的准确通告和过滤记录。即使这些都齐全，也只证明观测到的网络。要谈全球路由表结果，还需说明观测点和方法的时间序列。

六类回执不能互相借用

RFC 1481 点名的角色可以扩成一条证据链：IAB 给出推荐；地址机构作出资源决定；厂商交付可执行能力；运营者安装和配置；邻网按自己的策略接收；测量者描述系统结果。

每一步都改变命题：

  1. 文件与日期证明制度支持；
  2. 登记账证明地址分配；
  3. 构建与测试证明软件能力；
  4. 设备和配置记录证明本地部署；
  5. 对端观测证明跨边界传播；
  6. 方法透明的序列数据支持整体效果。

把其中任何两项合并，都会制造过度结论。RFC 不是路由器日志；路由器日志不是全球统计；一个聚合前缀也不能单独解释整张表的变化。

这正是 Heng Lu 关于运行代码优先、最小初始规范、局部未来决定与自愿采用以及现实层级的分析框架所能照亮的地方。共同符号能协调自主行动者，但不能替他们签署执行记录。

RFC 1481 还明确说没有讨论安全问题。它也不是成效报告。它是一份很短却很诚实的协调文件：方向获得了合法性，而让方向成为现实的权力依旧分散。

来源