摘要

  • RFC 831 是 1982 年的一份讨论提案，不是标准或部署记录。它设想在 SATNET 分区时，由 UCL 的多宿主“Header Munger”处理特定维护报文，但明确保持主机身份、不发布路由。
  • 出站报文经源路由抵达 M 后同时改写源与目的地址；若老旧目标不能反转源路由，M 就学习一项供回包使用的“软状态”映射。原文没有规定刷新、过期、删除、认证、审计或崩溃恢复。
  • 这套方案解决的是“报文能否进入”的问题，而不是“操作者是谁、操作是否获准、维护是否完成”。应急可达性只有在不扩张为一般转送权时，才仍是一项受控例外。

先画出不能走的正常路径

1982 年 12 月，Robert Braden 在 RFC 831 中讨论一个很具体的故障：如果卫星分组网 SATNET 被分成互不连通的两半，美国一侧的维护人员怎样接触欧洲一侧的设备？文中把替代入口称作“back door”，同时郑重说明这不是当时准备采纳的标准。它是一张供人检验的设计图，不是某次真实故障的实施报告。

正常情况下，控制主机 H 经 Internet 抵达 BBN 网关 B，再通过卫星接口报文处理机 S1 进入 SATNET，越过卫星网到 S2，最后抵达 UCL 网关 G。分区后，美国网关没有通往 S2、G 和 UCL 终端接入控制器的可用路由。照常填写目的地址的报文会被丢弃，并可能收到 ICMP Unreachable。

反向同样断裂。从英国一侧看，H 也不可达。即使有人把请求送到了 S2 附近，普通回包仍找不到 H。因此，应急入口不能只解决“去程如何绕过去”，还必须给回程建立一个不会误导整张网络的地址关系。

RFC 831 设计的替代链路是：H → Internet → VAN 网关 → VANNET IP 隧道 → UCL 端点 → UCLNET → G → S2。特殊代码只允许放在 H 和/或 UCL 端点，不要求修改 G、S2 或 VAN 网关。这种约束把事故处置的复杂性压缩在愿意承担它的两个系统中。

最重要的功能是“不宣布”

最直观的做法，是把 UCL 的普通隧道端点 U 升格为网关，让 VAN 网关学习到经 U 前往 UCLNET 的路由。RFC 831 明确反对这样做。因为一旦这条路由可见，VAN 网关就可能把本应走 SATNET 的 UCL 或 RSRE 普通流量也塞进 VANNET 隧道。仅为维修打开的通道，会在控制平面上变成新的公共道路。

方案于是引入多宿主的 Header Munger，简称 M。它在 VANNET 一侧表现为 M2，在 UCLNET 一侧表现为 M1。M 可以使用网关处理源路由的算法，却“otherwise acts as two hosts”，并且不发送路由更新。

这里要区分两个经常被混写的能力。网关算法回答“怎样处理眼前这一份报文”；路由权限回答“能否让其他系统相信自己是通往某片网络的普遍下一跳”。M 获得前者，故意没有后者。限制不是因为它技术上做不到转发，而是因为维修任务不应自动取得一般中转权。

两次改写修补两个方向

H 能到达 M 的 VANNET 地址 M2，于是先把维护请求送向 M2。M 收到报文后，把源地址改成 UCLNET 上的 M1，把目的地址改成 S2，再从本地网络送往 G 和 S2。这样，英国一侧看到的是两个本地可达的端点。

回包从 S2 发往 M1。M 再把它改写成能够通过 VANNET 和 Internet 返回 H 的报文。两次转换分别修补两种不可达：只改出站目的地址，S2 仍无法回答 H；只改源地址，请求本身仍无法穿过美国侧已经断掉的 SATNET 路由。

地址改写也改变证据的外观。下游日志可能只看见 M1，上游可能只看见 M2。一次成功回包最多证明 H、隧道、M2、改写函数、M1、G 与 S2 组成的特定链条完成了足够多的交换。它不证明 M 识别了真实操作者，也不证明 S2 许可了某项命令，更不证明软件维护达到预定结果。

把它直接叫作 NAT 会抹去历史边界。后来的 RFC 3022 系统描述了静态和动态地址转换，以及网络内部状态替代端到端地址意义的代价。这可以帮助比较，但不能据此声称 RFC 831 发明了 NAT，或者两者存在有文献证明的直系演化关系。

三种回程办法，三种状态代价

RFC 831 先考虑固定地址对应。M 可以代表一组 M1/M2 地址，每个地址预先关联某台美国主机和某个 SATNET 目标。这种办法容易理解，却要求管理员为每一对通信关系提前占用并维护配置。

第二种办法是去程和回程都使用 IPv4 源路由。RFC 791 定义了宽松和严格的源与记录路由选项。发送者把中间地址写进报文；每到达一个列出的地址，下一地址替换 IP 目的地址，当前接口地址则记入路径。若目标能够把记录下来的路径反转，就能按同一组关节返回。

