摘要

  • RFC 9870 注册了一组 IPFIX 信息元素，用来表明某个 SAFE 或 UNSAFE UDP 选项类型在一个流中至少被观察到一次。
  • 某一位被置位，只能证明观察边界内存在该类型；它不表示逐包顺序、出现次数、选项值、成功处理、应用交付或实际部署。

位图很容易让人把简洁误认为确定。一个置位确实回答了“导出器是否见过这个类型”，但 RFC 9870 在这里停下。它没有说明选项位于哪个数据报、出现了多少次、携带什么值，也没有说明接收端是否执行了它。

UDP 选项位于 UDP 包之后的剩余区域，以一个字节的 Kind 值标识。RFC 9870 不重新定义这些选项，也不提供其运行指导；它定义的是 IPFIX 导出器如何报告观察结果。

两个位域对应两个选项区间

Kind 0 至 191 属于 SAFE，192 至 255 属于 UNSAFE。信息元素 525 udpSafeOptions 使用 256 位无符号标志，其中最高 64 位必须为零；元素 526 udpUnsafeOptions 用 64 位表示 UNSAFE Kind。

在两者中，一个置位都只表示相应 Kind 在流内至少出现过一次。因此，两个流即使出现次数、先后顺序和选项值完全不同，也可能产生同一个位图。

如果不需要高位，IPFIX 可以使用缩短的编码。RFC 9870 的示例表明，强制 SAFE 选项可以装入一个八位组。字节变少并不会扩大证据范围：省略的高位区域不是端点处理行为的记录。

实验选项需要单独的标识证据

信息元素 527 至 529 表示 16 位实验标识符，以及观察到的 SAFE 或 UNSAFE 实验标识符列表。相应列表存在时，它优先于通用 EXP 或 UEXP 位；导出器必须在该流中保持通用位未设置。这避免两种表示被误当成两份独立佐证。

列表能够区分观察到哪个实验编号，但仍然不能证明选项被接受、正确执行或促成了成功的应用交换。

收集器可以据此查找值得进一步检查的流，或比较不同观察点。如果结论依赖顺序、次数、内容或端点行为，就必须使用真正记录这些事实的证据，而不能把 IPFIX 位图当成抓包或合规判定。

主要规范是 RFC 9870。UDP 选项背景来自 RFC 9868，IPFIX 协议和信息模型见 RFC 7011 与 RFC 7012。当前注册项可在 IANA IPFIX 信息元素注册表核验。这些材料规定格式，不证明当前部署情况或性能。