摘要

  • RFC 2452 认为 tcpActiveOpens 等多数 TCP 管理对象不依赖底层 IP 版本，不必因 IPv4/IPv6 各建一套。
  • IPv6 连接表则不同：同一节点上的四个地址与端口值未必能唯一标识一行，因此加入 ipv6TcpConnIfIndex。

四个值为何不够

管理站读取一条 TCP 连接记录时，常见字段是本地地址、本地端口、远端地址和远端端口。对于单一全局空间，这看起来像一把完整的钥匙。但 IPv6 地址带有作用域：链路本地地址只在特定链路上有意义，一个多接口节点上可能出现相同的地址值。若仅看四项，管理表就可能把不同接口上的观察误当成同一行。

RFC 2452 于 1998 年 12 月发布，为 IPv6 TCP 管理表加上第五个索引 ipv6TcpConnIfIndex。这个额外坐标属于管理信息库的行索引，不是 TCP 报文头中的第五个字段，也没有改变网络上传输的连接元组。它回答的是“这条管理记录属于哪个接口语境”，而不是“TCP 又多了一个端点参数”。

这项补充很窄。RFC 2452 明确说，大多数 RFC 2012 中的 TCP 管理对象不受底层 IP 版本影响。它举 tcpActiveOpens 为例：该计数器记录 TCP 从 CLOSED 直接进入 SYN-SENT 的次数，不论连接使用 IPv4 还是 IPv6。换言之，事件的 TCP 含义没有改变，计数器就没有理由复制。

但共用计数器不等于能按 IPv4/IPv6 拆分归因。一个累计值本身不指出是哪条连接、哪个地址族、哪个接口、哪个进程或用户触发了变化。RFC 2452 规定的是对象语义，并没有证明所有设备在内部共享同一存储，也没有声称一个计数值能够回答更细的问题。

兼容性把表分成两条

差异出现在连接表。RFC 2012 用 SMIv2 的 IpAddress 表示地址，这个类型只有四个八位组，无法容纳 IPv6。RFC 2452 因而单独创建了 ipv6TcpConnTable，只记录 IPv6 两端之间的连接；IPv4 连接仍留在旧表里。

也可以设想一张同时承载所有 IP 版本的新表，但那会要求修改 RFC 2012，并影响只支持 IPv4 的既有实现。分表让过渡成本留在新增的 IPv6 路径上，而不是强迫旧实现迁移。RFC 2452 还把模块放在实验性 MIB 子树下，因为它预期将来会更新 TCP-MIB，收纳这些定义。它是过渡设计，而非断言永久维持两套表最好。

第五个索引的含义由地址情况决定：若远端是链路本地地址而本地地址不是，它标识远端所在同一链路上的本地接口；否则，它标识与本地 IPv6 地址关联的接口。非零值与 ipv6IfIndex 中相同编号对应同一接口，并须在连接存续期间保持不变。

若接口无法判定，值可以为零；文档把通配本地地址 ::0 作为可能情形。零表示“不知道是哪一个”，不是一块编号为零的真实网卡。把它在后续分析中补成推测的接口，会把原本保留的不确定性改写成虚假确定性。

记录会消失，身份边界不会

RFC 2452 描述的是当前 TCP 连接。连接进入 CLOSED 时或之后不久，相应表行就会消失。因此这是一条瞬时管理观察，不是持续存在的用户、服务或进程身份。接口索引能区分记录语境，却不能证明远端主体身份、地址归属、路由可达或应用成功。

该表沿用了可写的 deleteTCB(12) 状态，它能在被管理节点上终止对应连接。已发表的 RFC 2012 文章专门讨论这个干预面；在这里它仅提示：观察表也可能触及敏感操作。索引再精确，也不会自动生成授权，更不能证明对端或应用实际感受到了什么。

后续的 RFC 4022 在 2005 年同时取代 RFC 2012 与 RFC 2452，以通用地址约定定义与 IP 版本无关的 TCP-MIB，并未原样保留旧 IPv6 表及其第五个索引。RFC 4001 提供 InetAddressType 与 InetAddress 的通用表示及带 zone 的形式，RFC 4007 则描述 IPv6 scope 和 zone。2017 年，RFC 8096 又单独把 RFC 2452 重新归类为 Historic，并为 MIB 仓库维护标记其中旧模块已废弃。这是两个不同的生命周期步骤：先有统一模型的技术替代，之后才有历史归类与模块清理。

来源