摘要

  • IEEE Registration Authority 直接分配 EtherType 与 LSAP，并把 OUI 00-00-5E 授予 IANA；IANA 的编号权只存在于这段已委派的子空间内。
  • 位于 IANA OUI 之后的两字节协议号不会因为长度相同、位置靠前就变成 EtherType，载体、OUI 与内部编号缺一不可。
  • RFC 9542 要求运营者把字段位置、命名空间、权威登记册、审批程序、规范文本、实现行为与应用结果拆成不同回执。

错误并不是把十六进制看错了，而是把字节的来历压扁了。

在 88-B7-00-00-5E-00-42 中，至少存在三次不同的制度动作。IEEE Registration Authority 分配了 OUI Extended EtherType 0x88B7；IEEE 又把 OUI 00-00-5E 分配给 IANA；IANA 随后在自己的 OUI 子空间里把协议号 0x0042 留作说明文档示例。末尾两个字节有意义，却不能脱离前面的 OUI 单独解释。

RFC 9542 于 2024 年 4 月以 BCP 141 发布，并取代 RFC 7042。它没有新建 IANA 登记册，也没有改变既有分配。它做的是更基础的工作：说明同一个以太网帧格式如何同时经过 IEEE 与 IANA 的责任边界，而不让任何一方借由“页面上出现过这个数字”取得额外权力。

先确定字段形态，再询问编号名称

EtherType 是 16 位标识符，数值不低于 0x0600。在最简单的 Ethernet II 帧中，它位于源、目的 MAC 地址之后；存在 VLAN 等标签时，前面还可能出现其他类型字段。EtherType 由 IEEE RA 分配，不由 IANA 分配。

IEEE 802 LLC 使用另一种结构。长度字段之后是成对的 8 位 LSAP；SNAP 形式再放入 AA-AA-03、三字节 OUI 和两字节协议号。这里，协议号的分配者是 OUI 持有者。

第三种形式使用 0x88B7。这个 EtherType 告诉解析器，后面将出现 OUI 与协议号。当 OUI 为 IANA 的 00-00-5E 时，完整形式是 88-B7-00-00-5E-qq-qq。外层 EtherType 属于 IEEE 的直接分配，内部 qq-qq 属于 IANA 的子分配。两者都是 16 位，不代表它们出自同一张登记表。

SNAP 还有一个容易混淆的例外：全零 OUI 后面的两字节可以承载任意 EtherType。把全零换成 00-00-5E 后，同一位置就变成 IANA OUI 下的协议号。决定授权链的不是“最后两个字节长什么样”，而是它前面的命名空间。

若资产系统只留一个名为 protocol type 的 16 位栏位，信息损失在写入那一刻就发生了。之后再接入更准确的登记册，也无法从 0042 逆推出原帧属于哪一种封装。

IANA 网站上的表，不一定是 IANA 的分配表

IANA 的 “IANA OUI Ethernet Numbers” 页面记录 IANA 在自身 OUI 下进行的分配。其 SNAP 协议号登记册明确列出 0x0042 为文档用途。这张表的确属于 IANA 的授权范围。

IANA 同时托管 “IEEE 802 Numbers”。其中 EtherTypes 一节写明这些号码并非由 IANA 分配，并称所列内容是来自不同来源、未经验证的信息，权威公开清单应向 IEEE RA 查询。托管、整理与专家协调可以提高可用性，却不会把分配权从 IEEE 转移给 IANA。

人读网页时可能注意到这段警告，采集程序却常常只抓表格行。于是系统可以拥有完整哈希、更新时间和签名，却仍在 authority 栏中写错机构。密码学只能证明文件没有被改动，不能证明采集者理解了页面的责任声明。

当这些数据进入防火墙、协议识别或准入控制，错误会变成执行结果。文档示例可能被当成正式协议，局部实验值可能被当成全球分配。登记册的“谁负责”必须成为数据模型的一部分，不能只是页面脚注。

分配条件揭示子空间的用途

IANA OUI 下的新协议号不能随意发放。RFC 9542 要求该用途服务于 IETF 标准或与 IETF 工作相关的其他标准，必须在 Internet-Draft 或 RFC 中记录，还应在固定偏移位置提供版本字段，或提供使旧版本识别新版本的等效标记。

通常的分配需要 Expert Review；边界值 0x0000 与 0xFFFF 已保留，只有经过 IESG Ratification 才能分配。更重要的是，已经拥有 EtherType 的协议不得再为同一用途申请 IANA OUI 协议号。它可以直接使用 EtherType，也可以在 SNAP 中把 EtherType 放在全零 OUI 后面。

这条禁令减少的不是几个数字，而是重复授权链。如果同一协议同时沿 IEEE 与 IANA 两条路径获得看似等价的编号，运营者会面对两个更新周期、两个历史记录和两个可能漂移的事实来源。

IANA OUI 下的 MAC 地址分配也受目的限制。区块必须用于标准，应按二的幂次分配与对齐，并不得帮助接口厂商逃避向 IEEE 取得自有地址块的要求。受委派者可以处理明确需求，却不能把委派变成对上层空间的替代管辖。

文档值与实验值是两类回执

IANA OUI 下的 0x0042 用于说明文档。其他按 OUI 组织、再加一个字节的参数，也通常把 0x42 留给示例。这样标准文本可以展示具体比特，而不占用真实部署的编号。

IEEE 另行指定 0x88B5 与 0x88B6 为本地实验 EtherType。它们属于 IEEE 的 EtherType 登记体系，目的也不是文档示例。把 00-00-5E-00-42 称为“实验 EtherType”，等于把载体、OUI、内部协议号和用途四件事混成一句假话。

这种混淆会从文本进入系统。示例配置被复制到生产，实验帧越过本地管理域，解析器把保留值贴上正式产品名称。治理办法不是禁止实验，而是让用途、范围、负责人和到期条件跟随编号一起保存。

登记回执不等于运行回执

权威登记记录可以证明某个机构在特定命名空间里保留或分配了一个值。它不能证明某台设备正确实现了规范，不能证明帧内负载符合名称，也不能证明接收应用完成了动作。

完整证据链从字节位置开始。标签、长度与偏移确定字段形态；载体确定外层解释；OUI 确定子空间；IEEE RA 或 IANA 的权威记录确定分配；评审程序与规范确定条件。之后还需要软件版本与配置来证明实现，需要原始抓包来证明某次观察，需要端点或应用日志来证明结果。

如果把后几项交给登记机构代言，唯一性协调就会被夸大成运行认证。RFC 9542 的设计恰好相反：每一层都有真实作用，也都保留明确的止点。权力较薄，证据反而更强。

让资产记录能承受一次真实事故

可审计的记录应保存原始字节、字段偏移、标签、外层载体、完整 OUI 标识符、登记册所有者、来源与快照日期、审批类别、规范文档、解析器版本和实际结果。友好名称可以提供检索，但不能取代这些字段。

这样，差异就能被定位。IANA 的信息性 EtherType 列表可能晚于 IEEE RA；IANA OUI 下的有效协议号可能被工具错误显示为 EtherType；文档保留值可能出现在生产链路。三种情况需要三种处置，不应由同一条“以网页为准”规则覆盖。

编号本身没有越权。越权来自上下文被删除之后，系统替它发明的解释。只要 00-00-5E 仍与 00-42 相连，IANA 的委派范围就清清楚楚；只剩 0042 时，任何登记册都可能被误写成权威。

来源