Independent Submission Q. Hu
Request for Comments: 6294 B. Carpenter
Category: Informational Univ. of Auckland
ISSN: 2070-1721 June 2011
Independent Submission Q. Hu
Request for Comments: 6294 B. Carpenter
Category: Informational Univ. of Auckland
ISSN: 2070-1721 June 2011
Survey of Proposed Use Cases for the IPv6 Flow Label
IPv6流标签的拟议用例调查
Abstract
摘要
The IPv6 protocol includes a flow label in every packet header, but this field is not used in practice. This paper describes the flow label standard and discusses the implementation issues that it raises. It then describes various published proposals for using the flow label and shows that most of them are inconsistent with the standard. Methods to address this problem are briefly reviewed. We also question whether the standard should be revised.
IPv6协议在每个数据包头中都包含一个流标签，但在实践中不使用此字段。本文描述了流标签标准，并讨论了它提出的实现问题。然后描述了使用流量标签的各种已发布建议，并表明其中大多数建议与标准不一致。简要回顾了解决这一问题的方法。我们还质疑是否应该修订该标准。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc6294.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6294.
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. A Brief History of the Flow Label . . . . . . . . . . . . 2
1.2. The Flow Label and Quality of Service . . . . . . . . . . 3
2. Flow Label Definition and Issues . . . . . . . . . . . . . . . 4
2.1. Flow Label Properties . . . . . . . . . . . . . . . . . . 4
2.2. Dependency Prohibition . . . . . . . . . . . . . . . . . . 5
2.3. Other Issues . . . . . . . . . . . . . . . . . . . . . . . 5
3. Documented Proposals for the Flow Label . . . . . . . . . . . 6
3.1. Specify the Flow Label as a Pseudo-Random Value . . . . . 7
3.1.1. End-to-End QoS Provisioning . . . . . . . . . . . . . 7
3.1.2. Load-Balancing . . . . . . . . . . . . . . . . . . . . 8
3.1.3. Security Nonce . . . . . . . . . . . . . . . . . . . . 8
3.2. Specify QoS Parameters in the Flow Label . . . . . . . . . 8
3.3. Use Flow Label Hop-by-Hop to Control Switching . . . . . . 9
3.4. Diffserv Use of IPv6 Flow Label . . . . . . . . . . . . . 12
3.5. Other Uses . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. Informative References . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. A Brief History of the Flow Label . . . . . . . . . . . . 2
1.2. The Flow Label and Quality of Service . . . . . . . . . . 3
2. Flow Label Definition and Issues . . . . . . . . . . . . . . . 4
2.1. Flow Label Properties . . . . . . . . . . . . . . . . . . 4
2.2. Dependency Prohibition . . . . . . . . . . . . . . . . . . 5
2.3. Other Issues . . . . . . . . . . . . . . . . . . . . . . . 5
3. Documented Proposals for the Flow Label . . . . . . . . . . . 6
3.1. Specify the Flow Label as a Pseudo-Random Value . . . . . 7
3.1.1. End-to-End QoS Provisioning . . . . . . . . . . . . . 7
3.1.2. Load-Balancing . . . . . . . . . . . . . . . . . . . . 8
3.1.3. Security Nonce . . . . . . . . . . . . . . . . . . . . 8
3.2. Specify QoS Parameters in the Flow Label . . . . . . . . . 8
3.3. Use Flow Label Hop-by-Hop to Control Switching . . . . . . 9
3.4. Diffserv Use of IPv6 Flow Label . . . . . . . . . . . . . 12
3.5. Other Uses . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. Informative References . . . . . . . . . . . . . . . . . . . . 14
IPv6 is being introduced to overcome the address shortage of the current IPv4 protocol, but it also offers a new feature, i.e., the Flow Label field in the IPv6 packet header. The flow label is not encrypted by IPsec and is present in all fragments. However, it is used very little in practice, for reasons discussed below and in [Amante11]. After a short introduction, this document summarizes the current specification of the IPv6 flow label and some open issues about its use in Section 2. Section 3 describes and analyzes various proposals that have been made for its use. Finally, Section 4 discusses the implications and attempts to draw conclusions.
IPv6的引入是为了克服当前IPv4协议的地址不足，但它还提供了一个新功能，即IPv6数据包头中的流标签字段。流标签不是由IPsec加密的，并且存在于所有片段中。然而，由于下文和[Amante11]中讨论的原因，它在实践中很少使用。在简短介绍之后，本文档在第2节中总结了IPv6流标签的当前规范以及有关其使用的一些未决问题。第3节描述并分析了为其使用而提出的各种建议。最后，第4节讨论了影响并试图得出结论。
The Flow Label field occupies bits 12 through 31 of the IPv6 packet header. It provides a potential way to mark a packet, identify a flow, and look up the corresponding flow state. This field is always present in an IPv6 header, so a phrase such as "a packet with no flow label" refers to a packet whose Flow Label field contains 20 zero bits, i.e., a flow label whose value is zero.
流标签字段占用IPv6数据包头的第12位到第31位。它提供了一种标记数据包、识别流和查找相应流状态的潜在方法。此字段始终存在于IPv6报头中，因此诸如“没有流标签的数据包”之类的短语指其流标签字段包含20个零位的数据包，即其值为零的流标签。
The original proposal for a flow label has been attributed to Dave Clark [Deering93], who proposed that it should contain a pseudo-random value. A Flow Label field was included in the packet header
关于流标签的最初建议是由Dave Clark[Deering93]提出的，他建议它应该包含一个伪随机值。数据包头中包含一个流标签字段
during the preliminary design of IPv6, which followed an intense period of debate about several competing proposals. The final choice was made in 1994 [RFC1752]. In particular, the IETF rejected a proposal known as the Common Architecture for Next Generation Internet Protocol (CATNIP) [RFC1707], which included so-called 'cache handles' to identify the next hop in high-performance routers. Thus, CATNIP introduced the notion of a header field that would be shared by all packets belonging to a flow, to control packet forwarding on a hop-by-hop basis. We recognize this today as a precursor of the MPLS label [RFC3031].
在IPv6的初步设计期间，围绕几个相互竞争的提案展开了激烈的辩论。最终选择是在1994年[RFC1752]。特别是，IETF拒绝了一项被称为下一代互联网协议（CATNIP）[RFC1707]的提案，该提案包括所谓的“缓存句柄”，用于识别高性能路由器中的下一跳。因此，CATNIP引入了报头字段的概念，该字段将由属于一个流的所有数据包共享，以便在逐跳的基础上控制数据包转发。我们今天认识到这是MPLS标签[RFC3031]的前身。
The IETF decided instead to develop a proposal known as the Simple Internet Protocol plus (SIPP) [RFC1710] into IP version 6. SIPP included "labeling of packets belonging to particular traffic 'flows' for which the sender requests special handling, such as non-default quality of service or 'real-time' service" [RFC1710]. In 1994, this used a 28-bit Flow Label field. In 1995, it was down to 24 bits [RFC1883], and it was finally reduced to 20 bits [RFC2460] to accommodate the IPv6 Traffic Class, which is fully compatible with the IPv4 Type of Service byte.
IETF决定将一个名为简单互联网协议plus（SIPP）[RFC1710]的提案开发成IP版本6。SIPP包括“属于特定流量“流”的数据包的标签，发送方请求对其进行特殊处理，例如非默认服务质量或“实时”服务”[RFC1710]。1994年，它使用了一个28位的流标签字段。1995年，它降到了24位[RFC1883]，最后降到了20位[RFC2460]，以适应IPv6流量类别，它与IPv4类型的服务字节完全兼容。
There was considerable debate in the IETF about the very purpose of the flow label. Was it to be a handle for fast switching, as in CATNIP, or was it to be meaningful to applications and used to specify quality of service? Must it be set by the sending host, or could it be set by routers? Could it be modified en route, or must it be delivered with no change?
IETF中对流量标签的用途进行了大量的讨论。它是像CATNIP那样用于快速切换的手柄，还是对应用程序有意义并用于指定服务质量？它必须由发送主机设置，还是可以由路由器设置？是否可以在途中修改，或者必须在交付时不做任何更改？
Because of these uncertainties, and more urgent work, the flow label was consistently ignored by implementors, and today is set to zero in almost every IPv6 packet. In fact, [RFC2460] defined it as "experimental and subject to change". There was considerable preliminary work, such as [Metzler00], [Conta01a], [Conta01b], and [Hagino01]. The ensuing proposed standard "IPv6 Flow Label Specification" (RFC 3697) [RFC3697] intended to clarify this situation by providing precise boundary conditions for use of the flow label. However, this has not proved successful in promoting use of the flow label in practice, as a result of which 20 bits are unused in every IPv6 packet header.
由于这些不确定性和更紧迫的工作，流标签一直被实现者忽略，现在几乎在每个IPv6数据包中都设置为零。事实上，[RFC2460]将其定义为“实验性的，可改变的”。有大量的前期工作，如[Metzler00]、[Conta01a]、[Conta01b]和[Hagino01]。随后提出的标准“IPv6流标签规范”（RFC 3697）[RFC3697]旨在通过提供流标签使用的精确边界条件来澄清这种情况。然而，事实证明，这并没有成功地在实践中推广流标签的使用，这导致每个IPv6数据包报头中有20位未使用。
Developments in high-speed switch design, and the success of MPLS, have largely obviated consideration of the flow label for high-speed switching. Thus, although various use cases for the flow label have been proposed, most of them assume that it should be used principally to support the provision of quality of service (QoS). For many years, it has been recognized that real-time Internet traffic
高速交换机设计的发展和MPLS的成功在很大程度上避免了对高速交换机的流标签的考虑。因此，尽管已经提出了流标签的各种用例，但大多数都假设它主要用于支持服务质量（QoS）的提供。多年来，人们已经认识到实时互联网流量
requires a different QoS from general data traffic, and this remains true in the era of network neutrality. Thus, an alternative to uniform best-effort service is needed, requiring packets to be classified as belonging to a particular class of service or flow. Currently, this leads to a layer violation problem, since a 5-tuple is often used to classify each packet. The 5-tuple includes source and destination addresses, port numbers, and the transport protocol type, so when we want to forward or process packets, we need to extract information from the layer above IP. This may be impossible when packets are encrypted such that port numbers are hidden, or when packets are fragmented, so the layer violation is not an academic concern. The flow label, being exempt from IPsec encryption and being replicated in packet fragments, avoids this difficulty. It has therefore attracted attention from the designers of new approaches to QoS.
需要不同于一般数据流量的QoS，在网络中立的时代，这一点仍然是正确的。因此，需要统一尽力而为服务的替代方案，要求分组被分类为属于特定服务类别或流。目前，这导致了层冲突问题，因为通常使用5元组对每个数据包进行分类。5元组包括源地址和目标地址、端口号和传输协议类型，因此当我们想要转发或处理数据包时，我们需要从IP上面的层提取信息。当数据包被加密，端口号被隐藏，或者数据包被分割时，这可能是不可能的，因此层冲突不是一个学术问题。流标签不受IPsec加密的限制，并在数据包片段中复制，从而避免了这一困难。因此，它引起了QoS新方法设计者的注意。
RFC 3697 [RFC3697] standardizes properties of the flow label, including the following:
RFC 3697[RFC3697]标准化了流量标签的属性，包括以下内容：
o If the packets are not part of any flow, the flow label value is zero.
o 如果数据包不是任何流的一部分，则流标签值为零。
o The 3-tuple {source address, destination address, flow label} uniquely identifies which packets belong to which particular flow.
o 三元组{源地址、目标地址、流标签}唯一标识哪些数据包属于哪个特定流。
o Packets can receive flow-specific treatment if the node has been set up with flow-specific state.
o 如果节点已设置为特定于流的状态，则数据包可以接收特定于流的处理。
o The flow label set by the source node must be delivered to the destination node; i.e., it is an end-to-end label.
o 源节点设置的流标签必须传递到目的节点；i、 例如，它是一个端到端标签。
o The same pair of source and destination addresses must not use the same flow label value again within a timeout of at least 120 seconds.
o 在至少120秒的超时时间内，同一对源地址和目标地址不得再次使用相同的流标签值。
One effect of the second of these rules is to avoid the layer violation problem mentioned in Section 1. By using the 3-tuple, we only use the IP layer to classify packets, without needing any transport-layer information. This may reduce the lookup time if flow-based treatment is required and will work even with IPsec encryption and fragmentation. Therefore, for traffic needing other than best-effort service, such as real-time applications, the flow label can be set to different values to represent different flows, and each node forwarding or receiving the packets may provide
第二条规则的一个效果是避免第1节中提到的图层冲突问题。通过使用三元组，我们只使用IP层对数据包进行分类，而不需要任何传输层信息。如果需要基于流的处理，这可能会减少查找时间，甚至可以与IPsec加密和碎片一起使用。因此，对于除了尽力而为服务之外需要的业务，例如实时应用，可以将流标签设置为不同的值以表示不同的流，并且转发或接收分组的每个节点可以提供
different flow-specific treatments by looking at the flow label value. This is more fine-grained than differentiated services (Diffserv) [Carpenter02] [RFC2474] but need not be less efficient.
通过查看“流标签”值，可以进行不同的流特定处理。这比区分服务（Diffserv）[Carpenter02][RFC2474]更细粒度，但不一定效率更低。
An additional important rule in the standard [RFC3697] effectively forbids any encoding of meaning in the bits of the flow label. To be exact, the standard states that "IPv6 nodes MUST NOT assume any mathematical or other properties of the flow label values assigned by source nodes". This rule is aimed at the case where a packet from a source using a particular encoding scheme for the flow label reaches a node that is using a different scheme. If, by chance, the bit pattern in the flow label is meaningful in both schemes, the receiver would misinterpret the flow label. Therefore, in the absence of other information, the receiver must not assume anything about the meaning of the value of the flow label.
标准[RFC3697]中的另一条重要规则有效地禁止流标签位中的任何意义编码。确切地说，该标准规定“IPv6节点不得假定源节点分配的流标签值的任何数学或其他属性”。该规则针对来自使用流标签的特定编码方案的源的数据包到达使用不同方案的节点的情况。如果碰巧，流标签中的位模式在这两种方案中都有意义，则接收器将误解流标签。因此，在没有其他信息的情况下，接收方不得对流标签的值的含义进行任何假设。
The standard [RFC3697] also states that "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". The problem this rule is intended to avoid is that if a source uses one method of choosing flow labels (e.g., counting up from 1), any router that assumes another method (e.g., pseudo-randomness) may not perform as intended.
标准[RFC3697]还规定“路由器性能不应取决于流标签值的分布。特别是，流标签位本身就不适合作为散列键的材料”。此规则旨在避免的问题是，如果源使用一种选择流标签的方法（例如，从1开始计数），则采用另一种方法（例如，伪随机性）的任何路由器可能无法按预期执行。
Note that there is no easy escape from the combination of these two prohibitions, which we will call the dependency prohibition. Unlike Diffserv code points, flow labels are not locally significant within a single administrative domain; they must be preserved end-to-end. In general, a router cannot know whether a particular packet originated in a host supporting a specific usage of the flow label. Therefore, any method that breaks one or both of these rules will only work if there is some way for a router to determine which sources use the same scheme as itself.
请注意，这两种禁令的结合并不能轻易避免，我们称之为依赖性禁令。与Diffserv代码点不同，流标签在单个管理域中并不具有局部意义；它们必须端到端地保存。通常，路由器无法知道特定数据包是否起源于支持流标签特定用法的主机。因此，任何违反一条或两条规则的方法只有在路由器有办法确定哪些源使用与自身相同的方案时才能起作用。
The interpretation of the dependency rule can be subtle and is not spelled out in [RFC3697]. A node must not assume properties of the flow label -- but it may know them by construction or by signaling. The bits of the flow label alone are poor material for a hash key -- but they may be combined with bits from other sources, to provide uniformly distributed hash outputs.
依赖关系规则的解释可能很微妙，在[RFC3697]中没有详细说明。节点不能假定流标签的属性——但它可以通过构造或信令来了解这些属性。仅流标签的位对于散列键来说是不好的材料——但它们可以与来自其他源的位组合，以提供均匀分布的散列输出。
[RFC3697] does not discuss how to use the flow label most effectively. This remains the major open issue, but some authors propose that the label should be used with reserved bandwidth to
[RFC3697]未讨论如何最有效地使用流标签。这仍然是一个主要的开放问题，但一些作者建议，标签应与保留带宽一起使用，以
achieve customized QoS provision. Coupled with admission control at the edge router, this could limit congestion. However, as we will see below, this is not the only proposed use.
实现定制的QoS提供。再加上边缘路由器的准入控制，这可以限制拥塞。然而，正如我们将在下面看到的，这并不是唯一建议的用途。
We now introduce some other open issues.
我们现在介绍一些其他未决问题。
o Unknown flow labels: [RFC1809] proposed that when a router receives a datagram with an unknown flow label, it should treat it as zero. However, the standard [RFC3697] is silent on this issue. Indeed, some methods of flow state establishment might choose to use an unknown label as the trigger for creating flow state.
o 未知流标签：[RFC1809]建议当路由器接收到具有未知流标签的数据报时，应将其视为零。然而，标准[RFC3697]对此问题没有提及。实际上，流状态建立的某些方法可能会选择使用未知标签作为创建流状态的触发器。
o Deleting old flow labels: When a flow finishes, how does the router know the flow label has expired? Should this be based on a timeout, on observation of the transport layer, or on explicit signaling? [RFC3697] defines a timeout (120 seconds) that effectively imposes a maximum lifetime on flow label state in a router. This implies that flow labeling is inappropriate for very intermittent flows, unless there is some mechanism to refresh router state. In contrast, [Banerjee02] suggested that a router should send an ICMP message to the source prior to deleting a particular label. The source node may then send a KEEPALIVE message to the router; if it does not, the router will release that label.
o 删除旧流标签：当流结束时，路由器如何知道流标签已过期？这是基于超时、传输层观察还是显式信令？[RFC3697]定义一个超时（120秒），该超时有效地在路由器中对流标签状态施加最大生存期。这意味着流标签不适合非常间歇的流，除非有某种机制刷新路由器状态。相反，[Banerjee02]建议路由器在删除特定标签之前向源发送ICMP消息。然后，源节点可以向路由器发送KEEPALIVE消息；如果没有，路由器将释放该标签。
o Choosing when to set the flow label: For what kinds of applications should we set up non-zero flow labels? [RFC1809] suggested not setting it for short flows containing few bytes but using it for long TCP connections and some real-time applications.
o 选择何时设置流标签：我们应该为哪些类型的应用程序设置非零流标签？[RFC1809]建议不要将其设置为包含少量字节的短流，而是将其用于长TCP连接和一些实时应用程序。
o Can we modify the flow label? [RFC3697] states that the flow label must be delivered unchanged. There are several advantages of immutable flow labels, apart from respecting the standard: the rule is easy to understand, does not require extra processing in routers or a signaling protocol, and allows for very simple host implementations. Also, it is straightforward for hosts and routers to simply ignore the flow label. However, this rule does appear to exclude any MPLS-like or CATNIP-like use for optimized packet switching. Some of the proposed mechanisms described below contradict this by suggesting that switches should change the flow label for routing purposes.
o 我们可以修改流量标签吗？[RFC3697]规定必须原封不动地交付流量标签。除了遵守标准外，不可变流标签还有几个优点：规则易于理解，不需要在路由器或信令协议中进行额外处理，并且允许非常简单的主机实现。此外，主机和路由器可以直接忽略流标签。然而，该规则似乎排除了用于优化分组交换的任何类似MPLS或类似CATNIP的用途。下面描述的一些建议的机制与此相矛盾，建议交换机出于路由目的应更改流标签。
In the following, we do not intend to recommend or criticize various proposals. This section shows the variety of proposals that have been published, and whether they are compatible with the existing standard. These proposals almost all assume that the flow label's
在下文中，我们不打算推荐或批评各种建议。本节显示了已发布的各种方案，以及它们是否与现有标准兼容。这些建议几乎都假设流标签
main purpose is to support QoS, and their flow label mechanisms are entangled with QoS mechanisms. We describe the proposals in five broad, and somewhat overlapping, categories, i.e.,
其主要目的是支持QoS，而其流标签机制与QoS机制纠缠在一起。我们将提案分为五大类，且有些重叠，即：。，
1. using pseudo-random flow label values for various purposes (for example, to improve routing performance when retrieving cached routing state);
1. 为各种目的使用伪随机流标签值（例如，在检索缓存的路由状态时提高路由性能）；
2. defining specific QoS requirements as parameters embedded in the flow label field;
2. 将特定的QoS需求定义为嵌入在流标签字段中的参数；
3. using the flow label to control packet switching;
3. 使用流标签控制分组交换；
4. using the flow label specifically to extend the existing differentiated services QoS architecture;
4. 专门使用流标签来扩展现有的区分服务QoS架构；
5. other uses.
5. 其他用途。
Among the proposals described in the following five sections, various methods are proposed to set up the flow label value. It should be noted that some of these proposals embody novel and perhaps controversial approaches to QoS provision, and these cannot readily be separated from their use of the flow label. We give a reasonable amount of technical detail for some of the proposals, to show the extent to which they propose detailed semantics for the flow label value.
在以下五节中描述的方案中，提出了各种方法来设置流量标签值。应该注意的是，这些建议中的一些体现了QoS提供的新颖且可能有争议的方法，并且这些方法不能轻易地与流标签的使用分开。我们为一些建议提供了合理数量的技术细节，以显示他们对流标签值提出详细语义的程度。
As our first example, [Lin06] specifies a 17-bit pseudo-random value. The figure below shows the proposed flow label structure.
作为我们的第一个示例，[Lin06]指定一个17位伪随机值。下图显示了建议的流标签结构。
o The Label Flag (LF) bit: 1 means this type of flow label is present. We note that this encoding is incompatible with the dependency prohibition in [RFC3697], since a source that does not use this method may also set the LF bit.
o 标签标志（LF）位：1表示存在这种类型的流标签。我们注意到该编码与[RFC3697]中的依赖项禁止不兼容，因为不使用该方法的源也可能设置LF位。
o The Label Type (LT): 2 bits; describes the type of packet.
o 标签类型（LT）：2位；描述数据包的类型。
o The Label Number (LN): randomly generated by the source node.
o 标签号（LN）：由源节点随机生成。
[Lin06] also describes a signaling process between source, routing, and destination nodes based on this label structure and on the IPv6 Traffic Class byte, in order to reserve and release router resources for a given flow within a given class of traffic. The pseudo-random LN value is used to uniquely identify a given flow.
[Lin06]还描述了基于此标签结构和IPv6流量类字节的源节点、路由节点和目标节点之间的信令过程，以便为给定流量类中的给定流保留和释放路由器资源。伪随机LN值用于唯一标识给定流。
Flow Label Specification (figure simplified from [Lin06])
流量标签规范（图由[Lin06]简化）
+--+----+-----------------------------+
| 1| 2 | 17 bits |
+--+----+-----------------------------+
|LF| LT | LN |
+--+----+-----------------------------+
+--+----+-----------------------------+
| 1| 2 | 17 bits |
+--+----+-----------------------------+
|LF| LT | LN |
+--+----+-----------------------------+
LF 0 Disable 1 Enable LT 00 Flow label requested by source 01 Flow label returned by destination 10 Flow label for data delivery 11 Flow label terminates connection LN Random number created by source
如果0禁用1启用源请求的LT 00流标签01目标返回的流标签10数据传递的流标签11流标签终止源创建的连接LN随机数
There have been numerous informal discussions of using pseudo-random flow labels to allow load-balancing or at least load-sharing. This would be achieved by including the flow label value among the fields in each packet header used as input to a modulo(N) hash used to select among N alternative paths. However, concerns about the interpretation of the dependency prohibition have generally prevented such proposals from being written up until recently [Carpenter11].
关于使用伪随机流标签来实现负载平衡或至少负载共享，已经有很多非正式的讨论。这将通过在每个分组报头中的字段中包括流标签值来实现，该字段用作模（N）散列的输入，模（N）散列用于在N个备选路径中进行选择。然而，直到最近，对依赖性禁令解释的担忧一直阻碍着此类提案的撰写[Carpenter11]。
Another proposal for a pseudo-random flow label value is [Blake09]. This states that off-path spoofing attacks have become a big issue for TCP and other transport-layer applications, and proposes that in IPv6 we should set a random value in the flow label to make the packet header more complex and less easy for the attacker to guess. The two ends of the session will agree on flow label values during the SYN/ACK exchange, but off-path attackers will be unlikely to guess the agreed value. Naturally, on-path attackers who can observe the flow labels in use can trivially defeat this protection. This proposal does not involve using the flow label value to retrieve routing state.
关于伪随机流标签值的另一个建议是[Blake09]。这表明非路径欺骗攻击已成为TCP和其他传输层应用程序的一个大问题，并建议在IPv6中，我们应在流标签中设置一个随机值，以使数据包头更复杂，攻击者更不容易猜测。会话的两端将在SYN/ACK交换期间就流标签值达成一致，但非路径攻击者不太可能猜到一致的值。当然，能够观察正在使用的流标签的路径上攻击者可以轻而易举地破坏这种保护。此建议不涉及使用流标签值检索路由状态。
[Prakash04] proposes to utilize the flow label to indicate required QoS parameters in detail. It uses the first few bits of the Flow Label field as codes to support different approaches, as summarized in the following table. Again, this is incompatible with the dependency prohibition in [RFC3697], since a source that does not use this method may also set the first two bits to non-zero.
[Prakash04]建议利用流标签详细指示所需的QoS参数。它使用流标签字段的前几位作为代码来支持不同的方法，如下表所示。同样，这与[RFC3697]中的依赖项禁止不兼容，因为不使用此方法的源也可能将前两位设置为非零。
Classification for various approaches (from [Prakash04])
各种方法的分类（来自[Prakash04]）
Bit Pattern Approach
------------------------------------------------------------------
00 No QoS requirement (Default QoS value)
01 Pseudo-Random value used for the value of Flow-Label
10 Support for Direct Parametric Representation
1100 Support for the DiffServ Model
1101 Reserved for future use
111 Reserved for future use
Bit Pattern Approach
------------------------------------------------------------------
00 No QoS requirement (Default QoS value)
01 Pseudo-Random value used for the value of Flow-Label
10 Support for Direct Parametric Representation
1100 Support for the DiffServ Model
1101 Reserved for future use
111 Reserved for future use
This method allows a pseudo-random option but also adds options for a direct QoS request and for Diffserv. In the direct QoS parameters approach, 18 bits are used to encode requirements for one-way delay, IP delay variation, bandwidth, and one-way packet loss. The proposal appears to assume that the Resource Reservation Protocol (RSVP) [RFC2205] mechanisms are used to actually implement these QoS parameters.
此方法允许使用伪随机选项，但也为直接QoS请求和区分服务添加了选项。在直接QoS参数方法中，18位用于编码单向延迟、IP延迟变化、带宽和单向数据包丢失的要求。该提案似乎假设资源预留协议（RSVP）[RFC2205]机制用于实际实现这些QoS参数。
This proposal allows the use of the flow label for various important QoS models, so the end user and service provider can choose the most suitable model for their situation; [Prakash04] claims that "The proposed approach results in a simple, scalable, modular and generic implementation to provide for QoS using the IPv6 flow label field".
该方案允许对各种重要的QoS模型使用流标签，因此最终用户和服务提供商可以根据自己的情况选择最合适的模型；[Prakash04]声称“提议的方法产生了一个简单、可扩展、模块化和通用的实现，以使用IPv6流标签字段提供QoS”。
Similarly, [Lee04] defines the Flow Label field in five parts, with the first 3 bits used as an approach type. The authors define two approaches: a "random" scheme and a "hybrid" scheme. If the first 3 bits equal "001", the flow label will be used as the random identifier of the flow, but if they equal "101", the remaining bits will include a hybrid QoS requirement for this packet, subdivided into traffic type (stringent or best-effort), bandwidth, buffer, and delay requirements. Once again, the dependency prohibition in [RFC3697] is broken. This proposal also includes throughput monitoring and dynamic capacity allocation. Effectively, this proposal uses the flow label both to signal Intserv-like QoS requirements and to classify traffic into Diffserv-like virtual label-switched paths. Packets with a "random" flow label are mapped into a generic (best-effort) virtual path.
类似地，[Lee04]将流量标签字段定义为五个部分，前3位用作接近类型。作者定义了两种方法：“随机”方案和“混合”方案。如果前3位等于“001”，则流标签将用作流的随机标识符，但如果它们等于“101”，则剩余位将包括该分组的混合QoS要求，细分为流量类型（严格或尽力）、带宽、缓冲区和延迟要求。[RFC3697]中的依赖项禁令再次被打破。该方案还包括吞吐量监控和动态容量分配。有效地，该方案使用流标签来表示类似Intserv的QoS需求，并将流量分类为类似Diffserv的虚拟标签交换路径。带有“随机”流标签的数据包被映射到通用（尽力而为）虚拟路径。
[Chakravorty08b] and [Chakravorty08a] describe an architectural framework called "IPv6 Label Switching Architecture" (6LSA). In 6LSA, network components identify a flow by looking at the Flow Label field in the IPv6 packet header; all packets with the same flow label must receive the same treatment and be sent to the same next hop. However, 6LSA resembles MPLS by considering that a label only has
[Chakravorty08b]和[Chakravorty08a]描述了一个称为“IPv6标签交换架构”（6LSA）的架构框架。在6LSA中，网络组件通过查看IPv6数据包报头中的流标签字段来识别流；具有相同流标签的所有数据包必须接受相同的处理并发送到相同的下一跳。然而，6LSA类似于MPLS，因为它考虑到标签只有
meaning between 6LSA routers and setting the flow label at each hop. If the original source sets a non-zero flow label, there is no mechanism to restore it before delivery: a fundamental breach of [RFC3697]. The authors of [Chakravorty08b] did at one stage discuss using an IPv6 hop-by-hop option to correct this problem, but this has not been documented. This is a more serious incompatibility than simply breaking the dependency prohibition.
6LSA路由器之间的含义和在每个跃点设置流标签。如果原始源设置了非零流量标签，则在交付之前没有恢复该标签的机制：根本违反了[RFC3697]。[Chakravorty08b]的作者曾在某个阶段讨论过使用IPv6逐跳选项来纠正此问题，但这一点尚未记录在案。这是一种比简单地打破依赖性禁令更严重的不兼容性。
Unlike traditional routing algorithms, but like MPLS, 6LSA packets are classified into a Forwarding Equivalence Class (FEC), and routers forward packets on different paths by looking at the FEC. Like previous solutions, this solution divides the Flow Label field into three parts. The first 3 bits identify the FEC, which will help the router or 6LSA nodes to group the IP packets that receive the same forwarding treatment and forward them on the same virtual path. The following 4 bits describe the application type, and the final 13 bits (defined by each node or a group of nodes) specify the hop-specific label. From the table below, we can see the FEC has 6 major categories, each with up to 16 subcategories.
与传统的路由算法不同，6LSA数据包与MPLS一样，被划分为转发等价类（FEC），路由器通过查看FEC在不同路径上转发数据包。与以前的解决方案一样，此解决方案将“流标签”字段分为三个部分。前3位标识FEC，这将帮助路由器或6LSA节点对接收相同转发处理的IP数据包进行分组，并在相同的虚拟路径上转发它们。以下4位描述应用程序类型，最后13位（由每个节点或一组节点定义）指定特定于跃点的标签。从下表中，我们可以看到FEC有6个主要类别，每个类别最多有16个子类别。
Flow Label Specification (shortened from [Chakravorty08b])
流量标签规范（从[Chakravorty08b]缩短）
+--------------------------+-------------+--------------------------+
| FEC (First 3 Bits) | Next 4 Bits | Purpose |
+--------------------------+-------------+--------------------------+
| No FEC (000) | 0000 | |
| Domain Specific (000) | 0001 - 1111 | |
| ------------------------ | | |
| VPN (001) | 0001 | (IPSec - Tunnel Mode) |
| | 0010 | (IPSec - Transport Mode) |
| | 0011 | (Special Encryption) |
| | 0100 | (VRF) |
| | 0101 | (End Network Specific) |
| | 0110 - 1111 | (Reserved) |
| ------------------------ | | |
| TE Subset/ | 0001 | (DiffServ) |
| QoS Enhancement (010) | 0010 | (RSVP) |
. . .
| | 1111 | (Reserved) |
| ------------------------ | | |
| Encapsulation (011) | 0001 | (IPv6 in IPv6) |
| | 0010 | (IPv4 in IPv6) |
| | 0011 | (Other in IPv6) |
| | 0100 | (Enterprise Specific) |
| | 0101 - 1111 | (Reserved) |
| ------------------------ | | |
| Enterprise Specific(111) | 0000 - 1111 | (Reserved) |
+--------------------------+-------------+--------------------------+
+--------------------------+-------------+--------------------------+
| FEC (First 3 Bits) | Next 4 Bits | Purpose |
+--------------------------+-------------+--------------------------+
| No FEC (000) | 0000 | |
| Domain Specific (000) | 0001 - 1111 | |
| ------------------------ | | |
| VPN (001) | 0001 | (IPSec - Tunnel Mode) |
| | 0010 | (IPSec - Transport Mode) |
| | 0011 | (Special Encryption) |
| | 0100 | (VRF) |
| | 0101 | (End Network Specific) |
| | 0110 - 1111 | (Reserved) |
| ------------------------ | | |
| TE Subset/ | 0001 | (DiffServ) |
| QoS Enhancement (010) | 0010 | (RSVP) |
. . .
| | 1111 | (Reserved) |
| ------------------------ | | |
| Encapsulation (011) | 0001 | (IPv6 in IPv6) |
| | 0010 | (IPv4 in IPv6) |
| | 0011 | (Other in IPv6) |
| | 0100 | (Enterprise Specific) |
| | 0101 - 1111 | (Reserved) |
| ------------------------ | | |
| Enterprise Specific(111) | 0000 - 1111 | (Reserved) |
+--------------------------+-------------+--------------------------+
The authors claim that fast switching using 20-bit labels instead of 128-bit IPv6 addresses will provide memory and processing savings, as well as network management advantages. "It also allows a network management entity updating available label tables, across the network to reduce man-in-the-middle attacks [sic]" [Chakravorty08b].
作者声称，使用20位标签而不是128位IPv6地址进行快速切换将节省内存和处理，并具有网络管理优势。“它还允许网络管理实体通过网络更新可用的标签表，以减少中间人攻击[sic]”[Chakravorty08b]。
We note that a similar proposal for QoS-based switching of IPv6 packets [Roberts05] is designed to use a hop-by-hop option, which has not so far been allocated by the IETF. Proposals related to this have been discussed by the Telecommunications Industry Association and the ITU-T [Adams08].
我们注意到，类似的基于QoS的IPv6数据包交换方案[Roberts05]设计为使用逐跳选项，IETF迄今尚未分配该选项。与此相关的建议已由电信行业协会和ITU-T讨论[Adams08]。
We also note that router lookup efficiency was a major concern at the time when Clark first proposed a flow label [Deering93], but with the advent of very large scale integrated circuits capable of rapid lookup in a routing table, most vendors no longer express such concern.
我们还注意到，当Clark首次提出流量标签[Deering93]时，路由器查找效率是一个主要问题，但随着能够在路由表中快速查找的超大规模集成电路的出现，大多数供应商不再表达这种担忧。
[Banerjee02] uses the Flow Label field as a replacement for the IPv6 Traffic Class field; this proposal suggests the incoming flow label can indicate the QoS requirement by matching a Diffserv classifier. The authors have used the first three bits to indicate this, and the following 16 bits to indicate a Differentiated Services Per-Hop Behavior Identification code (Diffserv PHB-ID) [RFC3140]; the last bit is reserved for future use. This method too breaks the dependency prohibition in [RFC3697].
[Banerjee02]使用流标签字段替换IPv6流量类别字段；该方案建议传入流标签可以通过匹配区分服务分类器来指示QoS需求。作者使用了前三位来表示这一点，接下来的16位表示区分服务每跳行为标识码（Diffserv PHB-ID）[RFC3140]；最后一位保留供将来使用。此方法也打破了[RFC3697]中的依赖项禁令。
[Beckman07a] blends the flow label as an MPLS-like switching tag with Diffserv. Unlike 6LSA, the method attempts to bypass the dependency prohibition by using one bit in the Diffserv Code Point [RFC2474] to indicate that the flow label is a switching tag. In this way, a router can determine whether the flow label conforms to [RFC3697] or to [Beckman07a]. In [Beckman07b], the same author proposes using the flow label as a way of compressing IPv6 headers by hashing the addresses into the flow label, again using the Diffserv Code Point to mark the packets accordingly.
[Beckman07a]将流标签作为类似MPLS的交换标签与Diffserv混合。与6LSA不同，该方法试图通过在Diffserv代码点[RFC2474]中使用一位来指示流标签是切换标签，从而绕过依赖项禁止。通过这种方式，路由器可以确定流标签是否符合[RFC3697]或[Beckman07a]。在[Beckman07b]中，同一位作者建议使用流标签作为压缩IPv6头的一种方式，将地址散列到流标签中，再次使用Diffserv代码点相应地标记数据包。
The Integrated Services QoS architecture [RFC1633] specifies that the flow label may be used as a packet filter [RFC2205]. At least one implementation supported this [Braden10].
综合服务QoS体系结构[RFC1633]规定流标签可用作包过滤器[RFC2205]。至少有一个实现支持此[Braden10]。
We are not aware of any proposals combining the flow label with the Next Steps in Signaling (NSIS) [RFC4080] architecture.
我们不知道有任何建议将流标签与信令（NSIS）[RFC4080]体系结构中的下一步相结合。
[Donley11] proposes a use case whereby certain flows encapsulated in a particular type of IPv4-in-IPv6 tunnel would be distinguished at the remote end of the tunnel by a specific flow label value. This would allow a service provider to deliver a tailored quality of service. This usage appears to be completely compatible with [RFC3697].
[Donley11]提出了一个用例，即封装在特定类型的IPv4-in-IPv6隧道中的某些流将在隧道的远程端通过特定的流标签值进行区分。这将允许服务提供商提供定制的服务质量。这种用法似乎与[RFC3697]完全兼容。
There has been some discussion of possible flow label use in both the ROLL (Routing Over Low power and Lossy networks) [RPL-07] and MEXT (Mobility EXTensions for IPv6) working groups of the IETF. Such uses tend to encode specific local meanings or routing-related tags in the label, so they appear to infringe the dependency prohibition or the immutability of the Flow Label field. The ROLL group has indeed most recently opted not to use the Flow Label field for these reasons, despite having to add the undesirable overhead of an IPv6 hop-by-hop option instead [RPL]. Similarly, MEXT has defined a new mobility option to support flow bindings [RFC6089] rather than using the IPv6 Flow Label field.
IETF的ROLL（低功耗和有损网络上的路由）[RPL-07]和MEXT（IPv6移动性扩展）工作组对可能的流标签使用进行了一些讨论。这种使用倾向于在标签中编码特定的局部含义或路由相关标签，因此它们似乎违反了流量标签字段的依赖性禁止或不变性。出于这些原因，ROLL组最近确实选择不使用Flow Label字段，尽管不得不添加IPv6逐跳选项[RPL]的不良开销。类似地，MEXT定义了一个新的移动选项来支持流绑定[RFC6089]，而不是使用IPv6流标签字段。
Three aspects of the current standard [RFC3697] have caused problems for many designers:
现行标准[RFC3697]的三个方面给许多设计师带来了问题：
1. The immutability of labels
1. 标签的不变性
2. "Nodes MUST NOT assume any mathematical or other properties of the Flow Label"
2. “节点不得采用流标签的任何数学或其他属性”
3. "Router performance SHOULD NOT be dependent on the distribution of the Flow Label values"
3. “路由器性能不应取决于流标签值的分布”
Taken together, these rules essentially forbid any encoding of the semantics of a flow, or of any information about its path, in the flow label. This was intentional, in accordance with the stateless nature of the Internet architecture and with the end-to-end principle [Saltzer84], [RFC3724]. It was also felt that QoS encoding via Diffserv was sufficient and that the requirement for high-speed switching could be met by MPLS. But this means that the majority of the proposals described above breach the standard and the intent of the standard. The authors often appear to be using the flow label either as an MPLS-like switching handle or as an encoded QoS signal.
总之，这些规则本质上禁止在流标签中对流的语义或关于其路径的任何信息进行任何编码。这是有意的，符合互联网架构的无状态性质和端到端原则[Saltzer84]，[RFC3724]。人们还认为，通过Diffserv进行QoS编码已经足够，MPLS可以满足高速交换的要求。但这意味着上述大多数提案违反了标准和标准的意图。作者似乎经常将流标签用作类似MPLS的交换句柄或编码的QoS信号。
In contrast, a few documents mentioned above do appear to respect the rules of RFC 3697. These are [Blake09], [Donley11], [Carpenter11], [Beckman07a], and [Beckman07b]. Additionally, [Lin06] would have joined this list if it had not assigned three flag bits in the Flow Label field. Although predating RFC 3697, the Integrated Services usage [RFC2205] also seems to be compatible.
相比之下，上面提到的一些文件似乎确实遵守了RFC 3697的规则。这些是[Blake09]、[Donley11]、[Carpenter11]、[Beckman07a]和[Beckman07b]。此外，如果[Lin06]没有在流标签字段中分配三个标志位，它将加入此列表。尽管早于RFC3697，但集成服务的使用[RFC2205]似乎也是兼容的。
What would other designers need to do, if they wish to respect RFC 3697? There appear to be two choices. One is to simply accept the existing rules at face value, as in the proposals just listed. This limits the application of the flow label. It can, for example, be used as a nonce or as part of the material for a hash used to share load among alternate paths. It cannot be the only material for such a hash, because of the dependency prohibition. The flow label could also be used consistently with RFC 3697, if an application designer so chose, as a way to associate all packets belonging to a given application session between two hosts, across multiple transport sessions. This, however, would presumably exclude using the flow label to govern routing decisions in any way, and would have widespread implications that have never been explored.
如果其他设计师希望尊重RFC 3697，他们需要做什么？似乎有两种选择。一个是简单地接受现有规则的表面价值，就像刚刚列出的建议一样。这限制了流标签的应用。例如，它可以用作nonce或用于在备用路径之间共享负载的散列的一部分。由于依赖性禁止，它不能是这种散列的唯一材料。如果应用程序设计者选择将流标签与RFC 3697一致使用，作为跨多个传输会话在两台主机之间关联属于给定应用程序会话的所有数据包的方法。然而，这可能会排除使用流标签以任何方式管理路由决策，并且会产生从未被探索过的广泛影响。
The other choice, for designers who wish to use the flow label to control switching or QoS directly, is to bypass the rules within a given domain (a set of cooperating nodes) in a way that nodes outside
对于希望使用流标签直接控制交换或QoS的设计人员来说，另一种选择是绕过给定域（一组协作节点）内的规则，其方式与外部节点不同
the domain cannot detect. In this case, any deviation from RFC 3697 has no possible effect outside the domain in question.
域无法检测到。在这种情况下，与RFC 3697的任何偏差在相关领域之外都不会产生任何可能的影响。
An example scheme to emulate the immutability of labels is as follows. Within the domain, all hosts set the label to zero, the routers set and interpret the label in any way they wish, and the last-hop router always sets the label back to zero. If a packet arrives from outside the domain with a non-zero label, there is a method (such as a special Diffserv code point) to mark this packet so that its label would be ignored and delivered unchanged. An alternative approach would be to define a hop-by-hop option to carry the original flow label across the domain, so that it could be changed within the domain but restored before forwarding the packet beyond the domain.
下面是一个模拟标签不变性的示例方案。在域内，所有主机都将标签设置为零，路由器以任何方式设置和解释标签，最后一跳路由器始终将标签设置回零。如果数据包从域外到达时带有非零标签，则有一种方法（例如特殊的Diffserv代码点）来标记此数据包，以便忽略其标签并原封不动地传递。另一种方法是定义一个逐跳选项，在整个域中携带原始流标签，这样就可以在域内对其进行更改，但在将数据包转发到域外之前将其恢复。
If a domain allows mutable labels in such a way, it may safely ignore the dependency prohibition, and it may set the bits in the label according to locally defined rules. Within the domain, the label could be used as desired, and most of the proposed designs discussed above could be "rescued".
如果域以这种方式允许可变标签，它可以安全地忽略依赖项禁止，并且可以根据本地定义的规则设置标签中的位。在该领域内，可根据需要使用该标签，且上文讨论的大多数拟议设计均可“拯救”。
However, given the considerable number of designers who have proposed solutions incompatible with RFC 3697, the relatively few designs using the standard rules, and the failure of designs such as ROLL and MEXT to make use of the flow label, it seems reasonable to ask whether the RFC 3697 standard has value.
然而，鉴于有相当多的设计师提出了与RFC 3697不兼容的解决方案，使用标准规则的设计相对较少，以及ROLL和MEXT等设计未能使用流量标签，因此询问RFC 3697标准是否有价值似乎是合理的。
The flow label is not protected in any way and can be forged by an on-path attacker. Off-path attackers may be able to guess a valid flow label unless a pseudo-random value is used. Specific usage models for the flow label need to allow for these exposures. For further discussion, see [RFC3697].
流标签不受任何保护，可由路径上的攻击者伪造。非路径攻击者可能会猜测有效的流标签，除非使用伪随机值。流量标签的特定使用模型需要考虑这些暴露。有关进一步讨论，请参阅[RFC3697]。
An invaluable review of this document was performed by Bob Braden. Helpful comments were made by Sheng Jiang.
Bob Braden对本文件进行了宝贵的审查。盛江发表了有益的评论。
[Adams08] Adams, J., Joung, J., and J. Song, "Progress and future development of Flow State Aware standards, and a proposal for alerting nodes or end-systems on data related to a flow", Work in Progress, June 2008.
[Adams08]Adams，J.，Joung，J.，和J.Song，“流量状态感知标准的进展和未来发展，以及就与流量相关的数据向节点或终端系统发出警报的建议”，正在进行的工作，2008年6月。
[Amante11] Amante, S., Carpenter, B., and S. Jiang, "Rationale for update to the IPv6 flow label specification", Work in Progress, May 2011.
[Amante11]Amante，S.，Carpenter，B.，和S.Jiang，“更新IPv6流标签规范的基本原理”，正在进行的工作，2011年5月。
[Banerjee02] Banerjee, R., Malhotra, S., and M. M, "A Modified Specification for use of the IPv6 Flow Label for providing An efficient Quality of Service using a hybrid approach", Work in Progress, April 2002.
[Banerjee02]Banerjee，R.，Malhotra，S.，和M.M.“使用IPv6流标签使用混合方法提供高效服务质量的修改规范”，正在进行的工作，2002年4月。
[Beckman07a] Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", Work in Progress, February 2007.
[Beckman07a]Beckman，M.，“IPv6动态流标签交换（FLS）”，正在进行的工作，2007年2月。
[Beckman07b] Beckman, M., "IPv6 Header Compression via Addressing Mitigation Protocol (IPv6 AMP)", Work in Progress, November 2006.
[Beckman07b]Beckman，M.，“通过寻址缓解协议（IPv6 AMP）的IPv6报头压缩”，正在进行的工作，2006年11月。
[Blake09] Blake, S., "Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks", Work in Progress, October 2009.
[Blake09]Blake，S.，“使用IPv6流标签作为传输层临时标志，以抵御非路径欺骗攻击”，正在进行的工作，2009年10月。
[Braden10] Braden, R., "Private Communication", 2010.
[Braden10]Braden，R.，“私人通信”，2010年。
[Carpenter02] Carpenter, B. and K. Nichols, "Differentiated Services in the Internet", Proc IEEE 90 (9) 1479-1494, 2002.
[Carpenter02]Carpenter，B.和K.Nichols，“互联网中的差异化服务”，Proc IEEE 90（9）1479-14942002。
[Carpenter11] Carpenter, B. and S. Amante, "Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels", Work in Progress, May 2011.
[Carpenter11]Carpenter，B.和S.Amante，“在隧道中使用IPv6流标签进行等成本多路径路由和链路聚合”，正在进行的工作，2011年5月。
[Chakravorty08a] Chakravorty, S., "Challenges of IPv6 Flow Label implementation", Proc IEEE MILCOM2008, 2008.
[Chakravorty08a]Chakravorty，S.，“IPv6流标签实施的挑战”，Proc IEEE MILCOM2008，2008年。
[Chakravorty08b] Chakravorty, S., Bush, J., and J. Bound, "IPv6 Label Switching Architecture", Work in Progress, July 2008.
[Chakravorty08b]Chakravorty，S.，Bush，J.，和J.Bound，“IPv6标签交换架构”，正在进行的工作，2008年7月。
[Conta01a] Conta, A. and B. Carpenter, "A proposal for the IPv6 Flow Label Specification", Work in Progress, July 2001.
[Conta01a]Conta，A.和B.Carpenter，“IPv6流标签规范提案”，正在进行的工作，2001年7月。
[Conta01b] Conta, A. and J. Rajahalme, "A model for Diffserv use of the IPv6 Flow Label Specification", Work in Progress, November 2001.
[Conta01b]Conta，A.和J.Rajahalme，“IPv6流标签规范的区分服务使用模型”，正在进行的工作，2001年11月。
[Deering93] Deering, S., "SIPP Overview and Issues", Minutes of the Joint Sessions of the SIP and PIP Working Groups, November 1993.
[Deering93]Deering，S.，“SIPP概述和问题”，SIP和PIP工作组联席会议记录，1993年11月。
[Donley11] Donley, C. and K. Erichsen, "Using the Flow Label with Dual-Stack Lite", Work in Progress, January 2011.
[Donley 11]Donley，C.和K.Erichsen，“使用双堆栈Lite的流标签”，正在进行的工作，2011年1月。
[Hagino01] Hagino, J., "Socket API for IPv6 flow label field", Work in Progress, April 2001.
[Hagino01]Hagino，J.，“IPv6流标签字段的套接字API”，正在进行的工作，2001年4月。
[Lee04] Lee, I. and S. Kim, "A QoS Improvement Scheme for Real-Time Traffic Using IPv6 Flow Labels", Lecture Notes in Computer Science Vol. 3043, 2004.
[Lee04]Lee，I.和S.Kim，“使用IPv6流标签的实时流量QoS改进方案”，计算机科学第3043卷，2004年课堂讲稿。
[Lin06] Lin, C., Tseng, P., and W. Hwang, "End-to-End QoS Provisioning by Flow Label in IPv6", JCIS , 2006.
[Lin06]Lin，C.，Tseng，P.，和W.Hwang，“IPv6中通过流标签提供端到端QoS”，JCIS，2006年。
[Metzler00] Metzler, J. and S. Hauth, "An end-to-end usage of the IPv6 flow label", Work in Progress, November 2000.
[Metzler00]Metzler，J.和S.Hauth，“IPv6流标签的端到端使用”，正在进行的工作，2000年11月。
[Prakash04] Prakash, B., "Using the 20 bit flow label field in the IPv6 header to indicate desirable quality of service on the internet", University of Colorado (M.Sc. Thesis), 2004.
[Prakas04] Praskas.B，“使用IPv6报头中的20位流标签字段来表示因特网上的理想服务质量”，科罗拉多大学（M.S.C.论文），2004。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]Braden，R.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC 16331994年6月。
[RFC1707] McGovern, M. and R. Ullmann, "CATNIP: Common Architecture for the Internet", RFC 1707, October 1994.
[RFC1707]McGovern，M.和R.Ullmann，“CATNIP：互联网的通用架构”，RFC 1707，1994年10月。
[RFC1710] Hinden, R., "Simple Internet Protocol Plus White Paper", RFC 1710, October 1994.
[RFC1710]Hinden，R.，“简单互联网协议加白皮书”，RFC1710，1994年10月。
[RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP Next Generation Protocol", RFC 1752, January 1995.
[RFC1752]Bradner，S.和A.Mankin，“IP下一代协议的建议”，RFC 1752，1995年1月。
[RFC1809] Partridge, C., "Using the Flow Label Field in IPv6", RFC 1809, June 1995.
[RFC1809]帕特里奇，C.，“在IPv6中使用流标签字段”，RFC1809，1995年6月。
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[RFC1883]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 1883，1995年12月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[RFC3140]Black，D.，Brim，S.，Carpenter，B.，和F.Le Faucheur，“每跳行为识别码”，RFC 31402001年6月。
[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月。
[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004.
[RFC3724]Kempf，J.，Ed.，Austein，R.，Ed.，和IAB，“中部崛起和端到端的未来：互联网架构演变的思考”，RFC 37242004年3月。
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[RFC4080]Hancock，R.，Karagiannis，G.，Loughney，J.，和S.Van den Bosch，“信号的下一步（NSIS）：框架”，RFC 40802005年6月。
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, January 2011.
[RFC6089]Tsirtsis，G.，Soliman，H.，Montavont，N.，Giaretta，G.，和K.Kuladinhi，“移动IPv6和网络移动（NEMO）基本支持中的流绑定”，RFC 60892011年1月。
[RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Work in Progress, March 2011.
[RPL]Winter，T.，Ed.，Thubert，P.，Ed.，Brandt，A.，Clausen，T.，Hui，J.，Kelsey，R.，Levis，P.，Pister，K.，Struik，R.，和J.Vasseur，“RPL：低功耗和有损网络的IPv6路由协议”，正在进行的工作，2011年3月。
[RPL-07] Winter, T., Ed. and P. Thubert, Ed., "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Work in Progress, March 2010.
[RPL-07]Winter，T.，Ed.和P.Thubert，Ed.，“RPL：低功耗和有损网络的IPv6路由协议”，正在进行的工作，2010年3月。
[Roberts05] Roberts, L. and J. Harford, "In-Band QoS Signaling for IPv6", Work in Progress, July 2005.
[Roberts05]Roberts，L.和J.Harford，“IPv6的带内QoS信令”，正在进行的工作，2005年7月。
[Saltzer84] Saltzer, J., Reed, D., and D. Clark, "End-To-End Arguments in System Design", ACM TOCS 2 (4) 277-288, 1984.
[Saltzer84]Saltzer，J.，Reed，D.，和D.Clark，“系统设计中的端到端参数”，ACM TOCS 2（4）277-2881984。
Authors' Addresses
作者地址
Qinwen Hu Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
奥克兰大学计算机科学系Qinwen Hu Department 92019奥克兰1142新西兰
EMail: qhu009@aucklanduni.ac.nz
EMail: qhu009@aucklanduni.ac.nz
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