RFC6437：IPv6 Flow Label Specification，November 2011
摘要
本文件规定了IPv6流标签字段以及IPv6节点标记流、IPv6节点转发标记数据包和流状态建立方法的最低要求。即使作为流标签可能用途的示例提及，特定用例的更详细要求也不在本文档的范围内。
使用流标签字段可以仅基于固定位置的IPv6主标头字段实现高效的IPv6流分类。
关于本备忘
这是一份互联网标准跟踪文件。
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经得到了公众的审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
有关本文件的当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6437。
版权声明
版权所有（c）2011 IETF信托基金和文件作者。版权所有。
本文件受BCP 78和IETF信托基金有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包括简化的BSD许可证文本，如第4节所述。如简化BSD许可证所述，不提供任何担保。
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献的材料。控制某些材料版权的人可能没有授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除非将其格式化为RFC或将其翻译为英语以外的语言。
1、 导言
从网络层的观点来看，流是从特定源发送到节点希望标记为流的特定单播、任播或组播目的地的数据包序列。从上层的观点来看，流可以由特定传输连接或媒体流的一个方向上的所有数据包组成。但是，流不一定是1:1映射到传输连接的。
传统上，流分类器基于源地址、目的地址、源端口、目的端口和传输协议类型的5元组。然而，由于分片或加密，其中一些字段可能不可用，或者通过IPv6扩展头链定位它们可能效率低下。此外，如果分类器仅依赖于IP层头，那么以后引入替代传输层协议将更容易。
使用流标签、源地址和目标地址字段的三元组可以实现高效的IPv6流分类，其中只使用固定位置的IPv6主标头字段。
流标签可以在无状态和有状态的场景中使用。无状态场景是指任何以任何方式处理流标签的节点都不需要在处理数据包之前或之后存储关于流的任何信息。有状态场景是指处理流标签值的节点需要存储有关流的信息，包括流标签值。有状态场景可能还需要一种信令机制来通知下游节点流标签正在以某种方式使用，并在网络中建立流状态。例如，RSVP[RFC2205]和通用互联网信令传输（General Internet Signaling Transport，GIST）[RFC5971]可以发送流标签值的信号。
流标签可以最简单地用于无状态场景。本规范主要关注无状态模型，以及如何将其用作默认机制。有状态模型、信令、特定流状态建立方法及其相关服务模型的详细信息不在本规范的范围内。第4节阐述了有状态模型的基本要求。
IPv6流支持的最低级别包括标记流。具体目标是支持并鼓励在各种形式的无状态负载分配中使用流标签，尤其是在等价多路径（Equal Cost Multi-Path，ECMP）和/或链路聚合组（Link Aggregation Group，LAG）路径中。ECMP和LAG是将多个物理链路连接在一起的方法，用于获取承载大于单个物理链路带宽的提供负载所需的容量。更多细节见另一份文件[RFC6438]。IPv6源节点应该能够标记已知流（例如TCP连接和应用程序流），即使节点本身不需要任何特定于流的处理。第3节给出了无状态流标记的节点要求。
本文件取代[RFC3697]和[RFC2460]的第6节和附录A。[RFC6436]中记录了所做更改的基本原理。本文件还包括对[RFC2205]中有关流量标签的更正。
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的描述进行解释。
2、 IPv6流标签规范
IPv6报头[RFC2460]中的20位流标签字段由节点用于标记流的数据包。零流标签用于指示尚未标记的数据包。数据包分类器可以使用流标签、源地址和目标地址字段的三元组来识别特定数据包所属的流。数据包由能够以无状态方式处理或已设置为流特定状态的节点以流特定方式处理。具体处理的性质和建立流状态的方法不在本规范的范围内。
流标签值的选择应确保其位表现出高度的可变性，使其适合用作负载分配方案中使用的哈希函数输入的一部分。同时，第三方不太可能猜到流标签来源将选择的下一个值。
在统计学中，离散均匀分布被定义为一种概率分布，在这种分布中，在给定的等间距值范围内（例如一系列整数）的每个值都有可能被选为下一个值。这种分布中的值表现出可变性和不可用性。因此，如第3节所述，最好采用离散均匀分布的近似值作为流量标签值的来源。有意地，对分布或用于实现这种分布的方法没有精确的数学要求。
一旦设置为非零值，则流标签将原封不动地传递到目标节点。转发节点必须保持非零流量标签值不变，或仅出于第6.1节中所述的强制操作安全原因对其进行更改。
无法验证流量标签是否在途中被修改，或者是否属于均匀分布。因此，互联网范围内的任何机制都不能在数学上依赖于未修改且均匀分布的流标签；他们有“尽力而为”的品质。实施者应该知道，流标签是一个未受保护的字段，可能是在途中意外或故意更改的（参见第6节）。这导致了以下正式规则：
路由器和负载分配器等转发节点不能仅依赖于均匀分布的流标签值。在诸如用于负载分配的散列键之类的任何使用中，流标签位必须至少与来自分组内的其他源的位组合，以便为每个流产生恒定的散列值，并在流之间产生散列值的适当分布。通常，使用的其他字段将是通常的5元组的部分或全部组件。这样，即使流标签值分布不均，负载分布仍会发生。
虽然下面建议使用均匀分布的流量标签值，这对负载分配总是有帮助的，但在一般情况下假设它们的存在是不安全的，即使流量标签值为零，用例也需要工作。
一般来说，数据包流不应该被重新排序，流标签字段的使用不会影响这一点。特别是，流标签值为零并不意味着可以接受重新排序。
3、 无状态场景中的流标签要求
本节定义了在流标签使用的无状态场景中设置流标签值的方法的最低要求。
要启用基于流标签的分类，源节点应将每个不相关的传输连接和应用程序数据流分配给新流。用于此目的的流的典型定义是任何携带相同5元组{dest addr，source addr，protocol，dest port，source port}的数据包集。应该注意的是，源节点总是能够方便、高效地访问这个5元组，对于随后转发数据包的节点来说，情况并非总是如此。
流量标签值应均匀分布，以辅助荷载分布。因此，建议源主机通过将给定流的所有数据包的流标签字段设置为从离散均匀分布的近似值中选择的相同值来支持流标签。可以使用有状态和无状态的赋值方法，但强制使用算法超出了本规范的范围。该算法应确保生成的流标签值以高概率唯一。然而，如果两个同时发生的流碰巧被分配了相同的流标签值，并且具有相同的源地址和目标地址，这仅仅意味着它们将在整个网络中接受相同的流标签处理。只要这是一个低概率事件，它就不会显著影响负荷分布。
一种可能的无状态算法是使用IP数据包5元组中合适的20位散列值。附录A中描述了一个简单的哈希函数示例。
另一种方法是使用伪随机数生成器为给定的传输会话分配流标签值；这种方法需要记录与每个传输套接字相关联的流标签，从而在源节点保持最小的局部状态。
从外部来看，这两种方法中的任何一种都会产生似乎是均匀分布和伪随机的值。
不建议使用按顺序分配流标签的实现，因为这样路径上的观察者就可以很容易地猜测下一个值。
未以其他方式设置流标签的源节点必须将其值设置为零。
转发到达包中的流标签值为零的流的节点可以更改流标签值。在这种情况下，建议转发节点将流的流标签字段设置为均匀分布的值，如刚刚针对源节点所述。
与设置流标签的源主机相同的注意事项；特别是，首选情况是流由5元组定义。然而，在某些情况下，所有数据包的完整5元组不容易被转发节点使用，尤其是对于分片数据包。在这种情况下，流可以由较少的IPv6头字段定义，通常只使用2元组{dest addr，source addr}。实施者可以选择其他方法，例如：
*转发节点可能会尽可能使用5元组来定义流，但如果完整的5元组不可用，则使用2元组。在这种情况下，属于同一传输会话的未分段和分段数据包将接收不同的流标签值，从而改变基于流标签的后续负载分布的效果。
*在所有情况下，转发节点都可以使用2元组来定义流。在这种情况下，后续的负载分配将仅基于IP地址。
在转发节点中设置流标签的选项，如果实现，可能在第一跳或入口路由器中很有价值。即使它们采用了流标识和标签分配的无状态方法，也可能会给每个数据包带来相当大的处理负载。但是，它不会干扰主机到路由器的负载分担[RFC4311]。它需要在网络管理员的控制下，以避免不必要的处理负载和任何其他不良影响。因此，它必须是一个可配置选项，默认情况下处于禁用状态。
上述规则结合在一起，允许给定的网络包括代表未设置流标签的主机设置流标签的路由器。所描述的复杂性解释了为什么主要建议源主机设置标签。
4、 流状态建立要求
设置流标签的节点还可以参与流状态建立方法，该方法导致将特定处理分配给特定流，可能包括信令。任何此类方法都不得干扰参与上述无状态场景的节点。因此，根据有状态方案设置流标签值的任何节点必须选择符合本规范第3节的标签。本文件不讨论更多细节。
5、 对RFC 2205的必要修正
[RFC2460]将流量标签字段的大小从24位减少到20位。[RFC2205]第a.9节中对24位流量标签字段的引用相应更新。
6、 安全考虑
本节考虑使用流量标签引起的安全问题，包括拒绝服务攻击的可能性和未经授权流量窃取服务的相关可能性（第6.2节）。第6.3节介绍了在IPsec存在的情况下使用流标签，包括其与IPsec隧道模式和其他隧道协议的交互。我们还注意到，通过检查未加密的流标签，可以通过揭示底层通信的某些结构来进行某种形式的流量分析。即使流标签是加密的，它作为一个固定位置的常数值存在可能有助于流量分析和密码分析。
即使正在使用IPsec身份验证[RFC4302]，流标签也不会受到任何保护，因此它可能会被路径上的攻击者伪造。建议实施者，任何对流标签值的中途更改都是无法检测到的。另一方面，攻击者无法轻易猜出均匀分布的伪随机流标签；请参阅[LABEL-SEC]了解更多讨论。如第3节所述，如果使用散列算法，则应包括一个使流标签值非常难以预测的步骤[RFC4086]，即使知道所使用的算法也是如此。
6.1、 隐蔽渠道风险
流标签可以用作隐蔽数据通道，因为表面上的伪随机流标签值实际上可能包含隐蔽数据[NSA]。例如，这可以通过使用一系列本来无害的UDP数据包来实现，这些数据包的流标签值构成了一条隐蔽消息，或者通过选择TCP会话来在连续数据包的流标签中携带隐蔽消息。这两种情况都可能被认为是可疑的——第一种是因为孤立的UDP数据包通常不会有非零流标签，第二种是因为给定TCP会话中的流标签值都应该相等。然而，其他方法，比如选择偶尔数据包的流标签，可能很难检测到。
在隐蔽通道风险被视为重大的情况下，唯一确定的防御措施是防火墙重写非零流量标签。这将是对规则的例外违反，即一旦设置为非零值，就不能更改流标签。为了保持负载分配能力，这样的防火墙应该按照转发节点描述的方法重写标签（参见第3节），就像传入的标签值为零一样，并且不能将非零流量标签设置为零。然而，这种行为是不可取的，因为（如第3节所讨论的）只有源节点可以直接访问完整的5元组。
6.2、 欺骗和拒绝服务
由于网络流量到特定于流的处理的映射是由IPv6报头的IP地址和流标签值触发的，因此对手可能能够通过修改IPv6报头或通过注入带有虚假地址和/或标签的包来获得网络不打算提供的服务类别。对这种威胁的具体分析只适用于特定的有状态方法，即发送信号和使用流标签，这超出了本文档的范围。显然，当指定任何此类方法时，都需要进行全面分析，但一般来说，如果没有一些外部保证手段，网络不应基于流标签做出资源分配决策。
在无状态模型中，当修改或注入的流量耗尽可用于转发该流量和其他流量流的资源时，可能会发生拒绝服务攻击[RFC4732]。如果对给定的流标签（或一组流标签）进行拒绝服务攻击，则包含受影响流标签的流量很可能会遇到比尽力而为网络性能更差的情况。
请注意，由于节点对IP头的处理通常未经验证，因此不能保证节点发送的流标签是根据本文档中的建议设置的。专门针对流量标签处理的中间人或注入式流量拒绝服务攻击将涉及设置异常流量标签。例如，攻击者可以将到达给定路由器的所有流标签设置为相同的任意非零值，或者可以执行流标签值的快速循环，以便给定流的每个数据包都具有不同的值。这两种攻击都会导致无状态负载分配算法性能不佳，并导致有状态分类器行为不正确。因此，无状态分类器不应单独使用流标签来控制负载分布，而有状态分类器应包括检测和忽略可疑流标签值的显式方法。
由于流由流标签的三元组以及源地址和目标地址标识，因此流标签引入的拒绝服务风险与地址欺骗导致的拒绝服务风险密切相关。能够伪造地址的对手也可能伪造标签，反之亦然。
有两个具有不同属性的问题：仅欺骗流标签和欺骗整个3元组，包括源地址和目标地址。
前者可以在使用或传输正确源地址的节点内完成。欺骗流标签的能力通常意味着能够伪造地址，但在许多情况下，欺骗者可能对欺骗地址不感兴趣，尤其是当欺骗者的目标是窃取服务而不是拒绝服务时。
后者可以由不受入口过滤[RFC2827]约束的主机或中间路由器完成。由于其特性，这通常仅适用于拒绝服务。在没有入口过滤的情况下，几乎任何第三方都可以发起此类攻击。
在存在入口过滤的情况下，只有在中间系统（如路由器）受损或通过某种其他形式的中间人攻击时，才能在源于零标签的数据包上伪造非零流标签，或修改或清除标签。
6.3、 IPsec和隧道交互
[RFC4301]、[RFC4302]和[RFC4303]中定义的IPsec协议在其任何加密计算中不包括IPv6报头的流标签（在隧道模式下，不包括外部IPv6报头的流标签）。因此，网络节点修改流标签对IPsec端到端安全性没有影响，因为它不会导致任何IPsec完整性检查失败。因此，IPsec不会针对对手修改流标签（即中间人攻击）提供任何防御。
IPsec隧道模式为封装的IP头的流标签提供安全性。隧道模式IPsec数据包包含两个IP报头：由隧道入口节点提供的外部报头和由数据包原始源提供的封装内部报头。当IPsec隧道通过执行流分类的节点时，中间网络节点对外部报头中的流标签进行操作。在隧道出口节点，IPsec处理包括移除外部报头和使用内部报头转发数据包（如果需要）。IPsec协议要求内部报头的流标签不被此解除封装处理更改，以确保对标签的修改不能用于跨IPsec隧道端点发起欺骗或拒绝服务攻击。本文件未对该要求进行任何更改；实际上，它禁止更改流标签。
当IPsec隧道出口解除封装处理包括对封装的分组进行足够强的密码完整性检查（其中充分性由本地安全策略确定）时，隧道出口节点可以安全地假定内部报头中的流标签具有与隧道入口节点相同的值。
该分析及其含义适用于任何执行完整性检查的隧道协议。当然，在封装IPv6标头中设置的任何流标签都会受到上一节所述风险的影响。
6.4、 安全过滤交互
如果出于安全原因，在防火墙或过滤路由器等节点上认为有必要进行基于经过IP报头的报头的数据包过滤，则流标签不会消除这种需要。
7、 与RFC 3697的差异
本规范与其前身[RFC3697]之间的主要区别如下：
本规范鼓励使用非零流量标签值，并明确定义了如何设置非零值。
本规范鼓励使用具有均匀分布的流标签值的无状态模型。
本规范未指定有状态模型的任何细节。
本规范保留了在路由过程中不得更改流标签的规则，但允许路由器代表不更改流标签的主机设置流标签。
本规范讨论隐蔽通道风险及其对防火墙的影响。
有关更多详细信息，请参阅[RFC6436]。
8、 致谢
Jari Arkko、Ran Atkinson、Fred Baker、Richard Barnes、Steve Blake、Tassos Chatzitomaoglou、Remi Depress、Alan Ford、Fernando Gont、Brian Haberman、Tony Hain、Joel Halpern、Qinwen Hu、Chris Morrow、Thomas Narten、Mark Smith、Pascal Thubert、Iljitsch van Beijnum和6man工作组的其他参与者发表了宝贵的评论和贡献。
克里斯蒂安·卡洛德在附录A中提出了冯·诺依曼算法。戴维·马龙和唐纳德·伊斯特莱克提供了有关哈希算法的额外信息。
Steve Deering和Alex Conta是RFC 3697的合著者，本文件以此为基础。
RFC 3697最初开发的贡献者包Ran Atkinson、Steve Blake、Jim Bound、Francis Dupont、Robert Elz、Tony Hain、Robert Hancock、Bob Hinden、Christian Huitema、Frank Kastenholz、Thomas Narten、Charles Perkins、Pekka Savola、Hesham Soliman、Michael Thomas、Margaret Wasserman和Alex Zinin。
9、 参考资料
9.1、 规范性引用文件
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
9.2、 资料性引用
[LABEL-SEC] Gont, F., "Security Assessment of the IPv6 Flow Label", Work in Progress, November 2010. [NSA] Potyraj, C., "Firewall Design Considerations for IPv6", National Security Agency I733-041R-2007, 2007, <http://www.nsa.gov/ia/_files/ipv6/I733-041R-2007.pdf>. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005. [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006. [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010. [RFC6436] Amante, S., Carpenter, B., and S. Jiang, "Rationale for Update to the IPv6 Flow Label Specification", RFC 6436, November 2011. [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, November 2011. [vonNeumann] von Neumann, J., "Various techniques used in connection with random digits", National Bureau of Standards Applied Math Series 12, 36-38, 1951.
附录A、 20位哈希函数示例
如第3节所述，无状态哈希函数可用于从IPv6数据包的5元组生成流标签值。选择一个合适的散列函数并非易事，而且需要大量的实践经验来确定最佳选择。下面是一个基于冯·诺依曼（von Neumann）算法的示例函数，该算法已知可产生近似均匀分布[vonNeumann]。对于必须为其生成流标签的每个数据包，执行以下步骤：
1、将目标地址和源地址分别拆分为两个64位的值，从而将5元组转换为7元组。
2、使用无符号64位算术将以下五个组件相加，丢弃任何进位：源地址的两部分、目标地址的两部分和协议号。
3、将von Neumann算法应用于生成的64位字符串：
1.从最低有效端开始，选择两位。
2.如果两位为00或11，则丢弃它们。
3.如果两位为01，则输出一个0位。
4.如果两位为10，则输出一位。
5.重复输入64位字符串中的下两位。
6.输出16位（或64位字符串耗尽）时停止。
4.将两个端口号添加到生成的16位数字中。
5.将结果值向左移位4位，并用0xfffff屏蔽。
6.结果完全为零的极不可能的情况下，将流量标签任意设置为值1。
请注意，这个简单的例子不包括第6节中建议的防止可预测性的步骤。
