Internet Engineering Task Force (IETF) W. George, Ed.
Request for Comments: 7439 Time Warner Cable
Category: Informational C. Pignataro, Ed.
ISSN: 2070-1721 Cisco
January 2015
Internet Engineering Task Force (IETF) W. George, Ed.
Request for Comments: 7439 Time Warner Cable
Category: Informational C. Pignataro, Ed.
ISSN: 2070-1721 Cisco
January 2015
Gap Analysis for Operating IPv6-Only MPLS Networks
运行仅IPv6 MPLS网络的差距分析
Abstract
摘要
This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is intended to focus on gaps in the standards defining the MPLS suite, and is not intended to highlight particular vendor implementations (or lack thereof) in the context of IPv6-only MPLS functionality.
本文档回顾了IPv6环境下的多协议标签交换（MPLS）协议套件，并确定了必须解决的差距，以便允许MPLS相关协议和应用程序与仅IPv6网络一起使用。本文档旨在关注定义MPLS套件的标准中的差距，而不是在仅IPv6 MPLS功能的上下文中强调特定的供应商实施（或缺乏实施）。
In the data plane, MPLS fully supports IPv6, and MPLS labeled packets can be carried over IPv6 packets in a variety of encapsulations. However, support for IPv6 among MPLS control-plane protocols, MPLS applications, MPLS Operations, Administration, and Maintenance (OAM), and MIB modules is mixed, with some protocols having major gaps. For most major gaps, work is in progress to upgrade the relevant protocols.
在数据平面上，MPLS完全支持IPv6，并且MPLS标记的数据包可以以各种封装方式通过IPv6数据包进行传输。然而，MPLS控制平面协议、MPLS应用程序、MPLS操作、管理和维护（OAM）以及MIB模块之间对IPv6的支持是混合的，有些协议存在重大差距。对于大多数重大差距，正在努力升级相关协议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7439.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7439.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 6
3.2. MPLS Control Plane . . . . . . . . . . . . . . . . . . . 6
3.2.1. Label Distribution Protocol (LDP) . . . . . . . . . . 6
3.2.2. Multipoint LDP (mLDP) . . . . . . . . . . . . . . . . 6
3.2.3. RSVP - Traffic Engineering (RSVP-TE) . . . . . . . . 7
3.2.3.1. Interior Gateway Protocol (IGP) . . . . . . . . . 8
3.2.3.2. RSVP-TE Point-to-Multipoint (P2MP) . . . . . . . 8
3.2.3.3. RSVP-TE Fast Reroute (FRR) . . . . . . . . . . . 8
3.2.4. Path Computation Element (PCE) . . . . . . . . . . . 8
3.2.5. Border Gateway Protocol (BGP) . . . . . . . . . . . . 9
3.2.6. Generalized Multi-Protocol Label Switching (GMPLS) . 9
3.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Layer 2 Virtual Private Network (L2VPN) . . . . . . . 9
3.3.1.1. Ethernet VPN (EVPN) . . . . . . . . . . . . . . . 10
3.3.2. Layer 3 Virtual Private Network (L3VPN) . . . . . . . 10
3.3.2.1. IPv6 Provider Edge/IPv4 Provider Edge (6PE/4PE) . 11
3.3.2.2. IPv6 Virtual Private Extension/IPv4 Virtual
Private Extension (6VPE/4VPE) . . . . . . . . . . 11
3.3.2.3. BGP Encapsulation Subsequent Address Family
Identifier (SAFI) . . . . . . . . . . . . . . . . 12
3.3.2.4. Multicast in MPLS/BGP IP VPN (MVPN) . . . . . . . 12
3.3.3. MPLS Transport Profile (MPLS-TP) . . . . . . . . . . 13
3.4. MPLS Operations, Administration, and Maintenance (MPLS
OAM) . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 14
3.4.2. Label Switched Path Ping (LSP Ping) . . . . . . . . . 15
3.4.3. Bidirectional Forwarding Detection (BFD) . . . . . . 16
3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 16
3.4.5. MPLS Transport Profile (MPLS-TP) OAM . . . . . . . . 16
3.5. MIB Modules . . . . . . . . . . . . . . . . . . . . . . . 17
4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 6
3.2. MPLS Control Plane . . . . . . . . . . . . . . . . . . . 6
3.2.1. Label Distribution Protocol (LDP) . . . . . . . . . . 6
3.2.2. Multipoint LDP (mLDP) . . . . . . . . . . . . . . . . 6
3.2.3. RSVP - Traffic Engineering (RSVP-TE) . . . . . . . . 7
3.2.3.1. Interior Gateway Protocol (IGP) . . . . . . . . . 8
3.2.3.2. RSVP-TE Point-to-Multipoint (P2MP) . . . . . . . 8
3.2.3.3. RSVP-TE Fast Reroute (FRR) . . . . . . . . . . . 8
3.2.4. Path Computation Element (PCE) . . . . . . . . . . . 8
3.2.5. Border Gateway Protocol (BGP) . . . . . . . . . . . . 9
3.2.6. Generalized Multi-Protocol Label Switching (GMPLS) . 9
3.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Layer 2 Virtual Private Network (L2VPN) . . . . . . . 9
3.3.1.1. Ethernet VPN (EVPN) . . . . . . . . . . . . . . . 10
3.3.2. Layer 3 Virtual Private Network (L3VPN) . . . . . . . 10
3.3.2.1. IPv6 Provider Edge/IPv4 Provider Edge (6PE/4PE) . 11
3.3.2.2. IPv6 Virtual Private Extension/IPv4 Virtual
Private Extension (6VPE/4VPE) . . . . . . . . . . 11
3.3.2.3. BGP Encapsulation Subsequent Address Family
Identifier (SAFI) . . . . . . . . . . . . . . . . 12
3.3.2.4. Multicast in MPLS/BGP IP VPN (MVPN) . . . . . . . 12
3.3.3. MPLS Transport Profile (MPLS-TP) . . . . . . . . . . 13
3.4. MPLS Operations, Administration, and Maintenance (MPLS
OAM) . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. Extended ICMP . . . . . . . . . . . . . . . . . . . . 14
3.4.2. Label Switched Path Ping (LSP Ping) . . . . . . . . . 15
3.4.3. Bidirectional Forwarding Detection (BFD) . . . . . . 16
3.4.4. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 16
3.4.5. MPLS Transport Profile (MPLS-TP) OAM . . . . . . . . 16
3.5. MIB Modules . . . . . . . . . . . . . . . . . . . . . . . 17
4. Gap Summary . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
IPv6 [RFC2460] is an integral part of modern network deployments. At the time when this document was written, the majority of these IPv6 deployments were using dual-stack implementations, where IPv4 and IPv6 are supported equally on many or all of the network nodes, and single-stack primarily referred to IPv4-only devices. Dual-stack deployments provide a useful margin for protocols and features that are not currently capable of operating solely over IPv6, because they can continue using IPv4 as necessary. However, as IPv6 deployment and usage becomes more pervasive, and IPv4 exhaustion begins driving changes in address consumption behaviors, there is an increasing likelihood that many networks will need to start operating some or all of their network nodes either as primarily IPv6 (most functions use IPv6, a few legacy features use IPv4), or as IPv6-only (no IPv4 provisioned on the device). This transition toward IPv6-only operation exposes any gaps where features, protocols, or implementations are still reliant on IPv4 for proper function. To that end, and in the spirit of the recommendation in RFC 6540 [RFC6540] that implementations need to stop requiring IPv4 for proper and complete function, this document reviews the MPLS protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks and networks that are primarily IPv6 (hereafter referred to as IPv6-primary). This document is intended to focus on gaps in the standards defining the MPLS suite, and not to highlight particular vendor implementations (or lack thereof) in the context of IPv6-only MPLS functionality.
IPv6[RFC2460]是现代网络部署的一个组成部分。在编写本文档时，这些IPv6部署中的大多数都使用了双栈实现，其中IPv4和IPv6在许多或所有网络节点上受到同等支持，而单栈主要指的是仅IPv4的设备。双栈部署为目前无法单独在IPv6上运行的协议和功能提供了有用的余量，因为它们可以根据需要继续使用IPv4。然而，随着IPv6部署和使用变得越来越普遍，IPv4耗尽开始推动地址使用行为的变化，许多网络需要开始运行其部分或全部网络节点的可能性越来越大，或者主要作为IPv6（大多数功能使用IPv6，少数传统功能使用IPv4），或仅作为IPv6（设备上未配置IPv4）。这种向仅限IPv6的过渡操作暴露了功能、协议或实现仍然依赖IPv4才能正常运行的任何差距。为此，本着RFC 6540[RFC6540]中建议的精神，即实施需要停止要求IPv4才能实现正确和完整的功能，本文档回顾了IPv6环境下的MPLS协议套件，并确定了必须解决的差距，以便允许MPLS相关协议和应用程序与仅IPv6的网络和主要为IPv6的网络（以下称为IPv6 primary）一起使用。本文档旨在关注定义MPLS套件的标准中的差距，而不是在仅IPv6 MPLS功能的上下文中强调特定的供应商实现（或缺乏实现）。
This section discusses some drivers for ensuring that MPLS completely supports IPv6-only operation. It is not intended to be a comprehensive discussion of all potential use cases, but rather a discussion of one use case to provide context and justification to undertake such a gap analysis.
本节讨论确保MPLS完全支持仅IPv6操作的一些驱动程序。其目的不是对所有潜在用例进行全面讨论，而是对一个用例进行讨论，以提供进行此类差距分析的背景和理由。
IP convergence is continuing to drive new classes of devices to begin communicating via IP. Examples of such devices could include set-top boxes for IP video distribution, cell tower electronics (macro or micro cells), infrastructure Wi-Fi access points, and devices for machine-to-machine (M2M) or Internet of Things (IoT) applications. In some cases, these classes of devices represent a very large deployment base, on the order of thousands or even millions of devices network-wide. The scale of these networks, coupled with the increasingly overlapping use of RFC 1918 [RFC1918] address space within the average network and the lack of globally routable IPv4 space available for long-term growth, begins to drive the need for
IP融合正在继续推动新类别的设备开始通过IP进行通信。此类设备的示例可包括用于IP视频分发的机顶盒、蜂窝塔电子设备（宏或微蜂窝）、基础设施Wi-Fi接入点以及用于机器对机器（M2M）或物联网（IoT）应用的设备。在某些情况下，这些设备类别代表了一个非常大的部署基础，在网络范围内的设备数量大约为数千甚至数百万。这些网络的规模，加上平均网络中RFC 1918[RFC1918]地址空间的使用日益重叠，以及长期增长所需的全球可路由IPv4空间的缺乏，开始推动对
many of the endpoints in this network to be managed solely via IPv6. Even if these devices are carrying some IPv4 user data, it is often encapsulated in another protocol such that the communication between the endpoint and its upstream devices can be IPv6-only without impacting support for IPv4 on user data. As the number of devices to manage increases, the operator is compelled to move to IPv6. Depending on the MPLS features required, it is plausible to assume that the (existing) MPLS network will need to be extended to these IPv6-only devices.
此网络中的许多端点将仅通过IPv6进行管理。即使这些设备承载一些IPv4用户数据，它通常也封装在另一个协议中，这样端点与其上游设备之间的通信只能是IPv6，而不会影响对用户数据的IPv4支持。随着需要管理的设备数量的增加，运营商不得不转向IPv6。根据所需的MPLS功能，可以假设（现有）MPLS网络将需要扩展到这些仅限IPv6的设备。
Additionally, as the impact of IPv4 exhaustion becomes more acute, more and more aggressive IPv4 address reclamation measures will be justified. Many networks are likely to focus on preserving their remaining IPv4 addresses for revenue-generating customers so that legacy support for IPv4 can be maintained as long as necessary. As a result, it may be appropriate for some or all of the network infrastructure, including MPLS Label Switching Routers (LSRs) and Label Edge Routers (LERs), to have its IPv4 addresses reclaimed and transition toward IPv6-only operation.
此外，随着IPv4耗尽的影响变得更加严重，越来越积极的IPv4地址回收措施将是合理的。许多网络可能会专注于为创收客户保留其剩余的IPv4地址，以便在必要时保持对IPv4的传统支持。因此，一些或所有网络基础设施（包括MPLS标签交换路由器（LSR）和标签边缘路由器（LER））可能适合回收其IPv4地址并过渡到仅IPv6的操作。
This gap analysis aims to answer the question of what fails when one attempts to use MPLS features on a network of IPv6-only devices. The baseline assumption for this analysis is that some endpoints, as well as Label Switching Routers (Provider Edge (PE) and Provider (P) routers), only have IPv6 transport available and need to support the full suite of MPLS features defined as of the time of this document's writing at parity with the support on an IPv4 network. This is necessary whether they are enabled via the Label Distribution Protocol (LDP) [RFC5036], RSVP - Traffic Engineering (RSVP-TE) [RFC3209], or Border Gateway Protocol (BGP) [RFC3107], and whether they are encapsulated in MPLS [RFC3032], IP [RFC4023], Generic Routing Encapsulation (GRE) [RFC4023], or Layer 2 Tunneling Protocol Version 3 (L2TPv3) [RFC4817]. It is important when evaluating these gaps to distinguish between user data and control-plane data, because while this document is focused on IPv6-only operation, it is quite likely that some amount of the user payload data being carried in the IPv6-only MPLS network will still be IPv4.
这一差距分析旨在回答这样一个问题：当一个人试图在只有IPv6设备的网络上使用MPLS功能时，什么会失败。本分析的基线假设是，一些端点以及标签交换路由器（提供商边缘（PE）和提供商（P）路由器）仅具有IPv6传输，并且需要支持本文档编写时定义的全套MPLS功能，与IPv4网络上的支持相同。无论它们是通过标签分发协议（LDP）[RFC5036]、RSVP-流量工程（RSVP-TE）[RFC3209]还是边界网关协议（BGP）[RFC3107]启用的，也无论它们是封装在MPLS[RFC3032]、IP[RFC4023]、通用路由封装（GRE）[RFC4023]还是第2层隧道协议版本3（L2TPv3）中，这都是必要的[RFC4817]。在评估这些差距以区分用户数据和控制平面数据时，这一点很重要，因为尽管本文档主要关注仅限IPv6的操作，但仅限IPv6的MPLS网络中承载的部分用户有效负载数据很可能仍然是IPv4。
A note about terminology: Gaps identified by this document are characterized as "Major" or "Minor". Major gaps refer to significant changes necessary in one or more standards to address the gap due to existing standards language having either missing functionality for IPv6-only operation or explicit language requiring the use of IPv4 with no IPv6 alternatives defined. Minor gaps refer to changes necessary primarily to clarify existing standards language. Usually
关于术语的说明：本文件确定的差距被描述为“主要”或“次要”。主要差距是指一个或多个标准中必要的重大变更，以解决由于现有标准语言缺少仅适用于IPv6操作的功能或明确的语言要求使用IPv4而未定义IPv6替代方案而造成的差距。次要差距是指主要为澄清现有标准语言而进行的必要变更。通常
these changes are needed in order to explicitly codify IPv6 support in places where it is either implicit or omitted today, but the omission is unlikely to prevent IPv6-only operation.
这些更改是必要的，以便在当前隐含或省略IPv6支持的地方明确地编码IPv6支持，但这种省略不太可能阻止仅使用IPv6的操作。
MPLS labeled packets can be transmitted over a variety of data links [RFC3032], and MPLS labeled packets can also be encapsulated over IP. The encapsulations of MPLS in IP and GRE, as well as MPLS over L2TPv3, support IPv6. See Section 3 of RFC 4023 [RFC4023] and Section 2 of RFC 4817 [RFC4817], respectively.
MPLS标记的数据包可以通过各种数据链路传输[RFC3032]，MPLS标记的数据包也可以通过IP封装。IP和GRE中的MPLS封装以及L2TPv3上的MPLS支持IPv6。分别参见RFC 4023[RFC4023]第3节和RFC 4817[RFC4817]第2节。
Gap: None.
差距：没有。
The Label Distribution Protocol (LDP) [RFC5036] defines a set of procedures for distribution of labels between Label Switching Routers that can use the labels for forwarding traffic. While LDP was designed to use an IPv4 or dual-stack IP network, it has a number of deficiencies that prevent it from working in an IPv6-only network. LDP-IPv6 [LDP-IPv6] highlights some of the deficiencies when LDP is enabled in IPv6-only or dual-stack networks and specifies appropriate protocol changes. These deficiencies are related to Label Switched Path (LSP) mapping, LDP identifiers, LDP discovery, LDP session establishment, next-hop address, and LDP Time To Live (TTL) security [RFC5082] [RFC6720].
标签分发协议（LDP）[RFC5036]定义了一组在标签交换路由器之间分发标签的过程，这些路由器可以使用标签转发流量。虽然LDP被设计为使用IPv4或双栈IP网络，但它存在许多缺陷，无法在仅IPv6的网络中工作。LDP-IPv6[LDP-IPv6]强调了在仅IPv6或双栈网络中启用LDP时的一些缺陷，并指定了适当的协议更改。这些缺陷与标签交换路径（LSP）映射、LDP标识符、LDP发现、LDP会话建立、下一跳地址和LDP生存时间（TTL）安全[RFC5082][RFC6720]有关。
Gap: Major; update to RFC 5036 in progress via [LDP-IPv6], which should close this gap.
差距：主要；正在通过[LDP-IPv6]更新RFC 5036，这将弥补这一差距。
Multipoint LDP (mLDP) is a set of extensions to LDP for setting up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) LSPs. These extensions are specified in RFC 6388 [RFC6388]. In terms of IPv6-only gap analysis, mLDP has two identified areas of interest:
多点LDP（mLDP）是LDP的一组扩展，用于建立点对多点（P2MP）和多点对多点（MP2MP）LSP。RFC 6388[RFC6388]中规定了这些扩展。就仅限IPv6的差距分析而言，mLDP有两个确定的关注领域：
1. LDP Control Plane: Since mLDP uses the LDP control plane to discover and establish sessions with the peer, it shares the same gaps as LDP (Section 3.2.1) with regards to control plane (discovery, transport, and session establishment) in an IPv6-only network.
1. LDP控制平面：由于mLDP使用LDP控制平面来发现和建立与对等方的会话，因此它在仅IPv6网络中的控制平面（发现、传输和会话建立）方面与LDP（第3.2.1节）具有相同的差距。
2. Multipoint (MP) Forwarding Equivalence Class (FEC) Root Address: mLDP defines its own MP FECs and rules, different from LDP, to map MP LSPs. An mLDP MP FEC contains a Root Address field that is an IP address in IP networks. The current specification allows specifying the root address according to the Address Family Identifier (AFI), and hence covers both IPv4 or IPv6 root addresses, requiring no extension to support IPv6-only MP LSPs. The root address is used by each LSR participating in an MP LSP setup such that root address reachability is resolved by doing a table lookup against the root address to find corresponding upstream neighbor(s). This will pose a problem if an MP LSP traverses IPv4-only and IPv6-only nodes in a dual-stack network on the way to the root node.
2. 多点（MP）转发等价类（FEC）根地址：mLDP定义自己的MP FEC和规则（不同于LDP）来映射MP LSP。mLDP MP FEC包含一个根地址字段，该字段是IP网络中的IP地址。当前规范允许根据地址族标识符（AFI）指定根地址，因此涵盖IPv4或IPv6根地址，无需扩展以支持仅IPv6 MP LSP。根地址由参与MP LSP设置的每个LSR使用，这样，根地址的可达性通过对根地址进行表查找来解决，以找到相应的上游邻居。如果MP LSP在到达根节点的途中遍历双堆栈网络中的仅IPv4和仅IPv6节点，则会出现问题。
For example, consider following setup, where R1/R6 are IPv4-only, R3/ R4 are IPv6-only, and R2/R5 are dual-stack LSRs:
例如，考虑以下设置，其中R1/R6仅为IPv4，R3/R4仅为IPv6，R2/R5为双栈LSRs：
( IPv4-only ) ( IPv6-only ) ( IPv4-only )
R1 -- R2 -- R3 -- R4 -- R5 -- R6
Leaf Root
( IPv4-only ) ( IPv6-only ) ( IPv4-only )
R1 -- R2 -- R3 -- R4 -- R5 -- R6
Leaf Root
Assume R1 to be a leaf node for a P2MP LSP rooted at R6 (root node). R1 uses R6's IPv4 address as the root address in MP FEC. As the MP LSP signaling proceeds from R1 to R6, the MP LSP setup will fail on the first IPv6-only transit/branch LSRs (R3) when trying to find IPv4 root address reachability. RFC 6512 [RFC6512] defines a recursive-FEC solution and procedures for mLDP when the backbone (transit/ branch) LSRs have no route to the root. The proposed solution is defined for a BGP-free core in a VPN environment, but a similar concept can be used/extended to solve the above issue of the IPv6-only backbone receiving an MP FEC element with an IPv4 address. The solution will require a border LSR (the one that is sitting on the border of an IPv4/IPv6 island (namely, R2 and R5 in this example)) to translate an IPv4 root address to an equivalent IPv6 address (and vice versa) through procedures similar to RFC 6512.
假设R1是根在R6（根节点）的P2MP LSP的叶节点。R1使用R6的IPv4地址作为MP FEC中的根地址。当MP LSP信令从R1发送到R6时，在尝试查找IPv4根地址可达性时，MP LSP设置将在第一个仅限IPv6的传输/分支LSR（R3）上失败。RFC 6512[RFC6512]定义了当主干（传输/分支）LSR没有到根的路由时，mLDP的递归FEC解决方案和过程。建议的解决方案是为VPN环境中的无BGP核心定义的，但可以使用/扩展类似的概念来解决上述问题，即仅IPv6主干接收具有IPv4地址的MP FEC元素。解决方案将需要边界LSR（位于IPv4/IPv6岛边界上的LSR（即本例中的R2和R5））通过类似于RFC 6512的过程将IPv4根地址转换为等效的IPv6地址（反之亦然）。
Gap: Major; update in progress for LDP via [LDP-IPv6], may need additional updates to RFC 6512.
差距：主要；正在通过[LDP-IPv6]对LDP进行更新，可能需要对RFC 6512进行额外更新。
RSVP-TE [RFC3209] defines a set of procedures and enhancements to establish LSP tunnels that can be automatically routed away from network failures, congestion, and bottlenecks. RSVP-TE allows establishing an LSP for an IPv4 or IPv6 prefix, thanks to its LSP_TUNNEL_IPv6 object and subobjects.
RSVP-TE[RFC3209]定义了一组程序和增强功能，以建立LSP隧道，该隧道可以自动路由，远离网络故障、拥塞和瓶颈。由于其LSP_TUNNEL_IPv6对象和子对象，RSVP-TE允许为IPv4或IPv6前缀建立LSP。
Gap: None.
差距：没有。
RFC 3630 [RFC3630] specifies a method of adding traffic engineering capabilities to OSPF Version 2. New TLVs and sub-TLVs were added in RFC 5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF Version 3.
RFC 3630[RFC3630]规定了向OSPF版本2添加流量工程功能的方法。RFC 5329[RFC5329]中添加了新的TLV和子TLV，以将TE功能扩展到OSPF版本3中的IPv6网络。
RFC 5305 [RFC5305] specifies a method of adding traffic engineering capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC 6119 [RFC6119] to extend TE capabilities to IPv6 networks.
RFC 5305[RFC5305]规定了向IS-IS添加流量工程功能的方法。RFC 6119[RFC6119]中添加了新的TLV和子TLV，以将TE功能扩展到IPv6网络。
Gap: None.
差距：没有。
RFC 4875 [RFC4875] describes extensions to RSVP-TE for the setup of Point-to-Multipoint (P2MP) LSPs in MPLS and Generalized MPLS (GMPLS) with support for both IPv4 and IPv6.
RFC 4875[RFC4875]描述了RSVP-TE的扩展，用于在MPLS和通用MPLS（GMPLS）中设置点对多点（P2MP）LSP，同时支持IPv4和IPv6。
Gap: None.
差距：没有。
RFC 4090 [RFC4090] specifies Fast Reroute (FRR) mechanisms to establish backup LSP tunnels for local repair supporting both IPv4 and IPv6 networks. Further, [RFC5286] describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS networks in the event of a single failure, whether link, node, or shared risk link group (SRLG) for both IPv4 and IPv6.
RFC 4090[RFC4090]指定了快速重路由（FRR）机制，以建立支持IPv4和IPv6网络的本地修复的备份LSP隧道。此外，[RFC5286]描述了在IPv4和IPv6的链路、节点或共享风险链路组（SRLG）发生单一故障的情况下，使用无环路替代方案为纯IP和MPLS网络中的单播通信提供本地保护。
Gap: None.
差距：没有。
The Path Computation Element (PCE) defined in RFC 4655 [RFC4655] is an entity that is capable of computing a network path or route based on a network graph and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed. The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs for path computations and is defined in RFC 5440 [RFC5440].
RFC 4655[RFC4655]中定义的路径计算元素（PCE）是能够基于网络图计算网络路径或路由并应用计算约束的实体。路径计算客户端（PCC）可以向PCE请求要计算的路径。PCE通信协议（PCEP）设计为PCC和PCE之间用于路径计算的通信协议，并在RFC 5440[RFC5440]中定义。
The PCEP specification [RFC5440] is defined for both IPv4 and IPv6 with support for PCE discovery via an IGP (OSPF [RFC5088] or IS-IS [RFC5089]) using both IPv4 and IPv6 addresses. Note that PCEP uses identical encoding of subobjects, as in RSVP-TE defined in RFC 3209 [RFC3209] that supports both IPv4 and IPv6.
PCEP规范[RFC5440]是为IPv4和IPv6定义的，支持通过同时使用IPv4和IPv6地址的IGP（OSPF[RFC5088]或is-is[RFC5089]）发现PCE。请注意，PCEP使用相同的子对象编码，如RFC 3209[RFC3209]中定义的RSVP-TE中所述，它同时支持IPv4和IPv6。
The extensions to PCEP to support confidentiality [RFC5520], route exclusions [RFC5521], monitoring [RFC5886], and P2MP TE LSPs [RFC6006] have support for both IPv4 and IPv6.
支持保密性[RFC5520]、路由排除[RFC5521]、监视[RFC5886]和P2MP TE LSP[RFC6006]的PCEP扩展同时支持IPv4和IPv6。
Gap: None.
差距：没有。
RFC 3107 [RFC3107] specifies a set of BGP protocol procedures for distributing the labels (for prefixes corresponding to any address family) between label switch routers so that they can use the labels for forwarding the traffic. RFC 3107 allows BGP to distribute the label for IPv4 or IPv6 prefix in an IPv6-only network.
RFC 3107[RFC3107]指定了一组BGP协议过程，用于在标签交换路由器之间分发标签（用于对应于任何地址系列的前缀），以便它们可以使用标签转发流量。RFC 3107允许BGP在仅限IPv6的网络中分发IPv4或IPv6前缀的标签。
Gap: None.
差距：没有。
The Generalized Multi-Protocol Label Switching (GMPLS) specification includes signaling functional extensions [RFC3471] and RSVP-TE extensions [RFC3473]. The gap analysis in Section 3.2.3 applies to these.
通用多协议标签交换（GMPLS）规范包括信令功能扩展[RFC3471]和RSVP-TE扩展[RFC3473]。第3.2.3节中的差距分析适用于这些。
RFC 4558 [RFC4558] specifies Node-ID Based RSVP Hello Messages with capability for both IPv4 and IPv6. RFC 4990 [RFC4990] clarifies the use of IPv6 addresses in GMPLS networks including handling in the MIB modules.
RFC 4558[RFC4558]指定基于节点ID的RSVP Hello消息，该消息同时支持IPv4和IPv6。RFC 4990[RFC4990]阐明了IPv6地址在GMPLS网络中的使用，包括MIB模块中的处理。
The second paragraph of Section 5.3 of RFC 6370 [RFC6370] describes the mapping from an MPLS Transport Profile (MPLS-TP) LSP_ID to RSVP-TE with an assumption that Node_IDs are derived from valid IPv4 addresses. This assumption fails in an IPv6-only network, given that there would not be any IPv4 addresses.
RFC 6370[RFC6370]第5.3节第二段描述了从MPLS传输配置文件（MPLS-TP）LSP_ID到RSVP-TE的映射，假设节点_ID来自有效的IPv4地址。考虑到不存在任何IPv4地址，这种假设在仅IPv6的网络中失败。
Gap: Minor; Section 5.3 of RFC 6370 [RFC6370] needs to be updated.
差距：轻微；RFC 6370[RFC6370]第5.3节需要更新。
L2VPN [RFC4664] specifies two fundamentally different kinds of Layer 2 VPN services that a service provider could offer to a customer: Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS). RFC 4447 [RFC4447] and RFC 4762 [RFC4762] specify the LDP protocol changes to instantiate VPWS and VPLS services, respectively, in an MPLS network using LDP as the signaling protocol. This is complemented by RFC 6074 [RFC6074], which specifies a set of procedures for instantiating L2VPNs (e.g., VPWS, VPLS) using BGP as a
L2VPN[RFC4664]指定了服务提供商可以向客户提供的两种根本不同的第2层VPN服务：虚拟专用线服务（VPWS）和虚拟专用局域网服务（VPLS）。RFC 4447[RFC4447]和RFC 4762[RFC4762]指定LDP协议更改，以分别在使用LDP作为信令协议的MPLS网络中实例化VPWS和VPLS服务。RFC 6074[RFC6074]补充了这一点，其中规定了一组使用BGP作为实例实例化L2VPN（例如VPW、VPL）的程序
discovery protocol and LDP, as well as L2TPv3, as a signaling protocol. RFC 4761 [RFC4761] and RFC 6624 [RFC6624] specify BGP protocol changes to instantiate VPLS and VPWS services in an MPLS network, using BGP for both discovery and signaling.
发现协议和LDP以及L2TPv3作为信令协议。RFC 4761[RFC4761]和RFC 6624[RFC6624]指定BGP协议更改，以实例化MPLS网络中的VPLS和VPWS服务，使用BGP进行发现和信令。
In an IPv6-only MPLS network, use of L2VPN represents a connection of Layer 2 islands over an IPv6 MPLS core, and very few changes are necessary to support operation over an IPv6-only network. The L2VPN signaling protocol is either BGP or LDP in an MPLS network, and both can run directly over IPv6 core infrastructure as well as IPv6 edge devices. RFC 6074 [RFC6074] is the only RFC that appears to have a gap for IPv6-only operation. In its discovery procedures (Sections 3.2.2 and 6 of RFC 6074 [RFC6074]), it suggests encoding PE IP addresses in the Virtual Switching Instance ID (VSI-ID), which is encoded in Network Layer Reachability Information (NLRI) and should not exceed 12 bytes (to differentiate its AFI/SAFI (Subsequent Address Family Identifier) encoding from RFC 4761). This means that a PE IP address cannot be an IPv6 address. Also, in its signaling procedures (Section 3.2.3 of RFC 6074 [RFC6074]), it suggests encoding PE_addr in the Source Attachment Individual Identifier (SAII) and the Target Attachment Individual Identifier (TAII), which are limited to 32 bits (AII Type=1) at the moment.
在仅限IPv6的MPLS网络中，L2VPN的使用表示IPv6 MPLS核心上的第2层孤岛连接，并且支持仅限IPv6网络上的操作所需的更改很少。L2VPN信令协议是MPLS网络中的BGP或LDP，两者都可以直接在IPv6核心基础设施以及IPv6边缘设备上运行。RFC 6074[RFC6074]是唯一一个似乎对仅IPv6操作存在差距的RFC。在其发现程序（RFC 6074[RFC6074]第3.2.2和6节）中，建议在虚拟交换实例ID（VSI-ID）中编码PE IP地址，虚拟交换实例ID编码在网络层可达性信息（NLRI）中，且不应超过12字节（以区分其AFI/SAFI（后续地址族标识符）编码与RFC 4761）. 这意味着PE IP地址不能是IPv6地址。此外，在其信令程序（RFC 6074[RFC6074]第3.2.3节）中，建议在源附件单独标识符（SAII）和目标附件单独标识符（TAII）中编码PE_addr，目前限制为32位（AII类型=1）。
RFC 6073 [RFC6073] defines the new LDP Pseudowire (PW) Switching Point PE TLV, which supports IPv4 and IPv6.
RFC 6073[RFC6073]定义了新的LDP伪线（PW）交换点PE TLV，它支持IPv4和IPv6。
Gap: Minor; RFC 6074 needs to be updated.
差距：轻微；RFC 6074需要更新。
Ethernet VPN [EVPN] defines a method for using BGP MPLS-based Ethernet VPNs. Because it can use functions in LDP and mLDP, as well as Multicast VPLS [RFC7117], it inherits LDP gaps previously identified in Section 3.2.1. Once those gaps are resolved, it should function properly on IPv6-only networks as defined.
以太网VPN[EVPN]定义了一种使用基于BGP MPLS的以太网VPN的方法。因为它可以使用LDP和mLDP中的函数，以及多播VPL[RFC7117]，所以它继承了先前在第3.2.1节中确定的LDP缺口。一旦这些差距得到解决，它应该在定义的仅限IPv6的网络上正常运行。
Gap: Major for LDP; update to RFC 5036 in progress via [LDP-IPv6] that should close this gap (see Section 3.2.1).
差距：自民党的主要优势；正在通过[LDP-IPv6]对RFC 5036进行更新，以弥补这一差距（见第3.2.1节）。
RFC 4364 [RFC4364] defines a method by which a Service Provider may use an IP backbone to provide IP VPNs for its customers. The following use cases arise in the context of this gap analysis:
RFC 4364[RFC4364]定义了一种方法，通过该方法，服务提供商可以使用IP主干为其客户提供IP VPN。此差距分析中出现了以下用例：
1. Connecting IPv6 islands over IPv6-only MPLS network
1. 通过仅限IPv6的MPLS网络连接IPv6孤岛
2. Connecting IPv4 islands over IPv6-only MPLS network
2. 通过仅限IPv6的MPLS网络连接IPv4孤岛
Both use cases require mapping an IP packet to an IPv6-signaled LSP. RFC 4364 defines Layer 3 Virtual Private Networks (L3VPNs) for IPv4-only and has references to 32-bit BGP next-hop addresses. RFC 4659 [RFC4659] adds support for IPv6 on L3VPNs, including 128-bit BGP next-hop addresses, and discusses operation whether IPv6 is the payload or the underlying transport address family. However, RFC 4659 does not formally update RFC 4364, and thus an implementer may miss this additional set of standards unless it is explicitly identified independently of the base functionality defined in RFC 4364. Further, Section 1 of RFC 4659 explicitly identifies use case 2 as out of scope for the document.
这两种用例都需要将IP数据包映射到IPv6信号LSP。RFC 4364仅为IPv4定义第3层虚拟专用网络（L3VPN），并引用32位BGP下一跳地址。RFC 4659[RFC4659]增加了对L3VPN上IPv6的支持，包括128位BGP下一跳地址，并讨论了IPv6是有效负载还是底层传输地址系列的操作。然而，RFC 4659并没有正式更新RFC 4364，因此，除非明确地独立于RFC 4364中定义的基本功能来标识，否则实现者可能会错过这组额外的标准。此外，RFC4659的第1节明确指出用例2超出了文档的范围。
The authors do not believe that there are any additional issues encountered when using L2TPv3, RSVP, or GRE (instead of MPLS) as transport on an IPv6-only network.
作者认为，在纯IPv6网络上使用L2TPv3、RSVP或GRE（而不是MPLS）作为传输时，不会遇到任何其他问题。
Gap: Major; RFC 4659 needs to be updated to explicitly cover use case 2 (discussed in further detail below)
差距：主要；RFC 4659需要更新，以明确涵盖用例2（下文将进一步详细讨论）
RFC 4798 [RFC4798] defines IPv6 Provider Edge (6PE), which defines how to interconnect IPv6 islands over a MPLS-enabled IPv4 cloud. However, use case 2 is doing the opposite, and thus could also be referred to as IPv4 Provider Edge (4PE). The method to support this use case is not defined explicitly. To support it, IPv4 edge devices need to be able to map IPv4 traffic to MPLS IPv6 core LSPs. Also, the core switches may not understand IPv4 at all, but in some cases they may need to be able to exchange Labeled IPv4 routes from one Autonomous System (AS) to a neighboring AS.
RFC 4798[RFC4798]定义了IPv6提供程序边缘（6PE），它定义了如何通过支持MPLS的IPv4云互连IPv6孤岛。然而，用例2的作用正好相反，因此也可以称为IPv4提供程序边缘（4PE）。支持此用例的方法没有明确定义。为了支持它，IPv4边缘设备需要能够将IPv4流量映射到MPLS IPv6核心LSP。此外，核心交换机可能根本不了解IPv4，但在某些情况下，它们可能需要能够交换从一个自治系统（AS）到相邻AS的标记IPv4路由。
Gap: Major; RFC 4798 covers only the "6PE" case. Use case 2 is currently not specified in an RFC.
差距：主要；RFC 4798仅涵盖“6PE”情况。用例2目前未在RFC中指定。
3.3.2.2. IPv6 Virtual Private Extension/IPv4 Virtual Private Extension (6VPE/4VPE)
3.3.2.2. IPv6虚拟专用扩展/IPv4虚拟专用扩展（6VPE/4VPE）
RFC 4659 [RFC4659] defines IPv6 Virtual Private Network Extension (6VPE), a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. It allows the core network to be MPLS IPv4 or MPLS IPv6, thus addressing use case 1 above. RFC 4364 should work as defined for use case 2 above, which could also be referred to as IPv4 Virtual Private Extension (4VPE), but the RFC explicitly does not discuss this use and defines it as out of scope.
RFC 4659[RFC4659]定义了IPv6虚拟专用网络扩展（6VPE），一种服务提供商可以使用其分组交换主干网为其IPv6客户提供虚拟专用网络（VPN）服务的方法。它允许核心网络为MPLS IPv4或MPLS IPv6，从而解决上述用例1。RFC 4364应该按照上面用例2的定义工作，它也可以被称为IPv4虚拟专用扩展（4VPE），但是RFC明确地没有讨论这种使用，并将其定义为超出范围。
Gap: Minor; RFC 4659 needs to be updated to explicitly cover use case 2.
差距：轻微；RFC4659需要更新以明确涵盖用例2。
RFC 5512 [RFC5512] defines the BGP Encapsulation SAFI and the BGP Tunnel Encapsulation Attribute, which can be used to signal tunneling over an IP Core that is using a single address family. This mechanism supports transport of MPLS (and other protocols) over Tunnels in an IP core (including an IPv6-only core). In this context, load balancing can be provided as specified in RFC 5640 [RFC5640].
RFC 5512[RFC5512]定义了BGP封装SAFI和BGP隧道封装属性，可用于通过使用单个地址族的IP核发出隧道信号。此机制支持通过IP核心（包括仅限IPv6的核心）中的隧道传输MPLS（和其他协议）。在这种情况下，可以按照RFC 5640[RFC5640]中的规定提供负载平衡。
Gap: None.
差距：没有。
RFC 6513 [RFC6513] defines the procedure to provide multicast service over an MPLS VPN backbone for downstream customers. It is sometimes referred to as Next Generation Multicast VPN (NG-MVPN) The procedure involves the below set of protocols.
RFC 6513[RFC6513]定义了通过MPLS VPN主干为下游客户提供多播服务的过程。它有时被称为下一代多播VPN（NG-MVPN）。该过程涉及以下一组协议。
RFC 6513 [RFC6513] explains the use of Protocol Independent Multicast (PIM) as a Provider Edge - Customer Edge (PE-CE) protocol, while Section 11.1.2 of RFC 6514 [RFC6514] explains the use of mLDP as a PE-CE protocol.
RFC 6513[RFC6513]解释了协议独立多播（PIM）作为提供商边缘-客户边缘（PE-CE）协议的使用，而RFC 6514[RFC6514]第11.1.2节解释了mLDP作为PE-CE协议的使用。
The MCAST-VPN NLRI route-type format defined in RFC 6514 [RFC6514] is not sufficiently covering all scenarios when mLDP is used as a PE-CE protocol. The issue is explained in Section 2 of [mLDP-NLRI] along with a new route type that encodes the mLDP FEC in NLRI.
当mLDP用作PE-CE协议时，RFC 6514[RFC6514]中定义的MCAST-VPN NLRI路由类型格式不足以覆盖所有场景。[mLDP NLRI]的第2节解释了该问题，以及在NLRI中编码mLDP FEC的新路由类型。
Further, [PE-CE] defines the use of BGP as a PE-CE protocol.
此外，[PE-CE]定义了BGP作为PE-CE协议的使用。
Gap: None.
差距：没有。
[RFC6513] explains the use of the below tunnels:
[RFC6513]解释了以下隧道的使用：
o RSVP-TE P2MP LSP
o RSVP-TE P2MP LSP
o PIM Tree
o PIM树
o mLDP P2MP LSP
o mLDP P2MP LSP
o mLDP MP2MP LSP
o mLDP MP2MP LSP
o Ingress Replication
o 入口复制
Gap: Gaps in RSVP-TE P2MP LSP (Section 3.2.3.2) and mLDP (Section 3.2.2) P2MP and MP2MP LSP are covered in previous sections. There are no MPLS-specific gaps for PIM Tree or Ingress Replication, and any protocol-specific gaps not related to MPLS are outside the scope of this document.
差距：RSVP-TE P2MP LSP（第3.2.3.2节）和mLDP（第3.2.2节）P2MP和MP2MP LSP中的差距已在前面的章节中涵盖。PIM树或入口复制不存在MPLS特定间隙，与MPLS无关的任何协议特定间隙不在本文档范围内。
Section 3.1 of RFC 6513 [RFC6513] explains the use of PIM as a PE-PE protocol, while RFC 6514 [RFC6514] explains the use of BGP as a PE-PE protocol.
RFC 6513[RFC6513]第3.1节解释了PIM作为PE-PE协议的使用，而RFC 6514[RFC6514]解释了BGP作为PE-PE协议的使用。
PE-PE multicast routing is not specific to P-tunnels or to MPLS. It can be PIM or BGP with P-tunnels that are label based or PIM tree based. Enabling PIM as a PE-PE multicast protocol is equivalent to running it on a non-MPLS IPv6 network, so there are not any MPLS-specific considerations and any gaps are applicable for non-MPLS networks as well. Similarly, BGP only includes the P-Multicast Service Interface (PMSI) tunnel attribute as a part of the NLRI, which is inherited from P-tunnel instantiation and considered to be an opaque value. Any gaps in the control plane (PIM or BGP) will not be specific to MPLS.
PE-PE多播路由并不特定于P隧道或MPLS。它可以是PIM或BGP，带有基于标签或PIM树的P隧道。启用PIM作为PE-PE多播协议相当于在非MPLS IPv6网络上运行它，因此不存在任何MPLS特定的注意事项，任何间隙也适用于非MPLS网络。类似地，BGP仅包括作为NLRI一部分的P-Multicast服务接口（PMSI）隧道属性，NLRI继承自P-tunnel实例化并被视为不透明值。控制平面（PIM或BGP）中的任何间隙都不是MPLS特有的。
Gap: Any gaps in PIM or BGP as a PE-PE multicast routing protocol are not unique to MPLS, and therefore are outside the scope of this document. It is included for completeness.
间隙：作为PE-PE多播路由协议的PIM或BGP中的任何间隙不是MPLS独有的，因此不在本文档的范围内。为完整起见，将其包括在内。
MPLS-TP does not require IP (see Section 2 of RFC 5921 [RFC5921]) and should not be affected by operation on an IPv6-only network. Therefore, this is considered out of scope for this document but is included for completeness.
MPLS-TP不需要IP（参见RFC 5921[RFC5921]第2节），并且不应受到仅在IPv6网络上运行的影响。因此，这被视为超出了本文件的范围，但为了完整性而包括在内。
Although not required, MPLS-TP can use IP. One such example is included in Section 3.2.6, where MPLS-TP identifiers can be derived from valid IPv4 addresses.
虽然不是必需的，但MPLS-TP可以使用IP。第3.2.6节中包含了一个这样的示例，其中MPLS-TP标识符可以从有效的IPv4地址派生。
Gap: None. MPLS-TP does not require IP.
差距：没有。MPLS-TP不需要IP。
For MPLS LSPs, there are primarily three OAM mechanisms: Extended ICMP [RFC4884] [RFC4950], LSP Ping [RFC4379], and Bidirectional Forwarding Detection (BFD) for MPLS LSPs [RFC5884]. For MPLS Pseudowires, there is also Virtual Circuit Connectivity Verification (VCCV) [RFC5085] [RFC5885]. Most of these mechanisms work in pure
对于MPLS LSP，主要有三种OAM机制：扩展ICMP[RFC4884][RFC4950]、LSP Ping[RFC4379]和MPLS LSP的双向转发检测（BFD）[RFC5884]。对于MPLS伪线，还有虚拟电路连接验证（VCCV）[RFC5085][RFC5885]。这些机制中的大多数在纯环境中工作
IPv6 environments, but there are some problems encountered in mixed environments due to address-family mismatches. The next subsections cover these gaps in detail.
IPv6环境，但由于地址族不匹配，在混合环境中会遇到一些问题。下一小节将详细介绍这些差距。
Gap: Major; RFC 4379 needs to be updated to better support multipath IPv6. Additionally, there is potential for dropped messages in Extended ICMP and LSP Ping due to IP version mismatches. It is important to note that this is a more generic problem with tunneling when address-family mismatches exist and is not specific to MPLS. While MPLS will be affected, it will be difficult to fix this problem specifically for MPLS, rather than fixing the more generic problem.
差距：主要；RFC 4399需要更新，以更好地支持多路径IPv6。此外，由于IP版本不匹配，扩展ICMP和LSP Ping中可能会丢失消息。重要的是要注意，当存在地址族不匹配且不是特定于MPLS时，这是一个更普遍的隧道问题。虽然MPLS会受到影响，但很难专门针对MPLS解决此问题，而不是解决更一般的问题。
Extended ICMP to support Multi-part messages is defined in RFC 4884 [RFC4884]. This extensibility is defined generally for both ICMPv4 and ICMPv6. The specific ICMP extensions for MPLS are defined in RFC 4950 [RFC4950]. ICMP Multi-part with MPLS extensions works for IPv4 and IPv6. However, the mechanisms described in RFC 4884 and 4950 may fail when tunneling IPv4 traffic over an LSP that is supported by an IPv6-only infrastructure.
RFC 4884[RFC4884]中定义了支持多部分消息的扩展ICMP。此扩展性通常为ICMPv4和ICMPv6定义。用于MPLS的特定ICMP扩展在RFC 4950[RFC4950]中定义。带有MPLS扩展的ICMP多部分协议适用于IPv4和IPv6。但是，RFC 4884和4950中描述的机制在通过仅IPv6基础设施支持的LSP进行IPv4流量隧道传输时可能会失败。
Assume the following:
假设如下：
o The path between two IPv4-only hosts contains an MPLS LSP.
o 两个仅IPv4主机之间的路径包含MPLS LSP。
o The two routers that terminate the LSP run dual stack.
o 终止LSP的两个路由器运行双堆栈。
o The LSP interior routers run IPv6 only.
o LSP内部路由器仅运行IPv6。
o The LSP is signaled over IPv6.
o LSP通过IPv6发送信号。
Now assume that one of the hosts sends an IPv4 packet to the other. However, the packet's TTL expires on an LSP interior router. According to RFC 3032 [RFC3032], the interior router should examine the IPv4 payload, format an ICMPv4 message, and send it (over the tunnel upon which the original packet arrived) to the egress LSP. In this case, however, the LSP interior router is not IPv4-aware. It cannot parse the original IPv4 datagram, nor can it send an IPv4 message. So, no ICMP message is delivered to the source. Some specific ICMP extensions, in particular, ICMP extensions for interface and next-hop identification [RFC5837], restrict the address family of address information included in an Interface Information Object to the same one as the ICMP (see Section 4.5 of RFC 5837). While these extensions are not MPLS specific, they can be used with MPLS packets carrying IP datagrams. This has no implications for IPv6-only environments.
现在假设其中一个主机向另一个主机发送IPv4数据包。但是，数据包的TTL在LSP内部路由器上过期。根据RFC 3032[RFC3032]，内部路由器应检查IPv4有效负载，格式化ICMPv4消息，并将其（通过原始数据包到达的隧道）发送到出口LSP。然而，在这种情况下，LSP内部路由器不支持IPv4。它无法解析原始IPv4数据报，也无法发送IPv4消息。因此，没有ICMP消息传递到源。一些特定的ICMP扩展，特别是接口和下一跳标识的ICMP扩展[RFC5837]，将接口信息对象中包含的地址信息的地址族限制为与ICMP相同的地址族（请参阅RFC 5837第4.5节）。虽然这些扩展不是特定于MPLS的，但它们可以与承载IP数据报的MPLS数据包一起使用。这对仅限IPv6的环境没有影响。
Gap: Major; IP version mismatches may cause dropped messages. However, as noted in the previous section, this problem is not specific to MPLS.
差距：主要；IP版本不匹配可能会导致消息丢失。但是，如前一节所述，此问题并非特定于MPLS。
The LSP Ping mechanism defined in RFC 4379 [RFC4379] is specified to work with IPv6. Specifically, the Target FEC Stacks include both IPv4 and IPv6 versions of all FECs (see Section 3.2 of RFC 4379). The only exceptions are the Pseudowire FECs, which are later specified for IPv6 in RFC 6829 [RFC6829]. The multipath information also includes IPv6 encodings (see Section 3.3.1 of RFC 4379).
RFC 4379[RFC4379]中定义的LSP Ping机制指定用于IPv6。具体而言，目标FEC堆栈包括所有FEC的IPv4和IPv6版本（参见RFC 4399第3.2节）。唯一的例外是伪线FEC，稍后在RFC 6829[RFC6829]中为IPv6指定了伪线FEC。多路径信息还包括IPv6编码（见RFC 4399第3.3.1节）。
LSP Ping packets are UDP packets over either IPv4 or IPv6 (see Section 4.3 of RFC 4379). However, for IPv6 the destination IP address is a (randomly chosen) IPv6 address from the range 0:0:0:0:0:FFFF:127/104; that is, using an IPv4-mapped IPv6 address. This is a transitional mechanism that should not bleed into IPv6-only networks, as [IPv4-MAPPED] explains. The issue is that the MPLS LSP Ping mechanism needs a range of loopback IP addresses to be used as destination addresses to exercise Equal Cost Multiple Path (ECMP), but the IPv6 address architecture specifies a single address (::1/128) for loopback. A mechanism to achieve this was proposed in [LOOPBACK-PREFIX].
LSP Ping数据包是IPv4或IPv6上的UDP数据包（参见RFC 4399第4.3节）。但是，对于IPv6，目标IP地址是范围为0:0:0:0:0:FFFF:127/104的（随机选择的）IPv6地址；也就是说，使用IPv4映射的IPv6地址。正如[IPv4 MAPPED]所解释的，这是一种过渡机制，不应渗透到仅IPv6的网络中。问题在于，MPLS LSP Ping机制需要一系列环回IP地址用作目标地址，以实现等成本多路径（ECMP），但IPv6地址体系结构为环回指定了一个地址（：：1/128）。[LOOPBACK-PREFIX]中提出了实现这一点的机制。
Additionally, RFC 4379 does not define the value to be used in the IPv6 Router Alert option (RAO). For IPv4 RAO, a value of zero is used. However, there is no equivalent value for IPv6 RAO. This gap needs to be fixed to be able to use LSP Ping in IPv6 networks. Further details on this gap are captured, along with a proposed solution, in [IPv6-RAO].
此外，RFC 4379未定义要在IPv6路由器警报选项（RAO）中使用的值。对于IPv4 RAO，使用的值为零。但是，IPv6 RAO没有等效值。为了能够在IPv6网络中使用LSP Ping，需要修复此差距。[IPv6 RAO]中提供了有关这一差距的更多详细信息以及建议的解决方案。
Another gap is that the mechanisms described in RFC 4379 may fail when tunneling IPv4 traffic over an LSP that is supported by IPv6-only infrastructure.
另一个差距是，RFC 4379中描述的机制在通过仅IPv6基础设施支持的LSP对IPv4流量进行隧道传输时可能会失败。
Assume the following:
假设如下：
o LSP Ping is operating in traceroute mode over an MPLS LSP.
o LSP Ping在MPLS LSP上以跟踪路由模式运行。
o The two routers that terminate the LSP run dual stack.
o 终止LSP的两个路由器运行双堆栈。
o The LSP interior routers run IPv6 only.
o LSP内部路由器仅运行IPv6。
o The LSP is signaled over IPv6.
o LSP通过IPv6发送信号。
Packets will expire at LSP interior routers. According to RFC 4379, the interior router must parse the IPv4 Echo Request and then send an IPv4 Echo Reply. However, the LSP interior router is not IPv4-aware. It cannot parse the IPv4 Echo Request, nor can it send an IPv4 Echo Reply. So, no reply is sent.
数据包将在LSP内部路由器上过期。根据RFC 4379，内部路由器必须解析IPv4回送请求，然后发送IPv4回送回复。但是，LSP内部路由器不支持IPv4。它无法分析IPv4回显请求，也无法发送IPv4回显回复。因此，没有发送回复。
The mechanism described in RFC 4379 also does not sufficiently explain the behavior in certain IPv6-specific scenarios. For example, RFC 4379 defines the K value as 28 octets when the Address Family is set to IPv6 Unnumbered, but it doesn't describe how to carry a 32-bit LSR Router ID in the 128-bit Downstream IP Address field.
RFC 4379中描述的机制也不能充分解释特定IPv6场景中的行为。例如，当地址族设置为IPv6 Unnumbered时，RFC 4379将K值定义为28个八位字节，但它没有描述如何在128位下游IP地址字段中携带32位LSR路由器ID。
Gap: Major; LSP Ping uses IPv4-mapped IPv6 addresses. IP version mismatches may cause dropped messages and unclear mapping from the LSR Router ID to Downstream IP Address.
差距：主要；LSP Ping使用IPv4映射的IPv6地址。IP版本不匹配可能会导致消息丢失和LSR路由器ID到下游IP地址的映射不清楚。
The BFD specification for MPLS LSPs [RFC5884] is defined for IPv4, as well as IPv6, versions of MPLS FECs (see Section 3.1 of RFC 5884). Additionally, the BFD packet is encapsulated over UDP and specified to run over both IPv4 and IPv6 (see Section 7 of RFC 5884).
MPLS LSP[RFC5884]的BFD规范是针对IPv4以及IPv6版本的MPLS FEC定义的（参见RFC 5884第3.1节）。此外，BFD数据包通过UDP进行封装，并指定在IPv4和IPv6上运行（请参阅RFC 5884的第7节）。
Gap: None.
差距：没有。
The OAM specifications for MPLS Pseudowires define usage for both IPv4 and IPv6. Specifically, VCCV [RFC5085] can carry IPv4 or IPv6 OAM packets (see Sections 5.1.1 and 5.2.1 of RFC 5085), and VCCV for BFD [RFC5885] also defines an IPv6 encapsulation (see Section 3.2 of RFC 5885).
MPLS伪线的OAM规范定义了IPv4和IPv6的使用。具体而言，VCCV[RFC5085]可以承载IPv4或IPv6 OAM数据包（参见RFC 5085第5.1.1节和第5.2.1节），BFD[RFC5885]的VCCV还定义了IPv6封装（参见RFC 5885第3.2节）。
Additionally, for LSP Ping for pseudowires, the Pseudowire FECs are specified for IPv6 in RFC 6829 [RFC6829].
此外，对于伪线的LSP Ping，在RFC 6829[RFC6829]中为IPv6指定了伪线FEC。
Gap: None.
差距：没有。
As with MPLS-TP, MPLS-TP OAM [RFC6371] does not require IP or existing MPLS OAM functions and should not be affected by operation on an IPv6-only network. Therefore, this is out of scope for this document but is included for completeness. Although not required, MPLS-TP can use IP.
与MPLS-TP一样，MPLS-TP OAM[RFC6371]不需要IP或现有MPLS OAM功能，并且不应受到仅在IPv6网络上运行的影响。因此，这超出了本文件的范围，但出于完整性考虑，将其包括在内。虽然不是必需的，但MPLS-TP可以使用IP。
Gap: None. MPLS-TP OAM does not require IP.
差距：没有。MPLS-TP OAM不需要IP。
RFC 3811 [RFC3811] defines the textual conventions for MPLS. These lack support for IPv6 in defining MplsExtendedTunnelId and MplsLsrIdentifier. These textual conventions are used in the MPLS-TE MIB specification [RFC3812], the GMPLS-TE MIB specification [RFC4802] and the FRR extension [RFC6445]. "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management" [MPLS-TC] tries to resolve this gap by marking this textual convention as obsolete.
RFC 3811[RFC3811]定义了MPLS的文本约定。在定义MPLStendedTunelId和MPLSLRIdentifier时，它们缺乏对IPv6的支持。这些文本约定用于MPLS-TE MIB规范[RFC3812]、GMPLS-TE MIB规范[RFC4802]和FRR扩展[RFC6445]。“多协议标签交换（MPLS）管理的文本约定（TC）定义”[MPLS-TC]试图通过将该文本约定标记为过时来解决这一差距。
The other MIB specifications for LSR [RFC3813], LDP [RFC3815], and TE [RFC4220] have support for both IPv4 and IPv6.
LSR[RFC3813]、LDP[RFC3815]和TE[RFC4220]的其他MIB规范同时支持IPv4和IPv6。
Lastly, RFC 4990 [RFC4990] discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS-TE MIB modules. In particular, Section 8 of RFC 4990 [RFC4990] describes a method of defining or monitoring an LSP tunnel using the MPLS-TE and GMPLS-TE MIB modules, working around some of the limitations in RFC 3811 [RFC3811].
最后，RFC 4990[RFC4990]讨论了如何在MPLS和GMPLS-TE MIB模块中处理IPv6源和目标。具体而言，RFC 4990[RFC4990]第8节描述了使用MPLS-TE和GMPLS-TE MIB模块定义或监控LSP隧道的方法，该方法绕过了RFC 3811[RFC3811]中的一些限制。
Gap: Minor; Section 8 of RFC 4990 [RFC4990] describes a method to handle IPv6 addresses in the MPLS-TE [RFC3812] and GMPLS-TE [RFC4802] MIB modules. Work underway to update RFC 3811 via [MPLS-TC], may also need to update RFC 3812, RFC 4802, and RFC 6445, which depend on it.
差距：轻微；RFC 4990[RFC4990]第8节描述了在MPLS-TE[RFC3812]和GMPLS-TE[RFC4802]MIB模块中处理IPv6地址的方法。正在进行的通过[MPLS-TC]更新RFC 3811的工作可能还需要更新RFC 3812、RFC 4802和RFC 6445，这取决于它。
This document has reviewed a wide variety of MPLS features and protocols to determine their suitability for use on IPv6-only or IPv6-primary networks. While some parts of the MPLS suite will function properly without additional changes, gaps have been identified in others that will need to be addressed with follow-on work. This section will summarize those gaps, along with pointers to any work in progress to address them. Note that because the referenced documents are works in progress and do not have consensus at the time of this document's publication, there could be other solutions proposed at a future time, and the pointers in this document should not be considered normative in any way. Additionally, work in progress on new features that use MPLS protocols will need to ensure that those protocols support operation on IPv6-only or IPv6-primary networks, or explicitly identify any dependencies on existing gaps that, once resolved, will allow proper IPv6-only operation.
本文档回顾了各种MPLS功能和协议，以确定它们是否适合仅在IPv6或IPv6主网络上使用。虽然MPLS套件的某些部分在不进行额外更改的情况下可以正常运行，但已发现其他部分存在差距，需要通过后续工作加以解决。本节将总结这些差距，以及解决这些差距的任何正在进行的工作的指针。请注意，由于参考文件是正在进行的工作，并且在本文件发布时没有达成共识，因此将来可能会提出其他解决方案，并且本文件中的指针不应被视为任何形式的规范性文件。此外，在使用MPLS协议的新功能上正在进行的工作需要确保这些协议仅支持IPv6或IPv6主网络上的操作，或者明确识别对现有差距的任何依赖，一旦解决这些差距，将允许正确的仅IPv6操作。
Identified Gaps in MPLS for IPv6-Only Networks
确定了仅用于IPv6网络的MPLS中的差距
+---------+---------------------------------------+-----------------+
| Item | Gap | Addressed in |
+---------+---------------------------------------+-----------------+
| LDP | LSP mapping, LDP identifiers, LDP | [LDP-IPv6] |
| S.3.2.1 | discovery, LDP session establishment, | |
| | next-hop address, and LDP TTL | |
| | security | |
+---------+---------------------------------------+-----------------+
| mLDP | Inherits gaps from LDP, RFC 6512 | Inherits |
| S.3.2.2 | [RFC6512] | [LDP-IPv6], |
| | | additional |
| | | fixes TBD |
+---------+---------------------------------------+-----------------+
| GMPLS | RFC 6370 [RFC6370] Node ID derivation | TBD |
| S.3.2.6 | | |
+---------+---------------------------------------+-----------------+
| L2VPN | RFC 6074 [RFC6074] discovery, | TBD |
| S.3.3.1 | signaling | |
+---------+---------------------------------------+-----------------+
| L3VPN | RFC 4659 [RFC4659] does not define a | TBD |
| S.3.3.2 | method for 4PE/4VPE | |
+---------+---------------------------------------+-----------------+
| OAM | RFC 4379 [RFC4379] No IPv6 multipath | [IPv6-RAO] |
| S.3.4 | support, no IPv6 RAO, possible | |
| | dropped messages in IP version | |
| | mismatch | |
+---------+---------------------------------------+-----------------+
| MIB | RFC 3811 [RFC3811] no IPv6 textual | [MPLS-TC] |
| Modules | convention | |
| S.3.5 | | |
+---------+---------------------------------------+-----------------+
+---------+---------------------------------------+-----------------+
| Item | Gap | Addressed in |
+---------+---------------------------------------+-----------------+
| LDP | LSP mapping, LDP identifiers, LDP | [LDP-IPv6] |
| S.3.2.1 | discovery, LDP session establishment, | |
| | next-hop address, and LDP TTL | |
| | security | |
+---------+---------------------------------------+-----------------+
| mLDP | Inherits gaps from LDP, RFC 6512 | Inherits |
| S.3.2.2 | [RFC6512] | [LDP-IPv6], |
| | | additional |
| | | fixes TBD |
+---------+---------------------------------------+-----------------+
| GMPLS | RFC 6370 [RFC6370] Node ID derivation | TBD |
| S.3.2.6 | | |
+---------+---------------------------------------+-----------------+
| L2VPN | RFC 6074 [RFC6074] discovery, | TBD |
| S.3.3.1 | signaling | |
+---------+---------------------------------------+-----------------+
| L3VPN | RFC 4659 [RFC4659] does not define a | TBD |
| S.3.3.2 | method for 4PE/4VPE | |
+---------+---------------------------------------+-----------------+
| OAM | RFC 4379 [RFC4379] No IPv6 multipath | [IPv6-RAO] |
| S.3.4 | support, no IPv6 RAO, possible | |
| | dropped messages in IP version | |
| | mismatch | |
+---------+---------------------------------------+-----------------+
| MIB | RFC 3811 [RFC3811] no IPv6 textual | [MPLS-TC] |
| Modules | convention | |
| S.3.5 | | |
+---------+---------------------------------------+-----------------+
Table 1: IPv6-Only MPLS Gaps
表1：仅限IPv6的MPLS差距
Changing the address family used for MPLS network operation does not fundamentally alter the security considerations currently extant in any of the specifics of the protocol or its features. However, follow-on work recommended by this gap analysis will need to address any effects that the use of IPv6 in their modifications may have on security.
更改用于MPLS网络操作的地址族不会从根本上改变协议或其功能的任何细节中目前存在的安全考虑因素。但是，此差距分析建议的后续工作将需要解决在其修改中使用IPv6可能对安全性产生的任何影响。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001, <http://www.rfc-editor.org/info/rfc3032>.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月<http://www.rfc-editor.org/info/rfc3032>.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001, <http://www.rfc-editor.org/info/rfc3107>.
[RFC3107]Rekhter，Y.和E.Rosen，“在BGP-4中携带标签信息”，RFC 3107，2001年5月<http://www.rfc-editor.org/info/rfc3107>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003, <http://www.rfc-editor.org/info/rfc3471>.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月<http://www.rfc-editor.org/info/rfc3471>.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月<http://www.rfc-editor.org/info/rfc3473>.
[RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004, <http://www.rfc-editor.org/info/rfc3811>.
[RFC3811]Nadeau，T.和J.Cucchiara，“多协议标签交换（MPLS）管理的文本约定（TC）定义”，RFC 3811，2004年6月<http://www.rfc-editor.org/info/rfc3811>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005, <http://www.rfc-editor.org/info/rfc4023>.
[RFC4023]Worster，T.，Rekhter，Y.，和E.Rosen，“在IP或通用路由封装（GRE）中封装MPLS”，RFC 4023，2005年3月<http://www.rfc-editor.org/info/rfc4023>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月<http://www.rfc-editor.org/info/rfc4379>.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006, <http://www.rfc-editor.org/info/4659>.
[RFC4659]De Clercq，J.，Ooms，D.，Carugi，M.，和F.Le Faucheur，“用于IPv6 VPN的BGP-MPLS IP虚拟专用网络（VPN）扩展”，RFC 46592006年9月<http://www.rfc-editor.org/info/4659>.
[RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and J. Young, "Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3", RFC 4817, March 2007, <http://www.rfc-editor.org/info/rfc4817>.
[RFC4817]Townsley，M.，Pignataro，C.，Wainner，S.，Seely，T.，和J.Young，“第2层隧道协议版本3上的MPLS封装”，RFC 48172007年3月<http://www.rfc-editor.org/info/rfc4817>.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036]Andersson，L.，Minei，I.，和B.Thomas，“LDP规范”，RFC 5036，2007年10月<http://www.rfc-editor.org/info/rfc5036>.
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011, <http://www.rfc-editor.org/info/rfc6074>.
[RFC6074]Rosen，E.，Davie，B.，Radoaca，V.，和W.Luo，“第二层虚拟专用网络（L2VPN）中的资源调配、自动发现和信令”，RFC 6074，2011年1月<http://www.rfc-editor.org/info/rfc6074>.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011, <http://www.rfc-editor.org/info/rfc6370>.
[RFC6370]Bocci，M.，Swallow，G.和E.Gray，“MPLS传输配置文件（MPLS-TP）标识符”，RFC 63702011年9月<http://www.rfc-editor.org/info/rfc6370>.
[RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, "Using Multipoint LDP When the Backbone Has No Route to the Root", RFC 6512, February 2012, <http://www.rfc-editor.org/info/rfc6512>.
[RFC6512]Wijnands，IJ.，Rosen，E.，Napierala，M.，和N.Leymann，“当主干没有到根的路由时使用多点LDP”，RFC 6512，2012年2月<http://www.rfc-editor.org/info/rfc6512>.
[EVPN] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", Work in Progress, draft-ietf-l2vpn-evpn-11, October 2014.
[EVPN]Sajassi，A.，Aggarwal，R.，Bitar，N.，Isaac，A.，和J.Uttaro，“基于BGP MPLS的以太网VPN”，正在进行的工作，草案-ietf-l2vpn-EVPN-11，2014年10月。
[IPv4-MAPPED] Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire Considered Harmful", Work in Progress, draft-itojun-v6ops-v4mapped-harmful-02, October 2003.
[IPv4映射]Metz，C.和J.Hagino，“被认为有害的网络上的IPv4映射地址”，正在进行的工作，草稿-itojun-v6ops-v4mapped-Habird-02，2003年10月。
[IPv6-RAO] Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert Option for MPLS OAM", Work in Progress, draft-raza-mpls-oam-ipv6-rao-02, September 2014.
[IPv6 RAO]Raza，K.，Akiya，N.，和C.Pignataro，“MPLS OAM的IPv6路由器警报选项”，正在进行的工作，草稿-Raza-MPLS-OAM-IPv6-RAO-022014年9月。
[LDP-IPv6] Asati, R., Manral, V., Papneja, R., and C. Pignataro, "Updates to LDP for IPv6", Work in Progress, draft-ietf-mpls-ldp-ipv6-14, October 2014.
[LDP-IPv6]Asati，R.，Manral，V.，Papneja，R.，和C.Pignataro，“IPv6的LDP更新”，正在进行的工作，草稿-ietf-mpls-LDP-IPv6-14，2014年10月。
[LOOPBACK-PREFIX] Smith, M., "A Larger Loopback Prefix for IPv6", Work in Progress, draft-smith-v6ops-larger-ipv6-loopback-prefix-04, February 2013.
[LOOPBACK-PREFIX]Smith，M.，“IPv6更大的环回前缀”，正在进行的工作，草稿-Smith-v6ops-Larger-IPv6-LOOPBACK-PREFIX-042013年2月。
[mLDP-NLRI] Wijnands, I., Rosen, E., and U. Joorde, "Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes", Work in Progress, draft-ietf-l3vpn-mvpn-mldp-nlri-10, November 2014.
[mLDP NLRI]Wijnands，I.，Rosen，E.，和U.Joorde，“在BGP MCAST-VPN路由的NLRI中编码mLDP FEC”，正在进行的工作，草案-ietf-l3vpn-mvpn-mLDP-NLRI-10，2014年11月。
[MPLS-TC] Manral, V., Tsou, T., Will, W., and F. Fondelli, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", Work in Progress, draft-manral-mpls-rfc3811bis-04, September 2014.
[MPLS-TC]Manral，V.，Tsou，T.，Will，W.，和F.Fondelli，“多协议标签交换（MPLS）管理的文本约定（TC）定义”，正在进行的工作，草稿-Manral-MPLS-rfc3811bis-042014年9月。
[PE-CE] Patel, K., Rekhter, Y., and E. Rosen, "BGP as an MVPN PE-CE Protocol", Work in Progress, draft-ietf-l3vpn-mvpn-pe- ce-02, October 2014.
[PE-CE]Patel，K.，Rekhter，Y.，和E.Rosen，“BGP作为MVPN PE-CE协议”，正在进行的工作，草案-ietf-l3vpn-MVPN-PE-CE-022014年10月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月<http://www.rfc-editor.org/info/rfc1918>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月<http://www.rfc-editor.org/info/rfc3630>.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004, <http://www.rfc-editor.org/info/rfc3812>.
[RFC3812]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）流量工程（TE）管理信息库（MIB）”，RFC 3812，2004年6月<http://www.rfc-editor.org/info/rfc3812>.
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004, <http://www.rfc-editor.org/info/rfc3813>.
[RFC3813]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）标签交换路由器（LSR）管理信息库（MIB）”，RFC 38132004年6月<http://www.rfc-editor.org/info/rfc3813>.
[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004, <http://www.rfc-editor.org/info/rfc3815>.
[RFC3815]Cucchiara，J.，Sjostrand，H.，和J.Luciani，“多协议标签交换（MPLS）管理对象的定义，标签分发协议（LDP）”，RFC 3815，2004年6月<http://www.rfc-editor.org/info/rfc3815>.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005, <http://www.rfc-editor.org/info/rfc4090>.
[RFC4090]Pan，P.，Swallow，G.和A.Atlas，“LSP隧道RSVP-TE快速改线扩展”，RFC 40902005年5月<http://www.rfc-editor.org/info/rfc4090>.
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005, <http://www.rfc-editor.org/info/rfc4220>.
[RFC4220]Dubuc，M.，Nadeau，T.，和J.Lang，“交通工程链路管理信息库”，RFC 4220，2005年11月<http://www.rfc-editor.org/info/rfc4220>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月<http://www.rfc-editor.org/info/rfc4364>.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.
[RFC4447]Martini，L.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月<http://www.rfc-editor.org/info/rfc4447>.
[RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, "Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement", RFC 4558, June 2006, <http://www.rfc-editor.org/info/rfc4558>.
[RFC4558]Ali，Z.，Rahman，R.，Prairie，D.，和D.Papadimitriou，“基于节点ID的资源预留协议（RSVP）你好：澄清声明”，RFC 4558，2006年6月<http://www.rfc-editor.org/info/rfc4558>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655]Farrel，A.，Vasseur，J.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月<http://www.rfc-editor.org/info/rfc4655>.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006, <http://www.rfc-editor.org/info/rfc4664>.
[RFC4664]Andersson，L.和E.Rosen，“第2层虚拟专用网络（L2VPN）框架”，RFC 4664，2006年9月<http://www.rfc-editor.org/info/rfc4664>.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007, <http://www.rfc-editor.org/info/rfc4761>.
[RFC4761]Kompella，K.和Y.Rekhter，“使用BGP进行自动发现和信令的虚拟专用LAN服务（VPLS）”，RFC 4761，2007年1月<http://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.
[RFC4762]Lasserre，M.和V.Kompella，“使用标签分发协议（LDP）信令的虚拟专用LAN服务（VPLS）”，RFC 4762，2007年1月<http://www.rfc-editor.org/info/rfc4762>.
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007, <http://www.rfc-editor.org/info/rfc4798>.
[RFC4798]De Clercq，J.，Ooms，D.，Prevost，S.，和F.Le Faucheur，“使用IPv6提供商边缘路由器（6PE）通过IPv4 MPLS连接IPv6孤岛”，RFC 4798，2007年2月<http://www.rfc-editor.org/info/rfc4798>.
[RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007, <http://www.rfc-editor.org/info/rfc4802>.
[RFC4802]Nadeau，T.和A.Farrel，“通用多协议标签交换（GMPLS）流量工程管理信息库”，RFC 48022007年2月<http://www.rfc-editor.org/info/rfc4802>.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007, <http://www.rfc-editor.org/info/rfc4875>.
[RFC4875]Aggarwal，R.，Papadimitriou，D.，和S.Yasukawa，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 4875，2007年5月<http://www.rfc-editor.org/info/rfc4875>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007, <http://www.rfc-editor.org/info/rfc4884>.
[RFC4884]Bonica，R.，Gan，D.，Tappan，D.，和C.Pignataro，“支持多部分消息的扩展ICMP”，RFC 4884，2007年4月<http://www.rfc-editor.org/info/rfc4884>.
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007, <http://www.rfc-editor.org/info/rfc4950>.
[RFC4950]Bonica，R.，Gan，D.，Tappan，D.，和C.Pignataro，“多协议标签交换的ICMP扩展”，RFC 49502007年8月<http://www.rfc-editor.org/info/rfc4950>.
[RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks", RFC 4990, September 2007, <http://www.rfc-editor.org/info/rfc4990>.
[RFC4990]Shiomoto，K.，Papneya，R.和R.Rabbat，“通用多协议标签交换（GMPLS）网络中地址的使用”，RFC 49902007年9月<http://www.rfc-editor.org/info/rfc4990>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.
[RFC5082]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，2007年10月<http://www.rfc-editor.org/info/rfc5082>.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5085]Nadeau，T.和C.Pignataro，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月<http://www.rfc-editor.org/info/rfc5085>.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008, <http://www.rfc-editor.org/info/rfc5088>.
[RFC5088]Le Roux，JL.，Vasseur，JP.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的OSPF协议扩展”，RFC 5088，2008年1月<http://www.rfc-editor.org/info/rfc5088>.
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008, <http://www.rfc-editor.org/info/rfc5089>.
[RFC5089]Le Roux，JL.，Vasseur，JP.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的IS-IS协议扩展”，RFC 5089，2008年1月<http://www.rfc-editor.org/info/rfc5089>.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008, <http://www.rfc-editor.org/info/rfc5286>.
[RFC5286]Atlas，A.和A.Zinin，“IP快速重路由的基本规范：无环路交替”，RFC 5286，2008年9月<http://www.rfc-editor.org/info/rfc5286>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 53052008年10月<http://www.rfc-editor.org/info/rfc5305>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008, <http://www.rfc-editor.org/info/rfc5329>.
[RFC5329]Ishiguro，K.，Manral，V.，Davey，A.，和A.Lindem，“OSPF版本3的流量工程扩展”，RFC 53292008年9月<http://www.rfc-editor.org/info/rfc5329>.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440]Vasseur，JP。和JL。Le Roux，“路径计算元件（PCE）通信协议（PCEP）”，RFC 54402009年3月<http://www.rfc-editor.org/info/rfc5440>.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009, <http://www.rfc-editor.org/info/rfc5512>.
[RFC5512]Mohapatra，P.和E.Rosen，“BGP封装后续地址族标识符（SAFI）和BGP隧道封装属性”，RFC 5512，2009年4月<http://www.rfc-editor.org/info/rfc5512>.
[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009, <http://www.rfc-editor.org/info/rfc5520>.
[RFC5520]Bradford，R.，Vasseur，JP.，和A.Farrel，“使用基于路径密钥的机制在域间路径计算中保持拓扑机密性”，RFC 5520，2009年4月<http://www.rfc-editor.org/info/rfc5520>.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, April 2009, <http://www.rfc-editor.org/info/rfc5521>.
[RFC5521]Oki，E.，Takeda，T.，和A.Farrel，“路由排除的路径计算元素通信协议（PCEP）扩展”，RFC 55212009年4月<http://www.rfc-editor.org/info/rfc5521>.
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-Balancing for Mesh Softwires", RFC 5640, August 2009, <http://www.rfc-editor.org/info/rfc5640>.
[RFC5640]Filsfils，C.，Mohapatra，P.，和C.Pignataro，“网状软电线的负载平衡”，RFC 56402009年8月<http://www.rfc-editor.org/info/rfc5640>.
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010, <http://www.rfc-editor.org/info/rfc5837>.
[RFC5837]Atlas，A.，Bonica，R.，Pignataro，C.，Shen，N.，和JR.Rivers，“为接口和下一跳识别扩展ICMP”，RFC 5837，2010年4月<http://www.rfc-editor.org/info/rfc5837>.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010, <http://www.rfc-editor.org/info/rfc5884>.
[RFC5884]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS标签交换路径（LSP）的双向转发检测（BFD）”，RFC 58842010年6月<http://www.rfc-editor.org/info/rfc5884>.
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010, <http://www.rfc-editor.org/info/rfc5885>.
[RFC5885]Nadeau，T.和C.Pignataro，“伪线虚拟电路连接验证（VCCV）的双向转发检测（BFD）”，RFC 58852010年6月<http://www.rfc-editor.org/info/rfc5885>.
[RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture", RFC 5886, June 2010, <http://www.rfc-editor.org/info/rfc5886>.
[RFC5886]Vasseur，JP.，Le Roux，JL.，和Y.Ikejiri，“基于路径计算元素（PCE）架构的一套监控工具”，RFC 58862010年6月<http://www.rfc-editor.org/info/rfc5886>.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010, <http://www.rfc-editor.org/info/rfc5921>.
[RFC5921]Bocci，M.，Bryant，S.，Frost，D.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月<http://www.rfc-editor.org/info/rfc5921>.
[RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, September 2010, <http://www.rfc-editor.org/info/rfc6006>.
[RFC6006]Zhao，Q.，King，D.，Verhaeghe，F.，Takeda，T.，Ali，Z.，和J.Meuria，“点对多点流量工程标签交换路径的路径计算元素通信协议（PCEP）扩展”，RFC 60062010年9月<http://www.rfc-editor.org/info/rfc6006>.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011, <http://www.rfc-editor.org/info/rfc6073>.
[RFC6073]Martini，L.，Metz，C.，Nadeau，T.，Bocci，M.和M.Aissaoui，“分段伪线”，RFC 60732011年1月<http://www.rfc-editor.org/info/rfc6073>.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, February 2011, <http://www.rfc-editor.org/info/rfc6119>.
[RFC6119]Harrison，J.，Berger，J.，和M.Bartlett，“IS-IS中的IPv6流量工程”，RFC 6119，2011年2月<http://www.rfc-editor.org/info/rfc6119>.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011, <http://www.rfc-editor.org/info/rfc6371>.
[RFC6371]Busi，I.和D.Allan，“基于MPLS的传输网络的运营、管理和维护框架”，RFC 63712011年9月<http://www.rfc-editor.org/info/rfc6371>.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.
[RFC6388]Wijnands，IJ.，Minei，I.，Kompella，K.，和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，2011年11月<http://www.rfc-editor.org/info/rfc6388>.
[RFC6445] Nadeau, T., Koushik, A., and R. Cetin, "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute", RFC 6445, November 2011, <http://www.rfc-editor.org/info/rfc6445>.
[RFC6445]Nadeau，T.，Koushik，A.，和R.Cetin，“用于快速重路由的多协议标签交换（MPLS）流量工程管理信息库”，RFC 64452011年11月<http://www.rfc-editor.org/info/rfc6445>.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513]Rosen，E.和R.Aggarwal，“MPLS/BGP IP VPN中的多播”，RFC 6513，2012年2月<http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012, <http://rfc-editor.org/info/rfc6514>.
[RFC6514]Aggarwal，R.，Rosen，E.，Morin，T.，和Y.Rekhter，“MPLS/BGP IP VPN中的BGP编码和多播过程”，RFC 6514，2012年2月<http://rfc-editor.org/info/rfc6514>.
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, April 2012, <http://www.rfc-editor.org/info/rfc6540>.
[RFC6540]George，W.，Donley，C.，Liljenstolpe，C.，和L.Howard，“所有具有IP能力的节点都需要IPv6支持”，BCP 177，RFC 65402012年4月<http://www.rfc-editor.org/info/rfc6540>.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, May 2012, <http://www.rfc-editor.org/info/rfc6624>.
[RFC6624]Kompella，K.，Kothari，B.，和R.Cherukuri，“使用BGP进行自动发现和信令的第2层虚拟专用网络”，RFC 66242012年5月<http://www.rfc-editor.org/info/rfc6624>.
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)", RFC 6720, August 2012, <http://www.rfc-editor.org/info/rfc6720>.
[RFC6720]Pignataro，C.和R.Asati，“标签分发协议（LDP）的通用TTL安全机制（GTSM）”，RFC 6720，2012年8月<http://www.rfc-editor.org/info/rfc6720>.
[RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6", RFC 6829, January 2013, <http://www.rfc-editor.org/info/rfc6829>.
[RFC6829]Chen，M.，Pan，P.，Pignataro，C.，和R.Asati，“IPv6上广告的伪线转发等价类（FEC）的标签交换路径（LSP）Ping”，RFC 68292013年1月<http://www.rfc-editor.org/info/rfc6829>.
[RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, February 2014, <http://www.rfc-editor.org/info/rfc7117>.
[RFC7117]Aggarwal，R.，Kamite，Y.，Fang，L.，Rekhter，Y.，和C.Kodeboniya，“虚拟专用局域网服务（VPLS）中的多播”，RFC 71172014年2月<http://www.rfc-editor.org/info/rfc7117>.
Acknowledgements
致谢
The authors wish to thank Alvaro Retana, Andrew Yourtchenko, Loa Andersson, David Allan, Mach Chen, Mustapha Aissaoui, and Mark Tinka for their detailed reviews, as well as Brian Haberman, Joel Jaeggli, Adrian Farrel, Nobo Akiya, Francis Dupont, and Tobias Gondrom for their comments.
作者希望感谢阿尔瓦罗·雷塔纳、安德鲁·尤琴科、洛亚·安德森、大卫·艾伦、马赫·陈、穆斯塔法·艾萨维和马克·廷卡的详细评论，以及布莱恩·哈伯曼、乔尔·贾格利、阿德里安·法雷尔、诺博·阿基亚、弗朗西斯·杜邦和托比亚斯·冈德罗姆的评论。
Contributors
贡献者
The following people have contributed text to this document:
以下人员为本文件提供了文本：
Rajiv Asati Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 United States
Rajiv Asati Cisco Systems 7025 Kit Creek Road Research Triangle Park，美国北卡罗来纳州27709
EMail: rajiva@cisco.com
EMail: rajiva@cisco.com
Kamran Raza Cisco Systems 2000 Innovation Drive Ottawa, ON K2K-3E8 Canada
加拿大渥太华K2K-3E8上的Kamran Raza Cisco Systems 2000创新大道
EMail: skraza@cisco.com
EMail: skraza@cisco.com
Ronald Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 United States
Ronald Bonica Juniper Networks美国弗吉尼亚州赫恩登市企业园大道2251号，邮编20171
EMail: rbonica@juniper.net
EMail: rbonica@juniper.net
Rajiv Papneja Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 United States
美国加利福尼亚州圣克拉拉市中心高速公路2330号，邮编95050
EMail: rajiv.papneja@huawei.com
EMail: rajiv.papneja@huawei.com
Dhruv Dhody Huawei Technologies Leela Palace Bangalore, Karnataka 560008 India
印度卡纳塔克邦班加罗尔杜鲁夫杜迪华为技术有限公司，邮编560008
EMail: dhruv.ietf@gmail.com
EMail: dhruv.ietf@gmail.com
Vishwas Manral Ionos Networks Sunnyvale, CA 94089 United States
Vishwas Manral Ionios网络美国加利福尼亚州桑尼维尔94089
EMail: vishwas@ionosnetworks.com
EMail: vishwas@ionosnetworks.com
Nagendra Kumar Cisco Systems, Inc. 7200 Kit Creek Road Research Triangle Park, NC 27709 United States
美国北卡罗来纳州Kit Creek Road研究三角公园7200号Nagendra Kumar Cisco Systems，Inc.美国北卡罗来纳州27709
EMail: naikumar@cisco.com
EMail: naikumar@cisco.com
Authors' Addresses
作者地址
Wesley George (editor) Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20111 United States
韦斯利·乔治（编辑）时代华纳有线电视13820美国弗吉尼亚州赫恩登日出谷大道20111
Phone: +1-703-561-2540
EMail: wesley.george@twcable.com
Phone: +1-703-561-2540
EMail: wesley.george@twcable.com
Carlos Pignataro (editor) Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States
卡洛斯·皮格纳塔罗（编辑）思科系统公司，美国北卡罗来纳州基特克里克路研究三角公园7200-12号，邮编：27709
Phone: +1-919-392-7428
EMail: cpignata@cisco.com
Phone: +1-919-392-7428
EMail: cpignata@cisco.com