Network Working Group J. Rajahalme
Request for Comments: 3697 Nokia
Category: Standards Track A. Conta
Transwitch
B. Carpenter
IBM
S. Deering
Cisco
March 2004
Network Working Group J. Rajahalme
Request for Comments: 3697 Nokia
Category: Standards Track A. Conta
Transwitch
B. Carpenter
IBM
S. Deering
Cisco
March 2004
IPv6 Flow Label Specification
IPv6流标签规范
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document.
本文档规定了IPv6流标签字段以及IPv6源节点标记流、IPv6节点转发标记数据包和流状态建立方法的最低要求。即使作为流标签可能使用的示例提到，特定用例的更详细要求也不在本文档的范围之内。
The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions.
使用流标签字段可以仅基于固定位置的IPv6主标头字段实现高效的IPv6流分类。
A flow is a sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that the source desires to label as a flow. A flow could consist of all packets in a specific transport connection or a media stream. However, a flow is not necessarily 1:1 mapped to a transport connection.
流是从特定源发送到源希望标记为流的特定单播、选播或多播目的地的数据包序列。流可以由特定传输连接或媒体流中的所有数据包组成。但是，流不一定要1:1映射到传输连接。
Traditionally, flow classifiers have been based on the 5-tuple of the source and destination addresses, ports, and the transport protocol type. However, some of these fields may be unavailable due to either fragmentation or encryption, or locating them past a chain of IPv6 option headers may be inefficient. Additionally, if classifiers depend only on IP layer headers, later introduction of alternative transport layer protocols will be easier.
传统上，流分类器基于源和目标地址、端口和传输协议类型的5元组。但是，由于碎片或加密，这些字段中的某些字段可能不可用，或者通过IPv6选项头链定位它们可能效率低下。此外，如果分类器仅依赖于IP层头，那么以后引入替代传输层协议将更容易。
The usage of the 3-tuple of the Flow Label and the Source and Destination Address fields enables efficient IPv6 flow classification, where only IPv6 main header fields in fixed positions are used.
使用流标签的三元组以及源和目标地址字段可以实现高效的IPv6流分类，其中只使用固定位置的IPv6主标头字段。
The minimum level of IPv6 flow support consists of labeling the flows. IPv6 source nodes supporting the flow labeling MUST be able to label known flows (e.g., TCP connections, application streams), even if the node itself would not require any flow-specific treatment. Doing this enables load spreading and receiver oriented resource reservations, for example. Node requirements for flow labeling are given in section 3.
IPv6流支持的最低级别包括标记流。支持流标记的IPv6源节点必须能够标记已知流（例如TCP连接、应用程序流），即使节点本身不需要任何特定于流的处理。例如，这样做可以实现负载扩展和面向接收器的资源预留。第3节给出了流量标签的节点要求。
Specific flow state establishment methods and the related service models are out of scope for this specification, but the generic requirements enabling co-existence of different methods in IPv6 nodes are set forth in section 4. The associated scaling characteristics (such as nodes involved in state establishment, amount of state maintained by them, and state growth function) will be specific to particular service models.
特定的流状态建立方法和相关服务模型不在本规范的范围内，但第4节阐述了支持IPv6节点中不同方法共存的一般要求。相关的扩展特性（例如状态建立中涉及的节点、它们维护的状态量以及状态增长函数）将特定于特定的服务模型。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[关键词]中的描述进行解释。
The 20-bit Flow Label field in the IPv6 header [IPv6] is used by a source to label packets of a flow. A Flow Label of zero is used to indicate packets not part of any flow. Packet classifiers use the triplet of Flow Label, Source Address, and Destination Address fields to identify which flow a particular packet belongs to. Packets are processed in a flow-specific manner by the nodes that have been set up with flow-specific state. The nature of the specific treatment and the methods for the flow state establishment are out of scope for this specification.
IPv6头[IPv6]中的20位流标签字段由源用于标记流的数据包。零流标签用于指示不属于任何流的数据包。包分类器使用流标签、源地址和目标地址字段的三元组来识别特定包属于哪个流。数据包由设置了特定于流状态的节点以特定于流的方式进行处理。具体处理的性质和流动状态建立的方法超出本规范的范围。
The Flow Label value set by the source MUST be delivered unchanged to the destination node(s).
源设置的流标签值必须原封不动地传递到目标节点。
IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow Label values assigned by source nodes. 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.
IPv6节点不得采用源节点分配的流标签值的任何数学或其他属性。路由器性能不应取决于流标签值的分布。特别是，流标签位本身对散列键的作用很差。
Nodes keeping dynamic flow state MUST NOT assume packets arriving 120 seconds or more after the previous packet of a flow still belong to the same flow, unless a flow state establishment method in use defines a longer flow state lifetime or the flow state has been explicitly refreshed within the lifetime duration.
保持动态流状态的节点不得假定在流的前一个数据包之后120秒或更长时间到达的数据包仍然属于同一个流，除非正在使用的流状态建立方法定义了更长的流状态生存期，或者在生存期内显式刷新了流状态。
The use of the Flow Label field does not necessarily signal any requirement on packet reordering. Especially, the zero label does not imply that significant reordering is acceptable.
流标签字段的使用不一定表示对数据包重新排序的任何要求。特别是，零标签并不意味着显著的重新排序是可以接受的。
If an IPv6 node is not providing flow-specific treatment, it MUST ignore the field when receiving or forwarding a packet.
如果IPv6节点未提供特定于流的处理，则在接收或转发数据包时必须忽略该字段。
To enable Flow Label based classification, source nodes SHOULD assign each unrelated transport connection and application data stream to a new flow. The source node MAY also take part in flow state establishment methods that result in assigning certain packets to specific flows. A source node which does not assign traffic to flows MUST set the Flow Label to zero.
要启用基于流标签的分类，源节点应将每个不相关的传输连接和应用程序数据流分配给新流。源节点还可以参与流状态建立方法，该方法导致将某些分组分配给特定流。未将流量分配给流的源节点必须将流标签设置为零。
To enable applications and transport protocols to define what packets constitute a flow, the source node MUST provide means for the applications and transport protocols to specify the Flow Label values to be used with their flows. The use of the means to specify Flow Label values is subject to appropriate privileges (see section 5.1). The source node SHOULD be able to select unused Flow Label values for flows not requesting a specific value to be used.
为了使应用程序和传输协议能够定义构成流的数据包，源节点必须为应用程序和传输协议提供方法，以指定要与其流一起使用的流标签值。使用指定流量标签值的方法应具有适当的权限（见第5.1节）。源节点应该能够为未请求使用特定值的流选择未使用的流标签值。
A source node MUST ensure that it does not unintentionally reuse Flow Label values it is currently using or has recently used when creating new flows. Flow Label values previously used with a specific pair of source and destination addresses MUST NOT be assigned to new flows with the same address pair within 120 seconds of the termination of the previous flow. The source node SHOULD provide the means for the applications and transport protocols to specify quarantine periods longer than the default 120 seconds for individual flows.
源节点必须确保在创建新流时不会无意中重用当前使用或最近使用的流标签值。在前一个流终止后的120秒内，不得将以前用于特定源地址对和目标地址对的流标签值分配给具有相同地址对的新流。源节点应为应用程序和传输协议提供指定隔离期的方法，该隔离期长于单个流的默认120秒。
To avoid accidental Flow Label value reuse, the source node SHOULD select new Flow Label values in a well-defined sequence (e.g., sequential or pseudo-random) and use an initial value that avoids
为避免意外的流标签值重用，源节点应以明确定义的顺序（例如，顺序或伪随机）选择新的流标签值，并使用避免重复使用的初始值
reuse of recently used Flow Label values each time the system restarts. The initial value SHOULD be derived from a previous value stored in non-volatile memory, or in the absence of such history, a randomly generated initial value using techniques that produce good randomness properties [RND] SHOULD be used.
每次系统重新启动时重新使用最近使用的流标签值。初始值应从存储在非易失性存储器中的先前值中导出，或者在没有此类历史记录的情况下，应使用使用产生良好随机性特性[RND]的技术随机生成的初始值。
To enable flow-specific treatment, flow state needs to be established on all or a subset of the IPv6 nodes on the path from the source to the destination(s). The methods for the state establishment, as well as the models for flow-specific treatment will be defined in separate specifications.
要启用特定于流的处理，需要在从源到目标的路径上的所有IPv6节点或其子集上建立流状态。建立状态的方法以及流量特定处理的模型将在单独的规范中定义。
To enable co-existence of different methods in IPv6 nodes, the methods MUST meet the following basic requirements:
要在IPv6节点中实现不同方法的共存，这些方法必须满足以下基本要求：
(1) The method MUST provide the means for flow state clean-up from the IPv6 nodes providing the flow-specific treatment. Signaling based methods where the source node is involved are free to specify flow state lifetimes longer than the default 120 seconds.
(1) 该方法必须提供从提供流特定处理的IPv6节点清除流状态的方法。涉及源节点的基于信令的方法可以自由指定长于默认120秒的流状态生存时间。
(2) Flow state establishment methods MUST be able to recover from the case where the requested flow state cannot be supported.
(2) 流状态建立方法必须能够从请求的流状态不受支持的情况下恢复。
This section considers security issues raised by the use of the Flow Label, primarily the potential for denial-of-service attacks, and the related potential for theft of service by unauthorized traffic (Section 5.1). Section 5.2 addresses the use of the Flow Label in the presence of IPsec including its interaction with IPsec tunnel mode and other tunneling protocols. We also note that inspection of unencrypted Flow Labels may allow some forms of traffic analysis by revealing some structure of the underlying communications. Even if the flow label were encrypted, its presence as a constant value in a fixed position might assist traffic analysis and cryptoanalysis.
本节考虑使用流量标签引起的安全问题，主要是拒绝服务攻击的可能性，以及未经授权流量窃取服务的相关可能性（第5.1节）。第5.2节介绍了在IPsec存在的情况下使用流标签，包括其与IPsec隧道模式和其他隧道协议的交互。我们还注意到，通过检查未加密的流标签，可以通过揭示底层通信的某些结构来进行某种形式的流量分析。即使流标签是加密的，它在固定位置作为常量存在也可能有助于流量分析和密码分析。
Since the mapping of network traffic to flow-specific treatment is triggered by the IP addresses and Flow Label value of the IPv6 header, an adversary may be able to obtain better service by modifying the IPv6 header or by injecting packets with false addresses and/or labels. Taken to its limits, such theft-of-service becomes a denial-of-service attack when the modified or injected traffic depletes the resources available to forward it and other
由于网络通信量到特定于流的处理的映射是由IPv6报头的IP地址和流标签值触发的，因此对手可以通过修改IPv6报头或通过注入具有虚假地址和/或标签的分组来获得更好的服务。就其局限性而言，当修改或注入的流量耗尽了转发该流量和其他流量所需的资源时，此类服务窃取就成为拒绝服务攻击
traffic streams. A curiosity is that if a DoS attack were undertaken against a given Flow Label (or set of Flow Labels), then traffic containing an affected Flow Label might well experience worse-than-best-effort network performance.
交通流。令人好奇的是，如果对给定的流标签（或一组流标签）进行DoS攻击，那么包含受影响的流标签的流量可能会比尽力而为的网络性能更差。
Note that since the treatment of IP headers by nodes is typically unverified, there is no guarantee that flow labels sent by a node are set according to the recommendations in this document. Therefore, any assumptions made by the network about header fields such as flow labels should be limited to the extent that the upstream nodes are explicitly trusted.
请注意，由于节点对IP头的处理通常未经验证，因此不能保证节点发送的流标签是根据本文档中的建议设置的。因此，网络对诸如流标签之类的报头字段所做的任何假设都应限制在上游节点被明确信任的范围内。
Since flows are identified by the 3-tuple of the Flow Label and the Source and Destination Address, the risk of theft or denial of service introduced by the Flow Label is closely related to the risk of theft or denial of service by address spoofing. An adversary who is in a position to forge an address is also likely to be able to forge a label, and vice versa.
由于流由流标签的三元组以及源地址和目标地址标识，因此流标签引入的盗窃或拒绝服务风险与地址欺骗导致的盗窃或拒绝服务风险密切相关。能够伪造地址的对手也可能伪造标签，反之亦然。
There are two issues with different properties: Spoofing of the Flow Label only, and spoofing of the whole 3-tuple, including Source and Destination Address.
有两个具有不同属性的问题：仅对流标签进行欺骗，以及对整个3元组（包括源地址和目标地址）进行欺骗。
The former can be done inside a node which is using or transmitting the correct source address. The ability to spoof a Flow Label typically implies being in a position to also forge an address, but in many cases, spoofing an address may not be interesting to the spoofer, especially if the spoofer's goal is theft of service, rather than denial of service.
前者可以在使用或传输正确源地址的节点内完成。欺骗流标签的能力通常意味着能够伪造地址，但在许多情况下，欺骗者可能对欺骗地址不感兴趣，特别是当欺骗者的目标是窃取服务而不是拒绝服务时。
The latter can be done by a host which is not subject to ingress filtering [INGR] or by an intermediate router. Due to its properties, such is typically useful only for denial of service. In the absence of ingress filtering, almost any third party could instigate such an attack.
后者可以由不受入口过滤[INGR]约束的主机或中间路由器来完成。由于它的特性，这通常只对拒绝服务有用。在没有入口过滤的情况下，几乎任何第三方都可以发起此类攻击。
In the presence of ingress filtering, forging a non-zero Flow Label on packets that originated with a zero label, or modifying or clearing a label, could only occur if an intermediate system such as a router was compromised, or through some other form of man-in-the-middle attack. However, the risk is limited to traffic receiving better or worse quality of service than intended. For example, if Flow Labels are altered or cleared at random, flow classification will no longer happen as intended, and the altered packets will receive default treatment. If a complete 3-tuple is forged, the altered packets will be classified into the forged flow and will receive the corresponding quality of service; this will create a denial of service attack subtly different from one where only the
在存在入口过滤的情况下，只有当中间系统（如路由器）受到破坏或通过某种其他形式的中间人攻击时，才能在源于零标签的数据包上伪造非零流标签，或修改或清除标签。然而，风险仅限于获得比预期更好或更差服务质量的交通。例如，如果随机更改或清除流标签，则流分类将不再按预期进行，更改的数据包将接受默认处理。如果一个完整的三元组是伪造的，则修改后的数据包将被分类到伪造流中，并将收到相应的服务质量；这将创建一种与只有
addresses are forged. Because it is limited to a single flow definition, e.g., to a limited amount of bandwidth, such an attack will be more specific and at a finer granularity than a normal address-spoofing attack.
地址是伪造的。由于该攻击仅限于单个流定义，例如，带宽有限，因此与普通地址欺骗攻击相比，该攻击更为具体，粒度更细。
Since flows are identified by the complete 3-tuple, ingress filtering [INGR] will, as noted above, mitigate part of the risk. If the source address of a packet is validated by ingress filtering, there can be a degree of trust that the packet has not transited a compromised router, to the extent that ISP infrastructure may be trusted. However, this gives no assurance that another form of man-in-the-middle attack has not occurred.
由于流由完整的三元组标识，如上所述，入口过滤[INGR]将减轻部分风险。如果通过入口过滤验证了数据包的源地址，则可以在一定程度上信任该数据包没有传输受损路由器，从而可以信任ISP基础设施。然而，这并不能保证另一种形式的中间人攻击没有发生。
Only applications with an appropriate privilege in a sending host will be entitled to set a non-zero Flow Label. Mechanisms for this are operating system dependent. Related policy and authorization mechanisms may also be required; for example, in a multi-user host, only some users may be entitled to set the Flow Label. Such authorization issues are outside the scope of this specification.
只有在发送主机中具有适当权限的应用程序才有权设置非零流标签。其机制取决于操作系统。还可能需要相关的政策和授权机制；例如，在多用户主机中，只有一些用户有权设置流标签。此类授权问题不在本规范的范围内。
The IPsec protocol, as defined in [IPSec, AH, ESP], does not include the IPv6 header's Flow Label in any of its cryptographic calculations (in the case of tunnel mode, it is the outer IPv6 header's Flow Label that is not included). Hence modification of the Flow Label by a network node has no effect on IPsec end-to-end security, because it cannot cause any IPsec integrity check to fail. As a consequence, IPsec does not provide any defense against an adversary's modification of the Flow Label (i.e., a man-in-the-middle attack).
[IPsec，AH，ESP]中定义的IPsec协议在其任何加密计算中不包括IPv6标头的流标签（在隧道模式下，不包括外部IPv6标头的流标签）。因此，网络节点修改流标签对IPsec端到端安全性没有影响，因为它不会导致任何IPsec完整性检查失败。因此，IPsec不会针对对手修改流标签（即中间人攻击）提供任何防御。
IPsec tunnel mode provides security for the encapsulated IP header's Flow Label. A tunnel mode IPsec packet contains two IP headers: an outer header supplied by the tunnel ingress node and an encapsulated inner header supplied by the original source of the packet. When an IPsec tunnel is passing through nodes performing flow classification, the intermediate network nodes operate on the Flow Label in the outer header. At the tunnel egress node, IPsec processing includes removing the outer header and forwarding the packet (if required) using the inner header. The IPsec protocol requires that the inner header's Flow Label not be changed by this decapsulation processing to ensure that modifications to label cannot be used to launch theft-or denial-of-service attacks across an IPsec tunnel endpoint. This document makes no change to that requirement; indeed it forbids changes to the Flow Label.
IPsec隧道模式为封装的IP头的流标签提供安全性。隧道模式IPsec数据包包含两个IP报头：由隧道入口节点提供的外部报头和由数据包原始源提供的封装内部报头。当IPsec隧道通过执行流分类的节点时，中间网络节点在外部报头中的流标签上操作。在隧道出口节点处，IPsec处理包括移除外部报头和使用内部报头转发分组（如果需要）。IPsec协议要求此解除封装处理不会更改内部标头的流标签，以确保对标签的修改不能用于跨IPsec隧道端点发起盗窃或拒绝服务攻击。本文件未对该要求进行任何更改；实际上，它禁止更改流标签。
When IPsec tunnel egress decapsulation processing includes a sufficiently strong cryptographic integrity check of the encapsulated packet (where sufficiency is determined by local security policy), the tunnel egress node can safely assume that the Flow Label in the inner header has the same value as it had at the tunnel ingress node.
当IPsec隧道出口解除封装处理包括对封装的分组的足够强的密码完整性检查（其中充分性由本地安全策略确定）时，隧道出口节点可以安全地假定内部报头中的流标签具有与在隧道入口节点处相同的值。
This analysis and its implications apply to any tunneling protocol that performs integrity checks. Of course, any Flow Label set in an encapsulating IPv6 header is subject to the risks described in the previous section.
此分析及其含义适用于执行完整性检查的任何隧道协议。当然，在封装IPv6标头中设置的任何流标签都会受到上一节所述风险的影响。
The Flow Label does nothing to eliminate the need for packet filtering based on headers past the IP header, if such filtering is deemed necessary for security reasons on nodes such as firewalls or filtering routers.
如果出于安全原因在节点（如防火墙或过滤路由器）上认为有必要进行基于IP报头的报头的包过滤，则流标签不会消除这种需要。
The discussion on the topic in the IPv6 WG mailing list has been instrumental for the definition of this specification. The authors want to thank Ran Atkinson, Steve Blake, Jim Bound, Francis Dupont, Robert Elz, Tony Hain, Robert Hancock, Bob Hinden, Christian Huitema, Frank Kastenholz, Thomas Narten, Charles Perkins, Pekka Savola, Hesham Soliman, Michael Thomas, Margaret Wasserman, and Alex Zinin for their contributions.
IPv6 WG邮件列表中关于该主题的讨论有助于定义本规范。作者要感谢兰·阿特金森、史蒂夫·布莱克、吉姆·邦德、弗朗西斯·杜邦、罗伯特·埃尔兹、托尼·海恩、罗伯特·汉考克、鲍勃·辛登、克里斯蒂安·惠特马、弗兰克·卡斯滕霍尔茨、托马斯·纳滕、查尔斯·帕金斯、佩卡·萨沃拉、赫萨姆·索利曼、迈克尔·托马斯、玛格丽特·瓦瑟曼和亚历克斯·津宁的贡献。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6 Specification", RFC 2460, December 1998.
[IPv6]Deering，S.和R.Hinden，“互联网协议版本6规范”，RFC 2460，1998年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RND] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RND]Eastlake，D.，Crocker，S.和J.Schiller，“安全的随机性建议”，RFC 1750，1994年12月。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]Kent，S.和R.Atkinson，“IP封装安全有效负载（ESP）”，RFC 2406，1998年11月。
[INGR] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[INGR]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[IPSec] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSec]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
Authors' Addresses
作者地址
Jarno Rajahalme Nokia Research Center P.O. Box 407 FIN-00045 NOKIA GROUP, Finland
芬兰诺基亚集团雅诺拉贾哈尔梅诺基亚研究中心邮政信箱407 FIN-00045
EMail: jarno.rajahalme@nokia.com
EMail: jarno.rajahalme@nokia.com
Alex Conta Transwitch Corporation 3 Enterprise Drive Shelton, CT 06484 USA
美国密苏里州谢尔顿市企业大道3号Alex Conta Transwitch Corporation 06484
EMail: aconta@txc.com
EMail: aconta@txc.com
Brian E. Carpenter IBM Zurich Research Laboratory Saeumerstrasse 4 / Postfach 8803 Rueschlikon Switzerland
Brian E.Carpenter IBM苏黎世研究实验室Saeumerstrasse 4/Postfach 8803瑞士鲁埃施利肯
EMail: brc@zurich.ibm.com
EMail: brc@zurich.ibm.com
Steve Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Steve Deering Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。