摘要

  • RFC 2021 的协议目录列出探针已经能够解码和计数的协议，它不是可下载解析器的仓库。
  • “有限可扩展性”只在实现已经找到父协议解复用字段、并把下一层选择做成表驱动时，才允许增加一个子级判别值。

RFC 2021 最容易被误读的例子是 UDP 端口 123。规范设想某台探针已有 C 代码，能穿过若干以太网封装，识别 IP，再读取 IP 的协议字段、识别 UDP，并定位 UDP 端口。表中已经把 161、53 和 69 分别认作 SNMP、DNS 和 TFTP。此时，管理者可以新增一行，把端口 123 记为 NTP，并开始计数。

新增的不是一门解析语言，而是已有分叉上的一个值。探针理解以太网、IP、UDP 和端口的位置，都是实现时写入的软件能力；新行没有教会它读取 NTP 报文，更没有给未知包型安装语法。规范因此把这种能力准确地叫作“有限可扩展性”：代码必须预先为它留出表驱动入口，而且最多只向上扩一层。

先是能力清单，后是可配置目录

第 5.2 节把协议目录称为探针能够监测的协议类型清单。protocolDirTable 的对象说明更直接：每个条目对应代理有能力解码和计数的一种协议。设备启动时，应预置它知道并愿意监测的协议；它不必穷举所有理论上可能的以太网类型，也不必因为在线路上看见一个值就自动生成条目。

写权限没有越过实现边界。管理者若提交代理既不能直接理解、也不能按既有算法理解的 protocolDirID，SET 请求必须被拒绝。目录可变，只说明已实现的识别词汇可以配置；它不产生新的识别能力。

三个字段还把不同层次的“身份”拆开。protocolDirID 描述分层封装路径；protocolDirParameters 按路径中每个节点的顺序提供一个参数字节，限定该路径如何解释；protocolDirLocalIndex 则是代理给下游表使用的本地快捷键。它在单个 SNMP 实体内唯一，至少跨一次管理系统重新初始化保持稳定，条目删除后在代理下次重启前不得复用。它不是跨设备通用的协议编号。

protocolDirType 记录能力，而不是授予能力。extensible 位只说明能否在该父节点下创建子条目；若新子条目缺乏探针内建支持，它本身不可继续扩展。地址识别又是另一项能力：探针能认出并计数一种网络层协议，不等于它能抽取地址。通过有限扩展创建的行，其地址映射必须标为 notSupported。

下游统计不能超越上游识别

协议分布表按接口上“最高被识别协议”累计包和字节。主机表与矩阵表通过本地目录索引，说明网络地址采用何种语义，以及最终计数的是哪一层协议。只有相关识别能力和配置开关都成立，这些表才可能出现条目。

因此，一个计数最多证明探针沿某条已实现路径完成了匹配。它不证明探针理解完整载荷，不证明哪个进程处理了报文，不证明应用交易、端到端交付、责任主体或安全状态。RFC 2021 还专门提醒，“Application Level”通常也不等于 OSI 第七层；它只是指超出 MAC 与网络层的较宽范围，可能包括传输、会话和表示层。

标识符在演进，解析边界没有消失

与 RFC 2021 同期的 RFC 2074 给出协议标识编码算法和例子。2000 年，RFC 2895 取代 RFC 2074，保留标准轨的编码参考；RFC 2896 把大量非规范性宏例子单独发布，并明确说明合规实现不必采用这些例子，且因厂商社区缺少贡献而停止维护。目录更丰富，并不等于解析器更丰富。

IPv6 暴露了另一层限制。RFC 3796 记录 RFC 2021 的地址表示仍有 IPv4 依赖，并指出当时正在推进的更新没有解决已识别的问题。分层标识可以描述多种封装，下游地址字段却仍可能受旧地址假设约束。

RFC 4502 在 2006 年 5 月取代 RFC 2021，保留协议目录与有限扩展的基本说明，同时更新高容量 Top N、合规与字段范围等内容。RFC Editor 还收录 RFC 2021 的一项已验证勘误：downloadToPROM(2) 与 downloadToRAM(3) 的文字编号写反。它与协议目录机制无关。

这段历史留下的不是“目录无用”，而是对证据等级的克制。目录能让实现已有的区分变得可见、可配置，并为统计提供稳定的本地引用；它不能把被写下来的名称变成正在运行的解析能力。

来源