摘要

  • ENCAPS 让入口边界从 DNS 取得自治域地址，为原始数据报增加外层 IP 首部；出口边界拆除外层后，原来的源地址、目的地址和数据报继续参与普通转发。
  • “主机和多数路由器无需变化”并不等于零成本：DNS 要增加域地址映射，边界要查询、封装和解封装，自治域地址要被组织和路由，每个过境数据报还要多付 20 字节。
  • RFC 1955 是信息性文档，并明确说明出版不代表 IPng 接受其思想；它仍假定内部 IPv4 地址具有全球唯一性，也没有讨论安全问题。

没被改写的包，多出了一段旅程

一台主机发出的仍是普通 IPv4 数据报。它到达入口边界时，路由器读取内部的源、目的地址，再查询一组新的自治域地址。新地址不替换旧地址，而是写进第二层 IP 首部。完整的旧数据报成为新数据报的载荷。

中间网络据此外层目的地转发。到达最后一个边界后，外层被拆下，内部数据报重新按旧目的地址前进。主机不必知道自己曾被包在另一条跨域路径里，大多数中转路由器也只需把外层看成普通 IP。

提案把“不翻译包内地址”列为核心优点。它没有把一个内部地址换成另一个地址，也就避开了翻译器对校验和、载荷内地址和应用协议的部分修补义务。但“不改写”只是对包内字节的描述。谁决定自治域映射、谁选出口、谁拆包，以及映射和路径是否一致，仍然是新增的控制事实。

RFC 在 1996 年 6 月发表，正文却说明这项构想在 1992 年 1 月已提交给 ROAD 小组，最早是一封电子邮件。后来它作为对 IPng 白皮书征集的回应进入 RFC 记录。文档自己划定了最重要的边界：发表不意味着 IPng 领域接受其中任何思想。

因此，它证明的是一个方案曾被认真写下，不是互联网曾按此运行。

临时方案面对的是两种倒计时

九十年代初的危机并非只有“地址快用完”。一方面，Class B 网络号很快变得紧张；另一方面，路由表的增长正在压迫设备容量和运营人员。更远处才是整个 32 位空间的长期上限。

ROAD 的判断是不能等一个万能方案成熟后再动手。立即、短期、中期和长期工作要同时开始。眼前阶段不能要求主机变化，因为庞大装机基础的升级速度赶不上路由问题的到来。

ENCAPS 于是主动把自己定义为中期桥梁。它不承诺永久解决一切，也承认无法提供所有新的带宽、时延等服务。它要买的是时间：尽量少改现网，让长期方案有机会被设计和部署。

提案列出的目标很诱人：主机不变，多数路由器不变，不需要新的互联网协议，不需要新的路由协议，不翻译地址，还能缩小路由表。但这些都是预期属性。现有来源没有实现清单、互通测试、包捕获或实测路由表，不能把设计承诺写成运行成绩。

这也解释了为何失败候选仍值得进入历史。它把取舍说得足够清楚，让后来者能问：所谓兼容，究竟保护了谁，又把工作交给了谁？

DNS 提供了第二个目的地

入口边界要用内部源、目的地址查询相应的自治域地址，并把这对地址写进外层。跨域路由因此可以围绕域级地址运行，不必让每个中间节点保存所有内部网络细节。

RFC 1955 设想从 Class A 与 Class B 空间中预留少量网络号来承载域地址。网络部分表明它是域标识，本地部分选择具体自治域。多个预留空间还可把自治域组织成文中所谓的“commonwealths”：一个分组知道自身成员的细节，其他分组则以更粗的形式出现。

边界路由器会把有关域地址注入过境域的域内路由。这样，中间普通设备不需要理解“这是特殊外壳”，仍可按现有 IP 规则转发。提案认为 BGP、IS-IS 或 OSPF 都可能用来计算域路径。

这不是说协议选择已经被验证。真正的技巧是把新抽象塑造成旧设备能执行的对象。兼容性来自表示方式，而不是中间节点获得了完整知识。

与此同时，两个平面必须同时正确。DNS 映射要指向合适的出口，路由系统也要能够到达那个域地址。正确映射加上错误路径不会成功；可达路径加上陈旧映射同样不会成功。外层首部只是把两份信念放进一次转发决定，并未让它们自动成为同一份证据。

不做地址翻译，仍然要管理状态

