摘要

  • RFC 7510 让封装器在外层 UDP 源端口写入本地生成的流熵，使普通 IP 路由器能够借助 ECMP 或链路聚合分散 MPLS 流量。
  • 源端口和目的端口 6635 都不是身份或授权。隧道端点、配置、过滤、拥塞范围、校验和、MPLS 标签栈以及可选安全机制仍是彼此独立的控制面。

先看一台会误解它的防火墙

对许多有状态设备来说，UDP 流量应当有来有回。设备记录源地址、目的地址、源端口、目的端口和协议，等待反向报文交换端口后返回。监控平台也会顺手把同一五元组称为“会话”。

MPLS-in-UDP 却不遵循这种直觉。RFC 7510 明确说明，隧道是单向的。报文发往 IANA 分配的目的端口，而回复不会被送回那个源端口，因为源端口只承担熵的作用。两个方向若都要穿过同一台中间盒，往往需要分别配置。

这条注释揭开了整个机制。字段仍处在 UDP 头部，但它的职责已经改变。一个稳定数值可以帮助报文留在同一路径桶里，却不表示某个应用正在监听；它可以让路由器分流，却不能证明封装者是谁；它可以被监控系统看见，却没有建立一段双方认可的会话。

为什么给 MPLS 套一层 UDP

许多 IP 路由器早已能够对 TCP 或 UDP 五元组做哈希，把微流分配到等价多路径和链路聚合成员。直接承载的 MPLS 报文未必向这些设备暴露足够多的可变字段，于是大量内部流可能堆到同一个成员上，其他路径却仍有余量。

RFC 7510 的办法不是要求所有中间设备深入理解标签栈，而是在 MPLS 报文外加 IP 和 UDP。外层 IP 地址表示隧道端点，UDP 头提供既有芯片熟悉的输入，源端口则制造可用于分流的差异。这样，MPLS 流量可以复用 IP 网络已经部署的负载分担能力。

文档的线格式图写得很直接：先是“源端口＝熵”和“目的端口＝MPLS”，随后是 UDP 长度、校验和，再往里才是 MPLS 标签栈与消息体。它不是把所有语义揉成一层，而是把三套职责叠在一起：外层端点、分流包装、标签转发。

因此，UDP 在这里更像适配器。它让现有 IP 转发设备看见足够的差异，但并没有把 MPLS 变成普通 UDP 应用，也没有赋予源端口传统应用端点的含义。

“流”由封装器本地决定

RFC 7510 把源端口定义为封装器生成的 16 位熵值，用于识别一个流。但文档紧接着规定：什么算一个流，由封装器本地决定；如何计算熵，也不在标准范围内。

这意味着，同样合规的实现可以选用不同输入。有的实现会散列内层地址和端口，有的只能使用在某个转发阶段已经可见的字段。接收侧仅凭外层源端口，无法反推出一个具有全球一致含义的客户、租户或应用。

如果隧道根本不需要熵，同一流中的报文仍应使用随机选定的固定值，目的是避免报文被不断分到不同路径而乱序。这里的“稳定”属于路径选择，不属于身份。它说明报文最好留在一个桶里，不说明两端建立了可认证关系。

标准还给出动态或私有端口范围的构造方法：计算 14 位哈希，再把最高两位设为二进制 11，从而落在 49152 至 65535。这样既保留足够差异，又避开用于标识特定应用和协议的较低端口。

然而，16 位空间依然有限，算法又是本地的。不同隧道、不同流甚至不同设备都可能重复使用同一数值。把它写进客户归属、计费或安全策略，相当于给一个路径提示强加标准从未承诺的权力。

6635 只说明里面是什么

目的端口的作用更固定。IANA 服务名称与端口号登记表 将 UDP 6635 记录为 mpls-udp。收到这一端口的、已经配置好的解封装端点，可以据此把 UDP 负载按 MPLS 报文处理。

这项登记回答的是解析问题，不是授权问题。它没有证明源地址背后的主体是谁，没有说明对方是否有权使用隧道，也没有保证内部标签在本地标签空间有效。全球共同认可一个负载类型，并不等于全球共同认可一个发送者。

RFC 7510 还要求封装器事先知道目标具备 MPLS-in-UDP 解封装能力。这个知识可以来自手工配置或动态通告，具体方法由别的机制决定。也就是说，能力关系先于报文建立；一份发往 6635 的数据报本身不是能力协商。

防火墙规则若只写“允许 UDP/6635”，便把负载标识错当成通行证。更稳健的做法是把许可绑定到预期的源、目的、接口、运营域、配置状态以及必要的密钥或信令，再在这段明确关系里允许 6635。

里面的标签仍有自己的边界

