摘要

  • RFC 9870 新增五个 IPFIX 信息元素；其中 SAFE 与 UNSAFE 位图回答的是“某类选项是否在这个 Flow 中至少被观察到一次”。
  • 实验标识列表在出现时取代通用 EXP 或 UEXP 位，能保留所见 ExID，却仍不保存包序、次数与接收端行为。
  • 每个判断都要带上观察点、Flow 边界、抽样方式、模板、导出器状态和收集回执；观察到不等于对端处理，零也不等于全网不存在。

“1”只回答一个问题

RFC 9870 先说明 UDP 选项是逐包出现的，而且可以在 Flow 进行期间随时插入。随后，它把这些离散事件投影成集合。udpSafeOptions 是 ElementID 525，为 0 到 191 的 SAFE Kind 分配位；udpUnsafeOptions 是 ElementID 526，为 192 到 255 的 UNSAFE Kind 分配位。

置一条件不是“持续存在”，而是“至少观察到一次”。一次探测与一万次发送可能留下同一个 1。开头出现、结尾出现、间歇出现也无法区分。两个选项同处一包还是分散在不同包里，位图同样不说。

这种压缩有明确价值。大规模清点或粗粒度发现不一定需要保存每个包。但下游规则若把集合成员关系解释成频率、稳定性或因果，问题就从技术效率变成证据越界。RFC 9870 没有给这种放大授权。

实验的名字留下了，过程没有

单一 EXP 标志无法区分并行实验。RFC 9868 为 SAFE 保留 Kind 127 的 EXP，为 UNSAFE 保留 Kind 254 的 UEXP；RFC 9870 再定义 16 位的 udpExID，以及分别承载 SAFE、UNSAFE 实验标识的两个 basicList。

读取时必须尊重优先关系。SAFE ExID 列表出现，就已经表示观察到 EXP，导出器不得在同一个 Flow 的 SAFE 位图里重复设置 EXP 位。UNSAFE 列表对 UEXP 采用同样规则。只看通用位图的分析器，可能把“证据移到了列表”误读成“没有证据”。

列表解决的是身份，不是时间。它能说明见过哪些 ExID，却不能说明各自出现多少次、谁先谁后、是否共处一包，或者接收端是否识别。标识更精确，并没有让丢失的事件轨迹重新出现。

零值也有观察边界

RFC 7011 把 Flow 约束为一组在某观察点、某时间区间内经过并共享指定属性的数据包。因此，RFC 9870 的零只表示在“这份记录所代表的 Flow”里没有观察到对应 Kind。它成立的前提还包括测量进程有能力识别该字段、选择策略明确、记录完整。

若观察点、活跃与空闲超时、Flow 键、抽样或导出能力未知，零不能扩写成“网络中不存在”。选项可能出现在另一链路、另一区间或未被选择的数据包里。相反，1 是窄而有力的正证据：这条测量路径至少看见一次；它不是目的端签发的回执。

SAFE 与 UNSAFE 描述传统接收方忽略选项可能造成的后果，不代表某个接收方实际解析、认证或执行。IPFIX 传输保护、收集器收到记录、端点接受策略、应用产生结果，仍是四个不同事实。

模板是解释合同

SAFE 位图采用 RFC 9740 引入的 unsigned256，但 RFC 9870 允许用缩减尺寸编码省略高位零字节。实验列表则依赖 RFC 6313 的 basicList。脱离 Template、字段长度、信息元素编号与注册语义，只留下一个整数，未来就可能无法忠实解释。

IANA 的 IPFIX 注册表记录 525 到 529 号元素，UDP 注册表记录 Kind 与 ExID。注册表给公共词汇分配稳定身份，并不证明某台设备支持、某条 Flow 被观察或某项行动已经发生。

来源