与同期 NAT 提案相比，ENCAPS 保存了内部包。NAT 需要修改 IP 与 TCP 校验和，还要处理应用载荷里出现的地址；多个出口可能要同步翻译表，遇到加密载荷则根本无法修改隐藏其中的地址。ENCAPS 避开了这些特定成本。

但入口仍要取得映射，域地址仍要分配，外层路由仍要存在，出口仍要识别并正确拆包。一个完全不变的内部包，也可能被包到错误出口、困在错误路径或在正确出口之后仍不可达。

提案还依赖一个重要假设：现有 IPv4 地址在相当长时间内仍能保持全球唯一。它进一步设想，未来可以让“域地址 + 内部 IP 地址”共同构成全球唯一地址。如果主机仍不变化，边界就需要 NAT；如果拒绝 NAT，主机便要自己查询域地址并增加外层。

这组分支暴露了真实约束。全球唯一性、主机零改动和边界零翻译不能同时无限延续。ENCAPS 选择了暂时保留什么，并没有消灭未来必须做的决定。

20 字节只是看得见的价格

文档给出了最容易量化的成本：过境数据报增加 20 字节 IP 首部，入口与出口承担额外处理。图上可以画出来的价格往往最先被接受。

更大的成本在控制面。每个名称需要新的域地址记录；域标识及其分组需要一致的分配；边界要增加查询、封装、域间路由和解封装；排障要同时观察内部目的地和外部路径。

RFC 没有详细规定缓存寿命、负查询、映射认证、只有一侧完成升级时的行为、路径 MTU、碎片、ICMP 错误归属或最终退场方式。安全部分直说未讨论安全。这些空白不能反推方案不可行，却足以阻止我们把一个简洁框图称为可运营系统。

后来，IP-in-IP 文档更完整地处理外层机制；IPv6 成为 IPng 的正式结果。这两条后续记录可以用来比较问题，却不能证明直接血统。相似外形不等于同一因果链。

CIDR 把聚合成本放在别处

CIDR 同样试图为互联网争取时间，但它改变的是地址分配与路由前缀的表达。拓扑聚合进入前缀和掩码，代价落在分配政策、提供商依附、路由协议能力与重新编号压力上。它不会因为聚合就给每个包增加自治域外壳。

ENCAPS 则让旧目的地乘坐一个新目的地。一个方案在既有地址层级内压缩路由，另一个方案在包外建立第二层域地址。两者都说“缩小路由表”，却让不同参与者付账。

所以“聚合”不是答案，只是问题入口。必须继续追问：谁维护映射，谁更改包，谁承担重编号，谁保存例外，谁能撤回方案？

文档、配置、执行与结果

运行代码优先要求历史证据逐层升级。RFC 证明提案文本存在。DNS 记录只能证明某时刻发布了映射。边界配置证明本地准备。捕获到外层包证明某个观察点发生了封装。还要看到正确出口、解封装、内部转发和应用接收，才能说明完整结果。

最小初始规范与本地未来决定提供了另一把尺子。把试验限制在愿意改变的边界，确实可以保护广大未参与者。但如果共享映射后来变成参与互联网的资格证，局部试验就膨胀成了新的权力层。真正的本地化必须保留拒绝、回退与退出。

现实层次也不能互换：文档里的域号、DNS 中的记录、缓存中的状态、线上出现的外层首部、出口执行的拆包和应用收到的数据，是六个不同事实。用前一个替后一个盖章，便是迁移神话的起点。

RFC 1955 没有成为长期答案。它仍留下一个严格的问题：当你说“几乎不用改任何东西”时，能否列出所有被搬到边界的东西？

来源与边界

文档身份和状态来自 RFC 1955 的 RFC Editor 记录，机制与免责声明来自 RFC 1955。ROAD 的危机与阶段划分见 RFC 1380，IPng 征集背景见 RFC 1550。CIDR 的不同短期策略来自 RFC 1519，地址翻译对照来自 RFC 1631。在不主张直接继承的前提下，后续结果以首版 IPv6 规范与 IP-in-IP 为界。分析框架来自 Running-Code Primacy、Minimum Initial Specification与 Reality Layers。

这些来源证明书面提案和有限比较，不证明 IPng 接受、标准化、实现、部署、采用率、性能、互通、安全、具体运营商、真实抓包、现有产品或通向后续协议的因果谱系。