摘要

  • RFC 9710 将 IANA IPFIX 注册表中 forwardingStatus 的抽象数据类型从 unsigned8 更正为 unsigned32，同时明确当前版本应通过 reduced-size encoding 以一字节导出。
  • collector 必须把 Information Element 定义与当前 IPFIX Template 声明的字段长度结合起来；一字节线缆值并不否定四字节抽象上限。
  • 注册表修正不会自动升级已部署 collector、追溯改写历史 Flow，也不能单独证明报文真实转发或丢弃。

同时成立的两种宽度

Information Element 89 记录 Flow 的转发状态及原因。当前结构只使用最低有效字节：两位表示 Unknown、Forwarded、Dropped 或 Consumed，六位表示原因。问题在于 RFC 7270 把抽象类型写成 unsigned32，旧 IANA 行却写成 unsigned8。RFC 9710 纠正后，注册表采用 unsigned32，又要求当前版本以 unsigned8 导出。

这不是自相矛盾。抽象类型给出最大表示空间，让未来版本可以定义高位；每个 Template 的 Field Length 才说明随后 Data Record 实际占用多少字节。RFC 7011 允许无符号整数在数值可容纳时省略前导零。于是，“抽象类型四字节”和“当前线缆字段一字节”描述的是两个层次。

忽略任一层都会产生不同故障。把元素 89 永久写死为一字节的解析器，也许能处理今天的数据，却无法承接未来高位含义；只看到 unsigned32 就一律读取四字节的解析器，则会错位读取一个 Template 明确声明长度为一的合法记录。可靠解释必须绑定 Information Element ID、Template ID、Observation Domain 和 Transport Session。

RFC 9710 还直接写出注册表的运行时意义：这些调整旨在便利自动提取，例如定时任务，让 Collectors 支持新的 Information Elements，并正确理解相关注册表新增值。IANA 页面因此不是“偶尔查阅的文档”，而是软件供应链输入。抓取 URL、时间、内容哈希、schema 生成器版本、构建物和部署实例都应可追溯。

八位状态仍只是出口断言

当前低字节中，0x40 表示 Forwarded 且无进一步信息；0x89 表示 Dropped，原因是 bad TTL。RFC 7270 的已验证勘误 5262 曾纠正后一例的错误说明。这证明表述准确很重要，却不意味着状态值拥有超出 Observation Point 的权力。

这个值是 Exporting Process 对某个 Flow 的断言。它不是目的端签收，不是逐包保全记录，不是完整路径，也不是唯一原因或 SLA 裁决。若要据此采取生产动作，运营者仍可能需要原始 Template 和 Data Set、出口配置、接口计数器、独立抓包或下游观测，以及明确的决策规则。“出口编码 Dropped”与“业务确因该原因失败”是两个命题。

历史数据更不能因注册表今天改了就自动获得新真相。旧字节保持不变；安全重解码依赖当时的 Template、schema 与软件版本。RFC 5610 定义的带内 type records 也不是万能补丁：它们受 Transport Session 限定，不得覆盖 collector 自身定义，也不能替代跟进 IANA 更新。

来源