摘要

  • 报告 LSR 处理不可交付的 MPLS 封装数据报时，可在选定的 ICMPv4 或 ICMPv6 多段错误中附加 MPLS Label Stack Object；普通 ICMP 可能只呈现暴露出来的 IP 数据报，而不呈现影响转发的标签栈。
  • 该扩展使用 RFC 4884 定义的扩展结构和对象头，可随 Time Exceeded 与 Destination Unreachable 消息发送；原始 IP 头和开头的负载字节仍须保留。
  • 观察到的标签栈是诊断证据，不是修复命令、路由或 LSP 授权、身份认证、访问授予或密码学证明。

RFC 4950 的实际机制很具体：当 LSR 生成适用的多段 ICMP 错误时，它可以把到达该报告路由器时的完整入站 MPLS 标签栈放进扩展对象。这样，增强型 traceroute 不只可以报告经过的节点，还能报告原始数据报在每个响应节点到达时所处的 MPLS 封装状态。它补上的，是普通 ICMP 错误负载中缺失的上下文，而不是一条新的控制通道。

每个标签栈条目占四个八位组。按 RFC 4950 的描述，字段包括 20 位 Label、按 2007 年文本命名的 3 个实验用途位、1 位 Bottom-of-Stack 标志，以及 8 位 TTL。消费者应把这些位当作报告格式中的字段来解析，不应把标签值当成改变转发的许可，也不应据此推断所有权、意图或策略合规性。对象保留原始 IP 头和开头的负载八位组，因此错误定位既有 IP 证据，也可能有入站标签上下文。

边界同样重要。RFC 4950 不定义一般性的 MPLS/ICMP 关系，也不定义特定封装的 TTL 操作。RFC 3032 提供的相关编码背景不能被扩展为“所有 MPLS 路径都以同一方式暴露”。如果 TTL 处理足以击败基本 traceroute，也会击败增强形式。RFC 中关于该扩展“广泛部署”的表述属于历史陈述，不能证明今天的覆盖率、厂商行为一致性或披露默认值。

核验应从可重复的证据夹具开始，而不是从修复假设开始。L3 夹具可以包括：一组已知会产生 Time Exceeded 的测试报文、一组会产生 Destination Unreachable 的测试报文、能保存原始 ICMP 报文的抓包点，以及逐字节解析 RFC 4884 扩展头和 RFC 4950 对象的工具。对每个响应，记录 ICMPv4/ICMPv6 类型、原始 IP 头和前导负载是否存在、对象长度、四八位组边界、Label、3 个实验用途位、Bottom-of-Stack、TTL 和响应节点。把有对象、无对象、被过滤和 TTL 不可见分别标记，不能把它们合并为“无 MPLS”。

运营者决策路径可以保持克制：第一步确认响应是否确实是选定的 ICMP 错误，并验证扩展结构；第二步检查对象完整性和原始 IP 片段；第三步将标签栈与本地遥测、设备记录和其他独立证据比对；第四步依据披露政策决定是否向诊断消费者发送完整栈、按目的地址或栈深度选择性发送，或不发送；第五步只有在独立证据支持时，才进入常规路由、LSP 或转发变更流程。ICMP 对象本身不创建或授权 LSP、不验证路由、不认证发送方、不授予访问权，也不命令另一台路由器。

缺少 Label Stack Object 也不能证明数据报没有经过 MPLS。能力支持、运营策略、过滤、兼容性和 TTL 行为都可能抑制观察；一个已报告的栈也不能单独证明端到端完整路径、根因，或每一跳都会返回等价信息。普通 ICMP 和 traceroute 仍可显示错误和经过节点，只是省略入站 MPLS 栈；在没有该扩展时，运营者会更多依赖内部遥测和设备侧记录。

来源