Internet Engineering Task Force (IETF) S. Amante
Request for Comments: 6436 Level 3
Category: Informational B. Carpenter
ISSN: 2070-1721 Univ. of Auckland
S. Jiang
Huawei
November 2011
Internet Engineering Task Force (IETF) S. Amante
Request for Comments: 6436 Level 3
Category: Informational B. Carpenter
ISSN: 2070-1721 Univ. of Auckland
S. Jiang
Huawei
November 2011
Rationale for Update to the IPv6 Flow Label Specification
更新IPv6流标签规范的基本原理
Abstract
摘要
Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it and to introduce some additional flexibility.
各种已发布的使用IPv6流标签的建议与其RFC 3697中的原始规范不兼容。此外，很少实际使用流量标签，部分原因是规范的正确解释存在一些不确定性。本文档讨论并激励对规范的更改，以澄清规范并引入一些额外的灵活性。
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/rfc6436.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6436.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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. Impact of Current Specification . . . . . . . . . . . . . . . 3
3. Changes to the Specification . . . . . . . . . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Impact of Current Specification . . . . . . . . . . . . . . . 3
3. Changes to the Specification . . . . . . . . . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 12
The flow label field in the IPv6 header was reserved but left Experimental by [RFC2460], which mandates only that "Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet."
IPv6报头中的流标签字段已保留，但由[RFC2460]保留，它只要求不支持流标签字段功能的主机或路由器在发起数据包时需要将该字段设置为零，在转发数据包时将该字段保持不变，在接收数据包时忽略该字段
The flow label field was normatively specified by [RFC3697]. In particular, we quote three rules from that RFC:
[RFC3697]规范性规定了流量标签场。特别是，我们引用了RFC中的三条规则：
a. "The Flow Label value set by the source MUST be delivered unchanged to the destination node(s)."
a. “源设置的流标签值必须原封不动地传递到目标节点。”
b. "IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow Label values assigned by source nodes."
b. “IPv6节点不得采用源节点分配的流标签值的任何数学或其他属性。”
c. "Router performance SHOULD NOT be dependent on the distribution of the Flow Label values. Especially, the Flow Label bits alone make poor material for a hash key."
c. 路由器的性能不应依赖于流标签值的分布。尤其是，流标签位本身对散列键的影响很差
Additionally, RFC 3697 does not define the method a host should adopt by default to choose the value of the flow label, if no specific method is in use. It was expected that various signaling methods might be defined for agreeing on values of the flow label, but no such methods have been standardized, except a pre-existing option in RSVP [RFC2205].
此外，如果未使用特定方法，RFC 3697未定义主机在默认情况下应采用的方法来选择流标签的值。预计可能会定义各种信令方法来商定流量标签的值，但除了RSVP[RFC2205]中预先存在的选项外，尚未对此类方法进行标准化。
The flow label is hardly used in practice in widespread IPv6 implementations, although some operating systems do set it [McGann05]. To some extent, this is due to the main focus being on basic deployment of IPv6, but the absence of a default method of choosing the flow label value means that most host implementations simply set it to zero. There is also anecdotal evidence that the rules quoted above have led to uncertainty about exactly what is possible. Furthermore, various use cases have been proposed that infringe one or another of the rules. None of these proposals has been accepted as a standard and in practice there is no significant deployment of any mechanism to set the flow label.
虽然某些操作系统确实设置了流标签，但在广泛的IPv6实施中，流标签在实践中很少使用[McGann05]。在某种程度上，这是因为主要关注IPv6的基本部署，但缺少选择流标签值的默认方法意味着大多数主机实现只是将其设置为零。也有传闻证据表明，上述规则导致了关于到底什么是可能的不确定性。此外，已经提出了各种违反一个或另一个规则的用例。这些建议均未被接受为标准，并且在实践中，没有任何重大的机制来设置流量标签。
The intention of this document is to explain this situation in more detail and to motivate changes to RFC 3697 intended to remove the uncertainties and encourage active usage of the flow label. It does not formally update RFC 3697, but it serves as background material for [RFC6437].
本文件旨在更详细地解释这种情况，并促使对RFC 3697进行修改，以消除不确定性并鼓励积极使用流量标签。它没有正式更新RFC 3697，但作为[RFC6437]的背景资料。
Rule (a) makes it impossible for the routing system to use the flow label as any form of dynamic routing tag. This was a conscious choice in the early design of IPv6, and there appears to be no practical possibility of revisiting this decision at this stage in the deployment of IPv6, which uses conventional routing mechanisms like those used for IPv4. However, this rule also makes it impossible to make any use at all of the flow label unless hosts choose to set it. It also forbids clearing the flow label for security reasons.
规则（a）使得路由系统无法将流标签用作任何形式的动态路由标记。在IPv6的早期设计中，这是一个有意识的选择，在IPv6部署的现阶段，似乎不可能重新考虑这一决定，IPv6使用传统的路由机制，如用于IPv4的路由机制。但是，此规则还使得不可能在所有流标签上都使用它，除非主机选择设置它。出于安全原因，它还禁止清除流标签。
This last point highlights the security properties, or rather the lack thereof, with regards to the flow label. The flow label field is always unprotected as it travels through the network, because there is no IPv6 header checksum, and the flow label is not included in transport pseudo-header checksums, nor in IPsec checksums. As a result, intentional and malicious changes to its value cannot be detected. Also, it could be used as a covert data channel, since apparently pseudo-random flow label values could in fact consist of covert data [NIST]. If the flow label were to carry quality-of-service semantics, then like the diffserv code point [RFC2474], it would not be intrinsically trustworthy across domain boundaries. As
最后一点强调了流标签的安全属性，或者更确切地说是缺乏安全属性。流标签字段在网络中传输时始终不受保护，因为没有IPv6标头校验和，并且流标签不包括在传输伪标头校验和中，也不包括在IPsec校验和中。因此，无法检测到对其值的故意和恶意更改。此外，它还可以用作隐蔽数据通道，因为显然伪随机流标签值实际上可能包含隐蔽数据[NIST]。如果流标签要承载服务质量语义，那么与diffserv代码点[RFC2474]一样，它在本质上不会跨域边界可信。像
a result, some security specialists believe that flow labels should be cleared for safety [LABEL-SEC] [NSA]. These points must be considered when discussing the immutability of the flow label across domain boundaries. In fact, the adjective "immutable" is confusing, since it implies a property that the flow label field does not actually possess. It has therefore been abandoned as a descriptive term in [RFC6437]. It is only used in the present document to explain why it has been abandoned.
因此，一些安全专家认为，应清除流量标签以确保安全[LABEL-SEC][NSA]。在讨论跨域边界的流标签的不变性时，必须考虑这些要点。事实上，形容词“不可变”令人困惑，因为它意味着流标签字段实际上不具备的属性。因此，在[RFC6437]中，它被放弃作为一个描述性术语。在本文件中，它只是用来解释为什么被放弃。
Rule (b) appears to forbid any usage in which the bits of the flow label are encoded with a specific semantic meaning. However, the words "MUST NOT assume" are to be interpreted precisely - if a router knows by configuration or by signaling that the flow label has been assigned in a certain way, it can make use of that knowledge. It is not made clear by the rule that there is an implied distinction between stateless models (in which there is no signaling, so no specific assumption about the meaning of the flow label value can be made) and stateful models (in which there is signaling and the router has explicit knowledge about the label).
规则（b）似乎禁止使用流标签的位编码具有特定语义的任何用法。然而，“不得假设”一词需要精确解释——如果路由器通过配置或通过发送信号知道流标签已以某种方式分配，则它可以利用该知识。该规则没有明确指出无状态模型（其中没有信令，因此无法对流标签值的含义做出具体假设）和有状态模型（其中有信令，路由器明确知道标签）之间存在隐含的区别。
If the word "alone" is overlooked, rule (c) has sometimes been interpreted as forbidding the use of the flow label as part of a hash used by load distribution mechanisms. In this case too, the word "alone" needs to be taken into account - a router is allowed to combine the flow label value with other data in order to produce a uniformly distributed hash.
如果忽略了“单独”一词，则规则（c）有时被解释为禁止使用流标签作为负载分布机制使用的哈希的一部分。在这种情况下，也需要考虑“单独”一词——允许路由器将流标签值与其他数据组合，以生成均匀分布的散列。
Both before and after these rules were laid down, a considerable number of proposals for use of the flow label were published that seem incompatible with them. Numerous examples and an analysis are presented in [RFC6294]. Those examples propose use cases in which some or all of the following apply:
在制定这些规则之前和之后，发布了大量使用流量标签的建议，这些建议似乎与这些规则不兼容。[RFC6294]中给出了大量示例和分析。这些示例提出了以下部分或全部适用的用例：
o The flow label may be changed by intermediate systems.
o 中间系统可更改流量标签。
o It doesn't matter if the flow label is changed, because the receiver doesn't use it.
o 流标签是否更改无关紧要，因为接收者不使用它。
o Some or all bits of the flow label are encoded: they have specific meanings understood by routers and switches along the path.
o 流标签的部分或所有位都经过编码：它们具有特定的含义，路径上的路由器和交换机可以理解。
o The encoding is related to the required quality of service, as well as identifying a flow.
o 编码与所需的服务质量以及识别流有关。
o The flow label is used to control forwarding or switching in some way.
o 流标签用于以某种方式控制转发或切换。
These proposals require either some form of semantics encoding in the bits of the flow label, or the ability for routers to modify the flow label, or both. Thus, they appear to infringe the rules from RFC 3697 quoted above.
这些建议要么要求在流标签的位中进行某种形式的语义编码，要么要求路由器能够修改流标签，或者两者兼而有之。因此，他们似乎违反了上述RFC 3697的规定。
We can conclude that a considerable number of researchers and designers have been stymied by RFC 3697. On the other hand, some other proposals discussed in [RFC6294] appear to be compatible with RFC 3697. Several are based on the originator of a packet choosing a pseudo-random flow label for each flow, which is one option suggested in RFC 3697. Thus, we can also conclude that there is a useful role for this approach.
我们可以得出结论，相当多的研究人员和设计师受到RFC3697的阻碍。另一方面，[RFC6294]中讨论的一些其他提案似乎与RFC 3697兼容。一些是基于数据包的发起者为每个流选择伪随机流标签，这是RFC3697中建议的一个选项。因此，我们还可以得出结论，这种方法具有有益的作用。
If our goal is for the flow label to be used in practice, the conflict between the various approaches creates a dilemma. There appear to be two major options:
如果我们的目标是在实践中使用流标签，那么各种方法之间的冲突会造成一个两难境地。似乎有两个主要的选择：
1. Discourage locally defined and/or stateful use of the flow label. Strengthen RFC 3697 to say that hosts should set a label value, without necessarily creating state, which would clarify and limit its possible uses. In particular, its use for load distribution and balancing would be encouraged.
1. 不鼓励本地定义和/或有状态地使用流标签。加强RFC 3697，使其说明主机应设置标签值，而不必创建状态，这将澄清并限制其可能的用途。特别是，将鼓励将其用于负载分配和平衡。
2. Relax the rules to encourage locally defined and/or stateful use of the flow label. This approach would make the flow label completely mutable and would exclude use cases depending on strict end-to-end immutability. It would encourage applications of a pseudo-random flow label, such as load distribution, on a local basis, but it would exclude end-to-end applications.
2. 放宽规则以鼓励本地定义和/或有状态地使用流标签。这种方法将使流标签完全可变，并根据严格的端到端不变性排除用例。它将鼓励在本地应用伪随机流标签，例如负载分布，但它将排除端到端应用。
There was considerable debate about these options and their variants during 2010 - 2011, with a variety of proposals in previous versions of this document and in mailing list discussions. After these discussions, there appears to be a view that simplicity should prevail, and that complicated proposals such as defining quality-of-service semantics in the flow label, or sub-dividing the flow label field into smaller sub-fields, will not prove efficient or deployable, especially in high-speed routers. There is also a clearly expressed view that using the flow label for various forms of stateless load distribution is the best simple application for it. At the same time, it is necessary to recognize that the strict immutability rule has drawbacks as noted above.
在2010-2011年期间，关于这些选项及其变体进行了大量辩论，在本文件以前的版本和邮件列表讨论中提出了各种各样的建议。在这些讨论之后，似乎有一种观点认为，简单性应该占上风，并且复杂的提议，例如在流标签中定义服务质量语义，或者将流标签字段细分为更小的子字段，将无法证明其有效性或可部署性，特别是在高速路由器中。还有一种明确的观点认为，将流标签用于各种形式的无状态负载分布是最好的简单应用程序。同时，有必要认识到，严格的不变性规则有上述缺陷。
Even under the rules of RFC 3697, the flow label is intrinsically untrustworthy, because modifications en route cannot be detected. For this reason, even with the current strict immutability rule, downstream nodes cannot rely mathematically on the value being unchanged. In this sense, any use of the flow label must be viewed
即使在RFC 3697的规则下，流标签本质上也是不可信的，因为无法检测到途中的修改。因此，即使使用当前严格的不变性规则，下游节点也不能在数学上依赖于保持不变的值。从这个意义上讲，必须查看流标签的任何使用
as an optimization on a best-effort basis; a packet with a changed (or zero) flow label value should never cause a hard failure.
尽最大努力进行优化；具有更改（或零）流标签值的数据包不应导致硬故障。
The remainder of this document discusses specific modifications to the standard, which are defined normatively in a companion document [RFC6437].
本文件的其余部分讨论了标准的具体修改，这些修改在配套文件[RFC6437]中进行了规范性定义。
Although RFC 3697 requires that the flow label be delivered unchanged, as noted above, it is not included in any transport-layer pseudo-header checksums nor in IPsec authentication [RFC4302]. Both RFC 2460 and RFC 3697 define the default flow label to be zero. At the time of writing, this is the observed value in an overwhelming proportion of IPv6 packets; the most widespread operating systems and applications do not set it, and routers do not rely on it. Thus, there is no reason to expect operational difficulties if a careful change is made to the rules of RFC 3697.
尽管RFC 3697要求流标签保持不变，如上所述，但它不包括在任何传输层伪报头校验和中，也不包括在IPsec身份验证[RFC4302]中。RFC 2460和RFC 3697都将默认流标签定义为零。在撰写本文时，这是绝大多数IPv6数据包中观察到的值；最广泛的操作系统和应用程序不设置它，路由器也不依赖它。因此，如果仔细修改RFC 3697的规则，则没有理由认为会出现操作困难。
In particular, the facts that the label is not checksummed and rarely used mean that the "immutability" of the label can be moderated without serious operational consequences.
特别是，标签没有校验和，很少使用，这意味着标签的“不变性”可以缓和，而不会产生严重的操作后果。
The purposes of the proposed changes are to remove the uncertainties left by RFC 3697, in order to encourage setting of the flow label by default, and to enable its generic use. The proposed generic use is to encourage uniformly distributed flow labels that can be used to assist load distribution or balancing. There should be no impact on existing IETF specifications other than RFC 3697 and no impact on currently operational software and hardware.
拟议变更的目的是消除RFC 3697留下的不确定性，以鼓励在默认情况下设置流量标签，并实现其通用性。建议的通用用途是鼓励均匀分布的流标签，这些标签可用于协助负载分布或平衡。除RFC 3697外，不应影响现有IETF规范，也不应影响当前运行的软件和硬件。
A secondary purpose is to allow changes to the flow label in a limited way, to allow hosts that do not set the flow label to benefit from it nevertheless. The fact that the flow label may in practice be changed en route is also reflected in the reformulation of the rules.
第二个目的是允许以有限的方式更改流标签，允许未设置流标签的主机从中受益。实际上，流量标签可能会在途中更改，这一事实也反映在规则的重新制定中。
A general description of the changes follows. The normative text is to be found in [RFC6437].
以下是对这些变化的一般描述。规范性文本见[RFC6437]。
The definition of a flow is subtly changed from RFC 3697 to allow any node, not just the source node, to set the flow label value. However, it is recommended that sources should set a uniformly distributed flow label value in all flows, replacing the less precise recommendation made in Section 3 of RFC 3697. Both stateful and stateless methods of assigning a uniformly distributed value could be used.
流的定义从RFC 3697微妙地更改为允许任何节点（而不仅仅是源节点）设置流标签值。但是，建议震源应在所有流量中设置均匀分布的流量标签值，以取代RFC 3697第3节中提出的不太精确的建议。可以使用分配均匀分布值的有状态和无状态方法。
Flow label values should be chosen such that their bits exhibit a high degree of variability, thus making them suitable for use as part of the input to a hash function used in a load distribution scheme. At the same time, third parties should have a low probability of guessing the next value that a source of flow labels will choose.
流标签值的选择应确保其位具有高度的可变性，从而使其适合用作负载分配方案中使用的哈希函数输入的一部分。同时，第三方猜测流量来源标签将选择的下一个值的概率应该很低。
In statistics, a discrete uniform distribution is defined as a probability distribution in which each value in a given range of equally spaced values (such as a sequence of integers) is equally likely to be chosen as the next value. The values in such a distribution exhibit both variability and unguessability. Thus, an approximation to a discrete uniform distribution is preferable as the source of flow label values. In contrast, an implementation in which flow labels are assigned sequentially is definitely not recommended, to avoid guessability.
在统计学中，离散均匀分布被定义为一种概率分布，其中在给定的等间距值范围内（如整数序列）的每个值都有可能被选为下一个值。这种分布中的值表现出可变性和不可用性。因此，优选离散均匀分布的近似值作为流量标签值的来源。相反，为避免猜测性，绝对不推荐按顺序分配流标签的实现。
In practice, it is expected that a uniform distribution of flow label values will be approximated by use of a hash function or a pseudo-random number generator. Either approach will produce values that will appear pseudo-random to an external observer.
在实践中，预期流标签值的均匀分布将通过使用散列函数或伪随机数生成器来近似。这两种方法都会产生对外部观察者来说是伪随机的值。
Section 3 of RFC 3697 allows nodes to participate in an unspecified stateful method of flow state establishment. The changes do not remove that option, but clarify that stateless models are also possible and are the recommended default. The specific text on requirements for stateful models has been reduced to a bare minimum requirement that they do not interfere with the stateless model. To enable stateless load distribution at any point in the Internet, a node using a stateful model should never send packets whose flow label values do not conform to a uniform distribution.
RFC3697的第3节允许节点参与流状态建立的未指定状态方法。这些更改并没有删除该选项，但澄清了无状态模型也是可能的，并且是推荐的默认模型。关于有状态模型需求的具体文本已经减少到一个最低要求，即它们不会干扰无状态模型。要在Internet上的任何一点启用无状态负载分布，使用有状态模型的节点不应发送其流标签值不符合统一分布的数据包。
The main novelty is that a forwarding node (typically a first-hop or ingress router) may set the flow label value if the source has not done so, according to the same recommendations that apply to the source. This might place a considerable processing load on ingress routers that choose to do so, even if they adopted a stateless method of flow identification and label assignment.
主要新颖之处在于，转发节点（通常是第一跳或入口路由器）可以根据应用于源的相同建议，在源没有这样做的情况下设置流标签值。这可能会给选择这样做的入口路由器带来相当大的处理负载，即使它们采用了流标识和标签分配的无状态方法。
The value of the flow label, once it has been set, must not be changed. However, some qualifications are placed on this rule, to allow for the fact that the flow label is an unprotected field and might be misused. No Internet-wide mechanism can depend mathematically on immutable flow labels. The new rules require that flow labels exported to the Internet should always be either zero or uniformly distributed, but even this cannot be relied on mathematically. Use cases need to be robust against non-conforming
流量标签的值一旦设置，就不能更改。然而，为了考虑到流量标签是一个未受保护的字段并且可能被误用的事实，对该规则进行了一些限定。没有一种互联网范围的机制可以在数学上依赖于不变的流标签。新规则要求导出到互联网的流量标签应始终为零或均匀分布，但即使是这样，也不能从数学上依赖。用例需要对不一致性具有鲁棒性
flow label values. This will also enhance compatibility with any legacy hosts that set the flow label according to RFC 2460 and RFC 3697.
流标签值。这还将增强与根据RFC 2460和RFC 3697设置流标签的任何遗留主机的兼容性。
A complication that led to much discussion is the possibility that hosts inside a particular network domain might use a stateful method of setting the flow label, and that packets bearing stateful labels might then erroneously escape the domain and be received by nodes performing stateless processing, such as load balancing. This might result in undesirable operational implications (e.g., congestion, reordering) for not only the inappropriately flow-labeled packets, but also well-behaved flow-labeled packets, during forwarding at various intermediate devices. It was suggested that border routers might "correct" this problem by overwriting such labels in packets leaving the domain. However, neither domain border egress routers nor intermediate routers/devices (using a flow label, for example, as a part of an input key for a load-distribution hash) can determine by inspection that a value is not part of a uniform distribution. Thus, there is no way that such values can be detected and "corrected". Therefore, the recommendation to choose flow labels from a uniform distribution also applies to stateful schemes.
导致大量讨论的一个复杂因素是，特定网络域内的主机可能使用有状态方法设置流标签，而带有有状态标签的数据包可能随后错误地脱离域，并被执行无状态处理（如负载平衡）的节点接收。这可能导致在各种中间设备的转发期间，不仅对不适当的流标记数据包，而且对行为良好的流标记数据包产生不希望的操作影响（例如，拥塞、重新排序）。有人建议，边界路由器可以通过覆盖离开域的数据包中的此类标签来“纠正”这个问题。然而，域边界出口路由器或中间路由器/设备（例如，使用流标签作为负载分布散列的输入键的一部分）都不能通过检查来确定值不是均匀分布的一部分。因此，无法检测和“纠正”此类值。因此，从均匀分布中选择流标签的建议也适用于有状态方案。
The following are some practical consequences of the above changes:
以下是上述变化的一些实际后果：
o Sending hosts that are not updated will in practice continue to send all-zero labels. If there is no label-setting router along the path taken by a packet, the label will be delivered as zero.
o 发送未更新的主机实际上将继续发送所有零标签。如果在一个包所走的路径上没有标签设置路由器，标签将作为零交付。
o Sending hosts conforming to the new specification will by default choose uniformly distributed labels between 1 and 0xFFFFF.
o 默认情况下，符合新规范的发送主机将选择1到0xFFFFF之间的均匀分布标签。
o Sending hosts may continue to send all-zero labels, in which case an ingress router may set uniformly distributed labels between 1 and 0xFFFFF.
o 发送主机可以继续发送所有零标签，在这种情况下，入口路由器可以在1和0xFFFFF之间设置均匀分布的标签。
o The flow label is no longer unrealistically asserted to be strictly immutable; it is recognized that it may, incorrectly, be changed en route. In some circumstances, this will break end-to-end usage, e.g., potential detection of third-party spoofing attacks [LABEL-SEC].
o 流标签不再不切实际地断言为严格不可变；人们认识到，可能会在途中错误地更改。在某些情况下，这将中断端到端的使用，例如，可能检测到第三方欺骗攻击[LABEL-SEC]。
o The expected default usage of the flow label is some form of stateless load distribution, such as the ECMP/LAG usage defined in [RFC6438].
o 流标签的预期默认用法是某种形式的无状态负载分布，如[RFC6438]中定义的ECMP/LAG用法。
o If the new rules are followed, all IPv6 traffic flows on the Internet should have zero or uniformly distributed flow label values.
o 如果遵循新规则，Internet上的所有IPv6流量都应具有零或均匀分布的流量标签值。
From an operational viewpoint, existing IPv6 hosts that set a default (zero) flow label value and ignore the flow label on receipt will be unaffected by implementations of the new specification. In general, it is assumed that hosts will ignore the value of the flow label on receipt; it cannot be relied on as an end-to-end signal. However, this doesn't apply if a cryptographically generated label is being used to detect attackers [LABEL-SEC].
从操作角度来看，设置默认（零）流标签值并在收到时忽略流标签的现有IPv6主机将不受新规范实施的影响。通常，假设主机在接收时忽略流标签的值；它不能作为端到端信号。但是，如果使用加密生成的标签来检测攻击者[label-SEC]，则不适用此规定。
Similarly, routers that ignore the flow label will be unaffected by implementations of the specification.
类似地，忽略流标签的路由器将不受规范实现的影响。
Hosts that set a default (zero) flow label but are in a domain where routers set a label as recommended in Section 3 will benefit from whatever flow label handling is used on the path.
设置默认（零）流标签但位于路由器按照第3节中的建议设置标签的域中的主机将受益于路径上使用的任何流标签处理。
Hosts and routers that adopt the recommended mechanism will enhance the performance of any load balancing devices that include the flow label in the hash used to select a particular path or server, even when packets leave the local domain.
采用推荐机制的主机和路由器将提高任何负载平衡设备的性能，这些设备在用于选择特定路径或服务器的哈希中包括流标签，即使数据包离开本地域。
See [RFC6437] and [LABEL-SEC] for full discussion. Some useful remarks are in [Partridge].
有关详细讨论，请参见[RFC6437]和[LABEL-SEC]。[鹧鸪]中有一些有用的评论。
The authors are grateful to Qinwen Hu for general discussion about the flow label and for his work in searching the literature. Valuable comments and contributions were made by Ran Atkinson, Fred Baker, Steve Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony Hain, Joel Halpern, Chris Morrow, Thomas Narten, Pekka Savola, Mark Smith, Pascal Thubert, Iljitsch van Beijnum, and other participants in the 6man working group.
作者感谢胡钦文对流量标签的一般性讨论以及他在文献检索方面所做的工作。Ran Atkinson、Fred Baker、Steve Blake、Remi Despres、Alan Ford、Fernando Gont、Brian Haberman、Tony Hain、Joel Halpern、Chris Morrow、Thomas Narten、Pekka Savola、Mark Smith、Pascal Thubert、Iljitsch van Beijnum和6man工作组的其他参与者发表了宝贵的评论和贡献。
[FLOWSWITCH] Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", Work in Progress, March 2007.
[FLOWSWITCH]Beckman，M.，“IPv6动态流标签交换（FLS）”，正在进行的工作，2007年3月。
[LABEL-SEC] Gont, F., "Security Assessment of the IPv6 Flow Label", Work in Progress, November 2010.
[LABEL-SEC]Gont，F.，“IPv6流标签的安全评估”，正在进行的工作，2010年11月。
[McGann05] McGann, O. and D. Malone, "Flow Label Filtering Feasibility", European Conference on Computer Network Defence , 2005.
[McGann05]McGann，O.和D.Malone，“流量标签过滤可行性”，欧洲计算机网络防御会议，2005年。
[NIST] Frankel, S., Graveman, R., Pearce, J., and M. Rooks, "Guidelines for the Secure Deployment of IPv6", National Institute of Standards and Technology Special Publication 800-119, 2010, <http://csrc.nist.gov/ publications/nistpubs/800-119/sp800-119.pdf>.
[NIST]Frankel，S.，Graveman，R.，Pearce，J.，和M.Rooks，“IPv6安全部署指南”，国家标准与技术研究所特别出版物800-1192010<http://csrc.nist.gov/ 出版物/nistpubs/800-119/sp800-119.pdf>。
[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>.
[NSA]Potyraj，C.，“IPv6的防火墙设计考虑”，国家安全局I733-041R-2007，2007<http://www.nsa.gov/ia/_files/ipv6/I733-041R-2007.pdf>.
[Partridge] Partridge, C., Arsenault, A., and S. Kent, "Information Assurance and the Transition to IP Version 6 (IPv6)", Military Communications Conference (MILCOM 2007) , 2007, <http://www.ir.bbn.com/documents/articles/ MILCOM_Paper_from_Proceedings.pdf>.
[Partridge]Partridge，C.，Arsenault，A.，和S.Kent，“信息保障和向IP版本6（IPv6）的过渡”，军事通信会议（MILCOM 2007），2007年<http://www.ir.bbn.com/documents/articles/ MILCOM论文摘自《美国医学会学报》pdf>。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[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月。
[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.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3697]Rajahalme，J.，Conta，A.，Carpenter，B.，和S.Deering，“IPv6流标签规范”，RFC 36972004年3月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[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月。
[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月。
[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月。
A model was discussed in an earlier version of this document which defined a notion of 'flow label domain' analogous to a differentiated services domain [RFC2474]. This model would have encouraged local usage of the flow label as an alternative to any form of generic use, but it required complex rules for the behavior of domain boundary routers, and proved controversial in discussion.
本文档的早期版本中讨论了一个模型，该模型定义了“流标签域”的概念，类似于区分服务域[RFC2474]。该模型鼓励本地使用流标签作为任何形式的通用使用的替代，但它需要域边界路由器行为的复杂规则，并且在讨论中被证明是有争议的。
Two even more complex alternative approaches were also considered and rejected.
还审议了两种更为复杂的备选办法，并予以拒绝。
The first was to distinguish locally significant flow labels from those conforming to RFC 3697 by setting or clearing the most significant bit (MSB) of the flow label. This led to quite complicated rules, seems impossible to make fully self-consistent, and was not considered practical.
第一种方法是通过设置或清除流标签的最高有效位（MSB），将本地有效流标签与符合RFC 3697的流标签区分开来。这导致了相当复杂的规则，似乎不可能使完全自我一致，也被认为是不实际的。
The second was to use a specific differentiated services code point (DSCP) [RFC2474] in the Traffic Class octet instead of the MSB of the flow label itself, to flag a locally defined behavior. A more elaborate version of this was proposed in [FLOWSWITCH]. There are two issues with that approach. One is that DSCP values are themselves only locally significant, inconsistent with the end-to-end nature of the original flow label definition. Secondly, it seems unwise to meld the semantics of differentiated services, which are currently deployed, with the unknown future semantics of flow label usage. However, this approach, while not recommended, does not appear to violate any basic principles if applied strictly within a single differentiated services domain.
第二种方法是在流量类八位字节中使用特定的区分服务代码点（DSCP）[RFC2474]，而不是流标签本身的MSB，以标记本地定义的行为。[FLOWSWITCH]中提出了更详细的版本。这种方法有两个问题。一个是DSCP值本身只是局部重要的，与原始流标签定义的端到端性质不一致。其次，将当前部署的区分服务的语义与未来未知的流标签使用语义相结合似乎是不明智的。然而，这种方法虽然不被推荐，但如果严格地应用于单个差异化服务领域，似乎不会违反任何基本原则。
Authors' Addresses
作者地址
Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd Broomfield, CO 80021 USA
美国科罗拉多州布鲁姆菲尔德埃尔多拉多大道1025号Shane Amante三级通信有限责任公司，邮编80021
EMail: shane@level3.net
EMail: shane@level3.net
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