RFC6438：Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels，November 2011
梗概
IPv6 流标签对其使用有一定的限制。本文档描述了在通过等价多路径路由和链路聚合使用流标签进行负载均衡时，这些限制如何应用，特别是对于 IP-in-IPv6 隧道流量。
本备忘录的状态
这是一份 Internet 标准跟踪文档。
本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 5741 的第 2 节。
有关本文档当前状态、勘误表以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc6438。
版权声明
版权所有 (c) 2011 IETF Trust 和文件作者。版权所有。
本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文件发布之日有效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且按照简化 BSD 许可中的说明在不保证的情况下提供。
1、 简介
当路由系统知道相同两个节点之间的多条网络路径同样好（在容量和延迟方面）时，可能希望在它们之间共享流量。两种这样的技术被称为等价多路径 (equal cost multipath，ECMP) 路由和链路聚合 (link aggregation，LAG) [IEEE802.1AX]。当然，有许多可能的方法来解决这个问题，但需要实现某些目标：
* 在每条路径上保持大致相等的流量份额。
（在某些情况下，多条路径可能不都具有相同的容量，目标可能是适当加权的流量份额，而不是相等的份额。这会影响负载分担算法，但不会改变参数。）
* 尽量减少或避免个别流量的无序交付。
* 当队列非空时，最小化任何路径上的空闲时间。
这些目标之间存在一些冲突：例如，严格避免空闲时间可能会导致在空闲路径上发送的小数据包超过来自同一流的更大数据包，从而导致无序传递。
ECMP 或 LAG 的一种轻量级方法是这样的：如果有 N 个同样好的路径可供选择，则从每个数据包报文头中的一组定义的字段中形成modulo(N)的哈希 [RFC2991]，这些字段肯定具有相同的值在整个流的持续时间内，并使用生成的输出哈希值来选择特定路径。如果选择散列函数以使输出值具有均匀的统计分布，则此方法将在 N 条路径之间大致平均地共享流量。如果散列输入中包含的头部字段一致，则来自给定流的所有数据包都将生成相同的散列输出值，因此不会发生乱序传递。假设涉及大量唯一流，该方法也很可能避免空闲时间，因为每个链路的队列将保持非空。
1.1、 为哈希输入选择 IP 报文头字段
在本文档的其余部分，我们将使用术语“流”来表示可以由源 IP 地址和目标 IP 地址单独 {2-tuple} 或源 IP 地址、目标 IP 地址、协议标识的数据包序列号、源端口号和目标端口号 {5-tuple}。应该注意，后者在 [RFC2474] 中更具体地称为“微流”，但该术语并未与 [RFC3697] 中的流标签一起使用。
那么，问题是哪些报文头字段用于标识流并用作模（N）散列算法的输入密钥。路由一般流量时的一个常见选择是简单地使用源 IP 地址和目标 IP 地址的哈希，即 2 元组。这对于避免无序交付是必要且足够的，并且由于在网络核心中发现的来源和目的地多种多样，通常在统计上足以平均分配负载。在实践中，许多实现使用 5 元组 {dest addr, source addr, protocol, dest port, source port} 作为散列函数的输入密钥，以最大化在等价路径上平均共享流量的概率。但是，将传输层信息作为散列的输入密钥包含在 IP 片段 [RFC2991] 或加密流量中可能是个问题。在散列输入中包括协议和端口号，总计 40 位，使得散列的计算成本略高，但由于临时端口的可变性质，确实改善了散列分布。临时端口号分布得很好 [Lee10]，通常会贡献 16 个可变位。然而，在 IPv6 的情况下，由于 next-header 的位置可变和长度可变，传输层信息不便于提取；所有实现都必须能够跳过下一个报文头，即使它们很少出现在实际流量中。事实上，[RFC2460] 暗示除了逐跳选项之外的下一个报文头通常不会被网络中的中间节点检查。这种情况可能对某些硬件实现具有挑战性，增加了网络设备供应商可能会牺牲从 IPv6 报文头中提取的字段长度的可能性。
值得注意的是，通用路由封装 (Generic Routing Encapsulation，GRE) 报文头 [RFC2784] 的可能存在以及该报文头中可能存在的 GRE 密钥对可能存在的 IPv6 扩展报文头产生了类似的挑战；任何使报文头分析复杂化的事情都是不可取的。
在 IP-in-IP 隧道方案中情况有所不同。识别隧道内的流更为复杂，特别是因为几乎所有硬件都只能根据最外层 IP 报文头中包含的信息来识别流。假设从多个来源到多个目的地的流量聚合在从隧道端点 (tunnel endpoint，TEP) A 到 TEP B 的单个 IP-in-IP 隧道中（见图）。那么形成隧道的所有数据包都有外部源地址A和外部目标地址B。很可能它们也有相同的端口和协议号。如果路由器 R1 和 R2 之间存在多条路径，并且应用 ECMP 或 LAG 选择特定路径，则 2 元组或 5 元组（及其哈希）将保持不变，不会实现负载分担，即会发生极化。如果来自一个或少量隧道的流量比例很高，由于部分极化，流量将不会按预期在 R1 和 R2 之间的路径上分配。（MPLS [MPLS-LABEL] 会出现相关问题。）
如上所述，对于 IPv6，由于下一个报文头放置，提取 5 元组非常不方便。因此出现的问题是，IPv6 数据包中的 20 位流标签是否适合用作 ECMP 或 LAG 哈希算法的输入，尤其是在内部数据包报文头不可访问的隧道的情况下。如果可以使用流标签代替 5 元组中的端口号和协议号，则可以简化实现。
1.2、 流标签规则
流标签由 [RFC2460] 保留为实验性的，但由 [RFC3697] 更好地定义。我们引用了该 RFC 中的三个规则：
1. “源设置的流标签值必须原封不动地传递给目标节点。”
2. “IPv6 节点不得假定源节点分配的流标签值的任何数学或其他属性。”
3. “路由器性能不应该依赖于流标签值的分布。特别是，流标签位单独为哈希密钥提供了较差的材料。”
这些规则，尤其是最后一条规则，导致设计人员在使用流标签来支持 ECMP 或 LAG 时犹豫不决。事实是，今天大多数节点在流标签中设置零值，第一条规则明确禁止路由系统在数据包离开源节点后更改流标签。考虑到正常的 IPv6 流量，流标签通常为零的事实意味着它不会为 ECMP 或 LAG 散列增加任何值，但它也不会对散列值的分布造成任何损害。
但是，在 IP-in-IPv6 隧道的情况下，TEP 本身就是外部数据包的源节点。因此，TEP 可以在它发送到隧道的数据包的外部 IPv6 报文头中自由设置流标签。
上面引用的后两条规则需要在 [RFC3697] 的上下文中看到，它假定以某种方式使用流标签的路由器将参与某种建立流状态的方法：“为了启用特定于流的处理，需要在从源到目的地的路径上的所有或部分 IPv6 节点上建立流状态。” RFC 或许应该明确表示，参与流状态建立的路由器可以依赖结果流标签值的属性，而无需进一步发出信号。如果路由器知道这些属性，则规则 2 是无关紧要的，它可以选择偏离规则 3。
在上面概述的隧道情况下，路由器 R1 和 R2 可以依赖由 TEP A 和 TEP B 设置的流标签，这些标签是通过已知方法分配的。这允许 ECMP 或 LAG 方法基于与 [RFC3697] 一致的流标签，而不管非隧道流量是否携带非零流标签值。
IETF 最近修订了 RFC 3697 [RFC6437]。该修订与本文件完全兼容，并消除了上述三项规则引起的担忧。因此，本规范适用于 RFC 3697 和 RFC 6437。
2、 规范符号
本文档中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“可以”和“可选”是按照 [RFC2119] 中的描述进行解释。
3、 指导方针
我们假设支持 ECMP 或 LAG 的路由器（上图中的 R1 和 R2）不知道它们正在处理隧道流量。如果希望在上述隧道场景中的 ECMP 或 LAG 哈希中包含 IPv6 流标签，则适用以下准则：
A. 内部数据包必须封装在外部 IPv6 数据包中，其源和目标地址是隧道端点 (TEP) 的地址。
B. 外部数据包中的流标签应该由发送 TEP 设置为符合 [RFC6437] 的 20 位值。相同的流标签值必须用于单个用户流中的所有数据包，由内部数据包的 IP 头字段确定。
C. 为实现这一点，发送 TEP 必须在确定所有数据包应进入给定隧道后将所有数据包分类为流，然后将相关流标签写入外部 IPv6 报文头。发送 TEP 可以最简单地通过其 {destination, source} 地址 2 元组或其 5 元组 {dest addr, source addr, protocol, dest port, source port} 来识别用户流。目前，使用内部数据包的 {dest addr, source addr, flow label} 三元组没有什么意义，但这样做是一个面向未来的选择。n 元组的选择是发送 TEP 中的一种实现选择。
* 如 [RFC6437] 中所述，流标签值应从均匀分布中选择。这些值将适合作为负载均衡哈希函数的输入，并且恶意第三方很难预测。
* 发送 TEP 可以通过使用内部 IP 头的 2 元组或 5 元组的合适的 20 位散列作为流标签值来执行无状态流标签分配。
* 如果内部数据包是一个 IPv6 数据包，它的流标签值也可以包含在这个散列中。
* 这种无状态方法创建了两个不同用户流散列到相同流标签的小概率。由于 [RFC6437] 允许源（在这种情况下为 TEP）定义它希望作为单个流的任何数据包集，因此偶尔将两个用户流标记为通过隧道的单个流是可以接受的。
D. 在执行负载分配的中间路由器上，用于确定 ECMP 和/或 LAG 中指向下一跳的传出组件链路的散列算法必须至少包括 3 元组 {dest addr, source addr, flow label} 和还可以包括 5 元组的其余组件。无论流量仅是隧道流量还是正常流量和隧道流量的混合，这都适用。
* 中间 IPv6 路由器可能会遇到隧道流量和普通 IPv6 流量的混合。因此，设计还应包括 {protocol, dest port, source port} 作为 ECMP 和/或 LAG 哈希算法的输入密钥，以为流标签设置为零的流提供额外的熵，包括非隧道流量流。
E. 网络中的各个节点可以自由实施符合本规范的不同算法，而不会影响网络的互操作性或功能。
F. 需要调整操作、管理和维护 (Operations, Administration, and Maintenance，OAM) 技术以根据流标签管理 ECMP 和 LAG。这些问题与 MPLS [RFC4379] 和伪线 [RFC6391] 出现的问题类似。
4、 安全考虑
流标签不受任何保护，并且可以被路径上的攻击者伪造。但是，预计隧道端点和 ECMP 或 LAG 路径将成为托管基础设施的一部分，该基础设施可以很好地防止路径上的攻击（例如，通过在两个隧道端点之间使用 IPsec）。如果使用明显的伪随机和不可预测的值，则偏离路径的攻击者不太可能猜测有效的流标签。在任何一种情况下，攻击者对 ECMP 或 LAG 所能做的最糟糕的事情就是尝试选择性地使特定路径过载。如需进一步讨论，请参阅 [RFC6437]。
5、 致谢
该文件由 IETF 76 的走廊讨论提出。Joel Halpern 对早期版本提出了重要意见。我们感谢 Qinwen Hu 对流标签的一般性讨论。Miguel Garcia、Brian Haberman、Sheng Jiang、Thomas Narten、Jarno Rajahalme、Brian Weis 等人提出了宝贵意见和贡献。
6、 参考文献
6.1、 规范性参考
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011.
6.2、 参考资料
[IEEE802.1AX] Institute of Electrical and Electronics Engineers, "Link Aggregation", IEEE Standard 802.1AX-2008, 2008. [Lee10] Lee, D., Carpenter, B., and N. Brownlee, "Observations of UDP to TCP Ratio and Port Numbers", Fifth International Conference on Internet Monitoring and Protection ICIMP 2010, May 2010. [MPLS-LABEL] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", Work in Progress, May 2011. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011.