问题在于，G 支持源路由，S2 或终端接入控制器却未必懂得如何生成反向源路由。因此，RFC 831 更倾向混合办法：H 在去程报文中携带源路由；M 处理时学习美国来源与 SATNET 目标之间的对应；S2 即使发送普通回包，M1 也能依据那项对应把它送回 H。

原文称这项映射为“soft state”。这个词不能替后人补写生命周期。RFC 831 说了怎样学习和使用，没有说多久刷新、何时过期、如何删除、重启后怎样恢复，也没有规定谁有权创建映射或怎样留下审计记录。

映射键还带着明确歧义：同一时刻，每个 SATNET 目标只能由一台美国主机访问。若两个 H 共享同一目标，目标发出的普通回包没有足够信息让 M 判断应该还给哪一方。这不是性能指标，而是隐藏状态丢失了端到端区分信息的证据。

一条 PSS 线路决定了地址长度

应急图并非只受 IP 算法支配。VANNET 隧道建立在交换式 X.25 服务上，呼叫方支付费用。正常情况下由 UCL 侧的 U 发起隧道；连接 M2 时则由美国一端发起。谁拨号，决定了账单落在哪里，也决定了哪一端必须在事故时仍有发起能力。

UCL 当时只有一条 PSS 物理线路。若 U 和 M 共用它，就需要不同的 X.25 子地址。VAN 网关还得同时支持 14 位和 12 位 X.121 地址。一个在 IP 层成立的恢复方案，完全可能因为下层少两位地址处理能力而无法启动。

这些细节不宜被夸张成普遍的网络经济学。它们提醒操作人员：真实的灾备路径包含呼叫方向、计费边界、物理接口、子地址和设备能力。只保存一张 IP 拓扑图，等于把能否执行的条件删掉了一半。

主机可以做中间跳，但必须承担网关后果

后来的 RFC 1122 更清楚地界定了这种例外。主机可以充当源路由中的中间跳，但必须按网关式规则处理 TTL、ICMP 错误和 IP 选项。对非本地目的地启用这种转送，应有一个默认关闭的配置开关，并受策略过滤约束。

这正好说明 M 的位置：它仍是主机，却因对报文执行中间转送而承担相应义务。进程被部署在哪种机器上，不会消除 TTL、错误传播、选项更新和策略判断。

默认立场的变化并非瞬间完成。RFC 1812 在 1995 年仍要求路由器支持转发报文中的源路由选项，并允许设置丢弃开关，但当时该开关不默认启用。这个历史事实只说明运行环境曾经不同，并不是今天应照做的建议。

到 RFC 6274，源路由的安全风险已经被认为超过诊断收益：绕过防火墙、访问原本不可达的系统、隐蔽连接、拓扑探测与资源消耗都在风险之列，建议变成默认丢弃。RFC 7126 又指出，广泛过滤已经使 LSRR 几乎无法用于故障排查；它要求选项级、可文档化的控制，默认丢弃，只为明确理由保留本地例外。

因此，RFC 831 的替代路径还依赖一个社会条件：沿途每个独立运营者都愿意处理该 IP 选项。规范公开存在，并不等于网络必须替它转送。

“中间盒”描述动作，不能授予权力

多年后的 RFC 3234 把超出普通 IP 路由、会转换或改道流量的中间设备归入 middlebox。按这个分析词汇，M 确实像中间盒：它改地址、依赖映射，并增加新的配置与故障表面。但 RFC 831 自己没有使用这个称呼。

更重要的是，类别名称只描述报文受到什么处理，不回答谁能调用、哪些目标允许、状态活多久、何时收回。把 M 叫作网关甚至更容易产生误导，因为它会让人误以为 M 获得了文中明确拒绝的一般路由权限。

最精确的说法仍是：一台多宿主主机，为选定的维修报文执行网关式动作，不发送路由更新。它的能力真实存在，却不通过路由协议向全网兜售。

能进门，不等于有权动手

RFC 831 处理的是路径连续性。它没有规定操作者身份、目标授权、加密、维护命令、变更审批或结果回执。文中的“后门”是替代入口，不是安全攻击的证据；但任何绕开正常拓扑的入口，都必须单独证明其控制边界。

一次应急操作至少要留下四个不同结论：请求到达入口；发起主体被识别；目标与动作获准；目标报告了预期结果。M 改写出的回包可以支持第一个结论，不能自动替代后三个。

RFC 831 最值得保留的，不是某种今天仍可直接部署的配方，而是它在故障时拒绝扩大权力的设计。特殊代码被放在少数节点，普通路径不被重写，维修主机不发布路由。

这扇后门之所以还能算门，正因为它没有把自己宣布成路。