摘要

  • RFC 1380 把立即操作、短期 CIDR、中期地址空间方案和长期 Internet 层研究分开，却明确要求四条线立即同时开始，而不是依次排队。
  • CIDR 被写成在既有地址体系内“买时间”的办法；它仍需要政策、协议、实现和部署，也会从长期方案抽走稀缺工程资源。
  • 建议、指标改善、迁移计划、架构选择与运行结果各有责任人和证据，不能用一个“已解决”状态把它们合并。

同一次增长，三种倒计时

RFC 1380 在 1992 年 11 月列出三个问题：B 类网络号趋紧，路由表膨胀，32 位 IP 地址空间最终可能不足。它们都源自增长，却并不共享一个截止日。

给中型机构发多个 C 类号，可以减少 B 类号消耗，却可能制造更多路由。换上内存更大的路由器，可以推迟设备极限，却没有改变地址分配造成的状态增长。扩充地址位数如果不同时处理聚合，只会把同一个路由问题搬进更大的空间。

文档还把路由压力分成机器极限与人的极限。内存、计算与更新带宽属于设备；配置路由政策、核对流量是否按意图行走，则消耗运营人员。Merit NSFNET 路由数据库与网络号分配数量约十二个月翻番，是有时间和观察点的压力证据，不是每台路由器的普查，更不是预言已经兑现。

ROAD 负责提出方向，不拥有后来的一切

ROAD 是一次性的特别小组，并非长期存在的普通 IETF 工作组。它在 Santa Fe IETF 后组织，经过面对面会议与邮件讨论，于 San Diego IETF 汇报；其成果随后进入 BOF、全会讨论和可能成立的工作组。

这一组织形态限定了权力。特别小组可以汇聚问题、比较候选、建议下一步，但不会因此取得所有地址分配、标准制定、厂商实现与本地迁移的决定权。RFC 1380 自称 IESG 审议的 preliminary report，状态为 Informational，并不规定 Internet Standard。它是一份过程记录，不是执行证明。

ROAD 对眼前的 CIDR 形成方向，却没有在 San Diego 选出唯一的“大地址”架构。前一个问题已有边界较清楚的干预手段，后一个问题仍缺少迁移影响与实现经验。两种结论不同，恰好说明审议没有把紧迫性当成同意票。

四个阶段不能排成队

RFC 1380 判断，不可能等一个设计同时解决近期路由压力、地址耗尽和长期 Internet 层功能，再赶在最早的危机之前完成选择、实现与部署。替换或扩展 Internet 层还要触及庞大的 installed base。

IESG 因而提出 immediate、short-term、mid-term、long-term 四个阶段。名字像先后顺序，正文却强调：所有阶段必须立即启动，不能连续执行。

这条规则改变了“紧急”的含义。它不是把所有人都调去最近的故障，而是给每条时间线一个可问责的起点。若长期工作必须等待临时工作结束，临时系统往往先长出用户、工具、预算和依赖；等到所谓空档出现，它已成为新的 installed base。

立即行动只会减速，不会结案

立即清单包括更保守的地址分配、让分配与聚合对齐、回收未用 B 类号、在关键位置升级路由器，以及调整拓扑。它们不需要新协议。RFC 1380 也明说：这些动作一个都不能解决根本问题，只能让问题来得慢一些。

因此每条记录必须保持原义。政策收紧证明规则变了；回收证明某一资源回到池中；设备升级证明某处容量增加；某一观察点的路由条目下降证明当地状态改善。它们都不能单独证明地址空间、人员负担或迁移风险已经消失。

这些动作也会重新分配成本。申请者承担更多举证，注册机构承担更多判断，运营商承担设备开支；拓扑简化还可能牺牲备用路径或路径质量。协议没有改变，并不等于制度没有留下长期痕迹。

CIDR 是一串协同动作，不是一只开关

RFC 1338 把 supernetting 定位成短期桥梁：先减缓 B 类号与路由表压力，等待长期方案。文档估计至少可支撑三年，那是计划假设，不是担保。

聚合要求地址先按可聚合边界分配，域间协议能携带任意 network-mask 对，路由器实现并部署这些语义，非 CIDR 区域与 IGP 边界得到处理。多宿主与更换服务商还会保留更具体路由。只有分配政策而没有 classless routing，甚至可能让路由表在过渡期更快增长。

RFC 1380 于是把工作交给不同表面：地址计划属于运营问题，BGP 需要扩展，IDRP 可能需要新的工作，部署还要处理非 CIDR 域。它说 CIDR 能在既有地址体系里抑制路由表、缓解 B 类号问题，并为地址耗尽“买时间”；它没有说这段时间是免费的。

RFC 1519 后来修订了 CIDR 规范，仍保留“连接眼前与长期方案”的表述。规范成熟是一种文档事实。实际收益还取决于采用率、拓扑、例外、观察点与时间。

桥梁也会消耗目的地

RFC 1380 把两笔容易隐藏的账写了出来。第一笔是迁移创伤。替换或扩展 Internet 层会影响厂商、运营者与用户；短中期方案要么降低这种代价，要么保留通往长期方案的平滑路径。

第二笔是机会成本。设计和部署临时措施会把人力从其他项目抽走，其中就包括长期方案。同一批协议工程师、试验网络、运营注意力和变更窗口，不能因为预算表上有两个名称就被使用两次。

所以“买到的时间”必须与“花掉的未来能力”并列记录。若临时办法增加十八个月余量，却占用两年的迁移团队，局部指标和整体计划会给出相反判断。RFC 1380 没有替后来的人提供这些测量，但要求选择临时措施时正视资源转移。

没有迁移证据，就没有大地址结论

面对更大地址方案，IESG 没有因截止日逼近而立即选边。RFC 1380 要求补齐对运行基础设施、既有协议、新路由协议、地址分配、性能、change control 所有权、网络管理、安全和培训成本的影响。Appendix B 还要求逐项回答、按受影响设备和功能列出变化，并披露实现经验。

招募提案、发布 Internet-Draft、公开评议、会议展示、IESG recommendation 与 IAB 决定，是不同文件和不同权限。时间表规定谁应在何时交付什么，不能预先证明候选方案已经正确。

后来的 IPv6 决定是一项新的行为

RFC 1719 记录，后来的 IPDecide BOF 更清楚地暴露了方向不足。它把提出 IPng recommendation 的责任放到 IESG，要求程序预先公开并留出 community comment，还要求把分配率、政策影响、CIDR 节省和新 IP 的开发、落地、迁移时间连接起来估算紧迫性。

1995 年的 RFC 1752 才记录后来那次选择：以修订后的 SIPP 为 IPng 基础，分别组织协议、自动配置、迁移与 coexistence/testing 工作，并把版本号 6 命名为 IPv6。

这并不使 RFC 1380 变成一份隐藏的 IPv6 决议。恰恰相反，它证明长期选择需要另一套证据、另一轮公开程序和另一份可归责的 recommendation。选择 IPv6 也不证明迁移完成、IPv4 退出或某一现场运行成功。

来源与边界

本文只使用 RFC 1338、RFC 1380、RFC 1519、RFC 1719 与 RFC 1752 的官方文本。它们能证明当时的问题定义、建议、评审条件和文件演进，不能证明某个当前网络的状态、每项预测的准确度、每个里程碑按时完成、某个产品实现、一次获授权的本地变更或实测运行结果。

可下的结论更窄：Internet 在 1992 年已经把紧急缓解与长期替代视为不同但必须同时开始的工作。临时措施需要三本账——收益、资源消耗、退出路径。少一本，系统就可能只看见买来的时间，看不见被它花掉的未来。