Internet Engineering Task Force (IETF) H. Shah, Ed.
Request for Comments: 6575 Ciena
Category: Standards Track E. Rosen, Ed.
ISSN: 2070-1721 G. Heron, Ed.
Cisco
V. Kompella, Ed.
Alcatel-Lucent
June 2012
Internet Engineering Task Force (IETF) H. Shah, Ed.
Request for Comments: 6575 Ciena
Category: Standards Track E. Rosen, Ed.
ISSN: 2070-1721 G. Heron, Ed.
Cisco
V. Kompella, Ed.
Alcatel-Lucent
June 2012
Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs
用于第2层VPN IP互通的地址解析协议（ARP）中介
Abstract
摘要
The Virtual Private Wire Service (VPWS), detailed in RFC 4664, provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge (PE) device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet or both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "Address Resolution Protocol (ARP) Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP.
RFC 4664中详细介绍的虚拟专用线服务（VPWS）在成对的客户边缘（CE）设备之间提供点对点连接。它通过将两个连接电路（每个连接一个CE设备和一个提供者边缘（PE）设备）绑定到一个伪线（连接两个PE）来实现。通常，连接电路必须采用相同的技术（例如，以太网或ATM），并且伪线必须承载该技术的帧。然而，如果已知帧的有效载荷仅由IP数据报组成，则可以提供点到点连接，其中伪线连接不同技术的连接电路。这要求PEs执行称为“地址解析协议（ARP）中介”的功能。ARP中介是指在任一连接电路上使用不同的解析协议时解析第2层地址的过程。即使CEs在它们之间运行路由协议，只要路由协议在IP上运行，本文档中描述的方法也适用。
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/rfc6575.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6575.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ....................................................3
1.1. Conventions Used in This Document ..........................4
2. ARP Mediation (AM) Function .....................................5
3. IP Layer 2 Interworking Circuit .................................6
4. IP Address Discovery Mechanisms .................................6
4.1. Discovery of IP Addresses of Locally Attached IPv4 CE ......7
4.1.1. Monitoring Local Traffic ............................7
4.1.2. CE Devices Using ARP ................................7
4.1.3. CE Devices Using Inverse ARP ........................8
4.1.4. CE Devices Using PPP ................................9
4.1.5. Router Discovery Method ............................10
4.1.6. Manual Configuration ...............................10
4.2. How a CE Learns the IPv4 Address of a Remote CE ...........10
4.2.1. CE Devices Using ARP ...............................11
4.2.2. CE Devices Using Inverse ARP .......................11
4.2.3. CE Devices Using PPP ...............................11
4.3. Discovery of IP Addresses of IPv6 CE Devices ..............11
4.3.1. Distinguishing Factors between IPv4 and IPv6 .......11
4.3.2. Requirements for PEs ...............................12
4.3.3. Processing of Neighbor Solicitations ...............12
4.3.4. Processing of Neighbor Advertisements ..............13
4.3.5. Processing Inverse Neighbor Solicitations (INSs) ...14
4.3.6. Processing of Inverse Neighbor
Advertisements (INAs) ..............................15
4.3.7. Processing of Router Solicitations .................15
4.3.8. Processing of Router Advertisements ................15
4.3.9. Duplicate Address Detection ........................16
4.3.10. CE Address Discovery for CEs Attached Using PPP ...16
5. CE IPv4 Address Signaling between PEs ..........................16
5.1. When to Signal an IPv4 Address of a CE ....................16
5.2. LDP-Based Distribution of CE IPv4 Addresses ...............17
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. ARP Mediation (AM) Function .....................................5
3. IP Layer 2 Interworking Circuit .................................6
4. IP Address Discovery Mechanisms .................................6
4.1. Discovery of IP Addresses of Locally Attached IPv4 CE ......7
4.1.1. Monitoring Local Traffic ............................7
4.1.2. CE Devices Using ARP ................................7
4.1.3. CE Devices Using Inverse ARP ........................8
4.1.4. CE Devices Using PPP ................................9
4.1.5. Router Discovery Method ............................10
4.1.6. Manual Configuration ...............................10
4.2. How a CE Learns the IPv4 Address of a Remote CE ...........10
4.2.1. CE Devices Using ARP ...............................11
4.2.2. CE Devices Using Inverse ARP .......................11
4.2.3. CE Devices Using PPP ...............................11
4.3. Discovery of IP Addresses of IPv6 CE Devices ..............11
4.3.1. Distinguishing Factors between IPv4 and IPv6 .......11
4.3.2. Requirements for PEs ...............................12
4.3.3. Processing of Neighbor Solicitations ...............12
4.3.4. Processing of Neighbor Advertisements ..............13
4.3.5. Processing Inverse Neighbor Solicitations (INSs) ...14
4.3.6. Processing of Inverse Neighbor
Advertisements (INAs) ..............................15
4.3.7. Processing of Router Solicitations .................15
4.3.8. Processing of Router Advertisements ................15
4.3.9. Duplicate Address Detection ........................16
4.3.10. CE Address Discovery for CEs Attached Using PPP ...16
5. CE IPv4 Address Signaling between PEs ..........................16
5.1. When to Signal an IPv4 Address of a CE ....................16
5.2. LDP-Based Distribution of CE IPv4 Addresses ...............17
6. IPv6 Capability Advertisement ..................................20
6.1. PW Operational Down on Stack Capability Mismatch ..........21
6.2. Stack Capability Fallback .................................21
7. IANA Considerations ............................................22
7.1. LDP Status Messages .......................................22
7.2. Interface Parameters ......................................22
8. Security Considerations ........................................22
8.1. Control Plane Security ....................................23
8.2. Data Plane Security .......................................24
9. Acknowledgements ...............................................24
10. Contributors ..................................................24
11. References ....................................................25
11.1. Normative References .....................................25
11.2. Informative References ...................................26
Appendix A. Use of IGPs with IP L2 Interworking L2VPNs ...........27
A.1. OSPF ......................................................27
A.2. RIP .......................................................27
A.3. IS-IS .....................................................28
6. IPv6 Capability Advertisement ..................................20
6.1. PW Operational Down on Stack Capability Mismatch ..........21
6.2. Stack Capability Fallback .................................21
7. IANA Considerations ............................................22
7.1. LDP Status Messages .......................................22
7.2. Interface Parameters ......................................22
8. Security Considerations ........................................22
8.1. Control Plane Security ....................................23
8.2. Data Plane Security .......................................24
9. Acknowledgements ...............................................24
10. Contributors ..................................................24
11. References ....................................................25
11.1. Normative References .....................................25
11.2. Informative References ...................................26
Appendix A. Use of IGPs with IP L2 Interworking L2VPNs ...........27
A.1. OSPF ......................................................27
A.2. RIP .......................................................27
A.3. IS-IS .....................................................28
Layer 2 Virtual Private Networks (L2VPNs) are constructed over a Service Provider IP/MPLS backbone but are presented to the Customer Edge (CE) devices as Layer 2 networks. In theory, L2VPNs can carry any Layer 3 protocol, but in many cases, the Layer 3 protocol is IP. Thus, it makes sense to consider procedures that are optimized for IP.
第2层虚拟专用网络（L2VPN）构建在服务提供商IP/MPLS主干上，但作为第2层网络呈现给客户边缘（CE）设备。理论上，L2VPN可以承载任何第三层协议，但在许多情况下，第三层协议是IP协议。因此，考虑为IP优化的过程是有意义的。
In a typical implementation, illustrated in the diagram below, the CE devices are connected to the Provider Edge (PE) devices via Attachment Circuits (ACs). The ACs are Layer 2 circuits. In a pure L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via AC2, both ACs would have to be of the same type (i.e., both Ethernet, both Frame Relay, etc.). However, if it is known that only IP traffic will be carried, the ACs can be of different technologies, provided that the PEs provide the appropriate procedures to allow the proper transfer of IP packets.
在下图所示的典型实现中，CE设备通过连接电路（ACs）连接到提供商边缘（PE）设备。ACs是第二层电路。在纯L2VPN中，如果通过AC1从CE1发送的流量通过AC2到达CE2，则两个ACs必须是相同类型的（即，两个以太网、两个帧中继等）。然而，如果已知仅承载IP通信量，则ACs可以采用不同的技术，前提是PEs提供适当的程序以允许IP分组的适当传输。
+-----+
+------ -----| CE3 |
|AC3 +-----+
+-----+
......| PE3 |...........
. +-----+ .
. | .
. | .
+-----+ AC1 +-----+ Service +-----+ AC2 +-----+
| CE1 |-----| PE1 |--- Provider ----| PE2 |-----| CE2 |
+-----+ +-----+ Backbone +-----+ +-----+
. .
........................
+-----+
+------ -----| CE3 |
|AC3 +-----+
+-----+
......| PE3 |...........
. +-----+ .
. | .
. | .
+-----+ AC1 +-----+ Service +-----+ AC2 +-----+
| CE1 |-----| PE1 |--- Provider ----| PE2 |-----| CE2 |
+-----+ +-----+ Backbone +-----+ +-----+
. .
........................
A CE, which is connected via a given type of AC, may use an IP address resolution procedure that is specific to that type of AC. For example, an Ethernet-attached IPv4 CE would use ARP [RFC826] and a Frame-Relay-attached CE might use Inverse ARP [RFC2390]. If we are to allow the two CEs to have a Layer 2 connection between them, even though each AC uses a different Layer 2 technology, the PEs must intercept and "mediate" the Layer-2-specific address resolution procedures.
通过给定类型的AC连接的CE可以使用特定于该类型AC的IP地址解析过程。例如，连接以太网的IPv4 CE将使用ARP[RFC826]，连接帧中继的CE可能使用反向ARP[RFC2390]。如果我们允许两个CE之间有第2层连接，即使每个AC使用不同的第2层技术，PEs必须拦截和“调解”第2层特定的地址解析过程。
In this document, we specify the procedures for VPWS services [RFC4664], which the PEs need to implement in order to mediate the IP address resolution mechanism. We call these procedures "ARP Mediation". Consider a Virtual Private Wire Service (VPWS) constructed between CE1 and CE2 in the diagram above. If AC1 and AC2 are of different technologies, e.g., AC1 is Ethernet and AC2 is Frame Relay (FR), then ARP requests coming from CE1 cannot be passed transparently to CE2. PE1 MUST interpret the meaning of the ARP requests and mediate the necessary information with PE2 before responding.
在本文档中，我们指定了VPWS服务[RFC4664]的过程，PEs需要实现这些过程，以协调IP地址解析机制。我们称这些过程为“ARP调解”。在上面的图中考虑在CE1和CE2之间构建的虚拟专用线服务（VPWS）。如果AC1和AC2采用不同的技术，例如，AC1是以太网，AC2是帧中继（FR），则来自CE1的ARP请求不能透明地传递给CE2。PE1必须解释ARP请求的含义，并在响应前与PE2协调必要的信息。
This document uses the term "ARP" to mean any protocol that is used to resolve IP addresses to link-layer addresses. For instance, in IPv4, ARP and Inverse ARP protocols are used for address resolution while in IPv6, Neighbor Discovery [RFC4861] and Inverse Neighbor Discovery [RFC3122] based on ICMPv6 are used for address resolution.
本文档使用术语“ARP”表示用于将IP地址解析为链路层地址的任何协议。例如，在IPv4中，ARP和反向ARP协议用于地址解析，而在IPv6中，基于ICMPv6的邻居发现[RFC4861]和反向邻居发现[RFC3122]用于地址解析。
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]中所述进行解释。
The ARP Mediation (AM) function is an element of a PE node that deals with the IP address resolution for CE devices connected via a VPWS L2VPN. By placing this function in the PE node, ARP Mediation is transparent to the CE devices.
ARP中介（AM）功能是PE节点的一个元素，用于处理通过VPWS L2VPN连接的CE设备的IP地址解析。通过将此功能放置在PE节点中，ARP中介对CE设备是透明的。
For a given point-to-point connection between a pair of CEs, the ARP Mediation procedure depends on whether the packets being forwarded are IPv4 or IPv6. A PE that is to perform ARP Mediation for IPv4 packets MUST perform the following logical steps:
对于一对CE之间的给定点对点连接，ARP中介过程取决于转发的数据包是IPv4还是IPv6。要对IPv4数据包执行ARP中介的PE必须执行以下逻辑步骤：
1. Discover the IP address of the locally attached CE device.
1. 查找本地连接的CE设备的IP地址。
2. Terminate. Do not forward ARP and Inverse ARP requests from the CE device at the local PE.
2. 终止不要在本地PE转发来自CE设备的ARP和反向ARP请求。
3. Distribute the IP address to the remote PE using pseudowire control signaling.
3. 使用伪线控制信令将IP地址分配给远程PE。
4. Notify the locally attached CE of the IP address of the remote CE.
4. 将远程CE的IP地址通知本地连接的CE。
5. Respond appropriately to ARP and Inverse ARP requests from the local CE device using the IP address of the remote CE and the hardware address of the local PE.
5. 使用远程CE的IP地址和本地PE的硬件地址适当响应来自本地CE设备的ARP和反向ARP请求。
A PE that is to perform ARP Mediation for IPv6 packets MUST perform the following logical steps:
要对IPv6数据包执行ARP中介的PE必须执行以下逻辑步骤：
1. Discover the IPv6 addresses of the locally attached CE device, together with those of the remote CE device.
1. 查找本地连接的CE设备的IPv6地址以及远程CE设备的IPv6地址。
2. Perform the following steps:
2. 执行以下步骤：
a. Intercept Neighbor Discovery (ND) and Inverse Neighbor Discovery (IND) packets received from the local CE device.
a. 拦截从本地CE设备接收的邻居发现（ND）和反向邻居发现（IND）数据包。
b. From these ND and IND packets, learn the IPv6 configuration of the CE.
b. 从这些ND和IND数据包中，了解CE的IPv6配置。
c. Forward the ND and IND packets over the pseudowire to the remote PE.
c. 通过伪线将ND和IND数据包转发到远程PE。
3. Intercept Neighbor Discovery and Inverse Neighbor Discovery packets received over the pseudowire from the remote PE, possibly modifying them (if required for the type of outgoing AC) before forwarding to the local CE and learning information about the IPv6 configuration of the remote CE.
3. 截获通过伪线从远程PE接收的邻居发现和反向邻居发现数据包，可能在转发到本地CE和了解远程CE的IPv6配置信息之前对其进行修改（如果传出AC类型需要）。
Details for the procedures described above are given in the following sections.
以下章节给出了上述步骤的详细信息。
The IP Layer 2 Interworking Circuit refers to interconnection of the Attachment Circuit with the IP Layer 2 Transport pseudowire that carries IP datagrams as the payload. The ingress PE removes the data link header of its local Attachment Circuit and transmits the payload (an IP packet) over the pseudowire with or without the optional control word. If the IP packet arrives at the ingress PE with multiple data link headers (for example, in the case of bridged Ethernet PDU on an ATM Attachment Circuit), all data link headers MUST be removed from the IP packet before transmission over the pseudowire (PW). The egress PE encapsulates the IP packet with the data link header used on its local Attachment Circuit.
IP层2互通电路是指连接电路与承载IP数据报作为有效载荷的IP层2传输伪线的互连。入口PE移除其本地连接电路的数据链路报头，并通过具有或不具有可选控制字的伪线传输有效负载（IP分组）。如果IP数据包到达具有多个数据链路头的入口PE（例如，在ATM连接电路上的桥接以太网PDU的情况下），则在通过伪线（PW）传输之前，必须从IP数据包中移除所有数据链路头。出口PE用在其本地连接电路上使用的数据链路报头封装IP分组。
The encapsulation for the IP Layer 2 Transport pseudowire is described in [RFC4447]. The "IP Layer 2 Interworking Circuit" pseudowire is also referred to as "IP pseudowire" in this document.
[RFC4447]中描述了IP层2传输伪线的封装。“IP层2互通电路”伪线在本文件中也称为“IP伪线”。
In the case of an IPv6 L2 Interworking Circuit, the egress PE MAY modify the contents of Neighbor Discovery or Inverse Neighbor Discovery packets before encapsulating the IP packet with the data link header.
在IPv6 L2互通电路的情况下，出口PE可以在用数据链路报头封装IP分组之前修改邻居发现或反向邻居发现分组的内容。
An IP Layer 2 Interworking Circuit enters monitoring state immediately after configuration. During this state, it performs two functions:
IP层2互通电路在配置后立即进入监控状态。在此状态下，它执行两个功能：
o Discovery of the CE IP device(s)
o 发现CE IP设备
o Establishment of the PW
o 工务局的成立
The establishment of the PW occurs independently from local CE IP address discovery. During the period when the PW has been established but the local CE IP device has not been discovered, only broadcast/multicast IP frames are propagated between the Attachment Circuit and pseudowire; unicast IP datagrams are dropped. The IP destination address is used to classify unicast/multicast packets.
PW的建立独立于本地CE IP地址发现。在已经建立PW但是没有发现本地CE-IP设备的期间，仅在连接电路和伪线之间传播广播/多播IP帧；单播IP数据报被丢弃。IP目标地址用于对单播/多播数据包进行分类。
Unicast IP frames are propagated between the AC and pseudowire only when CE IP devices on both Attachment Circuits have been discovered and notified and proxy functions have completed.
仅当发现并通知两个连接电路上的CE IP设备以及代理功能完成时，才在AC和伪线之间传播单播IP帧。
The need to wait for address resolution completion before unicast IP traffic can flow is simple.
在单播IP流量能够流动之前，需要等待地址解析完成，这很简单。
o PEs do not perform routing operations.
o PEs不执行路由操作。
o The destination IP address in the packet is not necessarily that of the attached CE.
o 分组中的目的地IP地址不一定是所附CE的目的地IP地址。
o On a broadcast link, there is no way to find out the Media Access Control (MAC) address of the CE based on the destination IP address of the packet.
o 在广播链路上，无法基于分组的目的地IP地址找到CE的媒体访问控制（MAC）地址。
A PE MUST support manual configuration of IPv4 CE addresses. This section also describes automated mechanisms by which a PE MAY also discover an IPv4 CE address.
PE必须支持IPv4 CE地址的手动配置。本节还描述了PE也可以通过其发现IPv4 CE地址的自动机制。
The PE devices MAY learn the IP addresses of the locally attached CEs from any IP traffic, such as link-local multicast packets (e.g., destined to 224.0.0.x), and are not restricted to the operations below.
PE设备可以从诸如链路本地多播分组（例如，目的地为224.0.0.x）之类的任何IP业务学习本地连接的ce的IP地址，并且不限于以下操作。
If a CE device uses ARP to determine the IP-address-to-MAC-address binding of its neighbor, the PE processes the ARP requests to learn the IP address of the local CE for the local Attachment Circuit.
如果CE设备使用ARP来确定其邻居的IP地址到MAC地址绑定，则PE处理ARP请求以了解本地连接电路的本地CE的IP地址。
The method described in this document only supports the case where there is a single CE per Attachment Circuit. However, customer-facing access topologies may exist whereby more than one CE appears to be connected to the PE on a single Attachment Circuit. For example, this could be the case when CEs are connected to a shared LAN that connects to the PE. In such a case, the PE MUST select one local CE. The selection could be based on manual configuration or the PE MAY optionally use the following selection criteria. In either case, manual configuration of the IP address of the local CE (and its MAC address) MUST be supported.
本文档中描述的方法仅支持每个附件电路有一个CE的情况。然而，可能存在面向客户的接入拓扑，其中多个CE似乎连接到单个连接电路上的PE。例如，当CE连接到连接到PE的共享LAN时，可能会出现这种情况。在这种情况下，PE必须选择一个本地CE。选择可以基于手动配置，或者PE可以选择使用以下选择标准。在任何一种情况下，都必须支持手动配置本地CE的IP地址（及其MAC地址）。
o Wait to learn the IP address of the remote CE (through PW signaling) and then select the local CE that is sending the request for IP address of the remote CE.
o 等待了解远程CE的IP地址（通过PW信令），然后选择发送远程CE IP地址请求的本地CE。
o Augment cross-checking with the local IP address learned through listening for link-local multicast packets (as per Section 4.1.1).
o 通过侦听链路本地多播数据包（根据第4.1.1节），增加与本地IP地址的交叉检查。
o Augment cross-checking with the local IP address learned through the Router Discovery Protocol (as described in Section 4.1.5).
o 使用通过路由器发现协议（如第4.1.5节所述）学习的本地IP地址增加交叉检查。
o There is still a possibility that the local PE may not receive an IP address advertisement from the remote PE, and there may exist multiple local IP routers that attempt to 'connect' to remote CEs. In this situation, the local PE MAY use some other criteria to select one IP device from many (such as "the first ARP received"), or an operator MAY configure the IP address of the local CE. Note that the operator does not have to configure the IP address of the remote CE (as that would be learned through pseudowire signaling).
o 本地PE可能仍然无法从远程PE接收IP地址公告，并且可能存在多个试图“连接”到远程CE的本地IP路由器。在这种情况下，本地PE可以使用一些其他标准从多个IP设备中选择一个IP设备（例如“接收到的第一个ARP”），或者运营商可以配置本地CE的IP地址。请注意，操作员不必配置远程CE的IP地址（这将通过伪线信令了解）。
Once the local and remote CEs have been discovered for the given Attachment Circuit, the local PE responds with its own MAC address to any subsequent ARP requests from the local CE with a destination IP address matching the IP address of the remote CE.
一旦为给定的连接电路发现了本地和远程CE，本地PE用其自己的MAC地址对来自本地CE的任何后续ARP请求作出响应，目标IP地址与远程CE的IP地址匹配。
The local PE signals the IP address of the local CE to the remote PE and MAY initiate an unsolicited ARP response to notify the IP-address-to-MAC-address binding for the remote CE to the local CE (again using its own MAC address).
本地PE向远程PE发送本地CE的IP地址的信号，并且可以发起未经请求的ARP响应，以通知远程CE到本地CE的IP地址到MAC地址绑定（再次使用其自己的MAC地址）。
Once the ARP Mediation function is completed (i.e., the PE device knows both the local and remote CE IP addresses), unicast IP frames are propagated between the AC and the established PW.
一旦ARP中介功能完成（即，PE设备知道本地和远程CE IP地址），单播IP帧在AC和建立的PW之间传播。
The PE MAY periodically generate ARP request messages for the IP address of the CE as a means of verifying the continued existence of the IP address and its MAC address binding. The absence of a response from the CE device for a given number of retries could be used as a trigger for withdrawal of the IP address advertisement to the remote PE. The local PE would then re-enter the address resolution phase to rediscover the IP address of the attached CE. Note that this "heartbeat" scheme is needed only where the failure of a CE device may otherwise be undetectable.
PE可以周期性地为CE的IP地址生成ARP请求消息，作为验证IP地址及其MAC地址绑定的持续存在的手段。对于给定的重试次数没有来自CE设备的响应可被用作将IP地址广告撤回到远程PE的触发器。本地PE随后将重新进入地址解析阶段，以重新发现所附CE的IP地址。请注意，只有当CE设备的故障可能无法检测时，才需要此“心跳”方案。
If a CE device uses Inverse ARP to determine the IP address of its neighbor, the attached PE processes the Inverse ARP request from the Attachment Circuit and responds with an Inverse ARP reply containing
如果CE设备使用反向ARP确定其邻居的IP地址，则连接的PE处理来自连接电路的反向ARP请求，并使用包含
the IP address of the remote CE, if the address is known. If the PE does not yet have the IP address of the remote CE, it does not respond, but records the IP address of the local CE and the circuit information. Subsequently, when the IP address of the remote CE becomes available, the PE MAY initiate an Inverse ARP request as a means of notifying the local CE of the IP address of the remote CE.
远程CE的IP地址（如果地址已知）。如果PE还没有远程CE的IP地址，则不会响应，而是记录本地CE的IP地址和电路信息。随后，当远程CE的IP地址变得可用时，PE可以发起反向ARP请求，作为将远程CE的IP地址通知本地CE的手段。
This is the typical mode of operation for Frame Relay and ATM Attachment Circuits. If the CE does not use Inverse ARP, the PE can still discover the IP address of the local CE using the mechanisms described in Sections 4.1.1 and 4.1.5.
这是帧中继和ATM连接电路的典型操作模式。如果CE不使用反向ARP，则PE仍然可以使用第4.1.1节和第4.1.5节中描述的机制发现本地CE的IP地址。
The IP Control Protocol [RFC1332] describes a procedure to establish and configure IP on a point-to-point connection, including the negotiation of IP addresses. When such an Attachment Circuit is configured for IP interworking, PPP negotiation is not performed end-to-end between CE devices. Instead, PPP negotiation takes place between the CE and its local PE. The PE performs proxy PPP negotiation and informs the attached CE of the IP address of the remote CE during IP Control Protocol (IPCP) negotiation using the IP-Address option (0x03).
IP控制协议[RFC1332]描述了在点到点连接上建立和配置IP的过程，包括IP地址协商。当这样的连接电路被配置用于IP互通时，在CE设备之间不执行端到端的PPP协商。相反，PPP谈判在行政长官与其当地PE之间进行。PE执行代理PPP协商，并在IP控制协议（IPCP）协商期间使用IP地址选项（0x03）通知连接的CE远程CE的IP地址。
When a PPP link completes Link Control Protocol (LCP) negotiations, the local PE MAY perform the following IPCP actions:
当PPP链路完成链路控制协议（LCP）协商时，本地PE可执行以下IPCP操作：
o The PE learns the IP address of the local CE from the Configure-Request received with the IP-Address option (0x03). If the IP address is non-zero, the PE records the address and responds with Configure-Ack. However, if the IP address is zero, the PE responds with Configure-Reject (as this is a request from the CE to assign it an IP address). Also, the IP-Address option is set with a zero value in the Configure-Reject response to instruct the CE not to include that option in any subsequent Configure-Request.
o PE从使用IP地址选项（0x03）接收的配置请求中学习本地CE的IP地址。如果IP地址不为零，则PE会记录该地址并使用配置确认进行响应。但是，如果IP地址为零，则PE会响应配置拒绝（因为这是CE向其分配IP地址的请求）。此外，IP地址选项在配置拒绝响应中设置为零值，以指示CE在任何后续配置请求中不包括该选项。
o If the PE receives a Configure-Request without the IP-Address option, it responds with a Configure-Ack. In this case, the PE is unable to learn the IP address of the local CE using IPCP; hence, it MUST rely on other means as described in Sections 4.1.1 and 4.1.5. Note that in order to employ other learning mechanisms, the IPCP negotiations MUST have reached the open state.
o 如果PE接收到不带IP地址选项的配置请求，则会以配置确认进行响应。在这种情况下，PE无法使用IPCP学习本地CE的IP地址；因此，必须采用第4.1.1节和第4.1.5节中所述的其他方法。请注意，为了采用其他学习机制，IPCP谈判必须达到开放状态。
o If the PE does not know the IP address of the remote CE, it sends a Configure-Request without the IP-Address option.
o 如果PE不知道远程CE的IP地址，则会发送不带IP地址选项的配置请求。
o If the PE knows the IP address of the remote CE, it sends a Configure-Request with the IP-Address option containing the IP address of the remote CE.
o 如果PE知道远程CE的IP地址，它将发送一个配置请求，其中IP地址选项包含远程CE的IP地址。
The IPCP IP-Address option MAY be negotiated between the PE and the local CE device. Configuration of other IPCP options MAY be rejected. Other Network Control Protocols (NCPs), with the exception of the Compression Control Protocol (CCP) and the Encryption Control Protocol (ECP), MUST be rejected. The PE device MAY reject configuration of the CCP and ECP.
IPCP IP地址选项可以在PE和本地CE设备之间协商。其他IPCP选项的配置可能会被拒绝。除压缩控制协议（CCP）和加密控制协议（ECP）外，必须拒绝其他网络控制协议（NCP）。PE设备可能拒绝CCP和ECP的配置。
In order to learn the IP address of the CE device for a given Attachment Circuit, the PE device MAY execute the Router Discovery Protocol [RFC1256] whereby a Router Discovery Request (ICMP - Router Solicitation) message is sent using a source IP address of zero. The IP address of the CE device is extracted from the Router Discovery Response (ICMP - Router Advertisement) message from the CE. It is possible that the response contains more than one router address with the same preference level, in which case, some heuristics (such as first on the list) are necessary. The use of the Router Discovery method by the PE is optional.
为了学习给定连接电路的CE设备的IP地址，PE设备可以执行路由器发现协议[rfc256]，由此使用零的源IP地址发送路由器发现请求（ICMP-路由器请求）消息。CE设备的IP地址从来自CE的路由器发现响应（ICMP-路由器广告）消息中提取。响应可能包含多个具有相同首选级别的路由器地址，在这种情况下，需要一些试探（例如列表上的第一个）。PE使用路由器发现方法是可选的。
In some cases, it may not be possible to discover the IP address of the local CE device using the mechanisms described in Sections 4.1.1 to 4.1.5. In such cases, manual configuration MAY be used. All implementations of this document MUST support manual configuration of the IPv4 address of the local CE. This is the only REQUIRED mode for a PE to support.
在某些情况下，可能无法使用第4.1.1至4.1.5节中描述的机制发现本地CE设备的IP地址。在这种情况下，可以使用手动配置。本文档的所有实现都必须支持本地CE的IPv4地址的手动配置。这是PE支持的唯一必需模式。
The support for configuration of the IP address of the remote CE is OPTIONAL.
远程CE的IP地址配置支持是可选的。
Once the local PE has received the IP address information of the remote CE from the remote PE, it will either initiate an address resolution request or respond to an outstanding request from the attached CE device.
一旦本地PE从远程PE接收到远程CE的IP地址信息，它将发起地址解析请求或响应来自连接的CE设备的未决请求。
In the event that the IPv4 address of the remote CE is manually configured, the address resolution can begin immediately as receipt of remote IP address of the CE becomes unnecessary.
在手动配置远程CE的IPv4地址的情况下，当不再需要接收CE的远程IP地址时，可以立即开始地址解析。
When the PE learns the IP address of the remote CE as described in Section 5.1, it may or may not already know the IP address of the local CE. If the IP address is not known, the PE MUST wait until it is acquired through one of the methods described in Sections 4.1.1, 4.1.2, and 4.1.5. If the IP address of the local CE is known, the PE MAY choose to generate an unsolicited ARP message to notify the local CE about the binding of the IP address of the remote CE with the PE's own MAC address.
当PE如第5.1节所述了解远程CE的IP地址时，它可能知道或可能还不知道本地CE的IP地址。如果IP地址未知，则PE必须等待，直到通过第4.1.1、4.1.2和4.1.5节所述的方法之一获取IP地址。如果本地CE的IP地址已知，则PE可以选择生成未经请求的ARP消息，以通知本地CE远程CE的IP地址与PE自己的MAC地址的绑定。
When the local CE generates an ARP request, the PE MUST proxy the ARP response [RFC925] using its own MAC address as the source hardware address and the IP address of the remote CE as the source protocol address. The PE MUST respond only to those ARP requests whose destination protocol address matches the IP address of the remote CE.
当本地CE生成ARP请求时，PE必须使用自己的MAC地址作为源硬件地址，使用远程CE的IP地址作为源协议地址，代理ARP响应[RFC925]。PE必须仅响应目标协议地址与远程CE的IP地址匹配的ARP请求。
When the PE learns the IP address of the remote CE, it SHOULD generate an Inverse ARP request. If the Attachment Circuit requires activation (e.g., Frame Relay), the PE SHOULD activate it first before the Inverse ARP request. It should be noted that the PE might never receive the response to its own request, nor see any Inverse ARP request from the CE, in cases where the CE is pre-configured with the IP address of the remote CE or where the use of Inverse ARP has not been enabled. In either case, the CE has used other means to learn the IP address of its neighbor.
当PE获知远程CE的IP地址时，它应该生成一个反向ARP请求。如果附件电路需要激活（例如，帧中继），则PE应在反向ARP请求之前首先激活它。应注意，在CE预先配置了远程CE的IP地址或未启用反向ARP的情况下，PE可能永远不会收到对其自身请求的响应，也不会看到来自CE的任何反向ARP请求。在这两种情况下，CE都使用了其他方法来了解其邻居的IP地址。
When the PE learns the IP address of the remote CE, it SHOULD initiate a Configure-Request and set the IP-Address option to the IP address of the remote CE. This notifies the local CE of the IP address of the remote CE.
当PE获知远程CE的IP地址时，它应启动配置请求，并将IP地址选项设置为远程CE的IP地址。这将通知本地CE远程CE的IP地址。
IPv4 uses ARP and Inverse ARP to resolve IP address and link-layer associations. Since these are dedicated address resolution protocols, and not IP packets, they cannot be carried on an IP pseudowire. They MUST be processed locally and the IPv4 address information they carry signaled between the PEs using the pseudowire control plane. IPv6 uses ICMPv6 extensions to resolve IP address and
IPv4使用ARP和反向ARP来解析IP地址和链路层关联。因为这些是专用的地址解析协议，而不是IP数据包，所以它们不能在IP伪线上携带。它们必须在本地处理，并且它们携带的IPv4地址信息在PEs之间使用伪线控制平面发出信号。IPv6使用ICMPv6扩展解析IP地址和
link address associations. As these are IPv6 packets, they can be carried on an IP pseudowire; therefore, no IPv6 address signaling is required.
链接地址关联。由于这些是IPv6数据包，它们可以通过IP伪线携带；因此，不需要IPv6地址信令。
A PE device that supports IPv6 MUST be capable of the following:
支持IPv6的PE设备必须具备以下功能：
o Intercepting ICMPv6 Neighbor Discovery [RFC4861] and Inverse Neighbor Discovery [RFC3122] packets received over the AC as well as over the PW,
o 拦截通过AC和PW接收的ICMPv6邻居发现[RFC4861]和反向邻居发现[RFC3122]数据包，
o Recording the IPv6 interface addresses and CE link-layer addresses present in these packets,
o 记录这些数据包中存在的IPv6接口地址和CE链路层地址，
o Possibly modifying these packets as dictated by the data link type of the egress AC (described in the following sections), and
o 可能根据出口AC的数据链路类型（在以下部分中描述）来修改这些分组，以及
o Forwarding them towards the original destination.
o 将它们转发到原始目的地。
The PE MUST also be capable of generating packets in order to interwork between Neighbor Discovery (ND) and Inverse Neighbor Discovery (IND). This is specified in Sections 4.3.3 to 4.3.6.
PE还必须能够生成数据包，以便在邻居发现（ND）和反向邻居发现（IND）之间互通。第4.3.3节至第4.3.6节对此进行了规定。
If an IP PW is used to interconnect CEs that use IPv6 Router Discovery [RFC4861], a PE device MUST also be capable of intercepting and processing those Router Discovery packets. This is required in order to translate between different link-layer addresses. If a Router Discovery message contains a link-layer address, then the PE MAY also use this message to discover the link-layer address and IPv6 interface address. This is described in more detail in Sections 4.3.7 and 4.3.8.
如果IP PW用于互连使用IPv6路由器发现[RFC4861]的CE，则PE设备还必须能够拦截和处理这些路由器发现数据包。这是在不同链路层地址之间进行转换所必需的。如果路由器发现消息包含链路层地址，则PE也可以使用此消息来发现链路层地址和IPv6接口地址。第4.3.7节和第4.3.8节对此进行了更详细的描述。
The PE device MUST learn a list of CE IPv6 interface addresses for its directly attached CE and another list of CE IPv6 interface addresses for the far-end CE. The PE device MUST also learn the link-layer address of the local CE and be able to use it when forwarding traffic between the local and far-end CEs. The PE MAY also wish to monitor the source link-layer address of data packets received from the CE and discard packets not matching its learned CE link-layer address.
PE设备必须了解其直接连接的CE的CE IPv6接口地址列表，以及远端CE的CE IPv6接口地址列表。PE设备还必须了解本地CE的链路层地址，并在本地和远端CE之间转发流量时能够使用该地址。PE还可能希望监视从CE接收的数据分组的源链路层地址，并丢弃与其读入的CE链路层地址不匹配的分组。
A Neighbor Solicitation received on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 interface address (if provided, this will not be the case for Duplicate Address Detection) and any link-layer address provided. The packet MUST then be
应检查从本地CE在AC上接收到的邻居请求，以确定并了解IPv6接口地址（如果提供，则不会出现重复地址检测）和提供的任何链路层地址。然后必须将数据包
forwarded over the pseudowire unmodified. A Neighbor Solicitation received over the pseudowire SHOULD be inspected to determine and learn an IPv6 interface address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute an appropriate link-layer address option, specifying the link-layer address of the PE interface attached to the local AC. Note that if the local AC is Ethernet, failure to substitute a link-layer address option may mean that the CE has no valid link-layer address with which to transmit data packets.
未经修改通过伪线转发。应检查通过伪线接收的邻居请求，以确定和了解远端CE的IPv6接口地址。如果存在源链路层地址选项，则PE必须将其删除。PE可以替换适当的链路层地址选项，指定连接到本地AC的PE接口的链路层地址。注意，如果本地AC是以太网，未能替换链路层地址选项可能意味着CE没有用于传输数据包的有效链路层地址。
When a PE with a local AC, which is of the type point-to-point Layer 2 circuit, e.g., FR, ATM or PPP, receives a Neighbor Solicitation from a far-end PE over the pseudowire, after learning the IP address of the far-end CE, the PE MAY use one of the following procedures:
当具有本地AC（属于点对点第2层电路类型，例如FR、ATM或PPP）的PE通过伪线从远端PE接收到邻居请求时，在学习远端CE的IP地址之后，PE可以使用以下过程之一：
1. Forward the Neighbor Solicitation to the local CE after replacing the source link-layer address with the link-layer address of the local AC.
1. 将源链路层地址替换为本地AC的链路层地址后，将邻居请求转发到本地CE。
2. Send an Inverse Neighbor Solicitation to the local CE, specifying the far-end CE's IP address and the link-layer address of the PE interface attached to local AC.
2. 向本地CE发送反向邻居请求，指定远端CE的IP地址和连接到本地AC的PE接口的链路层地址。
3. Reply to the far-end PE with a Neighbor Advertisement, using the IP address of the local CE as the source address and an appropriate link-layer address option that specifies the link-layer address of the PE interface attached to local AC. As described in Section 4.3.10, the IP address of the local CE is learned through IPv6 Control Protocol (IPv6CP) in the case of PPP and through Neighbor Solicitation in other cases.
3. 使用本地CE的IP地址作为源地址，并使用适当的链路层地址选项（该选项指定连接到本地AC的PE接口的链路层地址）通过邻居通告回复远端PE。如第4.3.10节所述，本地CE的IP地址通过IPv6控制协议学习（IPv6CP）在PPP的情况下，以及在其他情况下通过邻居征集。
A Neighbor Advertisement received on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 interface address and any link-layer address provided. The packet MUST then be forwarded over the IP pseudowire unmodified.
应检查AC上从本地CE接收的邻居公告，以确定并了解IPv6接口地址和提供的任何链路层地址。然后，数据包必须在未修改的情况下通过IP伪线转发。
A Neighbor Advertisement received over the pseudowire SHOULD be inspected to determine and learn an IPv6 interface address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute an appropriate link-layer address option, specifying the link-layer address of the PE interface attached to local AC. Note that if the local AC is Ethernet, failure to substitute a link-layer address option may mean that the local AC has no valid link-layer address with which to transmit data packets.
应检查通过伪线接收的邻居播发，以确定和了解远端CE的IPv6接口地址。如果存在源链路层地址选项，则PE必须将其删除。PE可以替换适当的链路层地址选项，指定连接到本地AC的PE接口的链路层地址。注意，如果本地AC是以太网，未能替换链路层地址选项可能意味着本地AC没有用于传输数据包的有效链路层地址。
When a PE with a local AC that is of the type point-to-point Layer 2 circuit, such as ATM, FR, or PPP, receives a Neighbor Advertisement over the pseudowire, in addition to learning the remote CE's IPv6 address, it SHOULD perform the following steps:
当具有点到点第2层电路类型的本地AC（例如ATM、FR或PPP）的PE通过伪线接收到邻居播发时，除了学习远程CE的IPv6地址外，还应执行以下步骤：
o If the AC supports Inverse Neighbor Discovery (IND) and the PE had already processed an Inverse Neighbor Solicitation (INS) from the local CE, it SHOULD send an Inverse Neighbor Advertisement (INA) on the local AC using source IP address information received in an ND advertisement (ND-ADV) and its own local AC link-layer information.
o 如果AC支持反向邻居发现（IND），并且PE已经处理了来自本地CE的反向邻居请求（INS），则它应该使用在ND播发（ND-ADV）中接收的源IP地址信息及其自己的本地AC链路层信息在本地AC上发送反向邻居播发（INA）。
o If the PE has not received any Inverse Neighbor Solicitation (INS) from the local CE and the AC supports Inverse Neighbor Discovery (IND), it SHOULD send an INS on the local AC using source IP address information received in the INA together with its own local AC link-layer information.
o 如果PE没有从本地CE接收到任何反向邻居请求（INS），并且AC支持反向邻居发现（IND），则应使用INA中接收的源IP地址信息及其自身的本地AC链路层信息在本地AC上发送INS。
An INS received on an AC from a local CE SHOULD be inspected to determine and learn the IPv6 addresses and the link-layer addresses. The packet MUST then be forwarded over the pseudowire unmodified.
应检查AC上从本地CE接收的INS，以确定并了解IPv6地址和链路层地址。然后必须在未修改的情况下通过伪线转发数据包。
An INS received over the pseudowire SHOULD be inspected to determine and learn one or more IPv6 addresses for the far-end CE. If the local AC supports IND (e.g., a switched Frame Relay AC), the packet SHOULD be forwarded to the local CE after modifying the link-layer address options to match the type of the local AC.
应检查通过伪线接收的INS，以确定和了解远端CE的一个或多个IPv6地址。如果本地AC支持IND（例如，交换帧中继AC），则在修改链路层地址选项以匹配本地AC的类型之后，分组应转发到本地CE。
If the local AC does not support IND, processing of the packet depends on whether the PE has learned at least one interface address for its directly attached CE.
如果本地AC不支持IND，则分组的处理取决于PE是否为其直接连接的CE学习了至少一个接口地址。
o If it has learned at least one IPv6 address for the CE, the PE MUST discard the Inverse Neighbor Solicitation (INS) and generate an Inverse Neighbor Advertisement (INA) back into the pseudowire. The destination address of the INA is the source address from the INS; the source address is one of the local CE's interface addresses; and all the local CE's interface addresses that have been learned so far SHOULD be included in the Target Address List. The Source and Target link-layer addresses are copied from the INS. In addition, the PE SHOULD generate ND advertisements on the local AC using the IPv6 address of the remote CE and the link-layer address of the local PE.
o 如果已经为CE读入了至少一个IPv6地址，则PE必须丢弃反向邻居请求（INS）并生成反向邻居通告（INA）返回到伪线中。INA的目标地址是INS的源地址；源地址是本地CE的接口地址之一；并且，到目前为止已了解的所有本地CE接口地址都应包括在目标地址列表中。源和目标链路层地址从INS复制。此外，PE应使用远程CE的IPv6地址和本地PE的链路层地址在本地AC上生成ND播发。
o If it has not learned at least one IPv6 and link-layer address of its directly connected CE, the INS MUST continue to be discarded until the PE learns an IPv6 and link-layer address from the local CE (through receiving, for example, a Neighbor Solicitation). After this has occurred, the PE will be able to respond to INS messages received over the pseudowire as described above.
o 如果未学习到其直接连接的CE的至少一个IPv6和链路层地址，则必须继续丢弃INS，直到PE从本地CE学习到IPv6和链路层地址（通过接收，例如，邻居请求）。发生这种情况后，PE将能够响应通过伪线接收的INS消息，如上所述。
An INA received on an AC from a local CE SHOULD be inspected to determine and learn one or more IPv6 addresses for the CE. It MUST then be forwarded unmodified over the pseudowire.
应检查AC上从本地CE接收的INA，以确定和了解CE的一个或多个IPv6地址。然后必须通过伪线将其转发而不进行修改。
An INA received over the pseudowire SHOULD be inspected to determine and learn one or more IPv6 addresses for the far-end CE.
应检查通过伪线接收的INA，以确定和了解远端CE的一个或多个IPv6地址。
If the local AC supports IND (e.g., a Frame Relay AC), the packet MAY be forwarded to the local CE after modifying the link-layer address options to match the type of the local AC.
如果本地AC支持IND（例如，帧中继AC），则在修改链路层地址选项以匹配本地AC的类型之后，分组可以被转发到本地CE。
If the local AC does not support IND, the PE MUST discard the INA and generate a Neighbor Advertisement (NA) towards its local CE. The source IPv6 address of the NA is the source IPv6 address from the INA; the destination IPv6 address is the destination IPv6 address from the INA; and the link-layer address is that of the local AC on the PE.
如果本地AC不支持IND，则PE必须丢弃INA并向其本地CE生成邻居广告（NA）。NA的源IPv6地址是来自INA的源IPv6地址；目标IPv6地址是来自INA的目标IPv6地址；链路层地址是PE上本地AC的地址。
A Router Solicitation received on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 address for the CE and, if present, the link-layer address of the CE. It MUST then be forwarded unmodified over the pseudowire.
应检查从本地CE在AC上收到的路由器请求，以确定和了解CE的IPv6地址，以及CE的链路层地址（如果存在）。然后必须通过伪线将其转发而不进行修改。
A Router Solicitation received over the pseudowire SHOULD be inspected to determine and learn an IPv6 address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute a source link-layer address option specifying the link-layer address of its local AC. The packet is then forwarded to the local CE.
应检查通过伪线接收的路由器请求，以确定和了解远端CE的IPv6地址。如果存在源链路层地址选项，则PE必须将其删除。PE可以替换指定其本地AC的链路层地址的源链路层地址选项。然后，分组被转发到本地CE。
A Router Advertisement received on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 address for the CE and, if present, the link-layer address of the CE. It MUST then be forwarded unmodified over the pseudowire.
应检查从本地CE在AC上接收的路由器广告，以确定和了解CE的IPv6地址以及CE的链路层地址（如果存在）。然后必须通过伪线将其转发而不进行修改。
A Router Advertisement received over the pseudowire SHOULD be inspected to determine and learn an IPv6 address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute a source link-layer address option specifying the link-layer address of its local AC. If an MTU option is present, the PE MAY reduce the specified MTU if the MTU of the pseudowire is less than the value specified in the option. The packet is then forwarded to the local CE.
应检查通过伪线接收到的路由器广告，以确定和了解远端CE的IPv6地址。如果存在源链路层地址选项，则PE必须将其删除。PE可以替换指定其本地AC的链路层地址的源链路层地址选项。如果存在MTU选项，则如果伪线的MTU小于该选项中指定的值，则PE可以减少指定的MTU。然后该分组被转发到本地CE。
Duplicate Address Detection [RFC4862] allows IPv6 hosts and routers to ensure that the addresses assigned to interfaces are unique on a link. As with all Neighbor Discovery packets, those used in Duplicate Address Detection will simply flow through the pseudowire, being inspected at the PEs at each end. Processing is performed as detailed in Sections 4.3.3 and 4.3.4. However, the source IPv6 address of Neighbor Solicitations used in Duplicate Address Detection is the unspecified address, so the PEs cannot learn the CE's IPv6 interface address (nor would it make sense to do so, given that at least one address is tentative at that time).
重复地址检测[RFC4862]允许IPv6主机和路由器确保分配给接口的地址在链路上是唯一的。与所有邻居发现数据包一样，用于重复地址检测的数据包将简单地流经伪线，在每一端的PEs处进行检查。按照第4.3.3节和第4.3.4节的详细说明进行处理。但是，重复地址检测中使用的邻居请求的源IPv6地址是未指定的地址，因此PEs无法了解CE的IPv6接口地址（鉴于当时至少有一个地址是暂定的，这样做也没有意义）。
The IPv6 Control Protocol (IPv6CP) [RFC5072] describes a procedure for establishing and configuring IPv6 on a point-to-point connection, including the negotiation of a link-local interface identifier. As in the case of IPv4, when such an AC is configured for IP interworking, PPP negotiation is not performed end-to-end between CE devices. Instead, PPP negotiation takes place between the CE and its local PE. The PE performs proxy PPP negotiation and informs the attached CE of the link-local identifier of its local interface using the Interface-Identifier option (0x01). This local interface identifier is used by stateless address autoconfiguration [RFC4862].
IPv6控制协议（IPv6CP）[RFC5072]描述了在点到点连接上建立和配置IPv6的过程，包括链路本地接口标识符的协商。与IPv4的情况一样，当这种AC配置为IP互通时，不会在CE设备之间端到端执行PPP协商。相反，PPP谈判在行政长官与其当地PE之间进行。PE执行代理PPP协商，并使用接口标识符选项（0x01）通知连接的CE其本地接口的链路本地标识符。此本地接口标识符由无状态地址自动配置[RFC4862]使用。
When a PPP link completes IPv6CP negotiations and the PPP link is open, a PE MAY discover the IPv6 unicast address of the CE using any of the mechanisms described above.
当PPP链路完成IPv6CP协商且PPP链路打开时，PE可使用上述任何机制发现CE的IPv6单播地址。
A PE device advertises the IPv4 address of the attached CE only when the encapsulation type of the pseudowire is IP Layer2 Transport (the value 0x000B, as defined in [RFC4446]). The IP Layer2 transport PW is also referred to as IP PW and is used interchangeably in this document. It is quite possible that the IPv4 address of a CE device
仅当伪线的封装类型为IP Layer2传输（值0x000B，如[RFC4446]中所定义）时，PE设备才会播发连接的CE的IPv4地址。IP Layer2传输PW也称为IP PW，可在本文件中互换使用。CE设备的IPv4地址很可能
is not available at the time the PW labels are signaled. For example, in Frame Relay, the CE device sends an Inverse ARP request only when the Data Link Connection Identifier (DLCI) is active. If the PE signals the DLCI to be active only when it has received the IPv4 address along with the PW Forwarding Equivalence Class (FEC) from the remote PE, a deadlock situation arises. In order to avoid such problems, the PE MUST be prepared to advertise the PW FEC before the IPv4 address of the CE is known; hence,the PE uses an IPv4 address value zero. When the IPv4 address of the CE device does become available, the PE re-advertises the PW FEC along with the IPv4 address of the CE.
在PW标签发出信号时不可用。例如，在帧中继中，CE设备仅在数据链路连接标识符（DLCI）激活时发送反向ARP请求。如果PE仅在从远程PE接收到IPv4地址和PW转发等价类（FEC）时才向DLCI发出激活信号，则会出现死锁情况。为了避免此类问题，PE必须在知道CE的IPv4地址之前准备公布PW FEC；因此，PE使用IPv4地址值零。当CE设备的IPv4地址变为可用时，PE将与CE的IPv4地址一起重新播发PW FEC。
Similarly, if the PE detects that an IP address of a CE is no longer valid (by methods described above), the PE MUST re-advertise the PW FEC with a null IP address to denote the withdrawal of the IP address of the CE. The receiving PE then waits for notification of the remote IP address. During this period, propagation of unicast IPv4 traffic is suspended, but multicast IPv4 traffic can continue to flow between the AC and the pseudowire.
类似地，如果PE检测到CE的IP地址不再有效（通过上述方法），则PE必须使用空IP地址重新通告PW FEC以指示CE的IP地址的撤回。然后，接收PE等待远程IP地址的通知。在此期间，单播IPv4流量的传播暂停，但多播IPv4流量可以继续在AC和伪线之间流动。
If two CE devices are locally attached to the PE on disparate AC types (for example, one CE connected to an Ethernet port and the other to a Frame Relay port), the IPv4 addresses are learned in the same manner as described above. However, since the CE devices are local, the distribution of IPv4 addresses for these CE devices is a local step.
如果两个CE设备在不同的AC类型上本地连接到PE（例如，一个CE连接到以太网端口，另一个连接到帧中继端口），则以与上述相同的方式读入IPv4地址。但是，由于CE设备是本地的，因此这些CE设备的IPv4地址分发是本地步骤。
Note that the PEs discover the IPv6 addresses of the remote CE by intercepting Neighbor Discovery and Inverse Neighbor Discovery packets that have been passed in-band through the pseudowire. Hence, there is no need to communicate the IPv6 addresses of the CEs through LDP signaling.
请注意，PEs通过截获已在带内通过伪线传递的邻居发现和反向邻居发现数据包来发现远程CE的IPv6地址。因此，不需要通过LDP信令来传送CEs的IPv6地址。
If the pseudowire is carrying both IPv4 and IPv6 traffic, the mechanisms used for IPv6 and IPv4 SHOULD NOT interact. In particular, just because a PE has learned a link-layer address for IPv6 traffic by intercepting a Neighbor Advertisement from its directly connected CE, it SHOULD NOT assume that it can use that link-layer address for IPv4 traffic until that fact is confirmed by reception of, for example, an IPv4 ARP message from the CE.
如果伪线同时承载IPv4和IPv6流量，则用于IPv6和IPv4的机制不应交互。具体地说，仅仅因为PE已经通过从其直接连接的CE截获邻居广告来学习IPv6通信的链路层地址，它就不应该假设它可以将该链路层地址用于IPv4通信，直到通过接收例如来自CE的IPv4 ARP消息来确认这一事实。
[RFC4447] uses Label Distribution Protocol (LDP) transport to exchange PW FECs in the Label Mapping message in the Downstream Unsolicited (DU) mode. The PW FEC comes in two flavors, with some
[RFC4447]使用标签分发协议（LDP）传输在下游未经请求（DU）模式下交换标签映射消息中的PW FEC。PW FEC有两种口味，有一些
common fields between them: PWid and Generalized ID FEC elements. The discussions below refer to these common fields for IP L2 Interworking encapsulation.
它们之间的公共字段：PWid和广义ID FEC元素。下面的讨论涉及IP L2互通封装的这些公共字段。
In addition to PW FEC, this document uses an IP Address List TLV (as defined in [RFC5036]) that is to be included in the optional parameter field of the Label Mapping message when advertising the PW FEC for the IP Layer2 Transport. The use of optional parameters in the Label Mapping message to extend the attributes of the PW FEC is specified in [RFC4447].
除PW FEC外，本文件还使用IP地址列表TLV（如[RFC5036]中所定义），在为IP层2传输播发PW FEC时，该IP地址列表TLV将包含在标签映射消息的可选参数字段中。[RFC4447]中规定了在标签映射消息中使用可选参数来扩展PW FEC的属性。
As defined in [RFC4447], when processing a received PW FEC, the PE matches the PW ID and PW type with the locally configured PW ID and PW Type. If there is a match and if the PW Type is IP Layer2 Transport, the PE further checks for the presence of an Address List TLV [RFC5036] in the optional parameter TLVs. The processing of the Address List TLV is as follows.
如[RFC4447]中所定义，当处理接收到的PW FEC时，PE将PW ID和PW类型与本地配置的PW ID和PW类型相匹配。如果存在匹配且PW类型为IP Layer2传输，则PE进一步检查可选参数TLVs中是否存在地址列表TLV[RFC5036]。地址列表TLV的处理如下所示。
o If a PE is configured for an AC to a CE enabled for IPv4 or dual-stack IPv4/IPv6, the PE SHOULD advertise an Address List TLV with address family type of IPv4 address. The PE SHOULD process the IPv4 Address List TLV as described in this document. The PE MUST advertise and process IPv6 capability using the procedures described in Section 6.
o 如果PE配置为针对IPv4或双栈IPv4/IPv6启用的AC到CE，则PE应公布地址列表TLV，地址族类型为IPv4地址。PE应按照本文档中的说明处理IPv4地址列表TLV。PE必须使用第6节中描述的程序公布和处理IPv6功能。
o If a PE does not receive any IPv4 address in the Address List TLV, it MAY assume IPv4 behavior. The address resolution for IPv4 MUST then depend on local manual configuration. In the case of mismatched configuration whereby one PE has manual configuration while the other does not, the IP address to link-layer address mapping remains unresolved, resulting in unsuccessful propagation of IPv4 traffic to the local CE.
o 如果PE在地址列表TLV中未接收到任何IPv4地址，则它可能会采取IPv4行为。IPv4的地址解析必须取决于本地手动配置。在配置不匹配的情况下，其中一个PE具有手动配置，而另一个PE没有，IP地址到链路层地址的映射仍然无法解析，从而导致IPv4流量无法成功传播到本地CE。
o If a PE is configured for an AC to a CE enabled for IPv6 only, the PE MUST advertise IPv6 capability using the procedures described in Section 6. In addition, by virtue of not setting the manual configuration for IPv4 support, IPv6-only support is realized.
o 如果PE配置为仅为IPv6启用的AC到CE，则PE必须使用第6节中描述的过程公布IPv6功能。此外，由于没有设置IPv4支持的手动配置，因此实现了仅支持IPv6。
We use the Address List TLV [RFC5036] to signal the IPv4 address of the local CE. This IP Address List TLV is included in the optional parameter field of the Label Mapping message.
我们使用地址列表TLV[RFC5036]向本地CE的IPv4地址发送信号。此IP地址列表TLV包含在标签映射消息的可选参数字段中。
The Address List TLV is only used for IPv4 addresses.
地址列表TLV仅用于IPv4地址。
The fields of the IP Address List TLV are set as follows:
IP地址列表TLV的字段设置如下：
Length Set to 6 to encompass 2 bytes of Address Family field and 4 bytes of Addresses field (because a single IPv4 address is used).
长度设置为6以包含2字节的地址族字段和4字节的地址字段（因为使用了单个IPv4地址）。
Address Family Set to 1 to indicate IPv4 as defined in [RFC5036].
地址族设置为1，表示[RFC5036]中定义的IPv4。
Addresses Contains a single IPv4 address that is the address of the CE attached to the advertising PE.
地址包含单个IPv4地址，该地址是连接到广告PE的CE的地址。
The address in the Addresses field is set to all zeros to denote that the advertising PE has not learned the IPv4 address of its local CE. Any non-zero address value denotes the IPv4 address of the advertising PE's attached CE device.
Addresses（地址）字段中的地址设置为全零，以表示广告PE尚未读入其本地CE的IPv4地址。任何非零地址值表示广告PE连接的CE设备的IPv4地址。
The IPv4 address of the CE is also supplied in the optional parameters field of the LDP Notification message along with the PW FEC. The LDP Notification message is used to signal any change in the status of the CE's IPv4 address.
CE的IPv4地址也与PW FEC一起提供在LDP通知消息的可选参数字段中。LDP通知消息用于表示CE IPv4地址状态的任何更改。
The encoding of the LDP Notification message is as follows.
LDP通知消息的编码如下所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address List TLV (as defined above) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWid FEC or Generalized ID FEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address List TLV (as defined above) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWid FEC or Generalized ID FEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status TLV status code is set to 0x0000002C "IP address of CE", to indicate that an IP address update follows. Since this notification does not refer to any particular message, the Message ID field is set to 0.
状态TLV状态代码设置为0x0000002C“CE的IP地址”，以指示随后的IP地址更新。由于此通知不引用任何特定消息，因此消息ID字段设置为0。
The PW FEC TLV SHOULD NOT include the interface parameters as they are ignored in the context of this message.
PW FEC TLV不应包括接口参数，因为在该消息的上下文中会忽略这些参数。
A Stack Capability Interface Parameter sub-TLV is signaled by the two PEs so that they can agree which network protocol(s) they SHOULD be using. As discussed earlier, the use of the Address List TLV signifies support for IPv4 stack, so the Stack Capability Interface Parameter sub-TLV is used to indicate whether support for IPv6 stack is required on a given IP PW.
堆栈能力接口参数sub TLV由两个PEs发出信号，以便他们能够商定应使用的网络协议。如前所述，使用地址列表TLV表示支持IPv4堆栈，因此堆栈能力接口参数sub TLV用于指示给定IP PW上是否需要支持IPv6堆栈。
The Stack Capability Interface Parameter sub-TLV is part of the interface parameters. The proposed format for the Stack Capability Interface Parameter sub-TLV is as follows:
堆栈能力接口参数sub TLV是接口参数的一部分。Stack Capability Interface Parameter sub 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Length | Stack Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Length | Stack Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter ID = 0x16
参数ID=0x16
Length = 4
Length = 4
The Stack Capability field is a bit field. Only one bit is defined in this document. When bit zero (the least significant bit with bitmask 0x0001) is set, it indicates IPv6 Stack Capability.
堆栈能力字段是位字段。本文档中仅定义了一位。设置位0（位掩码为0x0001的最低有效位）时，表示IPv6堆栈能力。
The presence of the Stack Capability Interface Parameter sub-TLV is relevant only when the PW type is IP PW. A PE that supports IPv6 on an IP PW MUST signal the Stack Capability Interface Parameter sub-TLV in the initial Label Mapping message for the PW. The PE nodes compare the value advertised by the remote PE with the local configuration and only use a capability that is supported by both.
只有当PW类型为IP PW时，堆栈能力接口参数sub TLV的存在才相关。在IP PW上支持IPv6的PE必须在PW的初始标签映射消息中向堆栈能力接口参数sub TLV发送信号。PE节点将远程PE公布的值与本地配置进行比较，并仅使用两者都支持的功能。
The behavior of a PE that does not understand an Interface Parameter sub-TLV is specified in Section 5.5 of RFC 4447 [RFC4447].
RFC 4447[RFC4447]第5.5节规定了不理解接口参数sub TLV的PE的行为。
In some deployment scenarios, it may be desirable to take a PW operationally down if there is a mismatch of the Stack Capability between the PEs. In other deployment scenarios, an operator may wish the IP version supported by both PEs to fall back to IPv4 if one of the PEs does not support IPv6. The following procedures MUST be followed for each of these cases.
在某些部署场景中，如果PEs之间的堆栈能力不匹配，可能需要在操作上关闭PW。在其他部署场景中，如果其中一个PEs不支持IPv6，则运营商可能希望两个PEs支持的IP版本退回到IPv4。每种情况都必须遵循以下程序。
If a PE that supports IPv6 and has not yet sent a Label Mapping message receives an initial Label Mapping message from the far-end PE that does not include the Stack Capability Interface Parameter sub-TLV, or one is received but it is not set to the 'IPv6 Stack Capability' value, then the PE supporting this procedure MUST NOT send a Label Mapping message for this PW.
如果支持IPv6且尚未发送标签映射消息的PE从远端PE接收到初始标签映射消息，该消息不包括堆栈能力接口参数sub TLV，或者接收到一条，但未将其设置为“IPv6堆栈能力”值，则支持此过程的PE不得为此PW发送标签映射消息。
If a PE that supports IPv6 has already sent an initial Label Mapping message for the PW and does not receive a Stack Capability Interface Parameter sub-TLV in the Label Mapping message from the far-end PE, or one is received but it is not set to 'IPv6 Stack Capability', the PE supporting this procedure MUST withdraw its PW label with the LDP status code meaning "IP Address type mismatch" (Status Code 0x0000004A). However, subsequently, if the configuration was to change at the far-end PE and a Stack Capability Interface Parameter sub-TLV in the Label Mapping message is received from the far-end PE, the local PE MUST re-advertise the Label Mapping message for the PW.
如果支持IPv6的PE已经为PW发送了初始标签映射消息，并且在来自远端PE的标签映射消息中没有接收到堆栈能力接口参数sub TLV，或者接收到一个，但未将其设置为“IPv6堆栈能力”，支持此过程的PE必须撤回其带有LDP状态代码的PW标签，表示“IP地址类型不匹配”（状态代码0x0000004A）。但是，随后，如果在远端PE更改配置，并且从远端PE接收到标签映射消息中的堆栈能力接口参数sub TLV，则本地PE必须重新公布PW的标签映射消息。
If a PE that supports IPv6 and has not yet sent a Label Mapping message receives an initial Label Mapping message from the far-end PE that does not include the Stack Capability Interface Parameter sub-TLV, or one is received but it is not set to the 'IPv6 Stack Capability' value, then it MAY send a Label Mapping message for this PW but MUST NOT include the Stack Capability Interface Parameter sub-TLV.
如果支持IPv6且尚未发送标签映射消息的PE从远端PE接收到初始标签映射消息，该消息不包括堆栈能力接口参数sub TLV，或者接收到一条，但未将其设置为“IPv6堆栈能力”值，然后，它可以为此PW发送标签映射消息，但不得包括堆栈能力接口参数sub TLV。
If a PE that supports IPv6 and has already sent a Label Mapping message for the PW with the Stack Capability Interface Parameter sub-TLV but does not receive a Stack Capability Interface Parameter sub-TLV from the far-end PE in the initial Label Mapping message (or one is received but it is not set to the 'IPv6 Stack Capability' value), the PE following this procedure MUST send a Label Withdraw for its PW label with the LDP status code meaning "Wrong IP Address type" (Status Code 0x000004B) followed by a Label Mapping message that does not include the Stack Capability Interface Parameter sub-TLV. If a Label Withdraw message with the "Wrong IP Address Type" status code is received by a PE, it SHOULD treat this as a normal Label Withdraw but MUST NOT respond with a Label Release. It MUST continue to wait for the next control message for the PW as specified in Section 6.2 of RFC 4447 [RFC4447].
如果支持IPv6且已使用堆栈能力接口参数sub-TLV为PW发送标签映射消息的PE在初始标签映射消息中未从远端PE接收堆栈能力接口参数sub-TLV（或接收到一个但未设置为“IPv6堆栈能力”值），遵循此过程的PE必须为其PW标签发送一个标签撤销，LDP状态代码表示“错误的IP地址类型”（状态代码0x000004B），后跟一个不包括堆栈能力接口参数sub TLV的标签映射消息。如果PE收到带有“错误IP地址类型”状态代码的标签撤销消息，则应将其视为正常的标签撤销，但不得以标签释放响应。必须按照RFC 4447[RFC4447]第6.2节的规定，继续等待PW的下一条控制消息。
This document uses new LDP status codes. IANA already maintains a registry of name "Status Code Name Space" defined by [RFC5036]. The following values have been assigned:
本文件使用新的LDP状态码。IANA已经维护了由[RFC5036]定义的名称“状态代码名称空间”的注册表。已指定以下值：
0x0000002C "IP Address of CE" 0x0000004A "IP Address Type Mismatch" 0x0000004B "Wrong IP Address Type"
CE的0x0000002C“IP地址”0x0000004A“IP地址类型不匹配”0x0000004B“错误的IP地址类型”
This document proposes a new Interface Parameters sub-TLV, that has been assigned from the 'Pseudowire Interface Parameters Sub-TLV type Registry'. The following value has been assigned for the Parameter ID:
本文档提出了一个新的接口参数子TLV，该子TLV已从“伪线接口参数子TLV类型注册表”分配。已为参数ID指定以下值：
0x16 "Stack Capability"
0x16“堆栈能力”
IANA has also set up a registry of "L2VPN PE stack Capabilities". This is a 16-bit field. Stack Capability bitmask 0x0001 is specified in Section 6 of this document. The remaining bitfield values (0x0002,..,0x8000) are to be assigned by IANA using the "IETF Review" policy defined in [RFC5226].
IANA还建立了“L2VPN PE堆栈功能”注册表。这是一个16位字段。堆栈功能位掩码0x0001在本文档第6节中有规定。IANA将使用[RFC5226]中定义的“IETF审查”策略分配剩余的位字段值（0x0002，…，0x8000）。
L2VPN PE Stack Capabilities:
L2VPN PE堆栈功能：
Bit (Value) Description
=============== ========================
Bit 0 (0x0001) - IPv6 stack capability
Bit 1 (0x0002) - Unassigned
Bit 2 (0x0004) - Unassigned
.
.
.
Bit (Value) Description
=============== ========================
Bit 0 (0x0001) - IPv6 stack capability
Bit 1 (0x0002) - Unassigned
Bit 2 (0x0004) - Unassigned
.
.
.
Bit 14 (0x4000) - Unassigned Bit 15 (0x8000) - Unassigned
位14（0x4000）-未分配位15（0x8000）-未分配
The security aspect of this solution is addressed for two planes: the control plane and the data plane.
此解决方案的安全方面针对两个平面：控制平面和数据平面。
Control plane security pertains to establishing the LDP connection and to pseudowire signaling and CE IP address distribution over that LDP connection. For greater security, the LDP connection between two trusted PEs MUST be secured by each PE verifying the incoming connection against the configured address of the peer and authenticating the LDP messages, as described in Section 2.9 of [RFC5036]. Pseudowire signaling between two secure LDP peers does not pose a security issue but mis-wiring could occur due to configuration error. However, the fact that the pseudowire will only be established if the two PEs have matching configurations (e.g., PW ID, PW type, and MTU) provides some protection against mis-wiring due to configuration errors.
控制平面安全性涉及建立LDP连接以及在该LDP连接上的伪线信令和CE IP地址分配。为了获得更高的安全性，两个受信任的PE之间的LDP连接必须由每个PE根据对等方的配置地址验证传入连接，并验证LDP消息，如[RFC5036]第2.9节所述。两个安全LDP对等点之间的伪线信令不会造成安全问题，但由于配置错误，可能会发生错误连接。然而，只有当两个PEs具有匹配配置（例如PW ID、PW类型和MTU）时，才会建立伪线，这一事实为防止由于配置错误而导致的错误接线提供了一些保护。
Learning the IP address of the appropriate CE can be a security issue. It is expected that the Attachment Circuit to the local CE will be physically secured. If this is a concern, the PE MUST be configured with the IP and MAC address of the CE when connected with Ethernet, IP and virtual circuit information (DLCI or VPI/VCI (Virtual Path Identifier / Virtual Circuit Identifier) when connected over Frame Relay or ATM, and IP address only when connected over PPP. During ARP/Inverse ARP frame processing, the PE MUST verify the received information against local configuration before forwarding the information to the remote PE to protect against hijacking of the connection.
了解相应CE的IP地址可能是一个安全问题。预计本地CE的连接电路将得到物理保护。如果这是一个问题，则PE在与以太网、IP和虚拟电路信息（DLCI或VPI/VCI（虚拟路径标识符/虚拟电路标识符））连接时必须配置CE的IP和MAC地址当通过帧中继或ATM连接时，IP地址仅在通过PPP连接时。在ARP/反向ARP帧处理期间，PE必须根据本地配置验证接收到的信息，然后再将信息转发给远程PE，以防止连接被劫持。
For IPv6, the preferred means of security is Secure Neighbor Discovery (SEND) [RFC3971]. SEND provides a mechanism for securing Neighbor Discovery packets over media (such as wireless links) that may be insecure and open to packet interception and substitution. SEND is based upon cryptographic signatures of Neighbor Discovery packets. These signatures allow the receiving node to detect packet modification and confirm that a received packet originated from the claimed source node. SEND is incompatible with the Neighbor Discovery packet modifications described in this document. As such, SEND cannot be used for Neighbor Discovery across an ARP Mediation pseudowire. PEs taking part in IPv6 ARP Mediation MUST remove all SEND packet options from Neighbor Discovery packets before forwarding into the pseudowire. If the CE devices are configured to accept only SEND Neighbor Discovery packets, Neighbor Discovery will fail. Thus, the CE devices MUST be configured to accept non-SEND packets, even if they treat them with lower priority than SEND packets. Because SEND cannot be used in combination with IPv6 ARP Mediation, it is suggested that IPv6 ARP Mediation only be used with secure Attachment Circuits. An exception to this recommendation applies to an implementation that supports the SEND Proxy [RFC6496], which allows a device such as PE to act as an ND proxy as described in [RFC6496].
对于IPv6，首选的安全方法是安全邻居发现（SEND）[RFC3971]。SEND提供了一种通过可能不安全且容易被数据包截获和替换的媒体（如无线链路）保护邻居发现数据包的机制。发送基于邻居发现数据包的加密签名。这些签名允许接收节点检测数据包修改，并确认接收到的数据包来自所声称的源节点。SEND与本文档中描述的邻居发现数据包修改不兼容。因此，SEND不能用于通过ARP调解伪线发现邻居。参与IPv6 ARP中介的PE必须在转发到伪线之前从邻居发现数据包中删除所有发送数据包选项。如果CE设备配置为仅接受发送邻居发现数据包，则邻居发现将失败。因此，CE设备必须被配置为接受非发送分组，即使它们以低于发送分组的优先级对待它们。由于SEND不能与IPv6 ARP中介结合使用，因此建议IPv6 ARP中介仅与安全连接电路一起使用。本建议的例外情况适用于支持发送代理[RFC6496]的实现，该实现允许PE等设备充当[RFC6496]中所述的ND代理。
The data traffic between CE and PE is not encrypted, and it is possible that in an insecure environment, a malicious user may tap into the CE-to-PE connection and generate traffic using the spoofed destination MAC address on the Ethernet Attachment Circuit. In order to avoid such hijacking, the local PE may verify the source MAC address of the received frame against the MAC address of the admitted connection. The frame is forwarded to the PW only when authenticity is verified. When spoofing is detected, the PE MUST sever the connection with the local CE, tear down the PW, and start over.
CE和PE之间的数据通信未加密，并且在不安全的环境中，恶意用户可能会侵入CE到PE连接，并使用以太网连接电路上伪造的目标MAC地址生成通信。为了避免这种劫持，本地PE可以对照所允许的连接的MAC地址来验证所接收帧的源MAC地址。只有在验证真实性时，帧才会转发到PW。当检测到欺骗时，PE必须断开与本地CE的连接，拆除PW，然后重新启动。
The authors would like to thank Yetik Serbest, Prabhu Kavi, Bruce Lasley, Mark Lewis, Carlos Pignataro, and others who participated in the discussions related to this document.
作者要感谢Yetik Serbest、Prabhu Kavi、Bruce Lasley、Mark Lewis、Carlos Pignataro和其他参与本文件相关讨论的人。
This document is the combined effort of many who have contributed, carefully reviewed, and provided technical clarifications. This includes the individuals listed in this section and those listed in the Editors' Addresses.
本文件是许多人的共同努力，他们做出了贡献，仔细审查并提供了技术澄清。这包括本节中列出的个人和编辑地址中列出的个人。
Matthew Bocci Alcatel-Lucent EMail: Mathew.bocci@alcatel-lucent.com
Matthew Bocci Alcatel-Lucent电子邮件：Mathew。bocci@alcatel-朗讯网
Tiberiu Grigoriu Alcatel-Lucent EMail: Tiberiu.Grigoriu@alcatel-lucent.com
提比略·格里戈里奥·阿尔卡特·朗讯电子邮件：提比略。Grigoriu@alcatel-朗讯网
Neil Hart Alcatel-Lucent EMail: Neil.Hart@alcatel-lucent.com
尼尔·哈特·阿尔卡特·朗讯电子邮件：尼尔。Hart@alcatel-朗讯网
Andrew Dolganow Alcatel-Lucent EMail: Andrew.Dolganow@alcatel-lucent.com
安德鲁·多尔加诺·阿尔卡特·朗讯电子邮件：安德鲁。Dolganow@alcatel-朗讯网
Shane Amante Level 3 EMail: Shane@castlepoint.net
Shane Amante三级电子邮件：Shane@castlepoint.net
Toby Smith Google EMail: tob@google.com
Toby Smith谷歌邮箱：tob@google.com
Andrew G. Malis Verizon EMail: Andy.g.Malis@verizon.com
Andrew G.Malis Verizon电子邮件：Andy.G。Malis@verizon.com
Steven Wright Bell South Corp EMail: steven.wright@bellsouth.com
史蒂文·赖特·贝尔南方公司电子邮件：史蒂文。wright@bellsouth.com
Waldemar Augustyn Consultant EMail: waldemar@wdmsys.com
Waldemar Augustyn顾问电子邮件：waldemar@wdmsys.com
Arun Vishwanathan Juniper Networks EMail: arunvn@juniper.net
Arun Vishwanathan Juniper Networks电子邮件：arunvn@juniper.net
Ashwin Moranganti IneoQuest Technologies EMail: Ashwin.Moranganti@Ineoquest.com
Ashwin Moranganti IneoQuest Technologies电子邮件：Ashwin。Moranganti@Ineoquest.com
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC2390] Bradley, T., Brown, C., and A. Malis, "Inverse Address Resolution Protocol", RFC 2390, September 1998.
[RFC2390]Bradley，T.，Brown，C.和A.Malis，“反向地址解析协议”，RFC 23901998年9月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446]Martini，L.，“伪线边到边仿真（PWE3）的IANA分配”，BCP 116，RFC 4446，2006年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, June 2001.
[RFC3122]Conta，A.，“反向发现规范对IPv6邻居发现的扩展”，RFC3122，2001年6月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664]Andersson，L.，Ed.，和E.Rosen，Ed.，“第二层虚拟专用网络（L2VPN）框架”，RFC 4664，2006年9月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC1332，1992年5月。
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[RFC5072]Varada，S.，Ed.，Haskins，D.，和E.Allen，“PPP上的IP版本6”，RFC 5072，2007年9月。
[RFC925] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984.
[RFC925]Postel，J.，“多局域网地址解析”，RFC 925，1984年10月。
[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256]迪林，S.，编辑，“ICMP路由器发现消息”，RFC1256，1991年9月。
[RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC 5309, October 2008.
[RFC5309]Shen，N.，Ed.，和A.Zinin，Ed.，“链路状态路由协议下局域网上的点对点操作”，RFC 5309，2008年10月。
[RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-Martinez, "Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)", RFC 6496, February 2012.
[RFC6496]Krishnan，S.，Laganier，J.，Bonola，M.，和A.Garcia Martinez，“安全代理和支持安全邻居发现（SEND）”，RFC 64962012年2月。
In an IP L2 interworking L2VPN, when an IGP on a CE connected to a broadcast link is cross-connected with an IGP on a CE connected to a point-to-point link, there are routing protocol related issues that MUST be addressed. The link state routing protocols are cognizant of the underlying link characteristics and behave accordingly when establishing neighbor adjacencies, representing the network topology, and passing protocol packets. The point-to-point operations of the routing protocols over a LAN are discussed in [RFC5309].
在IP L2互通L2VPN中，当连接到广播链路的CE上的IGP与连接到点到点链路的CE上的IGP交叉连接时，必须解决与路由协议相关的问题。链路状态路由协议了解底层链路特征，并在建立邻居邻接、表示网络拓扑和传递协议数据包时相应地进行行为。局域网上路由协议的点对点操作在[RFC5309]中进行了讨论。
The OSPF protocol treats a broadcast link type with a special procedure that engages in Neighbor Discovery to elect a designated router and a backup designated router (DR and BDR, respectively), with which each other router on the link forms adjacencies. However, these procedures are neither applicable nor understood by OSPF running on a point-to-point link. By cross-connecting two neighbors with disparate link types, an IP L2 interworking L2VPN may experience connectivity issues.
OSPF协议使用特殊程序处理广播链路类型，该程序参与邻居发现，以选择指定路由器和备份指定路由器（分别为DR和BDR），链路上的每个路由器与之形成邻接。然而，在点到点链路上运行的OSPF既不适用也不理解这些程序。通过交叉连接两个具有不同链路类型的邻居，IP L2互通L2VPN可能会遇到连接问题。
Additionally, the link type specified in the router Link State Advertisement (LSA) will not match for the two cross-connected routers.
此外，路由器链路状态通告（LSA）中指定的链路类型对于两个交叉连接的路由器不匹配。
Finally, each OSPF router generates network LSAs when connected to a broadcast link such as Ethernet, receipt of which by an OSPF router that believes itself to be connected to a point-to-point link further adds to the confusion.
最后，每个OSPF路由器在连接到诸如以太网的广播链路时生成网络LSA，而认为自己连接到点到点链路的OSPF路由器接收到该网络LSA进一步增加了混淆。
Fortunately, the OSPF protocol provides a configuration option (ospfIfType) whereby OSPF will treat the underlying physical broadcast link as a point-to-point link.
幸运的是，OSPF协议提供了一个配置选项（ospfIfType），OSPF将根据该选项将底层物理广播链路视为点对点链路。
It is strongly recommended that all OSPF protocols on CE devices connected to Ethernet interfaces use this configuration option when attached to a PE that is participating in an IP L2 Interworking VPN.
强烈建议连接到以太网接口的CE设备上的所有OSPF协议在连接到参与IP L2互通VPN的PE时使用此配置选项。
The RIP protocol broadcasts RIP advertisements every 30 seconds. If the multicast/broadcast traffic snooping mechanism is used as described in Section 4.1, the attached PE can learn the local CE router's IP address from the IP header of its advertisements. No special configuration is required for RIP in this type of Layer 2 IP Interworking L2VPN.
RIP协议每30秒广播一次RIP广告。如果如第4.1节所述使用多播/广播流量监听机制，则连接的PE可以从其播发的IP报头中学习本地CE路由器的IP地址。在这种类型的第2层IP互通L2VPN中，RIP不需要特殊配置。
The IS-IS protocol does not encapsulate its PDUs in IP; hence, it cannot be supported in IP L2 Interworking L2VPNs.
IS-IS协议没有将其PDU封装在IP中；因此，IP L2互通L2VPN中不支持它。
Editors' Addresses
编辑地址
Himanshu Shah (editor) Ciena EMail: hshah@ciena.com
Himanshu Shah（编辑）Ciena电子邮件：hshah@ciena.com
Eric Rosen (editor) Cisco Systems EMail: erosen@cisco.com
Eric Rosen（编辑）思科系统电子邮件：erosen@cisco.com
Giles Heron (editor) Cisco Systems EMail: giheron@cisco.com
Giles Heron（编辑）思科系统电子邮件：giheron@cisco.com
Vach Kompella (editor) Alcatel-Lucent EMail: vach.kompella@alcatel-lucent.com
Vach Kompella（编辑）阿尔卡特朗讯电子邮件：Vach。kompella@alcatel-朗讯网