Network Working Group J. De Clercq
Request for Comments: 4659 Alcatel
Category: Standards Track D. Ooms
OneSparrow
M. Carugi
Nortel Networks
F. Le Faucheur
Cisco Systems
September 2006
Network Working Group J. De Clercq
Request for Comments: 4659 Alcatel
Category: Standards Track D. Ooms
OneSparrow
M. Carugi
Nortel Networks
F. Le Faucheur
Cisco Systems
September 2006
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
用于IPv6 VPN的BGP-MPLS IP虚拟专用网（VPN）扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for support of IPv6. In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP".
本文档描述了一种方法，通过该方法，服务提供商可以使用其分组交换主干网为其IPv6客户提供虚拟专用网（VPN）服务。此方法重用并在必要时扩展“BGP/MPLS IP VPN”方法以支持IPv6。在BGP/MPLS IP VPN中，“多协议BGP”用于在服务提供商主干上分发IPv4 VPN路由，MPLS用于在主干上转发IPv4 VPN数据包。本文档定义了IPv6 VPN地址系列，并在“多协议BGP”中描述了相应的IPv6 VPN路由分布。
This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document.
本文档定义了对IPv4和IPv6主干上的IPv6 VPN服务的支持，以及对在核心上使用各种隧道技术的支持，包括MPLS、IP-in-IP、通用路由封装（GRE）和受IPsec保护的隧道。IPv4站点和IPv6站点之间的互通不在本文档的范围内。
Table of Contents
目录
1. Introduction ....................................................2
2. The VPN-IPv6 Address Family .....................................4
3. VPN-IPv6 Route Distribution .....................................5
3.1. Route Distribution Among PEs by BGP ........................5
3.2. VPN IPv6 NLRI Encoding .....................................6
3.2.1. BGP Next Hop encoding ...............................6
3.2.1.1. BGP Speaker Requesting IPv6 Transport ......7
3.2.1.2. BGP Speaker Requesting IPv4 Transport ......8
3.3. Route Target ...............................................8
3.4. BGP Capability Negotiation .................................8
4. Encapsulation ...................................................8
5. Address Types ..................................................10
6. Multicast ......................................................11
7. Carriers' Carriers .............................................11
8. Multi-AS Backbones .............................................11
9. Accessing the Internet from a VPN ..............................13
10. Management VPN ................................................14
11. Security Considerations .......................................14
12. Quality of Service ............................................15
13. Scalability ...................................................15
14. IANA Considerations ...........................................15
15. Acknowledgements ..............................................15
16. References ....................................................16
16.1. Normative References .....................................16
16.2. Informative References ...................................16
1. Introduction ....................................................2
2. The VPN-IPv6 Address Family .....................................4
3. VPN-IPv6 Route Distribution .....................................5
3.1. Route Distribution Among PEs by BGP ........................5
3.2. VPN IPv6 NLRI Encoding .....................................6
3.2.1. BGP Next Hop encoding ...............................6
3.2.1.1. BGP Speaker Requesting IPv6 Transport ......7
3.2.1.2. BGP Speaker Requesting IPv4 Transport ......8
3.3. Route Target ...............................................8
3.4. BGP Capability Negotiation .................................8
4. Encapsulation ...................................................8
5. Address Types ..................................................10
6. Multicast ......................................................11
7. Carriers' Carriers .............................................11
8. Multi-AS Backbones .............................................11
9. Accessing the Internet from a VPN ..............................13
10. Management VPN ................................................14
11. Security Considerations .......................................14
12. Quality of Service ............................................15
13. Scalability ...................................................15
14. IANA Considerations ...........................................15
15. Acknowledgements ..............................................15
16. References ....................................................16
16.1. Normative References .....................................16
16.2. Informative References ...................................16
This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network services for its IPv6 customers.
本文档描述了一种方法，通过该方法，服务提供商可以使用其分组交换主干网为其IPv6客户提供虚拟专用网络服务。
This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method [BGP/MPLS-VPN] for support of IPv6. In particular, this method uses the same "peer model" as [BGP/MPLS-VPN], in which the customers' edge routers ("CE routers") send their IPv6 routes to the Service Provider's edge routers ("PE routers"). BGP ("Border Gateway Protocol", [BGP, BGP-MP]) is then used by the Service Provider to exchange the routes of a particular IPv6 VPN among the PE routers that are attached to that IPv6 VPN. Eventually, the PE routers distribute, to the CE routers in a particular VPN, the IPv6 routes from other CE routers in that VPN. As with IPv4 VPNs, a key characteristic of this "peer model" is that the (IPv6) CE routers within an (IPv6) VPN do not peer with each other; there is no "overlay" visible to the (IPv6) VPN's routing algorithm.
此方法重用并在必要时扩展“BGP/MPLS IP VPN”方法[BGP/MPLS-VPN]，以支持IPv6。具体而言，该方法使用与[BGP/MPLS-VPN]相同的“对等模型”，其中客户的边缘路由器（“CE路由器”）将其IPv6路由发送到服务提供商的边缘路由器（“PE路由器”）。然后，服务提供商使用BGP（“边界网关协议”[BGP，BGP-MP]）在连接到该IPv6 VPN的PE路由器之间交换特定IPv6 VPN的路由。最终，PE路由器将来自该VPN中其他CE路由器的IPv6路由分配给特定VPN中的CE路由器。与IPv4 VPN一样，这种“对等模型”的一个关键特征是，（IPv6）VPN中的（IPv6）CE路由器不相互对等；（IPv6）VPN的路由算法看不到“覆盖”。
This document adopts the definitions, acronyms, and mechanisms described in [BGP/MPLS-VPN]. Unless it is stated otherwise, the mechanisms of [BGP/MPLS-VPN] apply and will not be re-described here.
本文件采用[BGP/MPLS-VPN]中描述的定义、首字母缩略词和机制。除非另有说明，[BGP/MPLS-VPN]的机制适用，此处不再重新描述。
A VPN is said to be an IPv6 VPN when each site of this VPN is IPv6 capable and is natively connected over an IPv6 interface or sub-interface to the Service Provider (SP) backbone via a Provider Edge device (PE).
如果VPN的每个站点都支持IPv6，并且通过IPv6接口或子接口通过提供商边缘设备（PE）与服务提供商（SP）主干网进行本机连接，则称VPN为IPv6 VPN。
A site may be both IPv4 capable and IPv6 capable. The logical interface on which packets arrive at the PE may determine the IP version. Alternatively, the same logical interface may be used for both IPv4 and IPv6, in which case a per-packet lookup at the Version field of the IP packet header determines the IP version.
站点可以同时支持IPv4和IPv6。数据包到达PE的逻辑接口可以确定IP版本。或者，相同的逻辑接口可用于IPv4和IPv6，在这种情况下，IP分组报头的版本字段处的每个分组查找确定IP版本。
This document only concerns itself with handling of IPv6 communication between IPv6 hosts located on IPv6-capable sites. Handling of IPv4 communication between IPv4 hosts located on IPv4- capable sites is outside the scope of this document and is covered in [BGP/MPLS-VPN]. Communication between an IPv4 host located in an IPv4- capable site and an IPv6 host located in an IPv6-capable site is outside the scope of this document.
本文档仅涉及位于支持IPv6的站点上的IPv6主机之间IPv6通信的处理。位于支持IPv4的站点上的IPv4主机之间IPv4通信的处理不在本文档的范围内，并在[BGP/MPLS-VPN]中介绍。位于支持IPv4的站点中的IPv4主机与位于支持IPv6的站点中的IPv6主机之间的通信不在本文档的范围内。
In a similar manner to how IPv4 VPN routes are distributed in [BGP/MPLS-VPN], BGP and its extensions are used to distribute routes from an IPv6 VPN site to all the other PE routers connected to a site of the same IPv6 VPN. PEs use "VPN Routing and Forwarding tables" (VRFs) to maintain the reachability information and forwarding information of each IPv6 VPN separately.
与[BGP/MPLS-VPN]中IPv4 VPN路由的分布方式类似，BGP及其扩展用于将路由从IPv6 VPN站点分布到连接到同一IPv6 VPN站点的所有其他PE路由器。PEs使用“VPN路由和转发表”（VRF）分别维护每个IPv6 VPN的可达性信息和转发信息。
As is done for IPv4 VPNs [BGP/MPLS-VPN], we allow each IPv6 VPN to have its own IPv6 address space, which means that a given address may denote different systems in different VPNs. This is achieved via a new address family, the VPN-IPv6 Address Family, in a fashion similar to that of the VPN-IPv4 address family, defined in [BGP/MPLS-VPN], which prepends a Route Distinguisher to the IP address.
与IPv4 VPN[BGP/MPLS-VPN]一样，我们允许每个IPv6 VPN拥有自己的IPv6地址空间，这意味着给定的地址可能表示不同VPN中的不同系统。这是通过一个新的地址系列，即VPN-IPv6地址系列，以类似于[BGP/MPLS-VPN]中定义的VPN-IPv4地址系列的方式实现的，该地址系列为IP地址预先添加了一个路由识别器。
In addition to its operation over MPLS Label Switched Paths (LSPs), the IPv4 BGP/MPLS VPN solution has been extended to allow operation over other tunneling techniques, including GRE tunnels, IP-in-IP tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3], and IPsec protected tunnels [2547-IPsec]. In a similar manner, this document allows support of an IPv6 VPN service over MPLS LSPs, as well as over other tunneling techniques.
除了通过MPLS标签交换路径（LSP）进行操作外，IPv4 BGP/MPLS VPN解决方案还被扩展以允许通过其他隧道技术进行操作，包括GRE隧道、IP隧道中的IP[2547-GRE/IP]、L2TPv3隧道[MPLS-In-L2TPv3]和IPsec保护的隧道[2547 IPsec]。以类似的方式，本文档允许通过MPLS LSP以及其他隧道技术支持IPv6 VPN服务。
This document allows support for an IPv6 VPN service over an IPv4 backbone, as well as over an IPv6 backbone. The IPv6 VPN service supported is identical in both cases.
本文档允许通过IPv4主干以及IPv6主干支持IPv6 VPN服务。在这两种情况下，支持的IPv6 VPN服务是相同的。
The IPv6 VPN solution defined in this document offers the following benefits:
本文档中定义的IPv6 VPN解决方案具有以下优点：
o From both the Service Provider perspective and the customer perspective, the VPN service that can be supported for IPv6 sites is identical to the one that can be supported for IPv4 sites.
o 从服务提供商和客户的角度来看，IPv6站点可以支持的VPN服务与IPv4站点可以支持的VPN服务相同。
o From the Service Provider perspective, operations of the IPv6 VPN service require the exact same skills, procedures, and mechanisms as those for the IPv4 VPN service.
o 从服务提供商的角度来看，IPv6 VPN服务的操作需要与IPv4 VPN服务完全相同的技能、过程和机制。
o Where both IPv4 VPNs and IPv6 VPN services are supported over an IPv4 core, the same single set of MP-BGP peering relationships and the same single PE-PE tunnel mesh MAY be used for both.
o 在IPv4核心上同时支持IPv4 VPN和IPv6 VPN服务的情况下，同一组MP-BGP对等关系和同一个PE-PE隧道网格可用于这两种服务。
o The IPv6 VPN service is independent of whether the core runs IPv4 or IPv6. This is so that the IPv6 VPN service supported before and after a migration of the core from IPv4 to IPv6 is undistinguishable to the VPN customer.
o IPv6 VPN服务独立于核心是运行IPv4还是IPv6。这使得VPN客户无法区分核心从IPv4迁移到IPv6前后支持的IPv6 VPN服务。
Note that supporting IPv4 VPN services over an IPv6 core is not covered by this document.
请注意，本文档不包括通过IPv6核心支持IPv4 VPN服务。
The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes from multiple "address families". We introduce the notion of the "VPN-IPv6 address family", which is similar to the VPN-IPv4 address family introduced in [BGP/MPLS-VPN].
BGP多协议扩展[BGP-MP]允许BGP承载来自多个“地址族”的路由。我们引入了“VPN-IPv6地址族”的概念，它类似于[BGP/MPLS-VPN]中引入的VPN-IPv4地址族。
A VPN-IPv6 address is a 24-octet quantity, beginning with an 8-octet "Route Distinguisher" (RD) and ending with a 16-octet IPv6 address.
VPN-IPv6地址是24个八位字节的数量，从8个八位字节的“路由区分器”（RD）开始，以16个八位字节的IPv6地址结束。
The purpose of the RD is solely to allow one to create distinct routes to a common IPv6 address prefix, which is similar to the purpose of the RD defined in [BGP/MPLS-VPN]. In the same way as it is possible per [BGP/MPLS-VPN], the RD can be used to create multiple different routes to the very same system. This can be achieved by creating two different VPN-IPv6 routes that have the same IPv6 part but different RDs. This allows the provider's BGP to install multiple different routes to the same system and allows policy to be used to decide which packets use which route.
RD的目的仅仅是允许用户创建到公共IPv6地址前缀的不同路由，这与[BGP/MPLS-VPN]中定义的RD的目的类似。通过与[BGP/MPLS-VPN]相同的方式，RD可用于创建到同一系统的多条不同路由。这可以通过创建具有相同IPv6部分但不同RDs的两个不同VPN-IPv6路由来实现。这允许提供商的BGP将多个不同的路由安装到同一系统，并允许使用策略来决定哪些数据包使用哪个路由。
Also, if two VPNs were to use the same IPv6 address prefix (effectively denoting different physical systems), the PEs would translate these into unique VPN-IPv6 address prefixes using different RDs. This ensures that if the same address is ever used in two different VPNs, it is possible to install two completely different routes to that address, one for each VPN.
此外，如果两个VPN使用相同的IPv6地址前缀（有效地表示不同的物理系统），PEs将使用不同的RDs将其转换为唯一的VPN-IPv6地址前缀。这确保了如果在两个不同的VPN中使用相同的地址，则可以为该地址安装两条完全不同的路由，每个VPN一条。
Since VPN-IPv6 addresses and IPv6 addresses belong to different address families, BGP never treats them as comparable addresses.
由于VPN-IPv6地址和IPv6地址属于不同的地址系列，BGP从不将它们视为可比较的地址。
A VRF may have multiple equal-cost VPN-IPv6 routes for a single IPv6 address prefix. When a packet's destination address is matched in a VRF against a VPN-IPv6 route, only the IPv6 part is actually matched.
对于单个IPv6地址前缀，VRF可能具有多个等成本VPN-IPv6路由。当数据包的目标地址在VRF中与VPN-IPv6路由匹配时，只有IPv6部分实际匹配。
The Route Distinguisher format and encoding is as specified in [BGP/MPLS-VPN].
路由识别器格式和编码如[BGP/MPLS-VPN]所述。
When a site is IPv4 capable and IPv6 capable, the same RD MAY be used for the advertisement of IPv6 addresses and IPv4 addresses. Alternatively, a different RD MAY be used for the advertisement of the IPv4 addresses and of the IPv6 addresses. Note, however, that in the scope of this specification, IPv4 addresses and IPv6 addresses will always be handled in separate contexts, and that no IPv4-IPv6 interworking issues and techniques will be discussed.
当站点支持IPv4和IPv6时，同一RD可用于IPv6地址和IPv4地址的播发。或者，可以使用不同的RD来公布IPv4地址和IPv6地址。但是，请注意，在本规范的范围内，IPv4地址和IPv6地址将始终在单独的上下文中处理，并且不会讨论IPv4-IPv6互通问题和技术。
As described in [BGP/MPLS-VPN], if two sites of a VPN attach to PEs that are in the same Autonomous System, the PEs can distribute VPN routes to each other by means of an (IPv4) internal Border Gateway Protocol (iBGP) connection between them. Alternatively, each PE can have iBGP connections to route reflectors. Similarly, for IPv6 VPN route distribution, PEs can use iBGP connections between them or use iBGP connections to route reflectors. For IPv6 VPN, the iBGP connections MAY be over IPv4 or over IPv6.
如[BGP/MPLS-VPN]所述，如果VPN的两个站点连接到同一自治系统中的PEs，则PEs可以通过它们之间的（IPv4）内部边界网关协议（iBGP）连接将VPN路由分发给彼此。或者，每个PE可以具有iBGP连接，以路由反射器。类似地，对于IPv6 VPN路由分发，PEs可以在它们之间使用iBGP连接，或者使用iBGP连接来路由反射器。对于IPv6 VPN，iBGP连接可以通过IPv4或IPv6。
The PE routers exchange, via MP-BGP [BGP-MP], reachability information for the IPv6 prefixes in the IPv6 VPNs and thereby announce themselves as the BGP Next Hop.
PE路由器通过MP-BGP[BGP-MP]交换IPv6 VPN中IPv6前缀的可达性信息，从而宣布自己为BGP下一跳。
The rules for encoding the reachability information and the BGP Next Hop address are specified in the following sections.
以下各节指定了对可达性信息和BGP下一跳地址进行编码的规则。
When distributing IPv6 VPN routes, the advertising PE router MUST assign and distribute MPLS labels with the IPv6 VPN routes. Essentially, PE routers do not distribute IPv6 VPN routes, but Labeled IPv6 VPN routes [MPLS-BGP]. When the advertising PE then receives a packet that has this particular advertised label, the PE will pop this label from the MPLS stack and process the packet appropriately (i.e., forward it directly according to the label or perform a lookup in the corresponding IPv6-VPN context).
分发IPv6 VPN路由时，广告PE路由器必须分配和分发带有IPv6 VPN路由的MPLS标签。本质上，PE路由器不分发IPv6 VPN路由，而是标记为IPv6 VPN路由[MPLS-BGP]。当广告PE随后接收到具有该特定广告标签的分组时，该PE将从MPLS堆栈弹出该标签并适当地处理该分组（即，根据该标签直接转发该分组或在相应的IPv6 VPN上下文中执行查找）。
The BGP Multiprotocol Extensions [BGP-MP] are used to advertise the IPv6 VPN routes in the MP_REACH Network Layer Reachability Information (NLRI). The Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) fields MUST be set as follows:
BGP多协议扩展[BGP-MP]用于在MP_到达网络层可达性信息（NLRI）中公布IPv6 VPN路由。地址族标识符（AFI）和后续地址族标识符（SAFI）字段必须设置如下：
- AFI: 2; for IPv6
- AFI:2；用于IPv6
- SAFI: 128; for MPLS labeled VPN-IPv6
- SAFI:128；用于标记为VPN-IPv6的MPLS
The NLRI field itself is encoded as specified in [MPLS-BGP]. In the context of this extension, the prefix belongs to the VPN-IPv6 Address Family and thus consists of an 8-octet Route Distinguisher followed by an IPv6 prefix as specified in Section 2, above.
NLRI字段本身按照[MPLS-BGP]中的规定进行编码。在本扩展的上下文中，前缀属于VPN-IPv6地址系列，因此由一个8位字节的路由标识符和一个IPv6前缀组成，如上文第2节所述。
The encoding of the BGP Next Hop depends on whether the policy of the BGP speaker is to request that IPv6 VPN traffic be transported to that BGP Next Hop using IPv6 tunneling ("BGP speaker requesting IPv6 transport") or using IPv4 tunneling ("BGP speaker requesting IPv4 transport").
BGP下一跳的编码取决于BGP扬声器的策略是使用IPv6隧道（“请求IPv6传输的BGP扬声器”）还是使用IPv4隧道（“请求IPv4传输的BGP扬声器”）请求将IPv6 VPN流量传输到该BGP下一跳。
Definition of this policy (to request transport over IPv4 tunneling or IPv6 tunneling) is the responsibility of the network operator and is beyond the scope of this document. Note that it is possible for that policy to request transport over IPv4 (resp. IPv6) tunneling while the BGP speakers exchange IPv6 VPN reachability information over IPv6 (resp. IPv4). However, in that case, a number of operational implications are worth considering. In particular, an undetected fault affecting the IPv4 (resp. IPv6) tunneling data path and not affecting the IPv6 (resp. IPv4) data path could remain undetected by BGP, which in turn may result in black-holing of traffic.
此策略的定义（通过IPv4隧道或IPv6隧道请求传输）由网络运营商负责，超出了本文档的范围。请注意，当BGP扬声器通过IPv6（分别IPv4）交换IPv6 VPN可达性信息时，该策略可以通过IPv4（分别IPv6）隧道请求传输。然而，在这种情况下，一些操作影响值得考虑。特别是，BGP可能无法检测到影响IPv4（分别为IPv6）隧道数据路径和不影响IPv6（分别为IPv4）数据路径的未检测到的故障，这反过来可能导致通信量的黑洞。
Control of this policy is beyond the scope of this document and may be based on user configuration.
此策略的控制超出了本文档的范围，可能基于用户配置。
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv6 tunneling (e.g., IPv6 MPLS LSPs, IPsec-protected IPv6 tunnels), the BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address
当使用IPv6隧道（例如，IPv6 MPLS LSP、受IPsec保护的IPv6隧道）将IPv6 VPN通信传输到BGP扬声器时，BGP扬声器应公布包含VPN-IPv6地址的下一跳网络地址字段
- whose 8-octet RD is set to zero, and
- 其8-八位字节RD设置为零，并且
- whose 16-octet IPv6 address is set to the global IPv6 address of the advertising BGP speaker.
- 其16个八位组IPv6地址设置为广告BGP扬声器的全局IPv6地址。
This is potentially followed by another VPN-IPv6 address
这之后可能会出现另一个VPN-IPv6地址
- whose 8-octet RD is set to zero, and
- 其8-八位字节RD设置为零，并且
- whose 16-octet IPv6 address is set to the link-local IPv6 address of the advertising BGP speaker.
- 其16个八位组IPv6地址设置为广告BGP扬声器的链路本地IPv6地址。
The value of the Length of the Next Hop Network Address field in the MP_REACH_NLRI attribute shall be set to 24 when only a global address is present, and to 48 if a link-local address is also included in the Next Hop field.
当仅存在全局地址时，MP_REACH_NLRI属性中的下一跳网络地址字段的长度值应设置为24，如果下一跳字段中还包括链路本地地址，则应设置为48。
If the BGP speakers peer using only their link-local IPv6 address (for example, in the case where an IPv6 CE peers with an IPv6 PE, where the CE does not have any IPv6 global address, and where eBGP peering is achieved over the link-local addresses), the "unspecified address" ([V6ADDR]) is used by the advertising BGP speaker to indicate the absence of the global IPv6 address in the Next Hop Network Address field.
如果BGP扬声器仅使用其链路本地IPv6地址进行对等（例如，在IPv6 CE与IPv6 PE进行对等的情况下，CE没有任何IPv6全局地址，并且eBGP通过链路本地地址进行对等，“未指定地址”（[V6ADDR]）由广告BGP扬声器使用，以指示下一跳网络地址字段中缺少全局IPv6地址。
The link-local address shall be included in the Next Hop field if and only if the advertising BGP speaker shares a common subnet with the peer the route is being advertised to [BGP-IPv6].
当且仅当播发BGP扬声器与正在向[BGP-IPv6]播发路由的对等方共享公共子网时，链路本地地址应包含在下一跳字段中。
In all other cases, a BGP speaker shall advertise to its peer in the Next Hop Network Address field only the global IPv6 address of the next hop.
在所有其他情况下，BGP扬声器应在下一跳网络地址字段中仅向其对等方公布下一跳的全局IPv6地址。
As a consequence, a BGP speaker that advertises a route to an internal peer may modify the Network Address of Next Hop field by removing the link-local IPv6 address of the next hop.
因此，播发到内部对等方的路由的BGP扬声器可以通过删除下一跳的链路本地IPv6地址来修改下一跳的网络地址字段。
An example scenario where both the global IPv6 address and the link-local IPv6 address shall be included in the BGP Next Hop address field is that where the IPv6 VPN service is supported over a multi-Autonomous System (AS) backbone with redistribution of labeled VPN-
BGP下一跳地址字段中应包括全局IPv6地址和链路本地IPv6地址的示例场景是，在多自治系统（AS）主干上支持IPv6 VPN服务，并重新分配标记的VPN-
IPv6 routes between Autonomous System Border Routers (ASBR) of different ASes sharing a common IPv6 subnet: in that case, both the global IPv6 address and the link-local IPv6 address shall be advertised by the ASBRs.
共享公共IPv6子网的不同ASE的自治系统边界路由器（ASBR）之间的IPv6路由：在这种情况下，ASBR应公布全局IPv6地址和链路本地IPv6地址。
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv4 tunneling (e.g., IPv4 MPLS LSPs, IPsec-protected IPv4 tunnels), the BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:
当使用IPv4隧道（例如，IPv4 MPLS LSP、受IPsec保护的IPv4隧道）将IPv6 VPN流量传输到BGP扬声器时，BGP扬声器应向其对等方公布包含VPN-IPv6地址的下一跳网络地址字段：
- whose 8-octet RD is set to zero, and
- 其8-八位字节RD设置为零，并且
- whose 16-octet IPv6 address is encoded as an IPv4-mapped IPv6 address [V6ADDR] containing the IPv4 address of the advertising BGP speaker. This IPv4 address must be routable by the other BGP Speaker.
- 其16个八位字节的IPv6地址编码为IPv4映射的IPv6地址[V6ADDR]，其中包含播发BGP扬声器的IPv4地址。此IPv4地址必须可由其他BGP扬声器路由。
The use of route target is specified in [BGP/MPLS-VPN] and applies to IPv6 VPNs. Encoding of the extended community attribute is defined in [BGP-EXTCOM].
路由目标的使用在[BGP/MPLS-VPN]中指定，并适用于IPv6 VPN。扩展社区属性的编码在[BGP-EXTCOM]中定义。
In order for two PEs to exchange labeled IPv6 VPN NLRIs, they MUST use BGP Capabilities Negotiation to ensure that they both are capable of properly processing such NLRIs. This is done as specified in [BGP-MP] and [BGP-CAP], by using capability code 1 (multiprotocol BGP), with AFI and SAFI values as specified above, in Section 3.2.
为了让两个PE交换标记为IPv6 VPN NLRIs，它们必须使用BGP功能协商，以确保它们都能够正确处理此类NLRIs。这是按照[BGP-MP]和[BGP-CAP]中的规定，通过使用能力代码1（多协议BGP）以及上文第3.2节中规定的AFI和SAFI值来实现的。
The ingress PE Router MUST tunnel IPv6 VPN data over the backbone towards the Egress PE router identified as the BGP Next Hop for the corresponding destination IPv6 VPN prefix.
入口PE路由器必须通过主干将IPv6 VPN数据隧道传输到出口PE路由器，出口PE路由器被标识为对应目标IPv6 VPN前缀的BGP下一跳。
When the 16-octet IPv6 address contained in the BGP Next Hop field is encoded as an IPv4-mapped IPv6 address (see Section 3.2.1.2), the ingress PE MUST use IPv4 tunneling unless explicitly configured to do otherwise. The ingress PE MAY optionally allow, through explicit configuration, the use of IPv6 tunneling when the 16-octet IPv6 address contained in the BGP Next Hop field is encoded as an IPv4- mapped IPv6 address. This would allow support of particular deployment environments where IPv6 tunneling is desired but where IPv4-mapped IPv6 addresses happen to be used for IPv6 reachability of the PEs instead of Global IPv6 addresses.
当BGP下一个跃点字段中包含的16个八位组IPv6地址编码为IPv4映射IPv6地址时（请参阅第3.2.1.2节），除非明确配置为使用IPv4隧道，否则入口PE必须使用IPv4隧道。当BGP下一跳字段中包含的16个八位组IPv6地址被编码为IPv4映射的IPv6地址时，入口PE可选择性地通过显式配置允许使用IPv6隧道。这将允许支持特定的部署环境，其中需要IPv6隧道，但IPv4映射的IPv6地址恰好用于PEs的IPv6可达性，而不是全局IPv6地址。
When the 16-octet IPv6 address contained in the BGP Next Hop field is not encoded as an IPv4-mapped address (see Section 3.2.1.1), the ingress PE MUST use IPv6 tunneling.
当BGP下一跳字段中包含的16个八位组IPv6地址未编码为IPv4映射地址时（请参阅第3.2.1.1节），入口PE必须使用IPv6隧道。
When a PE receives a packet from an attached CE, it looks up the packet's IPv6 destination address in the VRF corresponding to that CE. This enables it to find a VPN-IPv6 route. The VPN-IPv6 route will have an associated MPLS label and an associated BGP Next Hop. First, this MPLS label is pushed on the packet as the bottom label. Then, this labeled packet is encapsulated into the tunnel for transport to the egress PE identified by the BGP Next Hop. Details of this encapsulation depend on the actual tunneling technique, as follows:
当PE从连接的CE接收到数据包时，它会在对应于该CE的VRF中查找数据包的IPv6目标地址。这使它能够找到VPN-IPv6路由。VPN-IPv6路由将具有关联的MPLS标签和关联的BGP下一跳。首先，这个MPLS标签作为底部标签推送到数据包上。然后，将该标记的分组封装到隧道中，以便传输到由BGP下一跳标识的出口PE。这种封装的细节取决于实际的隧道技术，如下所示：
As with MPLS/BGP for IPv4 VPNs [2547-GRE/IP], when tunneling is done using IPv4 tunnels or IPv6 tunnels (resp. IPv4 GRE tunnels or IPv6 GRE tunnels), encapsulation of the labeled IPv6 VPN packet results in an MPLS-in-IP (resp. MPLS-in-GRE) encapsulated packet as specified in [MPLS-in-IP/GRE]. When tunneling is done using L2TPv3, encapsulation of the labeled IPv6 VPN packet results in an MPLS-in-L2TPv3- encapsulated packet, as specified in [MPLS-in-L2TPv3].
与IPv4 VPN的MPLS/BGP[2547-GRE/IP]一样，当使用IPv4隧道或IPv6隧道（分别为IPv4 GRE隧道或IPv6 GRE隧道）完成隧道时，封装标记的IPv6 VPN数据包将导致在[MPLS in IP/GRE]中指定的MPLS in IP（分别为MPLS in GRE）封装数据包。当使用L2TPv3完成隧道时，按照[MPLS-in-L2TPv3]中的规定，标记的IPv6 VPN数据包的封装将导致MPLS-in-L2TPv3封装的数据包。
As with MPLS/BGP for IPv4 VPNs, when tunneling is done using an IPsec secured tunnel [2547-IPsec], encapsulation of the labeled IPv6 VPN packet results in an MPLS-in-IP- or MPLS-in-GRE-encapsulated packet [MPLS-in-IP/GRE]. The IPsec Transport Mode is used to secure this IPv4 or GRE tunnel from ingress PE to egress PE.
与IPv4 VPN的MPLS/BGP一样，当使用IPsec安全隧道[2547 IPsec]进行隧道传输时，封装标记的IPv6 VPN数据包会导致MPLS in IP或MPLS in GRE封装数据包[MPLS in IP/GRE]。IPsec传输模式用于保护从入口PE到出口PE的IPv4或GRE隧道。
When tunneling is done using IPv4 tunnels (whether IPsec secured or not), the Ingress PE Router MUST use the IPv4 address that is encoded in the IPv4-mapped IPv6 address field of the BGP next hop field as the destination address of the prepended IPv4 tunneling header. It uses one of its IPv4 addresses as the source address of the prepended IPv4 tunneling header.
当使用IPv4隧道（无论IPsec是否安全）完成隧道时，入口PE路由器必须使用在BGP下一跳字段的IPv4映射IPv6地址字段中编码的IPv4地址作为前置IPv4隧道头的目标地址。它使用其一个IPv4地址作为带前缀的IPv4隧道头的源地址。
When tunneling is done using IPv6 tunnels (whether IPsec secured or not), the Ingress PE Router MUST use the IPv6 address that is contained in the IPv6 address field of the BGP next hop field as the destination address of the prepended IPv6 tunneling header. It uses one of its IPv6 addresses as the source address of the prepended IPv6 tunneling header.
当使用IPv6隧道（无论IPsec是否安全）完成隧道时，入口PE路由器必须使用BGP下一跳字段的IPv6地址字段中包含的IPv6地址作为前置IPv6隧道头的目标地址。它使用其一个IPv6地址作为前置IPv6隧道头的源地址。
When tunneling is done using MPLS LSPs, the LSPs can be established using any label distribution technique (LDP [LDP], RSVP-TE [RSVP-TE], etc.).
当使用MPLS lsp完成隧道时，可以使用任何标签分发技术（LDP[LDP]、RSVP-TE[RSVP-TE]等）来建立lsp。
When tunneling is done using MPLS LSPs, the ingress PE Router MUST directly push the LSP tunnel label on the label stack of the labeled IPv6 VPN packet (i.e., without prepending any IPv4 or IPv6 header). This pushed label corresponds to the LSP starting on the ingress PE Router and ending on the egress PE Router. The BGP Next Hop field is used to identify the egress PE router and in turn the label to be pushed on the stack. When the IPv6 address in the BGP Next Hop field is an IPv4-mapped IPv6 address, the embedded IPv4 address will determine the tunnel label to push on the label stack. In any other case, the IPv6 address in the BGP Next Hop field will determine the tunnel label to push on the label stack.
当使用MPLS LSP完成隧道时，入口PE路由器必须直接将LSP隧道标签推送到标记的IPv6 VPN数据包的标签堆栈上（即，不预先添加任何IPv4或IPv6报头）。该推送标签对应于从入口PE路由器开始到出口PE路由器结束的LSP。BGP Next Hop字段用于标识出口PE路由器，进而标识要推送到堆栈上的标签。当BGP下一跳字段中的IPv6地址是IPv4映射的IPv6地址时，嵌入的IPv4地址将确定要推送到标签堆栈上的隧道标签。在任何其他情况下，BGP下一跳字段中的IPv6地址将确定要推送到标签堆栈上的隧道标签。
To ensure interoperability among systems that implement this VPN architecture, all such systems MUST support tunneling using MPLS LSPs established by LDP [LDP].
为确保实现此VPN体系结构的系统之间的互操作性，所有此类系统必须支持使用LDP[LDP]建立的MPLS LSP进行隧道传输。
Since Link-local unicast addresses are defined for use on a single link only, those may be used on the PE-CE link, but they are not supported for reachability across IPv6 VPN Sites and are never advertised via MultiProtocol-Border Gateway Protocol (MP-BGP) to remote PEs.
由于链路本地单播地址定义为仅在单个链路上使用，因此这些地址可在PE-CE链路上使用，但不支持跨IPv6 VPN站点的可达性，并且从不通过多协议边界网关协议（MP-BGP）向远程PE播发。
Global unicast addresses are defined as uniquely identifying interfaces anywhere in the IPv6 Internet. Global addresses are expected to be commonly used within and across IPv6 VPN Sites. They are obviously supported by this IPv6 VPN solution for reachability across IPv6 VPN Sites and advertised via MP-BGP to remote PEs and are processed without any specific considerations to their global scope.
全局单播地址定义为唯一标识IPv6 Internet中任何位置的接口。IPv6 VPN站点内和跨IPv6 VPN站点通常使用全局地址。显然，该IPv6 VPN解决方案支持它们跨IPv6 VPN站点的可达性，并通过MP-BGP向远程PE发布，并且在处理它们时不考虑其全局范围。
Quoting from [UNIQUE-LOCAL]: "This document defines an IPv6 unicast address format that is globally unique and is intended for local communications [IPv6]. These addresses are called Unique Local IPv6 Unicast Addresses and are abbreviated in this document as Local IPv6 addresses. They are not expected to be routable on the global Internet. They are routable inside of a more limited area such as a site. They may also be routed between a limited set of sites."
引用[UNIQUE-LOCAL]：“本文档定义了一种IPv6单播地址格式，该格式是全局唯一的，用于本地通信[IPv6]。这些地址称为唯一本地IPv6单播地址，在本文档中缩写为本地IPv6地址。它们不应在全球Internet上路由。它们可在更有限的区域（如站点）内路由。它们也可在有限的一组站点之间路由。“
[UNIQUE-LOCAL] also says in its Section 4.7: "Local IPv6 addresses can be used for inter-site Virtual Private Networks (VPN) if appropriate routes are set up. Because the addresses are unique these VPNs will work reliably and without the need for translation. They have the additional property that they will continue to work if the individual sites are renumbered or merged."
[UNIQUE-LOCAL]在其第4.7节中还说：“本地IPv6地址可用于站点间虚拟专用网络（VPN）如果设置了适当的路由。由于地址是唯一的，这些VPN将可靠地工作，无需翻译。它们具有附加属性，即如果对各个站点重新编号或合并，它们将继续工作。”
In accordance with this, Unique Local IPv6 Unicast Addresses are supported by the IPv6 VPN solution specified in this document for reachability across IPv6 VPN Sites. Hence, reachability to such Unique Local IPv6 Addresses may be advertised via MP-BGP to remote PEs and processed by PEs in the same way as Global Unicast addresses.
据此，本文档中指定的IPv6 VPN解决方案支持唯一的本地IPv6单播地址，以实现跨IPv6 VPN站点的可达性。因此，可通过MP-BGP向远程PEs通告对此类唯一本地IPv6地址的可达性，并由PEs以与全局单播地址相同的方式进行处理。
Recommendations and considerations for which of these supported address types should be used in given IPv6 VPN environments are beyond the scope of this document.
在给定的IPv6 VPN环境中应使用哪种受支持的地址类型的建议和注意事项超出了本文档的范围。
Multicast operations are outside the scope of this document.
多播操作不在本文档的范围内。
Sometimes, an IPv6 VPN may actually be the network of an IPv6 ISP, with its own peering and routing policies. Sometimes, an IPv6 VPN may be the network of an SP that is offering VPN services in turn to its own customers. IPv6 VPNs like these can also obtain backbone service from another SP, the "Carrier's Carrier", using the Carriers' Carrier method described in Section 9 of [BGP/MPLS-VPN] but applied to IPv6 traffic. All the considerations discussed in [BGP/MPLS-VPN] for IPv4 VPN Carriers' Carrier apply for IPv6 VPN, with the exception that the use of MPLS (including label distribution) between the PE and the CE pertains to IPv6 routes instead of IPv4 routes.
有时，IPv6 VPN实际上可能是IPv6 ISP的网络，具有自己的对等和路由策略。有时，IPv6 VPN可能是SP的网络，该SP反过来向其自己的客户提供VPN服务。类似的IPv6 VPN还可以使用[BGP/MPLS-VPN]第9节中描述的运营商运营商方法从另一个SP“运营商的运营商”获得主干网服务，但适用于IPv6流量。[BGP/MPLS-VPN]中针对IPv4 VPN运营商的运营商讨论的所有注意事项均适用于IPv6 VPN，但PE和CE之间使用MPLS（包括标签分发）属于IPv6路由而非IPv4路由的情况除外。
The same procedures described in Section 10 of [BGP/MPLS-VPN] can be used (and have the same scalability properties) to address the situation where two sites of an IPv6 VPN are connected to different Autonomous Systems. However, some additional points should be noted
可以使用[BGP/MPLS-VPN]第10节中描述的相同过程（并且具有相同的可扩展性属性）来解决IPv6 VPN的两个站点连接到不同自治系统的情况。但是，还应注意一些其他要点
when applying these procedures for IPv6 VPNs; these are further described in the remainder of this section.
将这些程序应用于IPv6 VPN时；这些将在本节的其余部分中进一步描述。
Approach (a): VRF-to-VRF connections at the AS (Autonomous System) border routers.
方法（a）：AS（自治系统）边界路由器上的VRF到VRF连接。
This approach is the equivalent for IPv6 VPNs to procedure (a) in Section 10 of [BGP/MPLS-VPN]. In the case of IPv6 VPNs, IPv6 needs to be activated on the inter-ASBR VRF-to-VRF (sub)interfaces. In this approach, the ASBRs exchange IPv6 routes (as opposed to VPN-IPv6 routes) and may peer over IPv6 or over IPv4. The exchange of IPv6 routes MUST be carried out as per [BGP-IPv6]. This method does not use inter-AS LSPs.
此方法与[BGP/MPLS-VPN]第10节中的过程（a）等效。对于IPv6 VPN，需要在ASBR VRF到VRF（子）接口之间激活IPv6。在这种方法中，ASBR交换IPv6路由（与VPN-IPv6路由相反），并且可以通过IPv6或IPv4进行对等。IPv6路由的交换必须按照[BGP-IPv6]进行。此方法不将inter用作LSP。
Finally, note that with this procedure, since every AS independently implements the intra-AS procedures for IPv6 VPNs described in this document, the participating ASes may all internally use IPv4 tunneling, or IPv6 tunneling; or alternatively, some participating ASes may internally use IPv4 tunneling while others use IPv6 tunneling.
最后，请注意，通过此过程，由于每个AS都独立地实现本文档中描述的IPv6 VPN的AS内过程，因此参与的AS都可以在内部使用IPv4隧道或IPv6隧道；或者，一些参与的ASE可能在内部使用IPv4隧道，而其他ASE则使用IPv6隧道。
Approach (b): EBGP redistribution of labeled VPN-IPv6 routes from AS to neighboring AS.
方法（b）：EBGP将标记的VPN-IPv6路由从AS重新分配到相邻AS。
This approach is the equivalent for IPv6 VPNs to procedure (b) in Section 10 of [BGP/MPLS-VPN]. With this approach, the ASBRs use EBGP to redistribute labeled VPN-IPv4 routes to ASBRs in other ASes.
此方法与[BGP/MPLS-VPN]第10节中的过程（b）等效。通过这种方法，ASBR使用EBGP将标记的VPN-IPv4路由重新分配给其他ASE中的ASBR。
In this approach, IPv6 may or may not be activated on the inter-ASBR links since the ASBRs exchanging VPN-IPv6 routes may peer over IPv4 or IPv6 (in which case, IPv6 obviously needs to be activated on the inter-ASBR link). The exchange of labeled VPN-IPv6 routes MUST be carried out as per [BGP-IPv6] and [MPLS-BGP]. When the VPN-IPv6 traffic is to be transported using IPv6 tunneling, the BGP Next Hop Field SHALL contain an IPv6 address. When the VPN-IPv6 traffic is to be transported using IPv4 tunneling, the BGP Next Hop Field SHALL contain an IPv4 address encoded as an IPv4-mapped IPv6 address.
在这种方法中，由于交换VPN-IPv6路由的ASBR可以通过IPv4或IPv6进行对等（在这种情况下，显然需要在ASBR间链路上激活IPv6），所以IPv6可能在ASBR间链路上激活，也可能不在ASBR间链路上激活。标记VPN-IPv6路由的交换必须按照[BGP-IPv6]和[MPLS-BGP]进行。当使用IPv6隧道传输VPN-IPv6流量时，BGP下一跳字段应包含IPv6地址。当使用IPv4隧道传输VPN-IPv6流量时，BGP下一跳字段应包含编码为IPv4映射IPv6地址的IPv4地址。
This approach requires that there be inter-AS LSPs. As such, the corresponding (security) considerations described for procedure (b) in Section 10 of [BGP/MPLS-VPN] apply equally to this approach for IPv6.
这种方法要求存在内部AS LSP。因此，[BGP/MPLS-VPN]第10节中程序（b）所述的相应（安全）注意事项同样适用于IPv6的这种方法。
Finally, note that with this procedure, as with procedure (a), since every AS independently implements the intra-AS procedures for IPv6 VPNs described in this document, the participating ASes may all internally use IPv4 tunneling or IPv6 tunneling; alternatively, some participating ASes may internally use IPv4 tunneling while others use IPv6 tunneling.
最后，请注意，对于该过程，与过程（a）一样，由于每个as独立地实现本文档中描述的IPv6 VPN的as内过程，因此参与的ASE都可以在内部使用IPv4隧道或IPv6隧道；或者，一些参与的ASE可能在内部使用IPv4隧道，而其他ASE则使用IPv6隧道。
Approach (c): Multihop EBGP redistribution of labeled VPN-IPv6 routes between source and destination ASes, with EBGP redistribution of labeled IPv4 or IPv6 routes from AS to neighboring AS.
方法（c）：源和目标ASE之间标记的VPN-IPv6路由的多跳EBGP再分配，以及从AS到相邻AS的标记的IPv4或IPv6路由的EBGP再分配。
This approach is equivalent for exchange of VPN-IPv6 routes to procedure (c) in Section 10 of [BGP/MPLS-VPN] for exchange of VPN-IPv4 routes.
这种方法相当于将VPN-IPv6路由交换到[BGP/MPLS-VPN]第10节中用于交换VPN-IPv4路由的程序（c）。
This approach requires that the participating ASes either all use IPv4 tunneling or all use IPv6 tunneling.
这种方法要求参与的ASE要么全部使用IPv4隧道，要么全部使用IPv6隧道。
In this approach, VPN-IPv6 routes are neither maintained nor distributed by the ASBR routers. The ASBR routers need not be dual stack. An ASBR needs to maintain labeled IPv4 (or IPv6) routes to the PE routers within its AS. It uses EBGP to distribute these routes to other ASes. ASBRs in any transit ASes will also have to use EBGP to pass along the labeled IPv4 (or IPv6) routes. This results in the creation of an IPv4 (or IPv6) label switch path from ingress PE router to egress PE router. Now, PE routers in different ASes can establish multi-hop EBGP connections to each other over IPv4 or IPv6 and can exchange labeled VPN-IPv6 routes over those EBGP connections. Note that the BGP Next Hop field of these distributed VPN-IPv6 routes will contain an IPv6 address when IPv6 tunneling is used or an IPv4-mapped IPv6 address when IPv4 tunneling is used.
在这种方法中，ASBR路由器既不维护也不分发VPN-IPv6路由。ASBR路由器不需要是双栈的。ASBR需要维护到其AS内PE路由器的标记IPv4（或IPv6）路由。它使用EBGP将这些路由分发给其他ASE。任何传输ASE中的ASBR也必须使用EBGP沿标记的IPv4（或IPv6）路由传输。这导致创建从入口PE路由器到出口PE路由器的IPv4（或IPv6）标签交换机路径。现在，不同ASE中的PE路由器可以通过IPv4或IPv6相互建立多跳EBGP连接，并可以通过这些EBGP连接交换标记的VPN-IPv6路由。请注意，当使用IPv6隧道时，这些分布式VPN-IPv6路由的BGP下一跳字段将包含IPv6地址，或者当使用IPv4隧道时，将包含IPv4映射的IPv6地址。
The considerations described for procedure (c) in Section 10 of [BGP/MPLS-VPN] with respect to possible use of route-reflectors, with respect to possible use of a third label, and with respect to LSPs spanning multiple ASes apply equally to this IPv6 VPN approach.
[BGP/MPLS-VPN]第10节中关于可能使用路由反射器、可能使用第三标签以及跨越多个ASE的LSP的过程（c）所述注意事项同样适用于此IPv6 VPN方法。
The methods proposed by [BGP/MPLS-VPN] to access the global IPv4 Internet from an IPv4 VPN can be used in the context of IPv6 VPNs and the global IPv6 Internet. Note, however, that if the IPv6 packets from IPv6 VPN sites and destined for the global IPv6 Internet need to traverse the SP backbone, and that if this is an IPv4 only backbone, these packets must be tunneled through that IPv4 backbone.
[BGP/MPLS-VPN]提出的从IPv4 VPN访问全局IPv4 Internet的方法可在IPv6 VPN和全局IPv6 Internet的上下文中使用。但是，请注意，如果来自IPv6 VPN站点且目的地为全局IPv6 Internet的IPv6数据包需要穿越SP主干网，并且如果这是仅IPv4主干网，则这些数据包必须通过该IPv4主干网进行隧道传输。
Clearly, as is the case outside the VPN context, access to the IPv6 Internet from an IPv6 VPN requires the use of global IPv6 addresses.
显然，与VPN上下文之外的情况一样，从IPv6 VPN访问IPv6 Internet需要使用全局IPv6地址。
In particular, Unique Local IPv6 addresses cannot be used for IPv6 Internet access.
特别是，唯一的本地IPv6地址不能用于IPv6 Internet访问。
The management considerations discussed in Section 12 of [BGP/MPLS-VPN] apply to the management of IPv6 VPNs.
[BGP/MPLS-VPN]第12节中讨论的管理注意事项适用于IPv6 VPN的管理。
Where the Service Provider manages the CE of the IPv6 VPN site, the Service Provider may elect to use IPv4 for communication between the management tool and the CE for such management purposes. In that case, regardless of whether a customer IPv4 site is actually connected to the CE (in addition to the IPv6 site), the CE is effectively part of an IPv4 VPN in addition to belonging to an IPv6 VPN (i.e., the CE is attached to a VRF that supports IPv4 in addition to IPv6). Considerations presented in [BGP/MPLS-VPN], on how to ensure that the management tool can communicate with such managed CEs from multiple VPNs without allowing undesired reachability across CEs of different VPNs, are applicable to the IPv4 reachability of the VRF to which the CE attaches.
在服务提供商管理IPv6 VPN站点的CE的情况下，服务提供商可以选择使用IPv4进行管理工具和CE之间的通信，以实现此类管理目的。在这种情况下，无论客户IPv4站点是否实际连接到CE（除IPv6站点外），CE除了属于IPv6 VPN之外，实际上也是IPv4 VPN的一部分（即，CE连接到除IPv6之外还支持IPv4的VRF）。[BGP/MPLS-VPN]中提出的关于如何确保管理工具能够从多个VPN与此类受管CE进行通信而不允许不同VPN的CE之间存在不希望的可达性的注意事项适用于CE连接到的VRF的IPv4可达性。
Where the Service Provider manages the CE of the IPv6 VPN site, the Service Provider may elect to use IPv6 for communication between the management tool and the CE for such management purposes. Considerations presented in [BGP/MPLS-VPN], on how to ensure that the management tool can communicate with such managed CEs from multiple VPNs without allowing undesired reachability across CEs of different VPNs, are then applicable to the IPv6 reachability of the VRF to which the CE attaches.
如果服务提供商管理ipv6vpn站点的CE，则服务提供商可以选择使用IPv6进行管理工具和CE之间的通信，以实现此类管理目的。[BGP/MPLS-VPN]中提出的关于如何确保管理工具能够从多个VPN与此类受管CE进行通信，而不允许不同VPN的CE之间的不期望的可达性的注意事项适用于CE连接到的VRF的IPv6可达性。
The extensions defined in this document allow MP-BGP to propagate reachability information about IPv6 VPN routes.
本文档中定义的扩展允许MP-BGP传播有关IPv6 VPN路由的可达性信息。
Security considerations for the transport of IPv6 reachability information using BGP are discussed in RFC2545, Section 5, and are equally applicable for the extensions described in this document.
RFC2545第5节讨论了使用BGP传输IPv6可达性信息的安全注意事项，这些注意事项同样适用于本文档中描述的扩展。
The extensions described in this document for offering IPv6 VPNs use the exact same approach as the approach described in [BGP/MPLS-VPN]. As such, the same security considerations apply with regards to Data Plane security, Control Plane security, and PE and P device security as described in [BGP/MPLS-VPN], Section 13.
本文档中描述的用于提供IPv6 VPN的扩展使用与[BGP/MPLS-VPN]中描述的方法完全相同的方法。因此，与[BGP/MPLS-VPN]第13节所述的数据平面安全性、控制平面安全性以及PE和P设备安全性相同的安全注意事项也适用。
Since all the QoS mechanisms discussed for IPv4 VPNs in Section 14 of [BGP/MPLS-VPN] operate in the same way for IPv4 and IPv6 (Diffserv, Intserv, MPLS Traffic Engineering), the QoS considerations discussed in [BGP/MPLS-VPN] are equally applicable to IPv6 VPNs (and this holds whether IPv4 tunneling or IPv6 tunneling is used in the backbone.)
由于[BGP/MPLS-VPN]第14节中讨论的IPv4 VPN的所有QoS机制在IPv4和IPv6（Diffserv、Intserv、MPLS流量工程）中以相同的方式运行，因此[BGP/MPLS-VPN]中讨论的QoS注意事项同样适用于IPv6 VPN（这决定了骨干网中使用的是IPv4隧道还是IPv6隧道）
Each of the scalability considerations summarized for IPv4 VPNs in Section 15 of [BGP/MPLS-VPN] is equally applicable to IPv6 VPNs.
[BGP/MPLS-VPN]第15节中总结的IPv4 VPN的每个可扩展性注意事项同样适用于IPv6 VPN。
This document specifies (see Section 3.2) the use of the BGP AFI (Address Family Identifier) value 2, along with the BGP SAFI (Subsequent Address Family Identifier) value 128, to represent the address family "VPN-IPv6 Labeled Addresses", which is defined in this document.
本文件规定（见第3.2节）使用BGP AFI（地址族标识符）值2以及BGP SAFI（后续地址族标识符）值128来表示本文件中定义的地址族“VPN-IPv6标记地址”。
The use of AFI value 2 for IPv6 is as currently specified in the IANA registry "Address Family Identifier", so IANA need not take any action with respect to it.
IPv6的AFI值2的使用与IANA注册表“地址族标识符”中的当前规定相同，因此IANA无需对此采取任何行动。
The use of SAFI value 128 for "MPLS-labeled VPN address" is as currently specified in the IANA registry "Subsequence Address Family Identifier", so IANA need not take any action with respect to it.
SAFI值128用于“标记为VPN地址的MPLS”是IANA注册表“子序列地址族标识符”中当前指定的，因此IANA无需对此采取任何行动。
We would like to thank Gerard Gastaud and Eric Levy-Abegnoli, who contributed to this document.
我们要感谢Gerard Gastaud和Eric Levy Abegnoli对本文件的贡献。
In Memoriam
纪念
The authors would like to acknowledge the valuable contribution to this document from Tri T. Nguyen, who passed away in April 2002 after a sudden illness.
作者要感谢Tri T.Nguyen对本文件的宝贵贡献，他因突发疾病于2002年4月去世。
[BGP/MPLS-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[BGP/MPLS-VPN]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[BGP-EXTCOM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[BGP-EXTCOM]Sangli，S.，Tappan，D.，和Y.Rekhter，“BGP扩展社区属性”，RFC 4360，2006年2月。
[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[BGP-MP]Bates，T.，Rekhter，Y.，Chandra，R.，和D.Katz，“BGP-4的多协议扩展”，RFC 28582000年6月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[MPLS-BGP]Rekhter，Y.和E.Rosen，“在BGP-4中携带标签信息”，RFC 3107，2001年5月。
[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[BGP-CAP]Chandra，R.和J.Scudder，“BGP-4的能力广告”，RFC 3392，2002年11月。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[LDP]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.，和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[BGP-IPv6] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[BGP-IPv6]Marques，P.和F.Dupont，“将BGP-4多协议扩展用于IPv6域间路由”，RFC 25451999年3月。
[V6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[V6ADDR]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[UNIQUE-LOCAL] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[唯一本地]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547 VPNs", Work in Progress.
[2547-GRE/IP]Rekhter和Rosen，“在RFC2547 VPN中使用PE-PE GRE或IP”，正在进行中。
[2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of PE-PE IPsec in RFC2547 VPNs", Work in Progress, August 2005.
[2547 IPsec]Rosen，De Clercq，Paridaens，T'Joens，Sargor，“在RFC2547 VPN中使用PE-PE IPsec”，正在进行的工作，2005年8月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[MPLS-in-IP/GRE] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[IP/GRE中的MPLS]Worster，T.，Rekhter，Y.，和E.Rosen，“在IP或通用路由封装（GRE）中封装MPLS”，RFC 4023，2005年3月。
[MPLS-in-L2TPv3] Townsley, M., et al., "Encapsulation of MPLS over Layer-2 Tunneling Protocol Version 3", Work in Progress, February 2006.
[MPLS-in-L2TPv3]Townsley，M.等人，“第2层隧道协议版本3上的MPLS封装”，正在进行的工作，2006年2月。
[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
Authors' Addresses
作者地址
Jeremy De Clercq Alcatel Copernicuslaan 50, 2018 Antwerpen, Belgium
杰里米·德克莱克·阿尔卡特·哥白尼公司2018年安特卫普50号，比利时
EMail: jeremy.de_clercq@alcatel.be
EMail: jeremy.de_clercq@alcatel.be
Dirk Ooms OneSparrow Belegstraat 13, 2018 Antwerpen, Belgium
2018年12月13日，比利时安特卫普，德克·奥姆斯一只麻雀
EMail: dirk@onesparrow.com
EMail: dirk@onesparrow.com
Marco Carugi Nortel Networks S.A. Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT 78928 YVELINES Cedex 9 - France
Marco Carugi Nortel Networks S.A.马尼-莱斯-琼斯-博伊斯城堡活动公园78928伊夫林-塞德克斯9号-法国
EMail: marco.carugi@nortel.com
EMail: marco.carugi@nortel.com
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France
Francois Le Faucheur Cisco Systems，Inc.绿边企业村-法国索菲亚-安提波利斯大街T3400号巴蒂门特酒店
EMail: flefauch@cisco.com
EMail: flefauch@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。