Network Working Group Y. Rekhter
Request for Comments: 4797 R. Bonica
Category: Informational Juniper Networks
E. Rosen
Cisco Systems, Inc.
January 2007
Network Working Group Y. Rekhter
Request for Comments: 4797 R. Bonica
Category: Informational Juniper Networks
E. Rosen
Cisco Systems, Inc.
January 2007
Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks
在BGP/MPLS IP虚拟专用网络中使用提供商边缘到提供商边缘（PE-PE）通用路由封装（GRE）或IP
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
IESG Note
IESG注释
This document proposes an automated mechanism for establishing tunnels between provider-edge routers in a VPN, but does not provide an automated mechanism for establishing security associations for these tunnels. Without such a mechanism, this document is not appropriate for publication on the Internet standards track.
本文档提出了一种在VPN中的提供商边缘路由器之间建立隧道的自动机制，但未提供为这些隧道建立安全关联的自动机制。如果没有这样的机制，本文件不适合在互联网标准轨道上发布。
Abstract
摘要
This document describes an implementation strategy for BGP/MPLS IP Virtual Private Networks (VPNs) in which the outermost MPLS label (i.e., the tunnel label) is replaced with either an IP header or an IP header with Generic Routing Encapsulation (GRE).
本文档描述了BGP/MPLS IP虚拟专用网络（VPN）的实施策略，其中最外层的MPLS标签（即隧道标签）替换为IP头或具有通用路由封装（GRE）的IP头。
The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not.
本文描述的实现策略使得能够在其边缘设备感知MPLS和VPN，但其内部设备不感知的网络中部署BGP/MPLS IP VPN技术。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used In This Document . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE . . . . 5
4.2. MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE . . . . . 6
5. Implications on Packet Spoofing . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used In This Document . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE . . . . 5
4.2. MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE . . . . . 6
5. Implications on Packet Spoofing . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
A "conventional" BGP/MPLS IP VPN [2] is characterized as follows:
“传统”BGP/MPLS IP VPN[2]的特征如下：
Each Provider Edge (PE) router maintains one or more Virtual Routing and Forwarding (VRF) instances. A VRF instances is a VPN-specific forwarding table.
每个提供者边缘（PE）路由器维护一个或多个虚拟路由和转发（VRF）实例。VRF实例是VPN特定的转发表。
PE routers exchange reachability information with one another using BGP [3] with multi-protocol extensions [4].
PE路由器使用带有多协议扩展的BGP[3]彼此交换可达性信息[4]。
MPLS Label Switching Paths (LSPs) [5] connect PE routers to one another.
MPLS标签交换路径（LSP）[5]将PE路由器相互连接。
In simple configurations, the VPN service is offered by a single Autonomous System (AS). All service provider routers are contained by a single AS and all VPN sites attach to that AS. When an ingress PE router receives a packet from a VPN site, it looks up the packet's destination IP address in a VRF that is associated with the packet's ingress attachment circuit. As a result of this lookup, the ingress PE router determines an MPLS label stack, a data link header, and an output interface. The label stack is prepended to the packet, the data link header is prepended to that, and the resulting frame is queued for the output interface.
在简单配置中，VPN服务由单个自治系统（AS）提供。所有服务提供商路由器都包含在一个AS中，所有VPN站点都连接到该AS。当入口PE路由器从VPN站点接收到数据包时，它会在与数据包入口连接电路相关联的VRF中查找数据包的目标IP地址。作为该查找的结果，入口PE路由器确定MPLS标签堆栈、数据链路头和输出接口。标签堆栈在数据包前面，数据链路头在数据包前面，生成的帧排队等待输出接口。
The innermost label in the MPLS label stack is called the VPN route label. The VPN route label is significant and visible to the egress PE router only. It controls forwarding of the packet by the egress PE router.
MPLS标签堆栈中最里面的标签称为VPN路由标签。VPN路由标签很重要，仅对出口PE路由器可见。它通过出口PE路由器控制数据包的转发。
The outermost label in the MPLS label stack is called the tunnel label. The tunnel label causes the packet to be delivered to the egress PE router that understands the VPN route label. Specifically, the tunnel label identifies an MPLS LSP that connects the ingress PE router to the egress PE router. In the context of BGP/MPLS IP VPNs, this LSP is called a tunnel LSP.
MPLS标签堆栈中最外层的标签称为隧道标签。隧道标签导致数据包被传送到理解VPN路由标签的出口PE路由器。具体地说，隧道标签标识将入口PE路由器连接到出口PE路由器的MPLS LSP。在BGP/MPLS IP VPN的上下文中，此LSP称为隧道LSP。
The tunnel LSP provides a forwarding path between the ingress and egress PE routers. Quality of service (QoS) information can be mapped from the VPN packet to the tunnel LSP header so that required forwarding behaviors can be maintained at each hop along the forwarding path.
隧道LSP在入口和出口PE路由器之间提供转发路径。服务质量（QoS）信息可以从VPN数据包映射到隧道LSP报头，这样就可以在转发路径上的每个跃点上维护所需的转发行为。
Sections 9 and 10 of reference [2] define more complex configurations (i.e., carriers' carrier and multi-AS backbones) in which service providers offer L3VPN services across multiple autonomous systems. In these configurations, VPN route labels can be stitched together
参考文献[2]第9节和第10节定义了更复杂的配置（即，运营商的运营商和多AS主干网），其中服务提供商跨多个自治系统提供L3VPN服务。在这些配置中，VPN路由标签可以缝合在一起
across AS boundaries. Within each AS, tunnel LSPs carry VPN packets from network edge to network edge.
跨越边界。在每个AS中，隧道LSP将VPN数据包从网络边缘传送到网络边缘。
In most configurations, tunnel LSPs never traverse AS boundaries. The tunnel LSP is always contained within a single AS. In one particular configuration (i.e., Inter-provider Option C), tunnel LSPs may traverse AS boundaries.
在大多数配置中，隧道LSP从不作为边界进行遍历。隧道LSP始终包含在单个AS中。在一种特定配置（即，提供商间选项C）中，隧道LSP可以作为边界穿越。
This memo describes procedures for creating an MPLS packet that carries the VPN route label, but does not carry the tunnel label. Then, using either GRE or IP encapsulation, the ingress PE router sends the MPLS packet across the network to the egress PE router.
本备忘录描述了创建带有VPN路由标签但不带有隧道标签的MPLS数据包的过程。然后，使用GRE或IP封装，入口PE路由器通过网络将MPLS分组发送到出口PE路由器。
That is, a GRE or IP tunnel replaces the tunnel LSP that was present in "conventional" BGP/MPLS IP VPNs. Like the tunnel LSP, the GRE/IP tunnel provides a forwarding path between the ingress and egress PE routers. QoS information can be copied from the VPN packet to the GRE/IP tunnel header so that required forwarding behaviors can be maintained at each hop along the forwarding path. However, because the GRE/IP tunnel lacks traffic engineering capabilities, any traffic engineering features provided by the tunnel LSP are lost.
也就是说，GRE或IP隧道取代了“传统”BGP/MPLS IP VPN中存在的隧道LSP。与隧道LSP一样，GRE/IP隧道在入口和出口PE路由器之间提供转发路径。QoS信息可以从VPN数据包复制到GRE/IP隧道报头，以便在转发路径上的每个跃点都可以维护所需的转发行为。但是，由于GRE/IP隧道缺乏流量工程功能，因此隧道LSP提供的任何流量工程功能都将丢失。
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 RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
"Conventional" BGP/MPLS IP VPNs require an MPLS Label Switched Path (LSP) between a packet's ingress PE router and its egress PE router. This means that a BGP/MPLS IP VPN cannot be implemented if there is a part of the path between the ingress and egress PE routers that does not support MPLS.
“传统”BGP/MPLS IP VPN需要在数据包的入口PE路由器和出口PE路由器之间使用MPLS标签交换路径（LSP）。这意味着，如果入口和出口PE路由器之间存在不支持MPLS的部分路径，则无法实现BGP/MPLS IP VPN。
In order to enable BGP/MPLS IP VPNs to be deployed even when there are non-MPLS routers along the path between the ingress and egress PE routers, it is desirable to have an alternative, which allows the tunnel label to be replaced with either an IP or (IP + GRE) header. The encapsulation header would have the address of the egress PE router in its destination IP address field, and this would cause the packet to be delivered to the egress PE router.
为了使得即使在入口和出口PE路由器之间的路径上存在非MPLS路由器时也能够部署BGP/MPLS IP vpn，希望具有替代方案，其允许用IP或（IP+GRE）报头替换隧道标签。封装报头将在其目的地IP地址字段中具有出口PE路由器的地址，这将导致分组被传送到出口PE路由器。
In this procedure, the ingress and egress PE routers themselves must support MPLS, but that is not an issue, as those routers must necessarily have BGP/MPLS IP VPN support, whereas the transit routers need not support MPLS or BGP/MPLS VPNs.
在此过程中，入口和出口PE路由器本身必须支持MPLS，但这不是问题，因为这些路由器必须具有BGP/MPLS IP VPN支持，而传输路由器不需要支持MPLS或BGP/MPLS VPN。
In short, the technical approach specified here is:
简而言之，这里规定的技术方法是：
1. Continue to use MPLS to identify a VPN route, by continuing to add an MPLS label stack to the VPN packets. Between the ingress and egress PE router, the outermost member of the label stack will represent the VPN route label.
1. 通过继续向VPN数据包添加MPLS标签堆栈，继续使用MPLS标识VPN路由。在入口和出口PE路由器之间，标签堆栈的最外层成员将表示VPN路由标签。
2. An MPLS-in-GRE or MPLS-in-IP [6] encapsulation will be used to turn the MPLS packet, described above, back into an IP packet. This, in effect, creates a GRE or an IP tunnel between the ingress PE router and the egress PE router.
2. GRE中的MPLS或IP中的MPLS[6]封装将用于将上述MPLS数据包转换回IP数据包。这实际上在入口PE路由器和出口PE路由器之间创建了GRE或IP隧道。
The net effect is that an MPLS packet gets sent through a GRE or an IP tunnel.
其净效果是MPLS数据包通过GRE或IP隧道发送。
Service providers must protect the above-mentioned IP or GRE tunnel as recommended in Section 8.2 of reference [6]. As stated in that document:
服务提供商必须按照参考文献[6]第8.2节的建议保护上述IP或GRE隧道。如该文件所述：
"If the tunnel lies entirely within a single administrative domain, address filtering at the boundaries can be used to ensure that no packet with the IP source address of a tunnel endpoint or with the IP destination address of a tunnel endpoint can enter the domain from outside.
“如果隧道完全位于单个管理域内，则可以使用边界处的地址过滤来确保具有隧道端点的IP源地址或隧道端点的IP目标地址的数据包不能从外部进入域。
However, when the tunnel head and the tunnel tail are not in the same administrative domain, this may become difficult, and filtering based on the destination address can even become impossible if the packets must traverse the public Internet.
然而，当隧道头和隧道尾不在同一管理域中时，这可能变得困难，并且如果包必须穿越公共因特网，则基于目的地地址的过滤甚至可能变得不可能。
Sometimes only source address filtering (but not destination address filtering) is done at the boundaries of an administrative domain. If this is the case, the filtering does not provide effective protection at all unless the decapsulator of an MPLS-in-IP or MPLS-in-GRE validates the IP source address of the packet. This document does not require that the decapsulator validate the IP source address of the tunneled packets, but it should be understood that failure to do so presupposes that there is effective destination-based (or a combination of source-based and destination-based) filtering at the boundaries."
有时，在管理域的边界上只进行源地址筛选（而不进行目标地址筛选）。在这种情况下，除非MPLS in IP或MPLS in GRE的解封装器验证数据包的IP源地址，否则过滤根本无法提供有效的保护。本文件不要求解封装器验证隧道数据包的IP源地址，但应理解，如果不验证，则前提是边界处存在有效的基于目的地（或基于源和基于目的地的组合）的过滤。”
The following description is not meant to specify an implementation strategy; any implementation procedure that produces the same result is acceptable.
以下描述并非旨在指定实施策略；任何产生相同结果的实施程序都是可以接受的。
When an ingress PE router receives a packet from a Customer Edge (CE) router, it looks up the packet's destination IP address in a VRF that is associated with the packet's ingress attachment circuit. This enables the (ingress) PE router to find a VPN-IP route. The VPN-IP route will have an associated VPN route label and an associated BGP Next Hop. The label is pushed on the packet. Then an IP (or IP+GRE) encapsulation header is prepended to the packet, creating an MPLS-in-IP (or MPLS-in-GRE) encapsulated packet. The IP source address field of the encapsulation header will be an address of the ingress PE router itself. The IP destination address field of the encapsulation header will contain the value of the associated BGP Next Hop; this will be an IP address of the egress PE router. QoS information can be copied from the VPN packet to the GRE/IP tunnel header so that required forwarding behaviors can be maintained at each hop along the forwarding path.
当入口PE路由器从客户边缘（CE）路由器接收到数据包时，它在与数据包的入口连接电路相关联的VRF中查找数据包的目的地IP地址。这使（入口）PE路由器能够找到VPN-IP路由。VPN-IP路由将具有关联的VPN路由标签和关联的BGP下一跳。标签被推到包上。然后，一个IP（或IP+GRE）封装报头在包的前面，创建一个IP中的MPLS（或GRE中的MPLS）封装包。封装头的IP源地址字段将是入口PE路由器本身的地址。封装头的IP目的地址字段将包含相关BGP下一跳的值；这将是出口PE路由器的IP地址。QoS信息可以从VPN数据包复制到GRE/IP隧道报头，以便在转发路径上的每个跃点都可以维护所需的转发行为。
The IP address of the remote tunnel endpoints MAY be inferred from the Network Address of the Next Hop field of the MP_REACH_NLRI BGP attribute [4]. Note that the set of Next Hop Network Addresses is not known in advance, but is learned dynamically via the BGP distribution of VPN-IP routes. Assuming a consistent set of tunnel capabilities exist between all the PEs and Autonomous System Border Routers (ASBRs), no a priori configuration of the remote tunnel endpoints is needed. The entire set of PE and ASBRs MUST have the same tunnel capabilities if the dynamic creation of IP (or GRE) tunnels is desired. The preference to use an IP (or GRE) tunnel MUST be configured. A set of PEs using two or more tunnel mechanisms (i.e., LSP, GRE, IP, etc.) MUST determine the tunnel type on a per-peer basis. The automatic association of tunnel capabilities on a per-peer basis is for future study. Note that these tunnels SHOULD NOT be IGP-visible links, and routing adjacencies SHOULD NOT be supported across these tunnel.
远程隧道端点的IP地址可以从MP_REACH_NLRI BGP属性的下一跳字段的网络地址推断出来[4]。请注意，下一跳网络地址集事先未知，但通过VPN-IP路由的BGP分发动态学习。假设所有PEs和自治系统边界路由器（ASBR）之间存在一组一致的隧道功能，则不需要对远程隧道端点进行先验配置。如果需要动态创建IP（或GRE）隧道，则整套PE和ASBR必须具有相同的隧道功能。必须配置使用IP（或GRE）隧道的首选项。使用两个或多个隧道机制（即LSP、GRE、IP等）的一组PE必须基于每个对等点确定隧道类型。基于每个对等点的隧道能力的自动关联是为了将来的研究。请注意，这些隧道不应是IGP可见链路，并且不应跨这些隧道支持路由邻接。
Every egress PE is also an ingress PE, and hence has the ability to decapsulate MPLS-in-IP (or MPLS-in-GRE) packets. After decapsulation, the packets SHOULD be delivered to the routing function for ordinary MPLS switching.
每个出口PE也是入口PE，因此能够在IP（或GRE）数据包中解除MPLS的封装。在解除封装后，数据包应发送至路由功能，以进行普通MPLS交换。
As stated above, if the service provider deploys source-based filtering at network edges to protect the IP/GRE tunnel (instead of destination-based filtering), the decapsulator must validate the IP source address of the tunneled packets.
如上所述，如果服务提供商在网络边缘部署基于源的过滤以保护IP/GRE隧道（而不是基于目的地的过滤），则解封装器必须验证隧道数据包的IP源地址。
It should be noted that if the tunnel MPLS labels are replaced with an unsecured IP encapsulation, like GRE or IP, it becomes more difficult to protect the VPNs against spoofed packets. This is because a Service Provider (SP) can protect against spoofed MPLS packets by the simple expedient of not accepting MPLS packets from outside its own boundaries (or more generally, by keeping track of which labels are validly received over which interfaces, and discarding packets that arrive with labels that are not valid for their incoming interfaces).
应该注意的是，如果隧道MPLS标签被不安全的IP封装（如GRE或IP）替换，那么保护vpn免受伪造数据包的攻击就变得更加困难。这是因为服务提供商（SP）可以通过不接受来自其自身边界之外的MPLS数据包这一简单的权宜之计来防止被欺骗的MPLS数据包（或者更一般地说，通过跟踪哪些标签通过哪些接口有效接收，并丢弃到达的标签对其传入接口无效的数据包）。
By contrast, protection against spoofed IP packets requires all SP boundary routers to perform filtering; either (a) filtering packets from "outside" the SP, which are addressed to PE routers, or (b) filtering packets from "outside" the SP, which have source addresses that belong "inside" and, in addition, filtering on each PE all packets that have source addresses that belong "outside" the SP.
相比之下，针对伪造IP数据包的保护要求所有SP边界路由器执行过滤；（a）过滤来自SP“外部”的数据包（地址为PE路由器），或（b）过滤来自SP“外部”的数据包（源地址属于“内部”），此外，在每个PE上过滤所有源地址属于SP“外部”的数据包。
The maintenance of these filter lists can be management intensive. Furthermore, depending upon implementation, these filter lists can be performance affecting. However, such filters may be required for reasons other than protection against spoofed VPN packets, in which case the additional maintenance overhead of these filters to protect (among other things) against spoofing of VPN packets may be of no practical significance. Note that allocating IP addresses used for GRE or IP tunnels out of a single (or a small number of) IP block could simplify maintenance of the filters.
这些过滤器列表的维护可能是管理密集型的。此外，根据实现情况，这些过滤器列表可能会影响性能。然而，除了防止欺骗的VPN数据包之外，可能出于其他原因需要此类过滤器，在这种情况下，这些过滤器用于防止（除其他外）欺骗VPN数据包的额外维护开销可能没有实际意义。请注意，从单个（或少量）IP块中分配用于GRE或IP隧道的IP地址可以简化过滤器的维护。
Security considerations in reference [6] apply here as well. Additional security issues are discussed in the previous section "Implications on Packet Spoofing".
参考文献[6]中的安全注意事项也适用于此处。上一节“数据包欺骗的影响”讨论了其他安全问题。
Thanks to Robert Raszuk and Scott Wainner for their contributions to this document.
感谢Robert Raszuk和Scott Wainner对本文件的贡献。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[2] Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[3] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[3] Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[4] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[4] Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[5] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[5] Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[6] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[6] Worster，T.，Rekhter，Y.，和E.Rosen，“在IP或通用路由封装（GRE）中封装MPLS”，RFC4023，2005年3月。
Authors' Addresses
作者地址
Yakov Rekhter Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
美国加利福尼亚州桑尼维尔马蒂尔达大道北1194号雅科夫·雷克特·朱尼珀网络公司，邮编94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US
罗纳德P.博尼卡Juniper Networks 2251美国弗吉尼亚州赫恩登市企业园大道20171
EMail: rbonica@juniper.net
EMail: rbonica@juniper.net
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 US
Eric C.Rosen Cisco Systems，Inc.美国马萨诸塞州Boxborough马萨诸塞大道1414号01719
EMail: erosen@cisco.com
EMail: erosen@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
本文件受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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。