摘要

  • RFC 5332 规定，直接在 IP 中封装 MPLS 时，协议号或 Next Header 始终是 137；它不会因内部 MPLS 标签具有单播或组播复制语义而改变。
  • 以太网的 0x8848 在规定场景中表示顶层标签由上游分配，不是通用“组播”标志。正确字段仍不能证明标签上下文、NHLFE 复制、接收或业务结果。

一个稳定字段，承受了四个额外判断

设想一条数据管道把协议号 137 展开成四列：mpls=true、multicast=true、upstream=true、delivered=true。第一列有直接依据。后三列分别需要目的地址与隧道合同、标签空间与查表结果、接收与业务观测。

RFC 5332 刻意让 137 对这些差异保持中立。若 IP 目的地址是组播地址，该隧道可以是点到多点或多点到多点；同一条隧道内顶层标签的分配方向必须一致，但选择上游还是下游的机制不在 RFC 范围内。

因此，137 应当触发后续连接，而不是替后续证据签字。保存外层源/目的地址、隧道标识、分配合同与生效时间，才能知道下一步该查什么。

EtherType 的旧名字也曾制造同一种错觉

RFC 3032 最初把两个 MPLS 数据链路 codepoint 描述为单播与组播。RFC 5332 说明，那套组播用法从未部署，后续设计需要的是另一条分界：顶层标签由上游还是下游分配。旧用法因此被废弃。

在组播以太网帧中，顶层标签由下游分配时使用 0x8847，由上游分配时使用 0x8848。两种帧都可以承载 MPLS 组播。真正让标签成为组播标签的，是特定上下文中 NHLFE 所带的复制语义；即使当时的下一跳集合只有一个成员，这个定义仍然成立。

如果系统把 0x8847 直接写成“单播”，或者把 0x8848 写成“组播已确认”，它保留了历史称呼，却丢失了当前标准。数字没变，不代表命题没变。

分配方向只告诉系统去哪一层找意义

下游分配意味着接收方建立 label 到 FEC 的绑定并把它告知发送方。上游分配意味着发送方或第三方建立绑定。上游标签不必与下游标签共享同一个标签空间，RFC 5331 承担上下文解释规则。

所以 0x8848 的价值在于提醒接收方：不要把顶层标签当然地放进普通下游标签空间。它没有提供完整的表选择键，也没有证明实际查表成功。已发布的 RFC 5331 文章讨论上下文选择、PHP 与根身份；本文只强调封装字段不能替代那个机制。

一个可审计记录至少要连接顶层标签、原始栈、分配合同、对端支持证明、上下文选择器、命中的 NHLFE 与复制动作。少了后几项，“正确 codepoint”仍可能遇到错误上下文。

对端能力不能从本地安装状态推出

RFC 5332 把上游分配标签列为可选功能，并要求：只有已知下游 LSR 支持时才能使用。标准没有规定这种“已知”如何产生。

本地软件具备功能，只证明本地能力。它不证明新换入的对端支持，不证明某条邻接已协商，也不证明上周采集的能力状态仍有效。把设备功能清单当成对端事实，是把对象层和关系层混在一起。

能力 receipt 应绑定对端身份、链路或隧道、来源、版本、采集时间与失效条件。邻居替换、配置回滚或软件降级都应使旧证明进入待复核状态，而不是继续给未来报文授权。

GRE 的错误判定需要额外合同

GRE 外层目的地址为单播时，MPLS-in-GRE 始终使用 0x8847。目的地址为组播时，下游分配使用 0x8847，上游分配使用 0x8848。

若其他程序已经确定某条组播 GRE 隧道必须使用上游分配，那么收到 0x8847 就是错误，报文必须丢弃。这里的“错误”来自三项证据的组合：目的地址类别、隧道合同、实际 codepoint。单独扫描 0x8847 无法得出同样结论。

丢弃规范也不是影响 receipt。还要观察报文是否到达执行节点、实现是否执行了规则、后续路径是否存在、哪些服务使用该报文，以及最终交付怎样变化。

组播 MAC 的二十位不是接收者编号

MPLS 组播以太网目的地址采用 01-00-5e-8v-wx-yz。二十位 vwxyz 可以全为零，也可以来自标签栈中的某个标签。若栈至少有两层，默认使用第二层；配置可以选择另一层。只有一层时，使用该标签。

零值和标签派生值都是允许的实现选择，双方必须互通。接收方不能把所有零值都过滤掉，也不能不加区分地过滤所有非零值。标签派生后缀可以帮助更细的过滤，但 RFC 没有替实现决定过滤用途。

这些二十位不是组成员清单、用户身份或接收证明。它们可能只是某个标签的投影。交换设备的二层复制、LSR 的过滤、标签查表、MPLS 复制与最终接收仍是不同环节。

语义迁移必须成为可观察事件

从 RFC 3032 到 RFC 5332，codepoint 值保持，含义调整。这种变化若只发生在标准文档里，生产系统会长期出现“字节一致、结论不一致”。

应为解析器维护语义版本：适用 RFC、介质条件、外层地址条件、现行含义、已废弃含义、默认值与非法组合。每条派生记录绑定版本，并保存足够原始信息供未来重放。

升级前后应以同一批帧做差异测试。若 0x8848 从“组播”变为“上游分配”，所有依赖旧字段的过滤、统计、告警与资产视图都必须显式复核。否则升级只是让数据库内部出现两个时代。

安全风险不能自动生成攻击故事

RFC 5332 指出，恶意更改 codepoint 可能造成丢失或错误路由，但只改 codepoint、不改标签时，结果不可预测。恶意更改 MAC DA 可能使第三方收到报文。

抓到不一致字段可以证明报文与合同或规范不符。它不能证明恶意、行为者、实际查到的表、报文走出的接口或第三方确实接收。要把风险升级为事件，必须追加接收方决策、转发与结果证据。

最危险的做法是在分类完成后删除原始帧。那会让一个早期假设成为唯一历史。保留字节、捕获点、方向、合同 epoch 与实现版本，才能在新证据出现时重新判断。

把 137 放回它应在的位置

一条严谨的证据链从介质和外层地址开始，经过 137 或 EtherType、原始标签栈、分配合同、对端能力、上下文、NHLFE、MAC 派生政策、过滤、复制、接收，最后才到业务结果。

协议号 137 很重要，因为它让接收方知道如何解释下一层。它不需要同时成为组播证明、权限证明与结果证明。公共层越克制，本地运行系统越能保留选择；但这些选择必须留下 receipt，不能让中央平台事后用字段名称制造统一。

这正是运行代码优先于符号权力的工程版本：符号协调入口，运行系统产生事实，证据把两者连接起来，任何一层都不能冒充下一层。

来源