解封装之后，接收端面对的仍是 MPLS 标签栈。RFC 3032 定义标签栈编码；由 Eric Rosen、Arun Viswanathan 与 Ross Callon 共同撰写的 RFC 3031 则描述 MPLS 架构，把标签称为用于转发的、短而定长、具有本地意义的标识。

“本地意义”十分关键。顶层标签要在分配它的转发语境中解释。即使 UDP 目的端口是全球登记的，内部标签也不会因此获得全球含义。解封装器必须进入正确标签空间，并遵循相应的上游或下游分配规则。

MPLS 系统里还存在另一种熵。RFC 6790 在标签栈内部定义熵标签指示符和熵标签；RFC 7510 则把熵放在外层 UDP 源端口，让 IP 设备能够看见。两者所在层次不同，服务的转发设备也可能不同。

它们都不负责认证。熵标签不会因为更靠近 MPLS 而成为用户身份，UDP 源端口也不会因为长得像传输层字段就成为会话凭证。信号放在哪里，决定谁能使用它；并不决定谁有权行动。

校验和不是免费的优化

RFC 7510 对 IPv4 和 IPv6 采取不同默认值。IPv4 封装出于性能或实现原因，建议把 UDP 校验和设为零，但文档也提醒，某些 VPN 的标签损坏可能造成严重后果。IPv6 默认必须使用校验和。

RFC 6935 为隧道打开了受限的 IPv6 零校验和模式；RFC 6936 则列出严格适用条件，包括受控环境、对损坏率的认识以及运营者对剩余风险的明确接受。路径上的中间盒如果丢弃 IPv6 零校验和报文，整个隧道会形成黑洞。

后来的 RFC 8085 把源端口熵放进更广泛的 UDP 使用指导。它提醒设计者不能只借用 UDP 便于哈希的一面，还要承担校验和、中间盒与拥塞行为的成本。

取消一项计算可能提高吞吐，但未被发现的损坏不会凭空消失。熵值也不能补偿完整性风险。路径分得再均匀，损坏的报文仍然是损坏的报文。

安全来自边界，不来自端口号

RFC 7510 限定 MPLS-in-UDP 只能部署在单一运营者网络，或相邻且相互合作、能够管理拥塞的多个运营者网络中。它不是一项面向开放互联网、可以忽略拥塞控制的任意隧道。过滤器还应防止报文因错误或误配置逃出预定范围。

这个限制既是拓扑边界，也是责任边界。在受控域内，相关运营者能够协调容量、准入、监测和故障处理。跨越开放互联网时，无拥塞约束的 UDP 隧道可能把成本转嫁给无关网络。封装的便利无法替代合作关系。

安全部分同样明确：MPLS-in-UDP 本身不能保证完整性、隐私，也不能认证封装器。需要这些属性时，文档讨论 IPsec 与 DTLS。IANA 将 6636 登记为带 DTLS 的 MPLS-in-UDP，但端口号依旧只是机制的一部分；密钥、对端与策略仍需另行建立。

完整控制边界至少包括隧道端点地址、能力配置或信令、获准运营域、报文过滤、拥塞管理、校验和策略、标签空间以及所需的完整性或认证层。6635 在这条边界内很有用，却不能代替这条边界。

共享标准记录中的 Ross Callon

Ross Callon 的 IETF Datatracker 资料页 列出八份 RFC，其中包括 RFC 3031 与 RFC 7510。公开记录覆盖 OSI 地址分配、IPv6 过渡、MPLS 和运营商 VPN 等工作，为他的技术作者身份提供了可核查背景。

这并不意味着某份标准属于一个人。RFC 7510 有五位作者，并经过 IETF 共识程序；RFC 3031 有三位作者，背后还有更庞大的标准与实现共同体。实现者决定哈希字段，运营者决定部署边界，IANA 维护端口登记。人物文章必须保留这些分工。

Callon 的公开记录仍提供了一条值得观察的连续线索：RFC 3031 界定本地标签的转发含义，RFC 7510 则把标签栈放进一个便于 IP 设备分流的外层包装。两项机制都只有在字段不越权时才可靠。

源端口可以只代表熵，登记端口可以只代表负载类型，标签可以只代表本地转发上下文。把不同真相留给不同证据面，并不是系统不完整；恰恰是互操作得以成立的条件。

证据边界

公开来源能够证明 RFC 7510 的格式、适用范围、校验和与安全要求，IANA 的端口登记，MPLS 标签标准，以及 Ross Callon 的共同作者记录。它们不能证明当前部署数量、某家厂商的具体算法、一次由端口熵碰撞导致的真实事故，或 Callon 当前拥有任何机构权力。

“不应把端口熵当作身份”是依据标准字段语义与安全限制提出的编辑分析，不是对某起事件的报道。本文也没有断言外层 UDP 熵与标签栈内部的 MPLS 熵标签可以互换，或其中一种在任何环境下都更优。

资料来源