摘要

  • RFC 4008 以接口为主轴组织 NAT 配置、服务类别和状态；RFC 7658 后来解释，这一假设并不适合许多实现。
  • NATV2-MIB 缩小了共用的可写配置面，同时扩大了对逻辑实例、地址域、订户、资源池和运行状态的观察。

先建接口行，再谈映射

RFC 4008 给出的 SNMP 配置流程有一个很具体的起点：管理端先在 natInterfaceTable 建立一行，使用既有的 ifIndex，并说明该接口属于私有还是公共地址域。随后，地址映射表以同一个接口索引组织，最后再设置默认超时。换句话说，管理模型首先要求知道“这项 NAT 服务在哪个接口上”，再描述它如何转换地址。

这个设计并非毫无道理。数据包确实从设备接口进入、离开；运营者也常以接口来区分网络边界。RFC 4008 顺着这一点，把接口、地址映射、派生出的地址绑定与端口绑定，以及连接两侧表示的会话连成一组表。它还定义了统计和超时对象，目标既包括配置，也包括监测。 RFC 4008，第 1、4 节

问题在于，便于描述某些设备的物理边界，未必就是所有实现共有的管理边界。一项逻辑 NAT 功能可能跨越多个接口；某个映射可能关联一组接口；设备内部也可能根本不记录单一的接口归属。如果管理协议要求这个关系必须存在，产品就得为规范重新塑造自己的状态模型。

规范作者写下了什么教训

RFC 7658 对旧对象被弃用的原因说得很直接：各类 NAT 实现采用的算法和数据结构差异很大，因而配置参数彼此不兼容，只有少数实现能声称完全符合规范。即使把配置对象改成只读，超时等参数仍可能因实现而异，难以达到基本符合性。文档提出的教训是，管理 MIB 应尽可能只读，不应把暴露 NAT 配置参数当作核心用途。 RFC 7658，第 3 节

接口关联是另一项结构性错位。RFC 7658 指出，许多 NAT 实现不跟踪接口与映射的关系，或者一个映射会对应一组接口。可是 RFC 4008 的接口表和映射表都把 ifIndex 当作骨架。若设备内部没有这样的单一关系，就无法自然地填出规范要求的行。RFC 7658 据此将 NAT 描述为一种可能独立于接口的逻辑功能。

类别和协议编号也暴露了共用词汇的边界。RFC 4008 用 basicNat、napt、bidirectionalNat、twiceNat 四类服务描述 NAT；RFC 7658 认为这些分类定义不清，许多产品使用别的分类，甚至不分类。这里说的是 RFC 4008 的服务类别，并不是 RFC 3489 的锥形 NAT 分类。后来的 MIB 改用 RFC 4787 所述的 NAT 行为术语。旧 MIB 对协议另列 other、ICMP、UDP、TCP，并给它们分配与标准协议号无关的数值；这也难以自然表达 DCCP、SCTP 等协议。新模型使用 IANA 协议号。

不是给旧表补几列

2015 年的迁移分成两个规范动作。RFC 7658 保留 RFC 4008 对象定义，但将状态标为 deprecated；RFC 7659 则定义 NATV2-MIB。旧对象没有被悄悄赋予新含义，管理端必须知道自己读写的是哪一套模型。 RFC 7658 RFC 7659

NATV2-MIB 的目标更偏向监测。只读配置被缩减到解释状态和统计所需的上下文；可写配置基本移除，仅保留通知生成控制和 NAT 资源配额。它并非完全没有控制面：运营者仍可设置保护性限额。但规范不再承诺用一个通用表格来配置不同厂商的转换引擎。

新的组织单位是逻辑 NAT 实例。映射不再以接口作为主要归属。一个设备可以有多个 NAT 实例；每个实例可涉及多个地址域、协议、资源池和订户，并报告状态、统计与通知。这些维度对运营商级 NAT 尤其有用，因为多个订户共享地址和端口，而实例之间的资源也需要区分。

端口映射的索引方式也被重做，目的是便于从外部可见的数据包参数反查内部端点。它提供的是管理和排查路径，不会自动证明订户真实身份、数据包已送达，或上层应用成功。 RFC 7659，第 2、3 节

RFC 6888 为订户级资源控制提供了背景：CGN 的端口和状态是多个订户共享的资源，对单个订户设限可以防止其过度消耗资源。NATV2-MIB 因而加入订户感知、资源限额和相关计数器。规范说明的是可表达的管理能力，并没有列出哪些运营者实际启用了它、阈值如何设定或成效如何。 RFC 6888，第 4、5 节

管理视图不是服务结果

这段历史是一场抽象层的修正。RFC 4008 试图通过可写表格，把 NAT 转换变成可移植的配置对象；RFC 7658 记录了接口、参数、类别与协议清单为何不适配许多实现；RFC 7659 于是缩小了共同配置面，扩展对逻辑实例和共享状态的描述。

能据此得出的结论应当有限：管理模型为描述更广泛的 NAT 实现而改变了。这并不能证明所有厂商采用了 NATV2-MIB，也不能证明它成为普遍部署的管理标准或提升了转换性能。RFC 7659 说旧 NAT-MIB “并没有被广泛实现”，但未给出比例，也没有测量新 MIB 的采用情况。这里的证据是规范如何回应设计不匹配，不是行业普及率调查。

防火墙功能也有明确边界。RFC 4008 与 RFC 7658 均表示，这些 MIB 不处理防火墙功能，不应拿来配置或监测防火墙。一个 NAT 映射不等于一条过滤规则。

同样，MIB 的表行不等于用户的服务结果。已配置的资源池并非当前映射；订户索引不是经过验证的身份；计数器需要结合不连续时间来解释；通知不证明数据包抵达了目的地。NATV2-MIB 可以使管理视图更贴近逻辑功能，但不能把配置、当前状态、数据面转发、终端身份和应用结果合并为一个结论。

历史教训并非“管理标准越少越好”，而是共用模型不应把每种实现的本地控制都包装成统一接口。RFC 7658 没有给旧接口模型再添更多字段，而是重新考虑究竟要管理什么。NATV2-MIB 让更少的配置成为普遍承诺，却让更多逻辑状态变得可观察。问题也从“哪块接口拥有这条映射”转为“这条观察属于哪个 NAT 实例、地址域、订户、资源池和状态”。

来源