摘要

  • MPLS 路由器可以先剥去标签栈，再交由 IP 错误处理；传统报错引用因此可能保留了数据报，却丢掉了决定转发的上下文。
  • RFC 4950 要求保留原有 IP 引用，并为特定错误报文增加到达时的标签栈；它不是出口状态、回程路径或全球标签身份证明。
  • 多段 ICMP 的长度字段解决了解析边界，却必须面对已部署的固定偏移读法。标签是否可见，还取决于 TTL、报文送达和运营者的披露选择。

正确的引用，不完整的解释

设想一台标签交换路由器收到一个无法继续送达的数据报。为了按 IP 规则处理错误，它剥去包裹在外面的 MPLS 标签栈，露出 IP 首部。随后生成的 ICMP 报文说明错误原因，并带回原数据报的首部和开头一段内容。

引用的字节可能完全正确。问题在于，刚被去掉的标签，恰恰是这台设备原本会拿来决定转发的依据。数据报还在，决定它如何被处理的上下文却离开了报告。

这是 RFC 4950 在 2007 年 8 月提出的问题。Ronald P. Bonica、Der-Hwa Gan、Daniel C. Tappan 与 Carlos Pignataro 没有试图把错误报文变成完整的网络审计系统。他们给特定 ICMP 错误增加了一种对象，用来携带数据报抵达报错路由器时的 MPLS 标签栈。

这个改动小于“看见网络”，也比多打印几个数字重要。它改变了报告选择保存什么：不仅保存被处理的 IP 内容，也保存包裹在它外面、参与转发判断的状态。

原来的八个字节回答另一个问题

1981 年 9 月的 RFC 792 为 Time Exceeded 定义的引用包括 IP 首部，以及原数据报数据部分的前 64 位，也就是八个字节。规范解释，这些内容帮助源主机把错误对应到合适的进程；若上层协议使用端口号，端口被假定在这段开头数据中。

这是一种关联机制。它帮助接收方回答“哪次通信出了问题”，不负责完整重建途中每台设备如何作出判断。也不能把这份早期格式误读成后来所有 ICMP 报文永远只引用八个负载字节。

MPLS 把另一个上下文放在 IP 首部前面。RFC 3032 在 2001 年 1 月描述的标签栈位于链路层首部之后、网络层首部之前。每项占四个字节；栈顶最先出现，最底部条目的 S 位为一。

设备查找栈顶标签，可以得到下一跳和要执行的栈操作，例如替换栈顶、弹出条目，或者替换后再压入更多条目。因而，仅仅把 IP 引用得更长，并不自然恢复已经剥离的标签。缺失的不是原引用末尾再往后的几个字节，而是另一层信息。

把“到达时”写进对象定义

RFC 4950 的限定非常具体：一个 MPLS Label Stack Object 表示整个入站标签栈，保持数据报抵达产生错误的路由器时的格式和顺序。它可以附加在 Time Exceeded 与 Destination Unreachable 中，适用于 ICMPv4 和 ICMPv6。

规范建议这些选定的错误携带标签栈，同时要求继续保留原数据报的 IP 首部和开头负载。扩展不是用标签替换 IP 引用。两者服务于不同问题，必须能够放在一起解释。

“到达时”是最容易被显示界面抹平的限定。屏幕上若只有一个标签数字，读者可能把它理解成离开该设备时使用的标签，或者今天配置中仍然存在的绑定。但这个对象报告的是进入现场时的状态。它本身没有告诉读者下一步操作是否成功，也没有列出尚未发生的出口变化。

更不能把一台设备报告的数字直接连到下一台设备的同值数字上，便宣布发现了一条持久路径。RFC 3031 将 MPLS 标签定义为具有本地意义的标识，用来识别转发等价类，而不是目的 IP 地址的另一种编码。数值必须与适用的标签空间和设备上下文一起解释。相同的印刷形式，不保证相同的转发含义。

小对象也需要明确边界

这个对象的类别号是 1，子类型也是 1。前者区分 MPLS 标签栈这一类扩展，后者表示入站栈。若栈内有 n 项，对象长度便是 4 加上 4n 个字节：四字节对象首部，再加每项四字节。

举例说，三项栈对应一个十六字节对象。这只是按格式计算的例子，不是一次抓包。该长度也不包括位于对象之前、另行存在的 ICMP 扩展首部。

每项标签栈含二十位标签、三位当时称为 EXP 的字段、一位 S，以及八位 TTL。2009 年 2 月的 RFC 5462 将 EXP 改称 Traffic Class，即 TC，明确其流量类别用途。名字变化没有扩大四字节条目。阅读 2007 年示例时应保留历史语境，但不能由旧名称推论那三位今天仍是任意实验空间。

类别和子类型的登记解决的是共同格式问题：接收程序知道后面的字节应该怎样读。它并不为各台路由器报告的标签值颁发全球身份。登记一种记录，与支配记录所描述的网络，是两种不同的权力。

