Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 7098 Univ. of Auckland
Category: Informational S. Jiang
ISSN: 2070-1721 Huawei Technologies Co., Ltd
W. Tarreau
HAProxy Technologies, Inc.
January 2014
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 7098 Univ. of Auckland
Category: Informational S. Jiang
ISSN: 2070-1721 Huawei Technologies Co., Ltd
W. Tarreau
HAProxy Technologies, Inc.
January 2014
Using the IPv6 Flow Label for Load Balancing in Server Farms
在服务器场中使用IPv6流标签进行负载平衡
Abstract
摘要
This document describes how the currently specified IPv6 flow label can be used to enhance layer 3/4 (L3/4) load distribution and balancing for large server farms.
本文档介绍如何使用当前指定的IPv6流标签来增强大型服务器场的第3/4层（L3/4）负载分布和平衡。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7098.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7098.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary of Flow Label Specification . . . . . . . . . . . . . 2
3. Summary of Server Farm Load-Balancing Techniques . . . . . . 4
4. Applying the Flow Label to Layer 3/4 Load Balancing . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary of Flow Label Specification . . . . . . . . . . . . . 2
3. Summary of Server Farm Load-Balancing Techniques . . . . . . 4
4. Applying the Flow Label to Layer 3/4 Load Balancing . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12
The IPv6 flow label has been redefined [RFC6437] and is now a recommended IPv6 node requirement [RFC6434]. Its use for load sharing in multipath routing has been specified [RFC6438]. Another scenario in which the flow label could be used is in load distribution for large server farms. Load distribution is a slightly more general term than load balancing, but the latter is more commonly used. In the context of a server farm, both terms refer to mechanisms that distribute the workload of a server farm among different servers in order to optimize performance. Server load balancing commonly applies to HTTP traffic, but most of the techniques described would apply to other upper-layer applications as well. This document starts with brief introductions to the flow label and to server load-balancing techniques, and then describes how the flow label can be used to enhance load balancers operating on IP packets and TCP sessions, commonly known as layer 3/4 load balancers.
IPv6流标签已重新定义[RFC6437]，现在是建议的IPv6节点要求[RFC6434]。已指定其在多路径路由中用于负载共享[RFC6438]。另一个可以使用流标签的场景是在大型服务器场的负载分配中。负载分布是一个比负载平衡更一般的术语，但后者更常用。在服务器场的上下文中，这两个术语都指在不同服务器之间分配服务器场工作负载以优化性能的机制。服务器负载平衡通常适用于HTTP流量，但所描述的大多数技术也适用于其他上层应用程序。本文档首先简要介绍流标签和服务器负载平衡技术，然后描述如何使用流标签增强在IP数据包和TCP会话上运行的负载平衡器，通常称为第3/4层负载平衡器。
The motivation for this approach is to improve the performance of most types of layer 3/4 load balancers, especially for traffic including multiple IPv6 extension headers and in particular for fragmented packets. Fragmented packets, often the result of customers reaching the load balancer via a VPN with a limited MTU, are a common performance problem.
这种方法的动机是提高大多数类型的3/4层负载平衡器的性能，特别是对于包括多个IPv6扩展头的流量，尤其是对于碎片数据包。碎片数据包是一个常见的性能问题，通常是客户通过具有有限MTU的VPN到达负载平衡器的结果。
The IPv6 flow label [RFC6437] is a 20-bit field included in every IPv6 header [RFC2460]. It is recommended to be supported in all IPv6 nodes by [RFC6434]. There is additional background material in [RFC6436] and [RFC6294]. According to its definition, the flow label should be set to a constant value for a given traffic flow (such as an HTTP connection), and that value will belong to a uniform statistical distribution, making it potentially valuable for load-balancing purposes.
IPv6流标签[RFC6437]是包含在每个IPv6标头[RFC2460]中的20位字段。建议[RFC6434]在所有IPv6节点中支持该功能。[RFC6436]和[RFC6294]中还有其他背景资料。根据其定义，流标签应设置为给定流量（如HTTP连接）的常量值，该值将属于统一的统计分布，因此对于负载平衡而言具有潜在价值。
Any device that has access to the IPv6 header has access to the flow label, and it is at a fixed position in every IPv6 packet. In contrast, transport-layer information, such as the port numbers, is not always in a fixed position, since it follows any IPv6 extension headers that may be present. In fact, the logic of finding the transport header is always more complex for IPv6 than for IPv4, due to the absence of an Internet Header Length field in IPv6. Additionally, if packets are fragmented, the flow label will be present in all fragments, but the transport header will only be in one packet. Therefore, within the lifetime of a given transport-layer connection, the flow label can be a more convenient "handle" than the port number for identifying that particular connection.
任何可以访问IPv6报头的设备都可以访问流标签，并且它位于每个IPv6数据包中的固定位置。相反，传输层信息（如端口号）并不总是处于固定位置，因为它遵循可能存在的任何IPv6扩展头。事实上，由于IPv6中没有Internet标头长度字段，因此IPv6查找传输标头的逻辑总是比IPv4更复杂。此外，如果数据包是分段的，则流标签将出现在所有片段中，但传输报头将仅出现在一个数据包中。因此，在给定传输层连接的生命周期内，流标签可以是比端口号更方便的“句柄”，用于标识特定连接。
According to RFC 6437, source hosts should set the flow label; however, if they do not (i.e., its value is zero), forwarding nodes (such as the first-hop router) may set it instead. In both cases, the flow label value must be constant for a given transport session, normally identified by the IPv6 and Transport header 5-tuple. By default, the flow label value should be calculated by a stateless algorithm. The resulting value should form part of a statistically uniform distribution, regardless of which node sets it.
根据RFC6437，源主机应设置流标签；然而，如果它们没有（即，其值为零），则转发节点（例如第一跳路由器）可以改为设置它。在这两种情况下，给定传输会话的流标签值必须是常量，通常由IPv6和传输头5元组标识。默认情况下，流标签值应通过无状态算法计算。结果值应构成统计均匀分布的一部分，无论哪个节点设置它。
It is recognized that at the time of writing, very few traffic flows include a non-zero flow label value. The mechanism described below is one that can be added to existing load-balancing mechanisms, so that it will become effective as more and more flows contain a non-zero label. Even if the flow label is chosen from an imperfectly uniform distribution, it will nevertheless increase the information entropy of the IPv6 header as a whole. This allows for progressive introduction of load balancing based on the flow label.
众所周知，在撰写本文时，很少有流量包含非零流量标签值。下面描述的机制可以添加到现有的负载平衡机制中，以便随着越来越多的流包含非零标签而变得有效。即使流标签是从不完全均匀的分布中选择的，它仍然会增加整个IPv6报头的信息熵。这允许基于流标签逐步引入负载平衡。
If the recommendations in Section 3 of RFC 6437 are followed for traffic from a given source accessing a well-known TCP port at a given destination, the flow label can act as a substitute for the port numbers as far as a load balancer is concerned, and it can be found at a fixed position in the layer 3 header even if extension headers are present.
如果给定源访问给定目的地的已知TCP端口的流量遵循RFC 6437第3节中的建议，则就负载平衡器而言，流标签可以作为端口号的替代物，即使存在扩展标头，也可以在第3层标头中的固定位置找到它。
The flow label is defined as an end-to-end component of the IPv6 header, but there are three qualifications to this:
流标签定义为IPv6标头的端到端组件，但有三个限定条件：
1. Until the IPv6 flow label specification in RFC 6437 is widely implemented as recommended by RFC 6434, the flow label will often be set to the default value of zero.
1. 在按照RFC 6434的建议广泛实施RFC 6437中的IPv6流标签规范之前，流标签通常会设置为默认值零。
2. Because of the recommendation to use a stateless algorithm to calculate the label, there is a low (but non-zero) probability that two simultaneous flows from the same source to the same destination have the same flow label value despite having different transport-protocol port numbers.
2. 由于建议使用无状态算法来计算标签，因此尽管具有不同的传输协议端口号，但从相同源到相同目的地的两个同时流具有相同的流标签值的概率很低（但非零）。
3. The Flow Label field is in an unprotected part of the IPv6 header, which means that intentional or unintentional changes to its value cannot be easily detected by a receiver.
3. “流标签”字段位于IPv6标头的未受保护部分，这意味着接收器无法轻松检测到对其值的有意或无意更改。
The first two points are addressed below in Section 4 and the third in Section 5.
以下第4节和第5节分别阐述了前两点和第三点。
Load balancing for server farms is achieved by a variety of methods, often used in combination [Tarreau]. This section gives a general overview of common methods, although the flow label is not relevant to all of them. The actual load-balancing algorithm (the choice of which server to use for a new client session) is irrelevant to this discussion. We give examples for HTTP, but analogous techniques may be used for other application protocols.
服务器场的负载平衡是通过多种方法实现的，通常结合使用[Tarreau]。本节给出了常用方法的一般概述，尽管流标签并非与所有方法都相关。实际的负载平衡算法（选择用于新客户端会话的服务器）与本讨论无关。我们给出了HTTP的示例，但类似的技术也可用于其他应用程序协议。
o The simplest method is using the DNS to return different server addresses for a single name such as www.example.com to different users. This is typically done by rotating the order in which different addresses within the server site are listed by the relevant authoritative DNS server, on the assumption that the client will pick the first one. Routing may be configured such that the different addresses are handled by different ingress routers. Several variants of this load-balancing mechanism exist, such as expecting some clients to use all the advertised addresses when multiple connections are involved, or directing the traffic to multiple sites, also known as global load balancing. None of these mechanisms are in the scope of this document, and the proposal in this document does not affect their usability nor aim to replace them, so they will not be discussed further.
o 最简单的方法是使用DNS将单个名称（如www.example.com）的不同服务器地址返回给不同的用户。这通常是通过旋转相关权威DNS服务器列出服务器站点内不同地址的顺序来完成的，前提是客户端将选择第一个地址。路由可被配置为使得不同的地址由不同的入口路由器处理。存在这种负载平衡机制的几种变体，例如，当涉及多个连接时，期望某些客户端使用所有播发的地址，或者将流量定向到多个站点，也称为全局负载平衡。所有这些机制都不在本文件的范围内，本文件中的建议不影响其可用性，也不打算取代它们，因此将不再进一步讨论。
o Another method, for HTTP servers, is to operate a layer 7 reverse proxy in front of the server farm. The reverse proxy will present a single IP address to the world, communicated to clients by a single AAAA record. For each new client session (an incoming TCP connection and HTTP request), it will pick a particular server and proxy the session to it. The act of proxying should be more efficient and less resource-intensive than the act of serving the required content. The proxy must retain TCP state and proxy state for the duration of the session. This TCP state could, potentially, include the incoming flow label value.
o 对于HTTP服务器，另一种方法是在服务器场前面操作第7层反向代理。反向代理将向世界显示一个IP地址，并通过一个AAAA记录与客户端通信。对于每个新的客户端会话（传入的TCP连接和HTTP请求），它将选择一个特定的服务器并将会话代理给它。代理行为应该比提供所需内容的行为更高效，资源密集度更低。在会话期间，代理必须保留TCP状态和代理状态。此TCP状态可能包括传入流标签值。
o A component of some load-balancing systems is an SSL reverse proxy farm. The individual SSL proxies handle all cryptographic aspects and exchange unencrypted HTTP with the actual servers. Thus, from the load-balancing point of view, this really looks just like a server farm, except that it's specialized for HTTPS. Each proxy will retain SSL and TCP and maybe HTTP state for the duration of the session, and the TCP state could potentially include the flow label.
o 一些负载平衡系统的一个组件是SSL反向代理服务器场。各个SSL代理处理所有加密方面，并与实际服务器交换未加密的HTTP。因此，从负载平衡的角度来看，这看起来就像一个服务器场，只是它专门用于HTTPS。在会话期间，每个代理都将保留SSL和TCP以及HTTP状态，TCP状态可能包括流标签。
o Finally the "front end" of many load-balancing systems is a layer 3/4 load balancer. While it can be a dedicated device, it is also a standard function of some network switches or routers (e.g. using Equal-Cost Multipath Routing (ECMP) [RFC2991]). In this case, it is the layer 3/4 load balancer whose IP address is published as the primary AAAA record for the service. All client sessions will pass through this device. Depending on the specific scenario, the balancer will assign new sessions among the actual application servers, across an SSL proxy farm, or among a set of layer 7 proxies. In all cases, the layer 3/4 load balancer has to classify incoming packets very quickly and choose the target server or proxy so as to ensure persistence. 'Persistence' is defined as the guarantee that a given client session will run to completion on a single server. The layer 3/4 load balancer therefore needs to inspect each incoming packet to classify it. There are two common types of layer 3/4 load balancers, the totally stateless ones which only act on single packets, generally involving a per-packet hashing of easy-to-find information such as the source address and/or port into a server number, and the stateful ones that take the routing decision on the very first packets of a session and maintain the same direction for all packets belonging to the same session. Clearly, both types of layer 3/4 balancers could inspect and make use of the flow label value.
o 最后，许多负载平衡系统的“前端”是3/4层负载平衡器。虽然它可以是专用设备，但它也是一些网络交换机或路由器的标准功能（例如，使用等成本多路径路由（ECMP）[RFC2991]）。在这种情况下，是第3/4层负载平衡器，其IP地址作为服务的主AAAA记录发布。所有客户端会话都将通过此设备。根据特定场景，平衡器将在实际应用程序服务器之间、SSL代理服务器场之间或一组第7层代理之间分配新会话。在所有情况下，3/4层负载平衡器都必须非常快速地对传入数据包进行分类，并选择目标服务器或代理，以确保持久性。”“持久性”定义为保证给定的客户端会话将在单个服务器上运行到完成。因此，第3/4层负载平衡器需要检查每个传入数据包以对其进行分类。有两种常见的3/4层负载平衡器，完全无状态的负载平衡器仅作用于单个数据包，通常涉及将易于查找的信息（如源地址和/或端口）按数据包散列到服务器编号中，以及对会话的第一个数据包进行路由决策并对属于同一会话的所有数据包保持相同方向的有状态数据包。显然，这两种类型的3/4层平衡器都可以检查和利用流量标签值。
Our focus is on how the balancer identifies a particular flow. For clarity, note that two aspects of layer 3/4 load balancers are not affected by use of the flow label to identify sessions:
我们的重点是平衡器如何识别特定流。为清楚起见，请注意，使用流标签标识会话不会影响第3/4层负载平衡器的两个方面：
1. Balancers use various techniques to redirect traffic to a specific target server.
1. 平衡器使用各种技术将流量重定向到特定的目标服务器。
+ All servers are configured with the same IP address, they are all on the same LAN, and the load balancer sends directly to their individual MAC addresses. In this case, return packets from the server to the client are sent back without passing through the balancer, a technique known as direct server return, but we are not concerned here with the return packets.
+ 所有服务器都配置了相同的IP地址，它们都位于相同的LAN上，负载平衡器直接发送到它们各自的MAC地址。在这种情况下，从服务器到客户机的返回数据包在不经过平衡器的情况下被发回，这是一种称为直接服务器返回的技术，但我们这里不关心返回数据包。
+ All servers are configured with the same IP address, treated locally as an anycast address by layer 3 ECMP routing.
+ 所有服务器都配置了相同的IP地址，通过第3层ECMP路由在本地作为选播地址处理。
+ Each server has its own IP address, and the balancer uses an IP-in-IP tunnel to reach it.
+ 每台服务器都有自己的IP地址，平衡器使用IP-in-IP隧道来访问它。
+ Each server has its own IP address, and the balancer performs NAPT (Network Address and Port Translation) to deliver the client's packets to that address.
+ 每个服务器都有自己的IP地址，平衡器执行NAPT（网络地址和端口转换）以将客户端的数据包传递到该地址。
+ The choice between these methods is not affected by use of the flow label.
+ 这些方法之间的选择不受流标签使用的影响。
2. A layer 3/4 balancer must correctly handle Path MTU Discovery by forwarding relevant ICMPv6 packets in both directions. This too is not directly affected by use of the flow label. It should be noted that there may be difficulty correlating an ICMPv6 "Packet too big" response with the session it refers to, but that is out of the scope of the present document.
2. 第3/4层平衡器必须通过在两个方向上转发相关ICMPv6数据包来正确处理路径MTU发现。这也不受流标签使用的直接影响。应注意，将ICMPv6“数据包太大”响应与其所指的会话关联起来可能有困难，但这超出了本文档的范围。
The following diagram, inspired by [Tarreau], shows a layout with various methods in use together. (Below, "ASIC" stands for "Application-Specific Integrated Circuit".)
下图受[Tarreau]的启发，显示了一个包含多种方法的布局。（下面，“ASIC”代表“专用集成电路”。）
___________________________________________
( )
( Clients in the Internet )
(___________________________________________)
| |
------------ DNS-based ------------
| Ingress | load splitting | Ingress |
| router | affects | router |
------------ routing ------------
___|____________________________|___
| |
| |
| |
------------ ------------
| L3/4 ASIC| | L3/4 ASIC|
| balancer | | balancer |
------------ ------------
| load |
| spreading |
__________|________________________|___________
| | | |
------------ ------------ -------- --------
|HTTP proxy|...|HTTP proxy| | SSL |...| SSL |
| balancer | | balancer | | proxy| | proxy|
------------ ------------ -------- --------
____|_____________|_____________|_________|_____
| | | | |
-------- -------- -------- -------- --------
|HTTP | |HTTP | |HTTP | |HTTP | |HTTP |
|server| |server| |server| |server| |server|
-------- -------- -------- -------- --------
___________________________________________
( )
( Clients in the Internet )
(___________________________________________)
| |
------------ DNS-based ------------
| Ingress | load splitting | Ingress |
| router | affects | router |
------------ routing ------------
___|____________________________|___
| |
| |
| |
------------ ------------
| L3/4 ASIC| | L3/4 ASIC|
| balancer | | balancer |
------------ ------------
| load |
| spreading |
__________|________________________|___________
| | | |
------------ ------------ -------- --------
|HTTP proxy|...|HTTP proxy| | SSL |...| SSL |
| balancer | | balancer | | proxy| | proxy|
------------ ------------ -------- --------
____|_____________|_____________|_________|_____
| | | | |
-------- -------- -------- -------- --------
|HTTP | |HTTP | |HTTP | |HTTP | |HTTP |
|server| |server| |server| |server| |server|
-------- -------- -------- -------- --------
From the previous paragraphs, we can identify several points in this diagram where the flow label might be relevant:
从前面的段落中，我们可以确定此图中与流标签相关的几个点：
1. Layer 3/4 load balancers.
1. 第3/4层负载平衡器。
2. SSL proxies.
2. SSL代理。
3. HTTP proxies.
3. HTTP代理。
However, usage by the proxies seems unlikely to affect performance, because they must in any case process the application-layer header, so in this document we focus only on layer 3/4 balancers.
然而，代理的使用似乎不太可能影响性能，因为它们在任何情况下都必须处理应用层头，因此在本文档中，我们只关注3/4层平衡器。
The suggested model for using the flow label to enhance an layer 3/4 load-balancing mechanism is as follows:
使用流标签来增强第3/4层负载平衡机制的建议模型如下：
o We are only concerned with IPv6 traffic in which the flow label value has been set according to [RFC6437]. If the flow label of an incoming packet is zero, load balancers will continue to use the transport header in the traditional way. As the use of the flow label becomes more prevalent according to RFC 6434, load balancers, and therefore users, will reap a growing performance benefit.
o 我们只关注根据[RFC6437]设置流量标签值的IPv6流量。如果传入数据包的流标签为零，负载平衡器将继续以传统方式使用传输头。根据RFC 6434，随着流标签的使用变得越来越普遍，负载平衡器以及用户将获得越来越多的性能优势。
o If the flow label of an incoming packet is non-zero, layer 3/4 load balancers can use the 2-tuple {source address, flow label} as the session key for whatever load distribution algorithm they support. Alternatively, they might use the 3-tuple {dest address, source address, flow label}, especially if the server farm supports multiple server IP addresses, but using the 3-tuple will be significantly quicker than searching for the transport port numbers later in the packet. Moreover, the transport-layer information such as the source port is not repeated in fragments, which generally prevents stateless load balancers from supporting fragmented traffic since they generally cannot reassemble fragments.
o 如果传入数据包的流标签为非零，则第3/4层负载平衡器可以使用2元组{源地址，流标签}作为其支持的任何负载分配算法的会话密钥。或者，他们可以使用3元组{dest address，source address，flow label}，特别是如果服务器场支持多个服务器IP地址，但是使用3元组将比稍后在数据包中搜索传输端口号快得多。此外，传输层信息（如源端口）不会在片段中重复，这通常会阻止无状态负载平衡器支持片段通信，因为它们通常无法重新组装片段。
A stateless layer 3/4 load balancer would simply apply a hash algorithm to the 2-tuple or 3-tuple on all packets in order to select the same target server consistently for a given flow. Needless to say, the hash algorithm has to be well chosen for its purpose, but this problem is common to several forms of stateless load balancing. The discussion in [RFC6438] applies.
无状态3/4层负载平衡器只需对所有数据包上的2元组或3元组应用哈希算法，以便为给定流一致地选择相同的目标服务器。不用说，哈希算法的选择必须符合其目的，但这个问题在几种形式的无状态负载平衡中是常见的。[RFC6438]中的讨论适用。
A stateful layer 3/4 load balancer would apply its usual load distribution algorithm to the first packet of a session, and store the {tuple, server} association in a table so that subsequent packets belonging to the same session are forwarded to the same server. Thus, for all subsequent packets of the session, it can ignore all IPv6 extension headers, which should lead to a performance benefit. Whether this benefit is valuable will depend on engineering details of the specific load balancer.
有状态的第3/4层负载平衡器将其常用的负载分配算法应用于会话的第一个数据包，并将{tuple，server}关联存储在表中，以便属于同一会话的后续数据包被转发到同一服务器。因此，对于会话的所有后续数据包，它可以忽略所有IPv6扩展头，这将提高性能。这一好处是否有价值将取决于特定负载平衡器的工程细节。
Note that such a balancer will not identify new transport sessions from the same source that use the same flow label; they will be delivered to the same server. This is like the behavior of existing hash-based layer 4 balancers that always send similarly hashed packets to the same destination. However, a global state table in a flow label balancer cannot be shared between multiple
注意，这样的平衡器不会识别来自使用相同流标签的相同源的新传输会话；它们将被传送到同一服务器。这类似于现有的基于散列的第4层平衡器的行为，这些平衡器总是将类似的散列数据包发送到相同的目的地。但是，流标签平衡器中的全局状态表不能在多个服务器之间共享
services if these services rely on transport-layer information, since the goal of using the flow label is to avoid looking up that information.
服务，如果这些服务依赖于传输层信息，因为使用流标签的目的是避免查找该信息。
A related issue is that the balancer will not detect FIN/ACK sequences at the end of sessions. Therefore, it will rely on inactivity timers to delete session state. However, all existing balancers must maintain such timers to deal with hung sessions, and the practical impact on memory utilization is unlikely to be significant.
一个相关的问题是，平衡器在会话结束时不会检测FIN/ACK序列。因此，它将依赖非活动计时器来删除会话状态。然而，所有现有的平衡器都必须维护这样的计时器来处理挂起的会话，并且对内存利用率的实际影响不大。
o Layer 3/4 balancers that redirect the incoming packets by NAPT are not expected to obtain any saving of time by using the flow label, because they have no choice but to follow the extension header chain in order to locate and modify the port number and transport checksum. The same would apply to balancers that perform TCP state tracking for any reason.
o 通过NAPT重定向传入数据包的第3/4层平衡器不希望通过使用流标签来节省时间，因为它们别无选择，只能遵循扩展头链来定位和修改端口号和传输校验和。这同样适用于出于任何原因执行TCP状态跟踪的平衡器。
o Note that correct handling of ICMPv6 for Path MTU Discovery requires the layer 3/4 balancer to keep state for the client source address, independently of either the port numbers or the flow label.
o 请注意，正确处理ICMPv6以进行路径MTU发现需要第3/4层平衡器保持客户端源地址的状态，与端口号或流标签无关。
o SSL and HTTP proxies, if present, should forward the flow label value towards the server. This usually has no performance benefit, but it is consistent with the general model for the flow label described in RFC 6437.
o SSL和HTTP代理（如果存在）应将流标签值转发给服务器。这通常没有性能优势，但与RFC 6437中描述的流标签的一般模型一致。
It should be noted that the performance benefit, if any, depends entirely on engineering trade-offs in the design of the layer 3/4 balancer. An extra test is needed to check if the label is non-zero, but if there is a non-zero label, all logic for handling extension headers can be skipped except for the first packet of a new flow. Since the identifying state to be stored is only the tuple and the server identifier, storage requirements will be reduced. Additionally, the method will work for fragmented traffic and for flows where the transport information is missing (unknown transport protocol) or obfuscated (e.g., IPsec). Traffic reaching the load balancer via a VPN is particularly prone to the fragmentation issue, due to MTU size issues. For some load-balancer designs, these are very significant advantages.
应该注意的是，性能优势（如果有的话）完全取决于3/4层平衡器设计中的工程权衡。需要额外的测试来检查标签是否为非零，但如果存在非零标签，则可以跳过处理扩展头的所有逻辑，新流的第一个数据包除外。由于要存储的标识状态仅为元组和服务器标识符，因此存储需求将减少。此外，该方法将适用于碎片流量和传输信息丢失（未知传输协议）或混淆（例如IPsec）的流。由于MTU大小问题，通过VPN到达负载平衡器的流量特别容易出现碎片问题。对于某些负载平衡器设计，这些是非常显著的优势。
In the unlikely event of two simultaneous flows from the same source address having the same flow label value, the two flows would end up assigned to the same server, where they would be distinguished as normal by their port numbers. There are approximately one million possible flow label values, and if the rules for flow label generation [RFC6437] are followed, this would be a statistically rare
如果来自同一源地址的两个流同时具有相同的流标签值，则这两个流最终将分配到同一服务器，在该服务器上，它们将通过端口号正常区分。大约有一百万个可能的流标签值，如果遵循流标签生成规则[RFC6437]，这在统计上是罕见的
event, and would not damage the overall load-balancing effect. Moreover, with a million possible label values, it is very likely that there will be many more flow label values than servers at most sites, so it is already expected that multiple flow label values will end up on the same server for a given client IP address.
事件，并且不会损害整体负载平衡效果。此外，由于有一百万个可能的标签值，在大多数站点上，很可能会有比服务器多得多的流标签值，因此，对于给定的客户端IP地址，已经预期多个流标签值将最终出现在同一台服务器上。
In the case that many thousands of clients are hidden behind the same large-scale NAPT with a single shared IP address, the assumption of low probability of conflicts might become incorrect, unless flow label values are random enough to avoid following similar sequences for all clients. This is not expected to be a factor for IPv6 anyway, since there is no need to implement large-scale NAPT with address sharing [RFC4864]. The probability of conflicts is low for sites that implement network prefix translation [RFC6296], since this technique provides a different address for each client.
如果数千个客户端隐藏在同一个具有单个共享IP地址的大型NAPT后面，则冲突概率较低的假设可能会变得不正确，除非流标签值是随机的，足以避免所有客户端遵循类似的序列。无论如何，这并不是IPv6的一个因素，因为不需要通过地址共享实现大规模NAPT[RFC4864]。对于实现网络前缀转换[RFC6296]的站点，冲突的概率很低，因为这种技术为每个客户端提供了不同的地址。
Security aspects of the flow label are discussed in [RFC6437]. As noted there, a malicious source or man-in-the-middle could disturb load balancing by manipulating flow labels. This risk already exists today where the source address and port are used as a hashing key in layer 3/4 load balancers, as well as where a persistence cookie is used in HTTP to designate a server. It even exists on layer 3 components that only rely on the source address to select a destination, making them more DDoS-prone. Nevertheless, all these methods are currently used because the benefits for load balancing and persistence hugely outweigh the risks. The flow label does not significantly alter this situation.
[RFC6437]中讨论了流标签的安全方面。如上所述，恶意源或中间人可能通过操纵流标签来干扰负载平衡。目前，在3/4层负载平衡器中将源地址和端口用作哈希键，以及在HTTP中使用持久性cookie来指定服务器的情况下，这种风险已经存在。它甚至存在于仅依赖源地址选择目的地的第3层组件上，使它们更容易遭受DDoS攻击。然而，所有这些方法目前都在使用，因为负载平衡和持久性的好处远远大于风险。流量标签不会显著改变这种情况。
Specifically, the IPv6 flow label specification [RFC6437] states that "stateless classifiers should not use the flow label alone to control load distribution, and stateful classifiers should include explicit methods to detect and ignore suspect flow label values." The former point is answered by also using the source address. The latter point is more complex. If the risk is considered serious, the site ingress router or the layer 3/4 balancer should use a suitable heuristic to verify incoming flows with non-zero flow label values. If a flow from a given source address and port number does not have a constant flow label value, it is suspect and should be dropped. This would deal with both intentional and accidental changes to the flow label.
具体而言，IPv6流标签规范[RFC6437]规定，“无状态分类器不应单独使用流标签来控制负载分布，有状态分类器应包括检测和忽略可疑流标签值的显式方法。”前一点也通过使用源地址来回答。后一点更为复杂。如果风险被认为是严重的，站点入口路由器或3/4层平衡器应使用适当的启发式方法验证具有非零流标签值的传入流。如果来自给定源地址和端口号的流没有恒定的流标签值，则它是可疑的，应该删除。这将处理流标签的有意更改和意外更改。
A malicious source or man-in-the-middle could generate a flow in which the flow label is constant but the transport port numbers in some packets are invalid. Such packets, if load-balanced only on the basis of the flow label, could reach the target server and create a single-source DoS attack on its TCP engine.
恶意源或中间人可能会生成流，其中流标签为常量，但某些数据包中的传输端口号无效。如果仅根据流标签进行负载平衡，则此类数据包可能到达目标服务器，并在其TCP引擎上造成单源DoS攻击。
RFC 6437 notes in its Security Considerations that if the covert channel risk is considered significant, a firewall might rewrite non-zero flow labels. As long as this is done as described in RFC 6437, it will not invalidate the mechanisms described above.
RFC 6437在其安全注意事项中指出，如果认为隐蔽通道风险很大，防火墙可能会重写非零流量标签。只要按照RFC 6437中的说明进行，就不会使上述机制失效。
The flow label may be of use in protecting against DDoS attacks against servers. As noted in RFC 6437, a source should generate flow label values that are hard to predict, most likely by including a secret nonce in the hash used to generate each label. The attacker does not know the nonce and therefore has no way to invent flow labels that will all target the same server, even with knowledge of both the hash algorithm and the load-balancing algorithm. Still, it is important to understand that it is always trivial to force a load balancer to stick to the same server during an attack, so the security of the whole solution must not rely on the unpredictability of the flow label values alone, but should include defensive measures like most load balancers already have against abnormal use of source addresses or session cookies.
流标签可用于防范针对服务器的DDoS攻击。如RFC 6437中所述，源应生成难以预测的流标签值，最有可能的方法是在用于生成每个标签的哈希中包含一个秘密nonce。攻击者不知道nonce，因此无法发明将所有对象都指向同一服务器的流标签，即使知道哈希算法和负载平衡算法。尽管如此，重要的是要理解，在攻击过程中强制负载平衡器保持在同一台服务器上总是微不足道的，因此整个解决方案的安全性不能仅仅依赖于流标签值的不可预测性，但应该包括像大多数负载平衡器一样的防御措施，以防止源地址或会话cookie的异常使用。
New flows are assigned to a server according to any of the usual algorithms available on the load balancer (e.g., least connections, round robin, etc.). The association between the 2-tuple {source address, flow label} and the server is stored in a table (often called stick table) so that future traffic from the same source using the same flow label can be sent to the same server. This method is more robust against a loss of server and also makes it harder for an attacker to target a specific server, because the association between a flow label value and a server is not known externally.
根据负载平衡器上可用的任何常用算法（例如，最少连接、循环等），将新流分配给服务器。二元组{source address，flow label}和服务器之间的关联存储在一个表（通常称为stick table）中，以便将来使用相同流标签的来自相同源的流量可以发送到相同的服务器。此方法对于服务器丢失更为健壮，并且使攻击者更难以特定服务器为目标，因为流标签值和服务器之间的关联在外部是未知的。
In the case that a stateless hash function is used to assign client packets to specific servers, it may be advisable to use a cryptographic hash function of some kind, to ensure that an attacker cannot predict the behavior of the load balancer.
在使用无状态哈希函数将客户端数据包分配给特定服务器的情况下，建议使用某种加密哈希函数，以确保攻击者无法预测负载平衡器的行为。
Valuable comments and contributions were made by Fred Baker, Olivier Bonaventure, Ben Campbell, Lorenzo Colitti, Linda Dunbar, Donald Eastlake, Joel Jaeggli, Gurudeep Kamat, Warren Kumari, Julia Renouard, Julius Volz, and others.
Fred Baker、Olivier Bonaventure、Ben Campbell、Lorenzo Coletti、Linda Dunbar、Donald Eastlake、Joel Jaeggli、Gurudeep Kamat、Warren Kumari、Julia Renouard、Julius Volz和其他人发表了宝贵的评论和贡献。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
[RFC6434]Jankiewicz，E.，Loughney，J.和T.Narten，“IPv6节点要求”，RFC 64342011年12月。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011.
[RFC6437]Amante，S.，Carpenter，B.，Jiang，S.，和J.Rajahalme，“IPv6流标签规范”，RFC 6437，2011年11月。
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
[RFC2991]Thaler，D.和C.Hopps，“单播和多播下一跳选择中的多路径问题”，RFC 29912000年11月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，RFC 4864，2007年5月。
[RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for the IPv6 Flow Label", RFC 6294, June 2011.
[RFC6294]Hu，Q.和B.Carpenter，“IPv6流标签的拟议用例调查”，RFC 62942011年6月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 62962011年6月。
[RFC6436] Amante, S., Carpenter, B., and S. Jiang, "Rationale for Update to the IPv6 Flow Label Specification", RFC 6436, November 2011.
[RFC6436]Amante，S.，Carpenter，B.，和S.Jiang，“更新IPv6流标签规范的基本原理”，RFC 64362011年11月。
[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.
[RFC6438]Carpenter，B.和S.Amante，“在隧道中使用IPv6流标签进行等成本多路径路由和链路聚合”，RFC 6438，2011年11月。
[Tarreau] Tarreau, W., "Making applications scalable with load balancing", 2006, <http://1wt.eu/articles/2006_lb/>.
[Tarreau]Tarreau，W.“通过负载平衡使应用程序可扩展”，2006年<http://1wt.eu/articles/2006_lb/>.
Authors' Addresses
作者地址
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
Brian Carpenter奥克兰大学计算机系，奥克兰92019，新西兰1142
EMail: brian.e.carpenter@gmail.com
EMail: brian.e.carpenter@gmail.com
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China
中国北京海淀区北青路156号华为校区盛江华为技术有限公司Q14，邮编100095
EMail: jiangsheng@huawei.com
EMail: jiangsheng@huawei.com
Willy Tarreau HAProxy Technologies, Inc. R&D Network Products 3 rue du petit Robinson 78350 Jouy-en-Josas France
Willy Tarreau HAProxy Technologies，Inc.研发网络产品法国小鲁宾逊街3号约萨斯街78350
EMail: willy@haproxy.com
EMail: willy@haproxy.com