摘要

  • RFC 1287 是 1991 年 12 月的信息性文档，记录 IAB/IESG 对未来五到十年的四项共同假设，并列出路由与寻址、多协议架构、安全架构、流量控制与状态、高级应用五个演进领域。
  • 它讨论聚合、地址格式、迁移、部分连接和应用中继，也保留了对行政域聚合方式与路由组织的未决分歧。这样的议程是可核查的研究/工程表面，却不是已选标准、已部署网络或已交付结果。

这是一份把问题摆上桌面的记录，而非对未来的追认

RFC 1287 所描述的不是一次宣布胜者的会议。它回顾 1991 年 1 月的 IAB/IESG 联合讨论，以及随后 6 月有 IAB、IESG、IRSG 成员和受邀者参与的 Architecture Retreat。分组报告被编入文件并在 IETF 会议上呈现。这些事实足以说明：架构压力已被公开讨论，参与者试图建立共同的工作次序。

但文档的 Status 同时划出边界：它讨论可能的演进方向，提出走向期望目标的步骤，供讨论与评论；它不规定互联网标准。一次研讨会可以让问题被命名、让选择被比较，却不能单凭会议记录使一个协议成为标准、使一台网关开始转发，或使某个网络的服务已经可达。

共同假设是设计用的压力测试，不是保证书

参与者对未来五到十年形成四项基本假设：TCP/IP 与 OSI 会长期共存；互联网会包含多样的网络与服务；商业与私有网络会被纳入，不能期待公共运营者提供全部服务；架构需要有能力扩展到 10**9 个网络。最后一项尤其不能脱离原文的保留条件：RFC 说这个指数相当模糊，估计在 7 到 10 之间变化。

因此，它不是对当时网络数量的观察，也不是精确的增长预报，更不是某个设计已满足规模的证明。它给出一个苛刻的规划边界，使人们可以比较方案。TCP/IP 与 OSI 的共存也只是一个需要面对的条件；它不证明任意两套系统互通，不证明应用语义无损传递，更不证明用户能够取得所需结果。

五项优先领域组织了工作，却没有完成工作

RFC 1287 把路由与寻址视为最紧迫的问题，其余四项是多协议架构、安全架构、流量控制与状态、以及高级应用。在寻址部分，它讨论把网络号聚合成更大的单元，例如自治系统或行政域；讨论普通/特殊路由、扩展或复用地址字段，以及在迁移中可能需要的首部改写和转换元素状态。

原文并未假装这些讨论已经收束。它明确说，对行政域如何聚合、路由协议应如何处理聚合边界，并不存在完全一致的意见。它建议建立时间线、探索新地址格式、做地址映射网关原型、研究基于聚合的路由。建议原型意味着仍要学习；它不证明格式已经胜出、迁移已经完成，或一条真实路由已遵从设想。

共享链路不是互操作，应用中继也不是完成的服务

多协议章节没有预先规定一个由固定数量协议栈组成的互联网，而提出面向过程的模型。它区分 TCP/IP 核心、链路共享和应用互操作。链路共享允许不同协议栈共用传输介质、网络接口或低层协议，却可以彼此没有交互；RFC 用 “ships in the night” 描述这一层。

这一区分保住了几个常被压扁的阶段。共同物理资源不是端到端连接；应用中继或用户代理能够转送共享的应用语义，也不表示全部功能保存。原文还指出这些安排会带来复杂度、成本，通常还有功能损失。以 DNS 或目录作为组织概念，同样不等于一个名字所指的服务可达、允许访问、或已产生可见效果。

建议行动把责任问题留下，而没有替后人作答

RFC 1287 建议估算问题出现的时点和开发/部署时间线，研究格式和映射原型，推进聚合路由、政策复杂度和网关状态的工作。这些建议让控制面清楚：哪些问题须由研究、工程、标准过程或运营决策来回答。

它们并不回答后来的问题：谁批准了某项设计，谁承担迁移成本，哪位操作者实施了什么，实际系统是否交付了预期。其历史价值正是保留了计划与结果之间的距离。一份路线图能协调注意力，但不应被改写成已经发生的世界。

来源与证据限制

本文依据 RFC 1287 — Towards the Future Internet Architecture。该来源支持信息性地位、1991 年讨论、四项假设、五个领域、寻址选项与分歧、多协议模型及建议行动。它不证明已选架构、标准、部署、当今互联网状态、真实路由、地址分配、授权、可达服务或用户结果。