长度字段遇到已经运行的软件

标签栈对象依赖同年 4 月的 RFC 4884。该规范让一些 ICMP 报文可以分成原数据报引用与扩展结构；后者包含一个扩展首部，以及一个或多个对象。

边界不能只靠接收者猜测。规范从原来保留的空间取出一个八位长度属性，用来说明原数据报引用区域有多长。IPv4 以四字节字为单位，IPv6 以八字节字为单位；附加扩展时，引用区域至少保留一百二十八字节，不足则补零，并满足相应对齐要求。

一百二十八是这里的下限，不是允许引用的最大值。然而，历史兼容问题恰好围绕这个数展开。RFC 4884 记载，1999 年至它发布之间已有实现把扩展固定放在一百二十八字节引用之后，却没有填写后来明确规定的长度属性。某些读取程序因此只认固定位置，不看新长度。

新发送方若想兼容这类旧程序，就需要恰好保留一百二十八字节。若选择携带更长的引用，新程序可以按长度找到扩展，旧式扩展读取程序却可能在错误位置寻找首部。格式能够表达的内容，和已部署接收方能够正确消费的内容，并不总是同一回事。

这也不是简单的“旧软件忽略新字段，所以没有影响”。传统程序可能把附加内容误当成原数据报的一部分。RFC 4884 分析了这种情况和已知影响，没有许诺任意旧应用都能无损接受。

默认不猜，兼容模式另开一门

RFC 4884 给合规接收方的默认规则很清楚：引用长度属性为零，就判定没有扩展。可是，那恰好会漏掉旧实现实际附加的扩展。

解决办法不是悄悄改变默认解释，而是要求合规 traceroute 提供一个非默认兼容模式。在这个模式下，对足够长、没有长度属性的报文，程序可以按旧的一百二十八字节位置寻找扩展，再检查版本和校验和。

这一安排把兼容成本暴露出来了。默认路径遵循显式声明；兼容路径接受旧式定位方法的条件和风险。一个看似只是显示标签的功能，实际需要发送端、接收端和操作者共同知道自己采用哪套读法。

扩展首部采用版本二。对象自己的长度以字节计算，包括首部和负载。遇到不认识的对象，不意味着整份 ICMP 报文必定损坏；但长度与语法仍需检查，不能把未经验证的输入交给越界读取。校验和也只是报文校验，不会因此产生密码学意义的发送者认证。

报告中的栈，不是运送报告的栈

还有一种容易混淆的“把标签放进错误处理”。RFC 3032 讨论过：MPLS 域内部设备不一定知道如何直接路由回原数据报的源地址，尤其在某些隧道场景中。

一种办法是把生成的 ICMP 报文重新包在标签中，先沿原数据报目的地方向转发，到达知道如何返回源端的路由器之后，再送回去。这个办法复制标签值，但为运送新报文而设置相应 TTL，给可能绕行的旅程留出空间。

这里的标签正在工作：它们是运送错误报告的外层封装。RFC 4950 的对象则是报告内容中的证据，保存出错数据报到达时的栈。二者可以涉及相似数值，却扮演完全不同的角色。

把它们混为一谈，会同时读错状态和时间。收到的一份报告可以包含旧数据报的入站快照，同时经历不同于探测正向路径的返回过程。一个往返时延数字不能单凭附带的栈，就拆解成某一条链路的耗时。

多一行标签，不会自动多一个可见跳点

RFC 4950 特别声明，它不重新定义 MPLS 与 ICMP 的全部关系，也不改写封装特有的 TTL 处理。如果原本的 TTL 规则使普通 traceroute 失效，带扩展的 traceroute 同样会受到影响。

RFC 3443 在 2003 年区分了相关 TTL 模型。Uniform 模型在隧道出入口同步内外 TTL；Pipe 等模型的外层起始 TTL 则可以与内层值无关。后者可以让内层探测不因穿越标签交换路径中的每一跳而产生预期的超时报错。

这不等于外层 TTL 没有限制，也不是 Pipe 模型永远不产生任何 ICMP。它说明的是：探测者依赖的触发条件，可能没有按他想象的方式发生。扩展能丰富已经收到的错误，不能强迫网络产生或送达另一份错误。

此外，RFC 4950 明确讨论选择性披露。设备可以根据错误报文的目的地址决定是否附带标签，例如仅向管理地址段披露；也可以采用全局开关，或者根据入站栈深度作选择。

因此，缺少标签行不是“这里没有 MPLS”的充分证据。扩展可能没有生成，没有送达，没有被识别，或者没有向这位观察者公开。规范在 2007 年称其机制已经广泛部署，这是一项当时的陈述，不是今天的覆盖率，也不能把发布日期当成所有网络同时启用的日期。

这个历史留下的改进很实在：错误报告终于能够带回原先容易消失的转发上下文。它也留下同样实在的界限：现场证据可以更完整，观察者的位置却不会因此消失。