摘要

  • IPv6 流标签位于固定首部中，长度为 20 比特；它可与源、目的地址组成三字段分类键，无须先找到传输层端口。
  • 标签必须在同一流内稳定、在不同流之间尽量均匀，却既不唯一也不受保护；碰撞和伪造都属于明确边界。
  • RFC 6437 重塑了早期模型，RFC 6438 与 RFC 7098 则分别说明了隧道路径分配和三、四层服务器负载分配的有限用途。

隧道外层为何需要第三种材料

ECMP 或链路聚合通常需要从报文中取值并做哈希。在 IP-in-IPv6 隧道中，许多用户流共享一对外层地址；只使用这两个地址时，所有流可能被“极化”到同一成员。RFC 6438 给出的做法，是让发送端隧道端点根据内部二元组或五元组推导外层流标签：同一内部流保持同一值，不同流则尽量产生不同值。

中间路由器由此得到固定位置的哈希材料，却不必理解内部会话。偶尔发生碰撞并不违背模型。两个用户流若取得相同标签，就接受相同的标签式处理；这不表示二者是同一个流，也不保证每个流拥有独占路径。

这种安排体现了流标签的尺度。它解决的是“怎样保持处理一致”而非“流究竟是谁”。二十比特没有足够空间承诺全局唯一，协议也没有作出这种承诺。

零、稳定与分布

流标签为零，只表示报文未被标注。对于一个流，源端应为所有报文填写同一个非零值；在许多流之间，取值应接近离散均匀分布，并且难以预测。把五元组哈希成二十比特，或以少量源端状态作伪随机分配，都是规范举出的例子，而非强制算法。顺序递增不受推荐，因为它既容易预测，也不利于分布。

“流”不必与一条传输连接一一对应。不过 RFC 6437 建议，没有关联的传输连接或应用数据流通常应分属不同流。若相同地址之间的两个并发流发生标签碰撞，标签式分类器便无法单靠标签区分它们。

非零标签一旦写入，预期应原样到达。转发设备可以替源端给零标签赋值，但此能力必须可配置且默认关闭；规范仍偏好源端填写。这样做既承认有些源端不会行动，也限制中间网络随意改写分类材料。

固定位置比传输层语义更容易取得

端口常被用于负载分配，但 IPv6 报文并不保证中间设备总能方便地找到端口。非首片分片可能没有端口，扩展首部可能增加解析成本，加密也可能让传输信息不可见。流标签始终位于固定 IPv6 首部中。它没有还原端口或载荷含义，只提供另一组可直接读取的输入。

RFC 7098 把这一性质用于服务器场。三、四层负载均衡器可将“源地址加流标签”，或“目的地址、源地址加流标签”作为会话键。无状态设备对键做哈希，使同一流的报文落到同一服务器；有状态设备保存键与服务器的对应关系。标签为零的报文仍走传统的传输首部处理路径。

保存状态也不能消除歧义。若相同地址之间的新传输会话复用了旧标签，单凭该键就无法识别它是新会话。流标签能够支撑亲和性，却不知道应用会话何时结束、何时重建。

从 RFC 3697 到 RFC 6437

RFC 6437 取代 RFC 3697 时，重点转向鼓励非零值、无状态生成和近似均匀分布，同时保留非零标签不得沿途修改的规则，并为默认关闭的零标签代填留下受控空间。

从历史上看，这是一种通过减少语义负担来提高可用性的调整：源端负责给出稳定、分散的材料，网络把它作为哈希输入之一，而不是建立一个需要理解应用的状态体系。这是依据规范机制得出的编辑分析，并不等于所有网络都已经如此部署。

本包的三个来源没有提供当前采用率、厂商支持清单、性能基准或普遍收益数据。因此，本文只能说明协议允许什么、限制在哪里，不能断言今天有多少流标签非零或某种设备必然获得多少提升。

来源