IPv6 流标签在 RFC1883 中作为 20 位字段引入，原意是支持基于流的转发优化，但硬件转发发展使其在核心路由中失去优势。RFC6294 与 RFC6437 重新定义其用途，指出其在 ECMP 哈希中作为熵源虽常见，却存在被滥用的风险。
早期设计与演变：
RFC1883 于 1995 年发布，将流标签作为 IPv6 头部新增字段，要求同一流的所有数据包保持相同源地址、目的地址、优先级与流标签。当时认为流缓存转发可优化最长前缀匹配开销，路由器可“机会主义”建立流状态。然而随着内容可寻址内存实现的最长前缀匹配取代软件转发，维护流状态的扩展性劣势显现，流转发仅保留在防火墙、NAT/PAT 等必须维持流状态的节点。
哈希熵源的局限与流标签引入：
现代路由器按包查找下一跳，ECMP 需要足够熵源实现负载均衡。仅用 IPv4 的源 IP、目的 IP、协议号、源端口、目的端口五元组哈希，在双向通信中源目的固定导致熵不足。IPv6 同样面临此问题，RFC6294 提及可将流标签作为哈希分量补充熵，但这假设发送端正确设置流标签。
滥用场景与规避建议：
当发送端将流标签设为零或固定值、或不同流复用同一标签时，引入流标签反而降低哈希熵，导致 ECMP 分布失衡。RFC6437 要求发送端为每个流分配唯一标签，但合规性无法在网络侧强制验证。工程实践中，若无法确认上游主机正确实现 RFC6437，应在哈希算法中排除流标签字段，改用五元组或扩展头部字段作为熵源。
对运维工程师而言，关键在于验证流量源端是否遵循 RFC6437 分配唯一流标签。在无法保证合规的骨干网或跨域场景中，直接在哈希中使用流标签会引入确定性偏差，建议在负载均衡设备与聚合链路配置中显式禁用该字段，转而依赖可控的传输层端口信息。
原文: APNIC Blog（2018-01-11）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog