Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 7552 C. Pignataro
Updates: 5036, 6720 K. Raza
Category: Standards Track Cisco
ISSN: 2070-1721 V. Manral
Ionos Networks
R. Papneja
Huawei
June 2015
Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 7552 C. Pignataro
Updates: 5036, 6720 K. Raza
Category: Standards Track Cisco
ISSN: 2070-1721 V. Manral
Ionos Networks
R. Papneja
Huawei
June 2015
Updates to LDP for IPv6
IPv6的LDP更新
Abstract
摘要
The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4 or IPv6 networks, or both. This document corrects and clarifies the LDP behavior when an IPv6 network is used (with or without IPv4). This document updates RFCs 5036 and 6720.
标签分发协议（LDP）规范定义了通过IPv4或IPv6网络或两者交换标签绑定的过程。本文档纠正并澄清了使用IPv6网络（带或不带IPv4）时LDP的行为。本文件更新了RFCs 5036和6720。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc7552.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7552.
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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Topology Scenarios for Dual-Stack Environment ..............5
1.2. Single-Hop vs. Multi-Hop LDP Peering .......................6
2. Specification Language ..........................................6
3. LSP Mapping .....................................................7
4. LDP Identifiers .................................................8
5. Neighbor Discovery ..............................................8
5.1. Basic Discovery Mechanism ..................................8
5.1.1. Maintaining Hello Adjacencies .......................9
5.2. Extended Discovery Mechanism ..............................10
6. LDP Session Establishment and Maintenance ......................10
6.1. Transport Connection Establishment ........................10
6.1.1. Dual-Stack: Transport Connection Preference
and Role of an LSR .................................12
6.2. LDP Session Maintenance ...................................14
7. Binding Distribution ...........................................15
7.1. Address Distribution ......................................15
7.2. Label Distribution ........................................16
8. LDP Identifiers and Duplicate Next-Hop Addresses ...............17
9. LDP TTL Security ...............................................18
10. IANA Considerations ...........................................18
11. Security Considerations .......................................19
12. References ....................................................19
12.1. Normative References .....................................19
12.2. Informative References ...................................20
Appendix A. Additional Considerations .............................21
A.1. LDPv6 and LDPv4 Interoperability Safety Net ................21
A.2. Accommodating Implementations Not Compliant with RFC 5036 ..21
A.3. Why prohibit IPv4-mapped IPv6 addresses in LDP? ............22
A.4. Why a 32-bit value even for the IPv6 LDP Router Id? ........22
Acknowledgments ...................................................23
Contributors ......................................................23
Authors' Addresses.................................................24
1. Introduction ....................................................4
1.1. Topology Scenarios for Dual-Stack Environment ..............5
1.2. Single-Hop vs. Multi-Hop LDP Peering .......................6
2. Specification Language ..........................................6
3. LSP Mapping .....................................................7
4. LDP Identifiers .................................................8
5. Neighbor Discovery ..............................................8
5.1. Basic Discovery Mechanism ..................................8
5.1.1. Maintaining Hello Adjacencies .......................9
5.2. Extended Discovery Mechanism ..............................10
6. LDP Session Establishment and Maintenance ......................10
6.1. Transport Connection Establishment ........................10
6.1.1. Dual-Stack: Transport Connection Preference
and Role of an LSR .................................12
6.2. LDP Session Maintenance ...................................14
7. Binding Distribution ...........................................15
7.1. Address Distribution ......................................15
7.2. Label Distribution ........................................16
8. LDP Identifiers and Duplicate Next-Hop Addresses ...............17
9. LDP TTL Security ...............................................18
10. IANA Considerations ...........................................18
11. Security Considerations .......................................19
12. References ....................................................19
12.1. Normative References .....................................19
12.2. Informative References ...................................20
Appendix A. Additional Considerations .............................21
A.1. LDPv6 and LDPv4 Interoperability Safety Net ................21
A.2. Accommodating Implementations Not Compliant with RFC 5036 ..21
A.3. Why prohibit IPv4-mapped IPv6 addresses in LDP? ............22
A.4. Why a 32-bit value even for the IPv6 LDP Router Id? ........22
Acknowledgments ...................................................23
Contributors ......................................................23
Authors' Addresses.................................................24
The LDP specification [RFC5036] defines procedures and messages for exchanging FEC-label bindings over either IPv4 or IPv6 networks, or both (i.e., Dual-stack networks).
LDP规范[RFC5036]定义了通过IPv4或IPv6网络或两者（即双栈网络）交换FEC标签绑定的过程和消息。
However, RFC 5036 has the following deficiencies (i.e., lacks details) in regard to IPv6 usage (with or without IPv4):
然而，RFC 5036在IPv6使用（有或没有IPv4）方面存在以下缺陷（即缺乏细节）：
1. Label Switched Path (LSP) Mapping: No rule for mapping a particular packet to a particular LSP that has an Address Prefix Forwarding Equivalence Class (FEC) element containing the IPv6 address of the egress router
1. 标签交换路径（LSP）映射：没有规则将特定数据包映射到具有包含出口路由器IPv6地址的地址前缀转发等价类（FEC）元素的特定LSP
2. LDP Identifier: No details specific to IPv6 usage
2. LDP标识符：没有特定于IPv6使用的详细信息
3. LDP Discovery: No details for using a particular IPv6 destination (multicast) address or the source address
3. LDP发现：没有使用特定IPv6目标（多播）地址或源地址的详细信息
4. LDP Session Establishment: No rule for handling both IPv4 and IPv6 Transport Address optional objects in a Hello message, and subsequently two IPv4 and IPv6 transport connections
4. LDP会话建立：没有规则处理Hello消息中的IPv4和IPv6传输地址可选对象，以及随后的两个IPv4和IPv6传输连接
5. LDP Address Distribution: No rule for advertising IPv4 and/or IPv6 address bindings over an LDP session
5. LDP地址分配：没有在LDP会话上公布IPv4和/或IPv6地址绑定的规则
6. LDP Label Distribution: No rule for advertising IPv4 and/or IPv6 FEC-label bindings over an LDP session, or for handling the coexistence of IPv4 and IPv6 FEC Elements in the same FEC TLV
6. LDP标签分发：在LDP会话上公布IPv4和/或IPv6 FEC标签绑定，或处理同一FEC TLV中IPv4和IPv6 FEC元素共存的规则
7. Next-Hop Address Resolution: No rule for accommodating the usage of duplicate link-local IPv6 addresses
7. 下一个跃点地址解析：没有允许使用重复链路本地IPv6地址的规则
8. LDP Time to Live (TTL) Security: No rule for a built-in Generalized TTL Security Mechanism (GTSM) in LDP with IPv6 (this is a deficiency in [RFC6720])
8. LDP生存时间（TTL）安全性：在使用IPv6的LDP中没有内置通用TTL安全机制（GTSM）的规则（这是[RFC6720]中的一个缺陷）
This document addresses the above deficiencies by specifying the desired behavior/rules/details for using LDP in IPv6-enabled networks (IPv6-only or Dual-stack networks). This document closes the IPv6 MPLS gap discussed in Sections 3.2.1, 3.2.2, and 3.3.1.1 of [RFC7439].
本文档通过指定在支持IPv6的网络（仅IPv6或双栈网络）中使用LDP所需的行为/规则/详细信息来解决上述缺陷。本文档弥补了[RFC7439]第3.2.1、3.2.2和3.3.1.1节中讨论的IPv6 MPLS差距。
Note that this document updates [RFC5036] and [RFC6720].
请注意，本文件更新了[RFC5036]和[RFC6720]。
Two Label Switching Routers (LSRs) may involve Basic and/or Extended LDP Discovery in IPv6 and/or IPv4 address families in various topology scenarios.
在各种拓扑方案中，两个标签交换路由器（LSR）可能涉及IPv6和/或IPv4地址族中的基本和/或扩展LDP发现。
This document addresses the following three topology scenarios in which the LSRs may be connected via one or more Dual-stack LDP-enabled interfaces (Figure 1), or one or more Single-stack LDP-enabled interfaces (Figures 2 and 3):
本文档介绍了以下三种拓扑方案，其中LSR可通过一个或多个双栈LDP启用接口（图1）或一个或多个单栈LDP启用接口（图2和图3）连接：
R1------------------R2
IPv4+IPv6
R1------------------R2
IPv4+IPv6
Figure 1: LSRs Connected via a Dual-Stack Interface
图1：通过双堆栈接口连接的LSR
IPv4
R1=================R2
IPv6
IPv4
R1=================R2
IPv6
Figure 2: LSRs Connected via Two Single-Stack Interfaces
图2：通过两个单堆栈接口连接的LSR
R1------------------R2---------------R3
IPv4 IPv6
R1------------------R2---------------R3
IPv4 IPv6
Figure 3: LSRs Connected via a Single-Stack Interface
图3：通过单堆栈接口连接的LSR
Note that the topology scenario illustrated in Figure 1 also covers the case of a Single-stack LDP-enabled interface (say, IPv4) being converted to a Dual-stack LDP-enabled interface (by enabling IPv6 routing as well as IPv6 LDP), even though the LDP-over-IPv4 (LDPoIPv4) session may already be established between the LSRs.
注意，图1中所示的拓扑场景还包括单栈LDP启用接口（例如IPv4）转换为双栈LDP启用接口（通过启用IPv6路由以及IPv6 LDP）的情况，即使可能已经在LSR之间建立了LDP-over-IPv4（LDPoIPv4）会话。
Note that the topology scenario illustrated in Figure 2 also covers the case of two routers getting connected via an additional Single-stack LDP-enabled interface (IPv6 routing and IPv6 LDP), even though the LDPoIPv4 session may already be established between the LSRs over the existing interface(s).
请注意，图2中所示的拓扑场景还包括两个路由器通过附加的单堆栈LDP启用接口（IPv6路由和IPv6 LDP）连接的情况，即使LDPoIPv4会话可能已经通过现有接口在LSR之间建立。
This document also addresses the scenario in which the LSRs do the Extended Discovery in IPv6 and/or IPv4 address families:
本文档还介绍了LSR在IPv6和/或IPv4地址系列中执行扩展查找的场景：
IPv4
R1-------------------R2
IPv6
IPv4
R1-------------------R2
IPv6
Figure 4: LSRs Involving IPv4 and IPv6 Address Families
图4：涉及IPv4和IPv6地址系列的LSR
The LDP TTL Security mechanism specified by this document applies only to single-hop LDP peering sessions, not to multi-hop LDP peering sessions, in line with Section 5.5 of [RFC5082]. [RFC5082] describes the Generalized TTL Security Mechanism (GTSM).
根据[RFC5082]第5.5节，本文件规定的LDP TTL安全机制仅适用于单跳LDP对等会话，不适用于多跳LDP对等会话。[RFC5082]描述了通用TTL安全机制（GTSM）。
As a consequence, any LDP feature that relies on a multi-hop LDP peering session would not work with GTSM and will warrant (statically or dynamically) disabling GTSM. Please see Section 9.
因此，任何依赖于多跳LDP对等会话的LDP功能都不会与GTSM一起工作，并且将保证（静态或动态）禁用GTSM。请参见第9节。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Abbreviations:
缩写：
LDP Label Distribution Protocol
LDP标签分发协议
LDPoIPv4 LDP-over-IPv4 transport connection
LDPoIPv4 LDP-over-IPv4传输连接
LDPoIPv6 LDP-over-IPv6 transport connection
LDPoIPv6 LDP-over-IPv6传输连接
FEC Forwarding Equivalence Class
转发等价类
TLV Type Length Value
TLV类型长度值
LSR Label Switching Router
标签交换路由器
LSP Label Switched Path
标签交换路径
LSPv4 IPv4-signaled Label Switched Path
LSPv4 IPv4信令标签交换路径
LSPv6 IPv6-signaled Label Switched Path
LSPv6 IPv6信号标签交换路径
AFI Address Family Identifier
地址族标识符
LDP Id LDP Identifier
LDP Id LDP标识符
Single-stack LDP LDP supporting just one address family (for discovery, session setup, address/label binding exchange, etc.)
单栈LDP LDP仅支持一个地址系列（用于发现、会话设置、地址/标签绑定交换等）
Dual-stack LDP LDP supporting two address families (for discovery, session setup, address/label binding exchange, etc.)
支持两个地址族的双栈LDP LDP（用于发现、会话设置、地址/标签绑定交换等）
Dual-stack LSR LSR supporting Dual-stack LDP for a peer
双栈LSR LSR支持对等的双栈LDP
Single-stack LSR LSR supporting Single-stack LDP for a peer
单栈LSR LSR支持对等方的单栈LDP
Note that an LSR can be a Dual-stack and Single-stack LSR at the same time for different peers. This document loosely uses the term "address family" to mean "IP address family".
请注意，对于不同的对等方，LSR可以同时是双堆栈和单堆栈LSR。本文档松散地使用术语“地址系列”来表示“IP地址系列”。
Section 2.1 of [RFC5036] specifies the procedure for mapping a particular packet to a particular LSP using three rules. Quoting the third rule from [RFC5036]:
[RFC5036]第2.1节规定了使用三条规则将特定数据包映射到特定LSP的程序。引用[RFC5036]中的第三条规则：
If it is known that a packet must traverse a particular egress router, and there is an LSP that has an Address Prefix FEC element that is a /32 address of that router, then the packet is mapped to that LSP.
如果已知分组必须穿过特定出口路由器，并且存在具有地址前缀FEC元素的LSP，该地址前缀FEC元素是该路由器的/32地址，则该分组被映射到该LSP。
This rule is correct for IPv4 (to set up LSPv4), but not for IPv6 (to set up LSPv6), since an IPv6 router may even have a /64 or /96 or /128 (or whatever prefix length) address. Hence, that rule is updated here to use IPv4 or IPv6 addresses instead of /32 or /128 addresses, as shown below:
此规则适用于IPv4（设置LSPv4），但不适用于IPv6（设置LSPv6），因为IPv6路由器甚至可能具有/64或/96或/128（或任何前缀长度）地址。因此，该规则在此处更新为使用IPv4或IPv6地址，而不是/32或/128地址，如下所示：
If it is known that a packet must traverse a particular egress router, and there is an LSP that has an Address Prefix FEC element that is an IPv4 or IPv6 address of that router, then the packet is mapped to that LSP.
如果已知数据包必须穿过特定出口路由器，并且存在具有地址前缀FEC元素的LSP，该地址前缀FEC元素是该路由器的IPv4或IPv6地址，则该数据包被映射到该LSP。
In line with Section 2.2.2 of [RFC5036], this document specifies the usage of a 32-bit (unsigned non-zero integer) LSR Id on an IPv6-enabled LSR (with or without Dual-stacking).
根据[RFC5036]第2.2.2节，本文件规定了在启用IPv6的LSR（有或没有双重堆叠）上使用32位（无符号非零整数）LSR Id。
This document also qualifies the first sentence of the last paragraph of Section 2.5.2 of [RFC5036] to be per address family.
本文件还将[RFC5036]第2.5.2节最后一段的第一句限定为每个地址系列。
From Section 2.5.2 of [RFC5036]:
根据[RFC5036]第2.5.2节：
An LSR MUST advertise the same transport address in all Hellos that advertise the same label space.
LSR必须在所有播发相同标签空间的hello中播发相同的传输地址。
Updated by this document, as follows:
本文件更新如下：
For a given address family, an LSR MUST advertise the same transport address in all Hellos that advertise the same label space.
对于给定的地址族，LSR必须在所有播发相同标签空间的HELO中播发相同的传输地址。
This rightly enables the per-platform label space to be shared between IPv4 and IPv6.
这正确地允许在IPv4和IPv6之间共享每个平台的标签空间。
In summary, this document mandates the usage of a common LDP Identifier (the same LSR Id and label space id) for both IPv4 and IPv6 address families.
总之，本文档要求IPv4和IPv6地址系列使用公共LDP标识符（相同的LSR Id和标签空间Id）。
If Dual-stack LDP is enabled (i.e., LDP enabled in both IPv6 and IPv4 address families) on an interface or for a targeted neighbor, then the LSR MUST transmit both IPv6 and IPv4 LDP (Link or targeted) Hellos and include the same LDP Identifier (assuming per-platform label space usage) in them.
如果在接口或目标邻居上启用了双栈LDP（即，在IPv6和IPv4地址系列中都启用了LDP），则LSR必须传输IPv6和IPv4 LDP（链路或目标）hello，并在其中包含相同的LDP标识符（假设每个平台的标签空间使用情况）。
If Single-stack LDP is enabled (i.e., LDP enabled in either an IPv6 or IPv4 address family), then the LSR MUST transmit either IPv6 or IPv4 LDP (Link or targeted) Hellos, respectively.
如果启用了单堆栈LDP（即，在IPv6或IPv4地址系列中启用LDP），则LSR必须分别传输IPv6或IPv4 LDP（链路或目标）Hellos。
Section 2.4.1 of [RFC5036] defines the Basic Discovery mechanism for directly connected LSRs. Following this mechanism, LSRs periodically send LDP Link Hellos destined to the "all routers on this subnet" group multicast IP address.
[RFC5036]第2.4.1节定义了直接连接的LSR的基本发现机制。按照这种机制，LSR定期向“此子网上的所有路由器”组多播IP地址发送LDP链路HELOS。
Interestingly enough, per the IPv6 addressing architecture [RFC4291], IPv6 has three "all routers on this subnet" multicast addresses:
有趣的是，根据IPv6寻址体系结构[RFC4291]，IPv6有三个“此子网上的所有路由器”多播地址：
ff01:0:0:0:0:0:0:2 = Interface-local scope
ff01:0:0:0:0:0:0:2 = Interface-local scope
ff02:0:0:0:0:0:0:2 = Link-local scope
ff02:0:0:0:0:0:0:2 = Link-local scope
ff05:0:0:0:0:0:0:2 = Site-local scope
ff05:0:0:0:0:0:0:2 = Site-local scope
[RFC5036] does not specify which particular IPv6 "all routers on this subnet" group multicast IP address should be used by LDP Link Hellos.
[RFC5036]未指定LDP链路Hellos应使用哪个特定的IPv6“此子网上的所有路由器”组多播IP地址。
This document specifies the usage of link-local scope (i.e., ff02:0:0:0:0:0:0:2) as the destination multicast IP address in IPv6 LDP Link Hellos. An LDP Link Hello packet received on any of the other destination addresses MUST be dropped. Additionally, the link-local IPv6 address MUST be used as the source IP address in IPv6 LDP Link Hellos.
本文档指定了在IPv6 LDP链路Hellos中使用链路本地作用域（即ff02:0:0:0:0:0:2）作为目标多播IP地址。必须丢弃在任何其他目的地址上接收的LDP链路Hello数据包。此外，链路本地IPv6地址必须用作IPv6 LDP链路Hellos中的源IP地址。
Also, the LDP Link Hello packets MUST have their IPv6 Hop Limit set to 255, be checked for the same upon receipt (before any LDP-specific processing), and be handled as specified in Section 3 of [RFC5082]. The built-in inclusion of GTSM automatically protects IPv6 LDP from off-link attacks.
此外，LDP链路Hello数据包必须将其IPv6跃点限制设置为255，在收到时（在任何LDP特定处理之前）进行检查，并按照[RFC5082]第3节的规定进行处理。内置的GTSM可自动保护IPv6 LDP免受脱离链路攻击。
More importantly, if an interface is a Dual-stack LDP interface (i.e., LDP enabled in both IPv6 and IPv4 address families), then the LSR MUST periodically transmit both IPv6 and IPv4 LDP Link Hellos (using the same LDP Identifier per Section 4) on that interface and be able to receive them. This facilitates discovery of IPv6-only, IPv4-only, and Dual-stack peers on the interface's subnet and ensures successful subsequent peering using the appropriate (address family) transport on a multi-access or broadcast interface.
更重要的是，如果接口是双栈LDP接口（即，在IPv6和IPv4地址系列中启用LDP），则LSR必须在该接口上定期传输IPv6和IPv4 LDP链路hello（根据第4节使用相同的LDP标识符），并能够接收它们。这有助于在接口子网上发现仅IPv6、仅IPv4和双堆栈对等点，并确保在多访问或广播接口上使用适当的（地址系列）传输成功进行后续对等。
In the case of a Dual-stack LDP-enabled interface, the LSR SHOULD maintain Link Hello adjacencies for both IPv4 and IPv6 address families. This document, however, allows an LSR to maintain Receive-side Link Hello adjacencies only for the address family that has been used for the establishment of the LDP session (whether an LDPoIPv4 or LDPoIPv6 session).
对于启用双堆栈LDP的接口，LSR应为IPv4和IPv6地址族保持链路Hello邻接。然而，本文档允许LSR仅为用于建立LDP会话（无论是LDPoIPv4会话还是LDPoIPv6会话）的地址族维护接收侧链路Hello邻接。
The Extended Discovery mechanism (defined in Section 2.4.2 of [RFC5036]), in which the targeted LDP Hellos are sent to a unicast IPv6 address destination, requires only one IPv6-specific consideration: the link-local IPv6 addresses MUST NOT be used as the targeted LDP Hello packet's source or destination addresses.
扩展发现机制（定义见[RFC5036]第2.4.2节）将目标LDP Hello发送到单播IPv6地址目的地，只需考虑一个特定于IPv6的因素：链路本地IPv6地址不得用作目标LDP Hello数据包的源地址或目的地地址。
Section 2.5.1 of [RFC5036] defines a two-step process for LDP session establishment, once the neighbor discovery has completed (i.e., LDP Hellos have been exchanged):
[RFC5036]第2.5.1节定义了LDP会话建立的两步过程，一旦邻居发现完成（即交换LDP Hello）：
1. Transport connection establishment
1. 建立运输连接
2. Session initialization
2. 会话初始化
Section 6.1 discusses the LDP considerations for IPv6 and/or Dual-stacking in the context of session establishment, whereas Section 6.2 discusses the LDP considerations for IPv6 and/or Dual-stacking in the context of session maintenance.
第6.1节讨论了会话建立环境下IPv6和/或双堆叠的LDP注意事项，而第6.2节讨论了会话维护环境下IPv6和/或双堆叠的LDP注意事项。
Section 2.5.2 of [RFC5036] specifies the use of a Transport Address optional object (TLV) in LDP Hello messages to convey the transport (IP) address; however, it does not specify the behavior of LDP if both IPv4 and IPv6 Transport Address objects (TLVs) are sent in a Hello message or separate Hello messages. More importantly, it does not specify whether both IPv4 and IPv6 transport connections should be allowed if both IPv4 and IPv6 Hello adjacencies were present prior to session establishment.
[RFC5036]第2.5.2节规定了在LDP Hello消息中使用传输地址可选对象（TLV）来传输传输（IP）地址；但是，如果IPv4和IPv6传输地址对象（TLV）都在Hello消息或单独的Hello消息中发送，则它不会指定LDP的行为。更重要的是，它没有指定如果在会话建立之前存在IPv4和IPv6 Hello邻接，是否应同时允许IPv4和IPv6传输连接。
This document specifies the following:
本文件规定了以下内容：
1. An LSR MUST NOT send a Hello message containing both IPv4 and IPv6 Transport Address optional objects. In other words, there MUST be at most one Transport Address optional object in a Hello message. An LSR MUST include only the transport address whose address family is the same as that of the IP packet carrying the Hello message.
1. LSR不得发送同时包含IPv4和IPv6传输地址可选对象的Hello消息。换句话说，Hello消息中最多必须有一个传输地址可选对象。LSR必须只包括其地址系列与承载Hello消息的IP数据包的地址系列相同的传输地址。
2. An LSR SHOULD accept the Hello message that contains both IPv4 and IPv6 Transport Address optional objects but MUST use only the transport address whose address family is the same as that of the IP packet carrying the Hello message. An LSR SHOULD accept only the first Transport Address optional object for a given address
2. LSR应接受包含IPv4和IPv6传输地址可选对象的Hello消息，但必须仅使用其地址系列与承载Hello消息的IP数据包的地址系列相同的传输地址。LSR应该只接受给定地址的第一个传输地址可选对象
family in the received Hello message and ignore the rest if the LSR receives more than one Transport Address optional object for a given address family.
如果LSR接收到给定地址族的多个传输地址可选对象，则忽略其余的。
3. An LSR MUST send separate Hello messages (each containing either an IPv4 or IPv6 Transport Address optional object) for each IP address family if Dual-stack LDP is enabled (for an interface or neighbor).
3. 如果启用了双堆栈LDP（对于接口或邻居），则LSR必须为每个IP地址系列发送单独的Hello消息（每个消息包含IPv4或IPv6传输地址可选对象）。
4. An LSR MUST use a global unicast IPv6 address in an IPv6 Transport Address optional object of outgoing targeted Hellos and check for the same in incoming targeted Hellos (i.e., MUST discard the targeted Hello if it failed the check).
4. LSR必须在传出目标Hello的IPv6传输地址可选对象中使用全局单播IPv6地址，并在传入目标Hello中检查相同的地址（即，如果检查失败，则必须放弃目标Hello）。
5. An LSR MUST prefer using a global unicast IPv6 address in an IPv6 Transport Address optional object of outgoing Link Hellos if it had to choose between a global unicast IPv6 address and a unique-local or link-local IPv6 address.
5. 如果必须在全局单播IPv6地址和唯一的本地或链路本地IPv6地址之间进行选择，则LSR必须首选在传出链路Hellos的IPv6传输地址可选对象中使用全局单播IPv6地址。
6. A Single-stack LSR MUST establish either an LDPoIPv4 or LDPoIPv6 session with a remote LSR as per the enabled address family.
6. 单堆栈LSR必须根据启用的地址系列与远程LSR建立LDPoIPv4或LDPoIPv6会话。
7. A Dual-stack LSR MUST NOT initiate or accept the request for a TCP connection for a new LDP session with a remote LSR if it already has an LDPoIPv4 or LDPoIPv6 session for the same LDP Identifier established with that remote LSR.
7. 如果双栈LSR已经为与远程LSR建立的相同LDP标识符建立了LDPoIPv4或LDPoIPv6会话，则双栈LSR不得为与远程LSR的新LDP会话启动或接受TCP连接请求。
This means that only one transport connection is established, regardless of IPv6 and/or IPv4 Hello adjacencies present between two LSRs.
这意味着无论两个LSR之间存在IPv6和/或IPv4 Hello邻接，都只建立一个传输连接。
8. A Dual-stack LSR SHOULD prefer establishing an LDPoIPv6 session (instead of an LDPoIPv4 session) with a remote Dual-stack LSR by following the 'transport connection role' determination logic in Section 6.1.1.
8. 双栈LSR应更倾向于通过遵循第6.1.1节中的“传输连接角色”确定逻辑，与远程双栈LSR建立LDPoIPv6会话（而不是LDPoIPv4会话）。
Additionally, to ensure the above preference in the case where Dual-stack LDP is enabled on an interface, it would be desirable that IPv6 LDP Link Hellos are transmitted before IPv4 LDP Link Hellos, particularly when an interface is coming into service or being reconfigured.
此外，为了确保在接口上启用双栈LDP的情况下的上述偏好，期望在IPv4 LDP链路hello之前传输IPv6 LDP链路hello，特别是在接口投入服务或被重新配置时。
Section 2.5.2 of [RFC5036] specifies the rules for determining active/passive roles in setting up a TCP connection. These rules are clear for Single-stack LDP but not for Dual-stack LDP, in which an LSR may assume different roles for different address families, causing the LDP session to not get established.
[RFC5036]第2.5.2节规定了在建立TCP连接时确定主动/被动角色的规则。这些规则对于单栈LDP是明确的，但对于双栈LDP则不明确，在双栈LDP中，LSR可能为不同的地址族承担不同的角色，从而导致LDP会话无法建立。
To ensure a deterministic transport connection (active/passive) role in the case of Dual-stack LDP, this document specifies that the Dual-stack LSR conveys its transport connection preference in every LDP Hello message. This preference is encoded in a new TLV, named the "Dual-Stack capability" TLV, as defined below:
为确保在双栈LDP的情况下具有确定性传输连接（主动/被动）作用，本文件规定双栈LSR在每个LDP Hello消息中传达其传输连接首选项。此首选项编码在新的TLV中，名为“双堆栈能力”TLV，定义如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Dual-Stack capability | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TR | Reserved | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Dual-Stack capability | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TR | Reserved | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Dual-Stack Capability TLV
图5：双堆栈能力TLV
Where:
哪里：
U and F bits: 1 and 0 (as specified by [RFC5036])
U和F位：1和0（按照[RFC5036]的规定）
Dual-Stack capability: TLV code point (Ox0701)
双堆栈能力：TLV代码点（Ox0701）
TR: Transport Connection Preference
TR：传输连接首选项
This document defines the following two values:
本文件定义了以下两个值：
0100: LDPoIPv4 connection
0100:LDPoIPv4连接
0110: LDPoIPv6 connection (default)
0110:LDPoIPv6连接（默认）
Reserved This field is reserved. It MUST be set to zero on transmission and ignored on receipt.
保留此字段为保留字段。必须在传输时将其设置为零，在接收时将其忽略。
A Dual-stack LSR (i.e., an LSR supporting Dual-stack LDP for a peer) MUST include the Dual-Stack capability TLV in all of its LDP Hellos and MUST set the "TR" field to announce its preference for either an LDPoIPv4 or LDPoIPv6 transport connection for that peer. The default preference is LDPoIPv6.
双栈LSR（即，支持对等方双栈LDP的LSR）必须在其所有LDP HELLO中包括双栈能力TLV，并且必须设置“TR”字段以宣布其对该对等方的LDPoIPv4或LDPoIPv6传输连接的偏好。默认首选项是LDPoIPv6。
A Dual-stack LSR MUST always check for the presence of the Dual-Stack capability TLV in the received Hello messages and take appropriate action, as follows:
双堆栈LSR必须始终检查接收到的Hello消息中是否存在双堆栈功能TLV，并采取适当的措施，如下所示：
1. If the Dual-Stack capability TLV is present and the remote preference does not match the local preference (or does not get recognized), then the LSR MUST discard the Hello message and log an error.
1. 如果存在双堆栈功能TLV，且远程首选项与本地首选项不匹配（或无法识别），则LSR必须丢弃Hello消息并记录错误。
If an LDP session was already in place, then the LSR MUST send a fatal Notification message with status code of 'Transport Connection Mismatch' (0x00000032) and reset the session.
如果LDP会话已就位，则LSR必须发送状态代码为“传输连接不匹配”（0x00000032）的致命通知消息，并重置会话。
2. If the Dual-Stack capability TLV is present and the remote preference matches the local preference, then:
2. 如果存在双堆栈功能TLV，且远程首选项与本地首选项匹配，则：
a) If TR=0100 (LDPoIPv4), then determine the active/passive roles for the TCP connection using an IPv4 transport address as defined in Section 2.5.2 of RFC 5036.
a) 如果TR=0100（LDPoIPv4），则使用RFC 5036第2.5.2节中定义的IPv4传输地址确定TCP连接的主动/被动角色。
b) If TR=0110 (LDPoIPv6), then determine the active/passive roles for the TCP connection by using an IPv6 transport address as defined in Section 2.5.2 of RFC 5036.
b) 如果TR=0110（LDPoIPv6），则使用RFC 5036第2.5.2节中定义的IPv6传输地址确定TCP连接的主动/被动角色。
3. If the Dual-Stack capability TLV is NOT present and
3. 如果双堆栈功能TLV不存在，并且
a) only IPv4 Hellos are received, then the neighbor is deemed as a legacy IPv4-only LSR (supporting Single-stack LDP); hence, an LDPoIPv4 session SHOULD be established (similar to that of 2a above).
a) 仅接收IPv4 Hello，则邻居被视为仅IPv4的遗留LSR（支持单堆栈LDP）；因此，应建立LDPoIPv4会话（类似于上文2a的会话）。
However, if IPv6 Hellos are also received at any time during the life of the session from that neighbor, then the neighbor is deemed as a noncompliant Dual-stack LSR (similar to that of 3c below), resulting in any established LDPoIPv4 session being reset and a fatal Notification message being sent (with status code of 'Dual-Stack Noncompliance', 0x00000033).
但是，如果在会话生命周期内的任何时候也从该邻居接收到IPv6 Hello，则该邻居将被视为不符合双堆栈LSR（类似于下面3c的情况），从而导致重置任何已建立的LDPoIPv4会话并发送致命通知消息（状态代码为“双堆栈不符合”，0x00000033）。
b) only IPv6 Hellos are received, then the neighbor is deemed as an IPv6-only LSR (supporting Single-stack LDP) and an LDPoIPv6 session SHOULD be established (similar to that of 2b above).
b) 仅接收IPv6 Hello，则邻居被视为仅IPv6的LSR（支持单堆栈LDP），应建立LDPoIPv6会话（类似于上面2b的会话）。
However, if IPv4 Hellos are also received at any time during the life of the session from that neighbor, then the neighbor is deemed as a noncompliant Dual-stack LSR (similar to that of 3c below), resulting in any established LDPoIPv6 session being reset and a fatal Notification message being sent (with status code of 'Dual-Stack Noncompliance', 0x00000033).
但是，如果在会话生命周期内的任何时候也从该邻居接收到IPv4 Hello，则该邻居将被视为不符合双堆栈LSR（类似于下面3c的情况），从而导致重置任何已建立的LDPoIPv6会话并发送致命通知消息（状态代码为“双堆栈不符合”，0x00000033）。
c) both IPv4 and IPv6 Hellos are received, then the neighbor is deemed as a noncompliant Dual-stack neighbor and is not allowed to have any LDP session. A Notification message should be sent (with status code of 'Dual-Stack Noncompliance', 0x00000033).
c) 接收到IPv4和IPv6 Hello，则该邻居被视为不符合双堆栈的邻居，不允许有任何LDP会话。应发送通知消息（状态代码为“双堆栈不符合”，0x00000033）。
A Dual-stack LSR MUST convey the same transport connection preference ("TR" field value) in all (link and targeted) Hellos that advertise the same label space to the same peer and/or on the same interface. This ensures that two LSRs linked by multiple Hello adjacencies using the same label spaces play the same connection establishment role for each adjacency.
双栈LSR必须在所有（链接和目标）hello中传递相同的传输连接首选项（“TR”字段值），这些hello将相同的标签空间播发给相同的对等方和/或在相同的接口上。这确保了使用相同标签空间由多个Hello邻接链接的两个lsr对每个邻接起相同的连接建立作用。
A Dual-stack LSR MUST follow Section 2.5.5 of [RFC5036] and check for matching Hello messages from the peer (either all Hellos also include the Dual-Stack capability (with the same TR value) or none do).
双栈LSR必须遵循[RFC5036]的第2.5.5节，并检查来自对等方的匹配Hello消息（所有Hello也包括双栈功能（具有相同的TR值）或无）。
A Single-stack LSR does not need to use the Dual-Stack capability in Hello messages and SHOULD ignore this capability if received.
单堆栈LSR不需要在Hello消息中使用双堆栈功能，如果收到，则应忽略此功能。
An implementation may provide an option to favor one AFI (say, IPv4) over another AFI (say, IPv6) for the TCP transport connection, so as to use the favored IP version for the LDP session and force deterministic active/passive roles.
一种实现可以提供一种选择，以使一个AFI（例如，IPv4）优于另一个AFI（例如，IPv6）用于TCP传输连接，从而将优选的IP版本用于LDP会话并强制确定的主动/被动角色。
Note: An alternative to this new capability TLV could be a new Flag value in an LDP Hello message; however, it would be used even in Single-stack IPv6 LDP networks and linger on forever, even though Dual-stack will not. Hence, the idea of this alternative has been discarded.
注：此新功能TLV的替代方案可以是LDP Hello消息中的新标志值；然而，即使在单栈IPv6-LDP网络中，它也会被使用，并且会永远存在，即使双栈不会。因此，这一替代方案的想法已被抛弃。
This document specifies that two LSRs maintain a single LDP session, regardless of the number of Link or targeted Hello adjacencies between them, as described in Section 6.1. This is independent of whether:
本文件规定，如第6.1节所述，两个LSR维持一个LDP会话，而不管它们之间的链路或目标Hello邻接的数量如何。这与是否：
- they are connected via a Dual-stack LDP-enabled interface(s) or via two (or more) Single-stack LDP-enabled interfaces;
- 它们通过双栈LDP启用接口或通过两个（或更多）单栈LDP启用接口连接；
- a Single-stack LDP-enabled interface is converted to a Dual-stack LDP-enabled interface (see Figure 1) on either LSR;
- 在任一LSR上，单栈LDP启用接口转换为双栈LDP启用接口（见图1）；
- an additional Single-stack or Dual-stack LDP-enabled interface is added or removed between two LSRs (see Figure 2).
- 在两个LSR之间添加或删除额外的单堆栈或双堆栈LDP启用接口（见图2）。
If the last Hello adjacency for a given address family goes down (e.g., due to Dual-stack LDP-enabled interfaces being converted into Single-stack LDP-enabled interfaces on one LSR) and that address family is the same as the one used in the transport connection, then the transport connection (LDP session) MUST be reset. Otherwise, the LDP session MUST stay intact.
如果给定地址族的最后一个Hello邻接下降（例如，由于一个LSR上的双栈LDP启用接口转换为单栈LDP启用接口），并且该地址族与传输连接中使用的地址族相同，则必须重置传输连接（LDP会话）。否则，自民党会议必须完好无损。
If the LDP session is torn down for whatever reason (LDP disabled for the corresponding transport, Hello adjacency expiry, preference mismatch, etc.), then the LSRs SHOULD initiate the establishment of a new LDP session as per the procedures described in Section 6.1 of this document.
如果LDP会话因任何原因被中断（LDP因相应的传输被禁用、Hello邻接到期、偏好不匹配等），则LSR应按照本文件第6.1节所述的程序启动新LDP会话的建立。
LSRs by definition can be enabled for Dual-stack LDP globally and/or per peer so as to exchange the address and label bindings for both IPv4 and IPv6 address families, independent of any LDPoIPv4 or LDPoIPv6 session between them.
根据定义，LSR可以全局和/或每个对等点启用双堆栈LDP，以便为IPv4和IPv6地址族交换地址和标签绑定，而不依赖于它们之间的任何LDPoIPv4或LDPoIPv6会话。
However, there might be some legacy LSRs that are fully compliant with RFC 5036 for IPv4 but are noncompliant for IPv6 (for example, see Section 3.5.5.1 of RFC 5036), causing them to reset the session upon receiving IPv6 address bindings or IPv6 FEC (Prefix) label bindings from a peer compliant with this document. This is somewhat undesirable, as clarified further in Appendices A.1 and A.2.
但是，可能有一些旧LSR完全符合IPv4的RFC 5036，但不符合IPv6（例如，请参阅RFC 5036的第3.5.5.1节），导致它们在从符合本文档的对等方接收IPv6地址绑定或IPv6 FEC（前缀）标签绑定时重设会话。正如附录A.1和A.2中进一步阐明的，这有点不可取。
To help maintain backward compatibility (i.e., accommodate IPv4-only LDP implementations that may not be compliant with RFC 5036, Section 3.5.5.1), this specification requires that an LSR MUST NOT send any IPv6 bindings to a peer if the peer has been determined to be a legacy LSR.
为了帮助保持向后兼容性（即，适应可能不符合RFC 5036第3.5.5.1节的仅IPv4 LDP实现），本规范要求，如果对等方被确定为遗留LSR，则LSR不得向该对等方发送任何IPv6绑定。
The Dual-Stack capability TLV, which is defined in Section 6.1.1, is also used to determine whether or not a peer is a legacy (IPv4-only Single-stack) LSR.
第6.1.1节中定义的双栈功能TLV还用于确定对等方是否为遗留（仅IPv4单栈）LSR。
An LSR MUST NOT advertise (via an Address message) any IPv4-mapped IPv6 addresses (as defined in Section 2.5.5.2 of [RFC4291]) and MUST ignore such addresses if ever received. Please see Appendix A.3.
LSR不得（通过地址消息）公布任何IPv4映射的IPv6地址（如[RFC4291]第2.5.5.2节中的定义），并且必须在收到此类地址时忽略这些地址。请参见附录A.3。
If an LSR is enabled with Single-stack LDP for any peer, then it MUST advertise (via an Address message) its local IP addresses as per the enabled address family to that peer and process received Address messages containing IP addresses as per the enabled address family from that peer.
如果LSR为任何对等方启用了单堆栈LDP，则它必须（通过地址消息）根据启用的地址族向该对等方公布其本地IP地址，并根据该对等方的启用地址族处理包含IP地址的接收地址消息。
If an LSR is enabled with Dual-stack LDP for a peer and
如果LSR为对等方启用了双堆栈LDP，则
1. does not find the Dual-Stack capability TLV in the incoming IPv4 LDP Hello messages from that peer, then the LSR MUST NOT advertise its local IPv6 addresses to the peer.
1. 在来自该对等方的传入IPv4 LDP Hello消息中未找到双堆栈功能TLV，则LSR不得向该对等方公布其本地IPv6地址。
2. finds the Dual-Stack capability TLV in the incoming IPv4 (or IPv6) LDP Hello messages from that peer, then it MUST advertise (via an Address message) its local IPv4 and IPv6 addresses to that peer.
2. 在来自该对等方的传入IPv4（或IPv6）LDP Hello消息中查找双堆栈功能TLV，然后它必须（通过地址消息）向该对等方公布其本地IPv4和IPv6地址。
3. does not find the Dual-Stack capability TLV in the incoming IPv6 LDP Hello messages, then it MUST advertise (via an Address message) only its local IPv6 addresses to that peer.
3. 在传入的IPv6 LDP Hello消息中找不到双堆栈功能TLV，则它必须（通过地址消息）仅向该对等方播发其本地IPv6地址。
This last point helps to maintain forward compatibility (no need to require this TLV in the case of IPv6 Single-stack LDP).
最后一点有助于保持前向兼容性（在IPv6单堆栈LDP的情况下，不需要此TLV）。
An LSR MUST NOT allocate and MUST NOT advertise FEC-label bindings for link-local or IPv4-mapped IPv6 addresses (defined in Section 2.5.5.2 of [RFC4291]), and it MUST ignore such bindings if ever received. Please see Appendix A.3.
LSR不得为链路本地或IPv4映射的IPv6地址（定义见[RFC4291]第2.5.5.2节）分配FEC标签绑定，也不得公布FEC标签绑定，并且如果收到此类绑定，LSR必须忽略。请参见附录A.3。
If an LSR is enabled with Single-stack LDP for any peer, then it MUST advertise (via a Label Mapping message) FEC-label bindings for the enabled address family to that peer and process received FEC-label bindings for the enabled address family from that peer.
如果LSR为任何对等方启用了单堆栈LDP，则它必须（通过标签映射消息）向该对等方播发已启用地址系列的FEC标签绑定，并处理从该对等方接收到的已启用地址系列的FEC标签绑定。
If an LSR is enabled with Dual-stack LDP for a peer and
如果LSR为对等方启用了双堆栈LDP，则
1. does not find the Dual-Stack capability TLV in the incoming IPv4 LDP Hello messages from that peer, then the LSR MUST NOT advertise IPv6 FEC-label bindings to the peer (even if IP capability negotiation for the IPv6 address family was done).
1. 在来自该对等方的传入IPv4 LDP Hello消息中未找到双堆栈功能TLV，则LSR不得向该对等方播发IPv6 FEC标签绑定（即使已完成IPv6地址系列的IP功能协商）。
2. finds the Dual-Stack capability TLV in the incoming IPv4 (or IPv6) LDP Hello messages from that peer, then it MUST advertise FEC-label bindings for both IPv4 and IPv6 address families to that peer.
2. 在来自该对等方的传入IPv4（或IPv6）LDP Hello消息中查找双堆栈功能TLV，然后它必须向该对等方播发IPv4和IPv6地址族的FEC标签绑定。
3. does not find the Dual-Stack capability TLV in the incoming IPv6 LDP Hello messages, then it MUST advertise FEC-label bindings for IPv6 address families to that peer.
3. 在传入的IPv6 LDP Hello消息中找不到双堆栈功能TLV，则必须向该对等方公布IPv6地址族的FEC标签绑定。
This last point helps to maintain forward compatibility (no need to require this TLV for IPv6 Single-stack LDP).
最后一点有助于保持前向兼容性（IPv6单堆栈LDP不需要此TLV）。
An LSR MAY further constrain the advertisement of FEC-label bindings for a particular address family by negotiating the IP capability for a given address family, as specified in [RFC7473]. This allows an LSR pair to neither advertise nor receive the undesired FEC-label bindings on a per-address-family basis to a peer.
如[RFC7473]中所述，LSR可通过协商给定地址族的IP能力来进一步限制特定地址族的FEC标签绑定的公布。这允许LSR对既不播发也不接收针对对等方的每个地址族的不需要的FEC标签绑定。
If an LSR is configured to change an interface or peer from Single-stack LDP to Dual-stack LDP, then an LSR SHOULD use Typed Wildcard FEC procedures [RFC5918] to request the label bindings for the enabled address family. This helps to relearn the label bindings that may have been discarded before, without resetting the session.
如果LSR配置为将接口或对等方从单堆栈LDP更改为双堆栈LDP，则LSR应使用类型化通配符FEC过程[RFC5918]来请求启用地址族的标签绑定。这有助于重新学习以前可能已丢弃的标签绑定，而无需重置会话。
RFC 5036, Section 2.7 specifies the logic for mapping the IP routing next hop (of a given FEC) to an LDP peer so as to find the correct label entry for that FEC. The logic involves using the IP routing next-hop address as an index into the (peer address) database (which is populated by the Address message containing a mapping between each peer's local addresses and its LDP Identifier) to determine the LDP peer.
RFC 5036第2.7节规定了将（给定FEC的）IP路由下一跳映射到LDP对等方的逻辑，以便为该FEC找到正确的标签条目。该逻辑涉及使用IP路由下一跳地址作为（对等地址）数据库的索引（由包含每个对等方的本地地址与其LDP标识符之间的映射的地址消息填充），以确定LDP对等方。
However, this logic is insufficient to deal with duplicate IPv6 (link-local) next-hop addresses used by two or more peers. The reason is that all interior IPv6 routing protocols (can) use link-local IPv6 addresses as the IP routing next hops, and "IP Version 6 Addressing Architecture" [RFC4291] allows a link-local IPv6 address to be used on more than one link.
但是，此逻辑不足以处理两个或多个对等方使用的重复IPv6（链路本地）下一跳地址。原因是所有内部IPv6路由协议（can）都将链路本地IPv6地址用作IP路由下一跳，并且“IP版本6寻址体系结构”[RFC4291]允许在多个链路上使用链路本地IPv6地址。
Hence, this logic is extended by this specification to use not only the IP routing next-hop address but also the IP routing next-hop interface to uniquely determine the LDP peer(s). The next-hop address-based LDP peer mapping is to be done through the LDP peer address database (populated by Address messages received from the LDP peers), whereas next-hop interface-based LDP peer mapping is to be done through the LDP Hello adjacency/interface database (populated by Hello messages received from the LDP peers).
因此，该规范扩展了该逻辑，不仅使用IP路由下一跳地址，而且还使用IP路由下一跳接口来唯一地确定LDP对等方。基于下一跳地址的LDP对等映射将通过LDP对等地址数据库完成（由从LDP对等接收的地址消息填充），而基于下一跳接口的LDP对等映射将通过LDP Hello邻接/接口数据库完成（由从LDP对等接收的Hello消息填充）。
This extension solves the problem of two or more peers using the same link-local IPv6 address (in other words, duplicate peer addresses) as the IP routing next hops.
此扩展解决了两个或多个对等点使用与IP路由下一跳相同的链路本地IPv6地址（换句话说，重复的对等点地址）的问题。
Lastly, for better scale and optimization, an LSR may advertise only the link-local IPv6 addresses in the Address message, assuming that the peer uses only the link-local IPv6 addresses as static and/or dynamic IP routing next hops.
最后，为了更好地扩展和优化，LSR可以在地址消息中仅公布链路本地IPv6地址，假设对等方仅使用链路本地IPv6地址作为静态和/或动态IP路由下一跳。
This document mandates the use of the Generalized TTL Security Mechanism (GTSM) [RFC6720] for LDP Link Hello packets over IPv6 (see Section 5.1).
本文件要求在IPv6上对LDP链路Hello数据包使用通用TTL安全机制（GTSM）[RFC6720]（见第5.1节）。
This document further recommends enabling GTSM for the LDP/TCP transport connection over IPv6 (i.e., LDPoIPv6). This GTSM inclusion is intended to automatically protect IPv6 LDP peering sessions from off-link attacks.
本文件进一步建议通过IPv6（即LDPoIPv6）为LDP/TCP传输连接启用GTSM。此GTSM包含旨在自动保护IPv6 LDP对等会话免受脱离链路攻击。
[RFC6720] allows for the implementation to statically (via configuration) and/or dynamically override the default behavior (enable/disable GTSM) on a per-peer basis. Such an option could be set on either LSR in a peering session (since GTSM negotiation would ultimately disable GTSM between the LSR and its peer(s)).
[RFC6720]允许实现在每个对等基础上静态（通过配置）和/或动态覆盖默认行为（启用/禁用GTSM）。这种选项可以在对等会话中的任一LSR上设置（因为GTSM协商将最终禁用LSR与其对等方之间的GTSM）。
LDP Link Hello packets MUST have their IPv6 Hop Limit set to 255 and be checked for the same upon receipt before any further processing, as per Section 3 of [RFC5082].
根据[RFC5082]第3节，LDP链路Hello数据包必须将其IPv6跃点限制设置为255，并在收到数据包后进行检查，然后再进行进一步处理。
This document defines a new optional parameter for the LDP Hello message and two new status codes for the LDP Notification message.
本文档为LDP Hello消息定义了一个新的可选参数，为LDP通知消息定义了两个新的状态码。
The "Dual-Stack capability" parameter has been assigned a code point (0x0701) from the "TLV Type Name Space" registry. IANA has allocated this code point from the IETF Consensus range 0x0700-0x07ff for the Dual-Stack capability TLV.
已从“TLV类型名称空间”注册表为“双堆栈能力”参数分配了一个代码点（0x0701）。IANA已从IETF共识范围0x0700-0x07ff为双堆栈能力TLV分配了此代码点。
The 'Transport Connection Mismatch' status code has been assigned a code point (0x00000032) from the "Status Code Name Space" registry. IANA has allocated this code point from the IETF Consensus range and marked the E bit column with a '1'.
“传输连接不匹配”状态代码已从“状态代码名称空间”注册表分配了一个代码点（0x00000032）。IANA已从IETF共识范围中分配此代码点，并将E位列标记为“1”。
The 'Dual-Stack Noncompliance' status code has been assigned a code point (0x00000033) from the "Status Code Name Space" registry. IANA has allocated this code point from the IETF Consensus range and marked the E bit column with a '1'.
“双堆栈不符合”状态代码已从“状态代码名称空间”注册表分配了一个代码点（0x00000033）。IANA已从IETF共识范围中分配此代码点，并将E位列标记为“1”。
The extensions defined in this document only clarify the behavior of LDP; they do not define any new protocol procedures. Hence, this document does not add any new security issues to LDP.
本文件中定义的扩展仅澄清了LDP的行为；他们没有定义任何新的协议程序。因此，本文件未向LDP添加任何新的安全问题。
While the security issues relevant for [RFC5036] are relevant for this document as well, this document reduces the chances of off-link attacks when using an IPv6 transport connection by including the use of GTSM procedures [RFC5082]. Please see Section 9 for LDP TTL Security details.
虽然与[RFC5036]相关的安全问题也与本文档相关，但本文档通过使用GTSM过程[RFC5082]减少了使用IPv6传输连接时发生断开链路攻击的机会。有关LDP TTL安全的详细信息，请参见第9节。
Moreover, this document allows the use of IPsec [RFC4301] for IPv6 protection; hence, LDP can benefit from the additional security as specified in [RFC7321] as well as [RFC5920].
此外，本文件允许使用IPsec[RFC4301]进行IPv6保护；因此，LDP可以受益于[RFC7321]和[RFC5920]中规定的额外安全性。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.“LDP规范”，RFC 5036，DOI 10.17487/RFC5036，2007年10月<http://www.rfc-editor.org/info/rfc5036>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.
[RFC5082]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，Ed.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，DOI 10.17487/RFC5082，2007年10月<http://www.rfc-editor.org/info/rfc5082>.
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010, <http://www.rfc-editor.org/info/rfc5918>.
[RFC5918]Asati，R.，Minei，I.，和B.Thomas，“标签分发协议（LDP）“类型通配符”前向等价类（FEC）”，RFC 5918，DOI 10.17487/RFC5918，2010年8月<http://www.rfc-editor.org/info/rfc5918>.
[RFC4038] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, DOI 10.17487/RFC4038, March 2005, <http://www.rfc-editor.org/info/rfc4038>.
[RFC4038]Shin，M-K.，Ed.，Hong，Y-G.，Hagino，J.，Savola，P.，和E.Castro，“IPv6过渡的应用方面”，RFC 4038，DOI 10.17487/RFC4038，2005年3月<http://www.rfc-editor.org/info/rfc4038>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<http://www.rfc-editor.org/info/rfc4301>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 5340，DOI 10.17487/RFC5340，2008年7月<http://www.rfc-editor.org/info/rfc5340>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<http://www.rfc-editor.org/info/rfc5920>.
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, June 2011, <http://www.rfc-editor.org/info/rfc6286>.
[RFC6286]Chen，E.和J.Yuan，“BGP-4的自治系统范围唯一BGP标识符”，RFC 6286，DOI 10.17487/RFC6286，2011年6月<http://www.rfc-editor.org/info/rfc6286>.
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)", RFC 6720, DOI 10.17487/RFC6720, August 2012, <http://www.rfc-editor.org/info/rfc6720>.
[RFC6720]Pignataro，C.和R.Asati，“标签分发协议（LDP）的通用TTL安全机制（GTSM）”，RFC 6720，DOI 10.17487/RFC6720，2012年8月<http://www.rfc-editor.org/info/rfc6720>.
[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, <http://www.rfc-editor.org/info/rfc7321>.
[RFC7321]McGrew，D.和P.Hoffman，“封装安全有效载荷（ESP）和身份验证头（AH）的密码算法实现要求和使用指南”，RFC 7321，DOI 10.17487/RFC7321，2014年8月<http://www.rfc-editor.org/info/rfc7321>.
[RFC7439] George, W., Ed., and C. Pignataro, Ed., "Gap Analysis for Operating IPv6-Only MPLS Networks", RFC 7439, DOI 10.17487/RFC7439, January 2015, <http://www.rfc-editor.org/info/rfc7439>.
[RFC7439]George，W.，Ed.，和C.Pignataro，Ed.，“运行仅IPv6 MPLS网络的差距分析”，RFC 7439，DOI 10.17487/RFC7439，2015年1月<http://www.rfc-editor.org/info/rfc7439>.
[RFC7473] Raza, K. and S. Boutros, "Controlling State Advertisements of Non-negotiated LDP Applications", RFC 7473, DOI 10.17487/RFC7473, March 2015, <http://www.rfc-editor.org/info/rfc7473>.
[RFC7473]Raza，K.和S.Boutros，“控制非协商自民党申请的国家广告”，RFC 7473，DOI 10.17487/RFC7473，2015年3月<http://www.rfc-editor.org/info/rfc7473>.
It is not safe to assume that implementations compliant with RFC 5036 have supported the handling of an IPv6 address family (IPv6 FEC-label) in a Label Mapping message all along.
假设符合RFC 5036的实现始终支持在标签映射消息中处理IPv6地址系列（IPv6 FEC标签），这是不安全的。
If a router upgraded per this specification advertised both IPv4 and IPv6 FECs in the same Label Mapping message, then an IPv4-only peer (not knowing how to process such a message) may abort processing the entire Label Mapping message (thereby discarding even the IPv4 FEC-labels), as per Section 3.4.1.1 of [RFC5036].
根据[RFC5036]第3.4.1.1节，如果根据本规范升级的路由器在同一标签映射消息中同时公布IPv4和IPv6 FEC，则仅IPv4的对等方（不知道如何处理此类消息）可能会中止处理整个标签映射消息（从而丢弃IPv4 FEC标签）。
This would result in LDPv6 being somewhat undeployable in existing production networks.
这将导致LDPv6在现有生产网络中有些不可部署。
Section 7 of this document provides a good safety net and makes LDPv6 incrementally deployable without making any such assumption on the routers' support for IPv6 FEC processing in current production networks.
本文件第7节提供了一个良好的安全网，使LDPv6可以增量部署，而无需对路由器在当前生产网络中支持IPv6 FEC处理做出任何假设。
It is not safe to assume that implementations have been [RFC5036] compliant in gracefully handling an IPv6 address family (IPv6 Address List TLV) in an Address message all along.
假设实现一直以来都在[RFC5036]兼容地处理地址消息中的IPv6地址系列（IPv6地址列表TLV），这是不安全的。
If a router upgraded per this specification advertised IPv6 addresses (with or without IPv4 addresses) in an Address message, then an IPv4-only peer (not knowing how to process such a message) may not follow Section 3.5.5.1 of [RFC5036] and may tear down the LDP session.
如果根据本规范升级的路由器在地址消息中公布了IPv6地址（有或没有IPv4地址），则仅IPv4的对等方（不知道如何处理此类消息）可能不会遵循[RFC5036]第3.5.5.1节的规定，并且可能会中断LDP会话。
This would result in LDPv6 being somewhat undeployable in existing production networks.
这将导致LDPv6在现有生产网络中有些不可部署。
Sections 6 and 7 of this document provide a good safety net and make LDPv6 incrementally deployable without making any such assumption on the routers' support for IPv6 FEC processing in current production networks.
本文件第6节和第7节提供了一个良好的安全网，使LDPv6可以增量部署，而无需对路由器在当前生产网络中对IPv6 FEC处理的支持做出任何假设。
Per discussion with the 6MAN and V6OPS working groups, the overwhelming consensus was to not promote IPv4-mapped IPv6 addresses appearing in the routing table, as well as in LDP (address and label) databases.
根据与6MAN和V6OPS工作组的讨论，压倒性的共识是不促进在路由表以及LDP（地址和标签）数据库中出现IPv4映射IPv6地址。
Also, [RFC4038], Section 4.2 suggests that IPv4-mapped IPv6-addressed packets should never appear on the wire.
此外，[RFC4038]第4.2节建议，IPv4映射的IPv6寻址数据包不应出现在线路上。
The first four octets of the LDP Identifier, the 32-bit LSR Id (i.e., LDP router Id), identify the LSR and provide a globally unique value within the MPLS network, regardless of the address family used for the LDP session.
LDP标识符的前四个八位字节，即32位LSR Id（即LDP路由器Id），识别LSR并在MPLS网络内提供全局唯一值，而不管LDP会话使用的地址族如何。
Please note that the 32-bit LSR Id value would not map to any IPv4 address in an IPv6-only LSR (i.e., Single-stack), nor would there be an expectation of it being IP routable or DNS resolvable. In IPv4 deployments, the LSR Id is typically derived from an IPv4 address, generally assigned to a loopback interface. In IPv6-only deployments, this 32-bit LSR Id must be derived by some other means that guarantees global uniqueness within the MPLS network, similar to that of the BGP Identifier [RFC6286] and the OSPF router Id [RFC5340].
请注意，32位LSR Id值不会映射到仅IPv6 LSR（即单堆栈）中的任何IPv4地址，也不会期望它是IP可路由或DNS可解析的。在IPv4部署中，LSR Id通常来自IPv4地址，通常分配给环回接口。在仅限IPv6的部署中，此32位LSR Id必须通过其他方式派生，以确保MPLS网络内的全局唯一性，类似于BGP标识符[RFC6286]和OSPF路由器Id[RFC5340]的唯一性。
This document reserves 0.0.0.0 as the LSR Id and prohibits its usage with IPv6, in line with the OSPF router Id in OSPF version 3 [RFC5340].
本文件保留0.0.0.0作为LSR Id，并禁止其与IPv6一起使用，与OSPF版本3[RFC5340]中的OSPF路由器Id一致。
Acknowledgments
致谢
We acknowledge the authors of [RFC5036], since some text in this document is borrowed from [RFC5036].
我们感谢[RFC5036]的作者，因为本文件中的一些文本是从[RFC5036]借来的。
Thanks to Bob Thomas for providing critical feedback to improve this document early on.
感谢Bob Thomas提供关键反馈，以便在早期改进本文档。
Many thanks to Eric Rosen, Lizhong Jin, Bin Mo, Mach Chen, Shane Amante, Pranjal Dutta, Mustapha Aissaoui, Matthew Bocci, Mark Tinka, Tom Petch, Kishore Tiruveedhula, Manoj Dutta, Vividh Siddha, Qin Wu, Simon Perreault, Brian E. Carpenter, Santosh Esale, Danial Johari, and Loa Andersson for thoroughly reviewing this document and for providing insightful comments and multiple improvements.
非常感谢Eric Rosen、Lizhong Jin、Bin Mo、Mach Chen、Shane Amante、Pranjal Dutta、Mustapha Aissaoui、Matthew Bocci、Mark Tinka、Tom Petch、Kishore Tiruveedhula、Manoj Dutta、Liverh Siddha、Qin Wu、Simon Perreault、Brian E.Carpenter、Santosh Esale、Danial Johari、，以及Loa Andersson对本文件进行了全面审查，并提供了深刻的意见和多项改进。
Contributors
贡献者
The following individuals contributed to this document:
以下个人对本文件作出了贡献：
Nagendra Kumar Cisco Systems, Inc. 7200 Kit Creek Road Research Triangle Park, NC 27709, United States EMail: naikumar@cisco.com
Nagendra Kumar Cisco Systems，Inc.地址：美国北卡罗来纳州Kit Creek Road研究三角公园7200号，邮编：27709，电子邮件：naikumar@cisco.com
Andre Pelletier Cisco Systems, Inc. 2000 Innovation Drive Kanata, ON K2K-3E8, Canada EMail: apelleti@cisco.com
Andre Pelletier Cisco Systems，Inc.2000 Innovation Drive Kanata，加拿大K2K-3E8电子邮件：apelleti@cisco.com
Authors' Addresses
作者地址
Rajiv Asati Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709-4987 United States
Rajiv Asati Cisco Systems，Inc.美国北卡罗来纳州Kit Creek Road研究三角公园7025号，邮编：27709-4987
EMail: rajiva@cisco.com
EMail: rajiva@cisco.com
Carlos Pignataro Cisco Systems, Inc. 7200 Kit Creek Road Research Triangle Park, NC 27709-4987 United States
卡洛斯·皮格纳塔罗思科系统公司，美国北卡罗来纳州基特克里克路研究三角公园7200号，邮编：27709-4987
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com
Kamran Raza Cisco Systems, Inc. 2000 Innovation Drive Ottawa, ON K2K-3E8 Canada
Kamran Raza Cisco Systems，Inc.位于加拿大渥太华K2K-3E8的创新大道2000号
EMail: skraza@cisco.com
EMail: skraza@cisco.com
Vishwas Manral Ionos Networks 4100 Moorpark Ave., Ste. #122 San Jose, CA 95117 United States Phone: +1 408 447 1497
维什瓦斯-曼拉尔-伊洛诺斯网络公司，地址：圣路易斯摩尔帕克大道4100号#122加利福尼亚州圣何塞95117美国电话：+1408 447 1497
EMail: vishwas@ionosnetworks.com
EMail: vishwas@ionosnetworks.com
Rajiv Papneja Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 United States Phone: +1 571 926 8593
Rajiv Papneya华为技术公司2330美国加利福尼亚州圣克拉拉中央高速公路95050电话：+1 571 926 8593
EMail: rajiv.papneja@huawei.com
EMail: rajiv.papneja@huawei.com