摘要

  • NAT 可以在网络边界节省全球唯一的 IPv4 地址，但依赖地址值的应用不能只靠改写 IP 首部来适配。
  • RFC 2993 的历史提醒在于，额外工作落到了哪里：应用层网关、终端协同更新、本地名称管理和技术支持，而不只是路由路径上的一台设备。

地址转换器可以完全按规则工作，应用却仍然连不上。问题未必在转换表。它可能始于同一个地址在私网里指向一个端点、到公网后代表另一个值，而应用消息正文中还留着第三份地址。

这种张力在 1994 年的提案里已经出现。RFC 1631 把网络地址转换（NAT）作为应对 IPv4 地址压力的一种渐进办法：末端网络复用内部地址，边界设备只转换进入全球地址空间的那部分通信。文件也承认代价：IP 地址的端到端意义被削弱，网络状态随之增加。若站点有多个出口，各个转换设备还必须对映射保持一致认识。这是一个可逐步部署的过渡方案，并非零成本的架构。

到了 2000 年 11 月，Tony Hain 在 RFC 2993 中回看了六年来 NAT 兴趣与部署的增长。关键问题不再只是路由器能否把一个地址换成另一个，而是当地址出现在转换器不会检查的位置时，服务还能否工作。

答案取决于应用。两个端点之间只经过一个 NAT 的简单通信，可能比较容易处理；但有些协议会在负载中携带 IP 地址，另一些则要求首部在校验和、认证或安全处理中保持一致。只改首部的转换器无法修补这些假设。应用层网关（ALG）和代理可以提供帮助，但每一种都必须理解自己要修补的协议。更早在同一年，RFC 2775 也指出，出现新的地址依赖型应用时，ALG 或代理必须随之更新。

于是，“透明”成了一项有条件的承诺。如果应用既不暴露也不依赖被转换的地址，边界功能或许可以不被察觉；否则，就得在运行该应用的各处协调变通方案。RFC 2993 对比了相对简单的双端通信，与冗余 NAT 路径和文档协作一类的多点应用。文件称，协调复杂度会随端点数量“几何式”增长；它没有给出方程或测量过的成本曲线，这描述的是架构的扩展难题，而不是实验结果。

冗余路径又带来另一种状态依赖。位于不同路径上的两个转换器，必须对某台设备的映射有一致认识。如果连接状态留在一条路径，而流量切换到另一条，新路径就可能生成不同的映射。即使后来恢复旧路由，也不一定能恢复原来的会话。因此，数据包里的地址并不是全部状态；映射本身以及它所在的路径同样重要。

成本还可能从一家机构转给另一家。RFC 2993 提到，互联网服务提供商管理的 NAT 或许能简化其一部分支持工作，同时增加本地的地址和名称管理。这是文件描述的负担转移，不是证明所有运营者总成本都上升了。企业合并后，本地管理员可能要处理重复使用的私网地址、安排内外不同的 DNS 响应，或协调过去对服务商不可见的应用修补。

安全问题让“转换”和“策略”的区别更重要。RFC 2993 警告，NAT（尤其是端口转换）可能营造出安全屏障的印象，却没有防火墙那种明确的访问控制意图。它也讨论了 IPsec、DNS 行为以及 SNMPv3 认证的兼容问题。这些机制取决于协议和配置，不能据此断言任何 NAT 都会破坏任何安全协议。转换器改变的是依赖地址的证据；它本身并不决定哪些流量应当获准通过。

后来的文件让这项工作更明确，却不能证明问题已消失。RFC 3022 于 2001 年取代 RFC 1631，描述传统 NAT；RFC 3235 于 2002 年为应用设计者提供 NAT 友好指南。这些文件不能证明 RFC 2993 导致了某项具体部署，也不能证明所有软件都遵循了指南；它们说明，边界转换技术催生了应用设计层面的文献。

RFC 2993 的历史价值并非裁定 NAT 总会失败，而是把边界上的地址节省与上层必须承担的兼容工作分开。转换器可以只部署在一个网关上；修复服务却可能要求在许多终端更新应用、在多条路径间维持映射状态，并让本地团队接管名称管理。网络没有让这项工作消失，只是改变了谁必须发现并协调它。

来源