Summary

  • RFC 1108 将 IPv4 选项 133 定义为可重复出现的附加安全标签容器，每一种格式代码都必须由独立且可互操作的规范说明。
  • 每个扩展安全选项都依赖同行的基本安全选项与一致配置；移除扩展字段可能令数据包失效，也可能让接收端赋予错误的敏感度。

稳定容器，外置语义

扩展安全选项以类型 133 开始，长度可变但至少为三个八位组，并带有一个八位组的“附加安全信息格式代码”。代码选中哪一种语法，后续字段就按那种语法解释；如果该格式本身允许，后续字段甚至可以为空。

仅在注册表里分配一个名称并不够。RFC 1108 要求每个格式代码都由一份 RFC 说明其语法，并给出足够明确、可由算法执行的接收或拒绝步骤，使不同厂商能够互操作。比特位与人类可读标签之间的映射可以受限，但机器处理所需的公开契约不能缺席。

该选项会复制进分片，也可以在同一数据报中出现多次，实际数量受 IPv4 首部容量限制。不过，可重复不等于可独立存在。凡携带 ESO 的数据报都必须同时携带 Basic Security Option；有 ESO 而无 BSO 即属错误。未注册的代码、前后不一致的长度，以及不符合对应 RFC 的内容，同样是错误，并可触发 ICMP Parameter Problem。

系统也不必全盘支持。它可以实现 BSO 而不实现 ESO，或只支持部分 ESO 格式代码。BSO 中的 Protection Authority 位与 ESO 的格式代码空间没有对应关系。于是，两个相邻字段可以共同参与一次安全判断，却分别受不同注册体系和能力集合约束。

路由环节还需要另一层配合。中间系统若要依据 ESO 标签选择受保护路径，路由协议本身也要扩展以携带相关信息。选项只能运输一项声明；网络还必须具备端口安全参数、受支持代码清单和相应路由状态，才能据此行动。

移除并非中性操作

RFC 7126 后来记录，ESO 的使用主要限于私有的高安全网络。删除 ESO 可能使接收端把数据包当作标签不完整而丢弃。更严重的是，接收端可能给数据赋予错误的敏感度，从而提升或降低其处理级别。

这种不对称决定了默认策略：设备事先无法知道自己是否会部署到这类环境，因此不应仅因 ESO 出现就默认删除该选项或丢包。只有明确知道本地环境不用 ESO 时，管理员才可配置丢弃；设备还应提供可审计的包计数。

现有来源没有给出当代部署比例、目前仍受支持的代码清单，也不能证明所有产品行为一致。可以确定的只是架构结论：扩展性没有消除协调成本，而是把协调转移到注册表、独立规范和必须持续对齐的配置中。

来源