Network Working Group J. De Clercq
Request for Comments: 4798 Alcatel-Lucent
Category: Standards Track D. Ooms
OneSparrow
S. Prevost
BT
F. Le Faucheur
Cisco
February 2007
Network Working Group J. De Clercq
Request for Comments: 4798 Alcatel-Lucent
Category: Standards Track D. Ooms
OneSparrow
S. Prevost
BT
F. Le Faucheur
Cisco
February 2007
Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)
使用IPv6提供商边缘路由器（6PE）通过IPv4 MPLS连接IPv6孤岛
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are Dual Stack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration.
本文档介绍如何通过支持多协议标签交换（MPLS）的IPv4云互连IPv6孤岛。这种方法依赖于IPv6提供商边缘路由器（6PE），它是双栈，以便连接到IPv6孤岛和MPLS核心，而MPLS核心仅在运行IPv4 MPLS时才需要。6PE路由器使用IPv4上的多协议边界网关协议（MP-BGP）在核心上透明地交换IPv6可达性信息。在这样做时，BGP下一跳字段用于传送6PE路由器的IPv4地址，以便可以在没有显式隧道配置的情况下使用动态建立的IPv4信号MPLS标签交换路径（LSP）。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. Protocol Overview ...............................................4
3. Transport over IPv4-signaled LSPs and IPv6 Label Binding ........5
4. Crossing Multiple IPv4 Autonomous Systems .......................7
5. Security Considerations ........................................10
6. Acknowledgements ...............................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. Protocol Overview ...............................................4
3. Transport over IPv4-signaled LSPs and IPv6 Label Binding ........5
4. Crossing Multiple IPv4 Autonomous Systems .......................7
5. Security Considerations ........................................10
6. Acknowledgements ...............................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
There are several approaches for providing IPv6 connectivity over an MPLS core network [RFC4029] including (i) requiring that MPLS networks support setting up IPv6-signaled Label Switched Paths (LSPs) and establish IPv6 connectivity by using those LSPs, (ii) use configured tunneling over IPv4-signaled LSPs, or (iii) use the IPv6 Provider Edge (6PE) approach defined in this document.
有几种通过MPLS核心网络提供IPv6连接的方法[RFC4029]，包括（i）要求MPLS网络支持设置IPv6信号标签交换路径（LSP）并通过使用这些LSP建立IPv6连接，（ii）通过IPv4信号LSP使用配置的隧道，或（iii）使用IPv6提供程序边缘（6PE）本文件中定义的方法。
The 6PE approach is required as an alternative to the use of standard tunnels. It provides a solution for an MPLS environment where all tunnels are established dynamically, thereby addressing environments where the effort to configure and maintain explicitly configured tunnels is not acceptable.
需要使用6PE方法作为标准隧道的替代方案。它为动态建立所有隧道的MPLS环境提供了一个解决方案，从而解决了无法配置和维护显式配置隧道的环境。
This document specifies operations of the 6PE approach for interconnection of IPv6 islands over an IPv4 MPLS cloud. The approach requires that the edge routers connected to IPv6 islands be Dual Stack Multiprotocol-BGP-speaking routers [RFC4760], while the core routers are only required to run IPv4 MPLS. The approach uses MP-BGP over IPv4, relies on identification of the 6PE routers by their IPv4 address, and uses IPv4-signaled MPLS LSPs that do not require any explicit tunnel configuration.
本文档规定了通过IPv4 MPLS云互连IPv6孤岛的6PE方法的操作。该方法要求连接到IPv6孤岛的边缘路由器是双栈多协议BGP路由器[RFC4760]，而核心路由器只需要运行IPv4 MPLS。该方法通过IPv4使用MP-BGP，依赖于通过IPv4地址识别6PE路由器，并使用不需要任何显式隧道配置的IPv4信号MPLS LSP。
Throughout this document, the terminology of [RFC2460] and [RFC4364] is used.
在本文件中，使用了[RFC2460]和[RFC4364]的术语。
In this document an 'IPv6 island' is a network running native IPv6 as per [RFC2460]. A typical example of an IPv6 island would be a customer's IPv6 site connected via its IPv6 Customer Edge (CE) router to one (or more) Dual Stack Provider Edge router(s) of a Service Provider. These IPv6 Provider Edge routers (6PE) are connected to an IPv4 MPLS core network.
在本文档中，“IPv6孤岛”是根据[RFC2460]运行本机IPv6的网络。IPv6孤岛的典型示例是客户的IPv6站点通过其IPv6客户边缘（CE）路由器连接到服务提供商的一个（或多个）双堆栈提供商边缘路由器。这些IPv6提供商边缘路由器（6PE）连接到IPv4 MPLS核心网络。
+--------+
|site A CE---+ +-----------------+
+--------+ | | | +--------+
6PE-+ IPv4 MPLS core +-6PE--CE site C |
+--------+ | | | +--------+
|site B CE---+ +-----------------+
+--------+
+--------+
|site A CE---+ +-----------------+
+--------+ | | | +--------+
6PE-+ IPv4 MPLS core +-6PE--CE site C |
+--------+ | | | +--------+
|site B CE---+ +-----------------+
+--------+
IPv6 islands IPv4 cloud IPv6 island
<-------------><---------------------><-------------->
IPv6 islands IPv4 cloud IPv6 island
<-------------><---------------------><-------------->
Figure 1
图1
The interconnection method described in this document typically applies to an Internet Service Provider (ISP) that has an IPv4 MPLS network, that is familiar with BGP (possibly already offering BGP/MPLS VPN services), and that wants to offer IPv6 services to some of its customers. However, the ISP may not (yet) want to upgrade its network core to IPv6, nor use only IPv6-over-IPv4 tunneling. With the 6PE approach described here, the provider only has to upgrade some Provider Edge (PE) routers to Dual Stack operations so that they behave as 6PE routers (and route reflectors if those are used for the exchange of IPv6 reachability among 6PE routers) while leaving the IPv4 MPLS core routers untouched. These 6PE routers provide connectivity to IPv6 islands. They may also provide other services simultaneously (IPv4 connectivity, IPv4 L3VPN services, L2VPN services, etc.). Also with the 6PE approach, no tunnels need to be explicitly configured, and no IPv4 headers need to be inserted in front of the IPv6 packets between the customer and provider edge.
本文档中描述的互连方法通常适用于具有IPv4 MPLS网络、熟悉BGP（可能已经提供BGP/MPLS VPN服务）并希望向其部分客户提供IPv6服务的互联网服务提供商（ISP）。但是，ISP可能（还）不想将其网络核心升级到IPv6，也不想只使用IPv6-over-IPv4隧道。使用本文所述的6PE方法，提供商只需将某些提供商边缘（PE）路由器升级为双栈操作，以便它们在保持IPv4 MPLS核心路由器不变的情况下，充当6PE路由器（以及用于在6PE路由器之间交换IPv6可达性的路由反射器）。这些6PE路由器提供到IPv6孤岛的连接。它们还可以同时提供其他服务（IPv4连接、IPv4 L3VPN服务、L2VPN服务等）。同样使用6PE方法，不需要显式配置隧道，也不需要在客户和提供商边缘之间的IPv6数据包前面插入IPv4报头。
The ISP obtains IPv6 connectivity to its peers and upstreams using means outside of the scope of this document, and its 6PE routers readvertise it over the IPv4 MPLS core with MP-BGP.
ISP使用本文档范围之外的方法获得与对等方和上游的IPv6连接，其6PE路由器通过IPv4 MPLS核心和MP-BGP读取该连接。
The interface between the edge router of the IPv6 island (Customer Edge (CE) router) and the 6PE router is a native IPv6 interface which can be physical or logical. A routing protocol (IGP or EGP) may run between the CE router and the 6PE router for the distribution of IPv6 reachability information. Alternatively, static routes and/or a default route may be used on the 6PE router and the CE router to control reachability. An IPv6 island may connect to the provider network over more than one interface.
IPv6孤岛的边缘路由器（客户边缘（CE）路由器）与6PE路由器之间的接口是本机IPv6接口，可以是物理接口，也可以是逻辑接口。路由协议（IGP或EGP）可在CE路由器和6PE路由器之间运行，用于分发IPv6可达性信息。或者，可以在6PE路由器和CE路由器上使用静态路由和/或默认路由来控制可达性。IPv6孤岛可以通过多个接口连接到提供商网络。
The 6PE approach described in this document can be used for customers that already have an IPv4 service from the network provider and additionally require an IPv6 service, as well as for customers that require only IPv6 connectivity.
本文档中描述的6PE方法可用于已从网络提供商处获得IPv4服务且另外需要IPv6服务的客户，以及仅需要IPv6连接的客户。
The scenario is also described in [RFC4029].
[RFC4029]中也描述了该场景。
Note that the 6PE approach specified in this document provides global IPv6 reachability. Support of IPv6 VPNs is not within the scope of this document and is addressed in [RFC4659].
请注意，本文档中指定的6PE方法提供了全局IPv6可达性。IPv6 VPN的支持不在本文档的范围内，请参见[RFC4659]。
Deployment of the 6PE approach over an existing IPv4 MPLS cloud does not require an introduction of new mechanisms in the core (other than potentially those described at the end of Section 3 for dealing with dynamic MTU discovery). Configuration and operations of the 6PE approach have a lot of similarities with the configuration and operations of an IPv4 VPN service ([RFC4364]) or IPv6 VPN service ([RFC4659]) over an IPv4 MPLS core because they all use MP-BGP to distribute non-IPv4 reachability information for transport over an IPv4 MPLS Core. However, the configuration and operations of the 6PE approach is somewhat simpler, since it does not involve all the VPN concepts such as Virtual Routing and Forwarding (VRFs) tables.
在现有IPv4 MPLS云上部署6PE方法不需要在核心中引入新机制（第3节末尾描述的用于处理动态MTU发现的机制除外）。6PE方法的配置和操作与IPv4 MPLS核心上的IPv4 VPN服务（[RFC4364]）或IPv6 VPN服务（[RFC4659]）的配置和操作有很多相似之处，因为它们都使用MP-BGP分发非IPv4可达性信息，以便在IPv4 MPLS核心上传输。然而，6PE方法的配置和操作稍微简单一些，因为它不涉及所有VPN概念，例如虚拟路由和转发（VRFs）表。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Each IPv6 site is connected to at least one Provider Edge router that is located on the border of the IPv4 MPLS cloud. We call such a router a 6PE router. The 6PE router MUST be dual stack IPv4 and IPv6. The 6PE router MUST be configured with at least one IPv4 address on the IPv4 side and at least one IPv6 address on the IPv6 side. The configured IPv4 address needs to be routable in the IPv4 cloud, and there needs to be a label bound via an IPv4 label distribution protocol to this IPv4 route.
每个IPv6站点至少连接到一个位于IPv4 MPLS云边界上的提供商边缘路由器。我们称这种路由器为6PE路由器。6PE路由器必须是双栈IPv4和IPv6。6PE路由器必须在IPv4端配置至少一个IPv4地址，在IPv6端配置至少一个IPv6地址。配置的IPv4地址需要在IPv4云中可路由，并且需要通过IPv4标签分发协议将标签绑定到此IPv4路由。
As a result of this, every considered 6PE router knows which MPLS label to use to send packets to any other 6PE router. Note that an MPLS network offering BGP/MPLS IP VPN services already fulfills these requirements.
因此，每个考虑的6PE路由器都知道使用哪个MPLS标签向任何其他6PE路由器发送数据包。请注意，提供BGP/MPLS IP VPN服务的MPLS网络已经满足这些要求。
No extra routes need to be injected in the IPv4 cloud.
不需要在IPv4云中注入额外的路由。
We call the 6PE router receiving IPv6 packets from an IPv6 site an ingress 6PE router (relative to these IPv6 packets). We call a 6PE router forwarding IPv6 packets to an IPv6 site an egress 6PE router (relative to these IPv6 packets).
我们将从IPv6站点接收IPv6数据包的6PE路由器称为入口6PE路由器（相对于这些IPv6数据包）。我们将向IPv6站点转发IPv6数据包的6PE路由器称为出口6PE路由器（相对于这些IPv6数据包）。
Interconnecting IPv6 islands over an IPv4 MPLS cloud takes place through the following steps:
通过以下步骤通过IPv4 MPLS云互连IPv6孤岛：
1. Exchange IPv6 reachability information among 6PE routers with MP-BGP [RFC2545]:
1. 使用MP-BGP[RFC2545]在6PE路由器之间交换IPv6可达性信息：
The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP sessions as per [RFC2545] running over IPv4. The MP-BGP Address Family Identifier (AFI) used MUST be IPv6 (value 2). In doing so, the 6PE routers convey their IPv4 address as the BGP Next Hop for the advertised IPv6 prefixes. The IPv4 address of the egress 6PE router MUST be encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field. This encoding is consistent with the definition of an IPv4-mapped IPv6 address in [RFC4291] as an "address type used to represent the address of IPv4 nodes as IPv6 addresses". In addition, the 6PE MUST bind a label to the IPv6 prefix as per [RFC3107]. The Subsequence Address Family Identifier (SAFI) used in MP-BGP MUST be the "label" SAFI (value 4) as defined in [RFC3107]. Rationale for this and label allocation policies are discussed in Section 3.
6PE路由器必须根据在IPv4上运行的[RFC2545]通过MP-BGP会话交换IPv6前缀。使用的MP-BGP地址族标识符（AFI）必须是IPv6（值2）。在这样做时，6PE路由器将其IPv4地址作为播发的IPv6前缀的BGP下一跳进行传输。出口6PE路由器的IPv4地址必须在BGP下一跳字段中编码为IPv4映射的IPv6地址。此编码与[RFC4291]中IPv4映射IPv6地址的定义一致，即“用于将IPv4节点的地址表示为IPv6地址的地址类型”。此外，6PE必须根据[RFC3107]将标签绑定到IPv6前缀。MP-BGP中使用的子序列地址族标识符（SAFI）必须是[RFC3107]中定义的“标签”SAFI（值4）。第3节讨论了这一政策的基本原理和标签分配政策。
2. Transport IPv6 packets from the ingress 6PE router to the egress 6PE router over IPv4-signaled LSPs:
2. 通过IPv4信号LSP将IPv6数据包从入口6PE路由器传输到出口6PE路由器：
The ingress 6PE router MUST forward IPv6 data over the IPv4- signaled LSP towards the egress 6PE router identified by the IPv4 address advertised in the IPv4-mapped IPv6 address of the BGP Next Hop for the corresponding IPv6 prefix.
入口6PE路由器必须通过IPv4信号LSP向出口6PE路由器转发IPv6数据，出口6PE路由器由相应IPv6前缀的BGP下一跳的IPv4映射IPv6地址中公布的IPv4地址标识。
As required by the BGP specification [RFC4271], PE routers form a full peering mesh unless Route Reflectors are used.
根据BGP规范[RFC4271]的要求，除非使用路由反射器，否则PE路由器将形成一个完整的对等网格。
In this approach, the IPv4-mapped IPv6 addresses allow a 6PE router that has to forward an IPv6 packet to automatically determine the IPv4-signaled LSP to use for a particular IPv6 destination by looking at the MP-BGP routing information.
在这种方法中，IPv4映射的IPv6地址允许必须转发IPv6数据包的6PE路由器通过查看MP-BGP路由信息自动确定用于特定IPv6目的地的IPv4信令LSP。
The IPv4-signaled LSPs can be established using any existing technique for label setup [RFC3031] (LDP, RSVP-TE, etc.).
可以使用任何现有的标签设置技术[RFC3031]（LDP、RSVP-TE等）来建立IPv4信号LSP。
To ensure interoperability among systems that implement the 6PE approach described in this document, all such systems MUST support tunneling using IPv4-signaled MPLS LSPs established by LDP [RFC3036].
为确保实施本文件所述6PE方法的系统之间的互操作性，所有此类系统必须支持使用LDP[RFC3036]建立的IPv4信号MPLS LSP进行隧道传输。
When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than successively prepend an IPv4 header and then perform label imposition
当通过IPv4 MPLS主干对IPv6数据包进行隧道传输时，而不是依次在IPv4报头前加上前缀，然后执行标签强制
based on the IPv4 header, the ingress 6PE Router MUST directly perform label imposition of the IPv6 header without prepending any IPv4 header. The (outer) label imposed MUST correspond to the IPv4- signaled LSP starting on the ingress 6PE Router and ending on the egress 6PE Router.
基于IPv4报头，入口6PE路由器必须直接执行IPv6报头的标签施加，而无需预先添加任何IPv4报头。施加的（外部）标签必须对应于从入口6PE路由器开始到出口6PE路由器结束的IPv4信号LSP。
While this approach could theoretically operate in some situations using a single level of labels, there are significant advantages in using a second level of labels that are bound to IPv6 prefixes via MP-BGP advertisements in accordance with [RFC3107].
虽然这种方法在理论上可以在某些情况下使用单一级别的标签，但根据[RFC3107]，使用通过MP-BGP广告绑定到IPv6前缀的第二级别标签具有显著优势。
For instance, the use of a second level label allows Penultimate Hop Popping (PHP) on the IPv4 Label Switch Router (LSR) upstream of the egress 6PE router, without any IPv6 capabilities/upgrades on the penultimate router; this is because it still transmits MPLS packets even after the PHP (instead of having to transmit IPv6 packets and encapsulate them appropriately).
例如，使用第二级标签允许在出口6PE路由器上游的IPv4标签交换路由器（LSR）上进行倒数第二跳弹出（PHP），而在倒数第二路由器上没有任何IPv6功能/升级；这是因为即使在PHP之后，它仍然传输MPLS数据包（而不是必须传输IPv6数据包并适当地封装它们）。
Also, an existing IPv4-signaled LSP that is using "IPv4 Explicit NULL label" over the last hop (e.g., because that LSP is already being used to transport IPv4 traffic with the Pipe Diff-Serv Tunneling Model as defined in [RFC3270]) could not be used to carry IPv6 with a single label since the "IPv4 Explicit NULL label" cannot be used to carry native IPv6 traffic (see [RFC3032]), while it could be used to carry labeled IPv6 traffic (see [RFC4182]).
此外，在最后一个跃点上使用“IPv4显式空标签”的现有IPv4信号LSP（例如，因为该LSP已被用于使用[RFC3270]中定义的管道区分服务隧道模型传输IPv4通信量）不能用于承载带有单个标签的IPv6，因为“IPv4显式空标签”无法用于承载本机IPv6流量（请参阅[RFC3032]），而可以用于承载带标签的IPv6流量（请参阅[RFC4182]）。
This is why a second label MUST be used with the 6PE approach.
这就是为什么6PE方法必须使用第二个标签的原因。
The label bound by MP-BGP to the IPv6 prefix indicates to the egress 6PE Router that the packet is an IPv6 packet. This label advertised by the egress 6PE Router with MP-BGP MAY be an arbitrary label value, which identifies an IPv6 routing context or outgoing interface to send the packet to, or MAY be the IPv6 Explicit Null Label. An ingress 6PE Router MUST be able to accept any such advertised label.
MP-BGP绑定到IPv6前缀的标签向出口6PE路由器指示该数据包是IPv6数据包。使用MP-BGP的出口6PE路由器公布的该标签可以是任意标签值，用于标识要将数据包发送到的IPv6路由上下文或传出接口，也可以是IPv6显式空标签。入口6PE路由器必须能够接受任何此类广告标签。
[RFC2460] requires that every link in the IPv6 Internet have an MTU of 1280 octets or larger. Therefore, on MPLS links that are used for transport of IPv6, as per the 6PE approach, and that do not support link-specific fragmentation and reassembly, the MTU must be configured to at least 1280 octets plus the encapsulation overhead.
[RFC2460]要求IPv6 Internet中的每条链路都有1280个八位字节或更大的MTU。因此，根据6PE方法，在用于IPv6传输且不支持特定于链路的分段和重新组装的MPLS链路上，MTU必须配置为至少1280个八位字节加上封装开销。
Some IPv6 hosts might be sending packets larger than the MTU available in the IPv4 MPLS core and rely on Path MTU discovery to learn about those links. To simplify MTU discovery operations, one option is for the network administrator to engineer the MTU on the core facing interfaces of the ingress 6PE consistent with the core MTU. ICMP 'Packet Too Big' messages can then be sent back by the ingress 6PE without the corresponding packets ever entering the MPLS
某些IPv6主机可能正在发送比IPv4 MPLS核心中可用的MTU大的数据包，并依赖路径MTU发现来了解这些链路。为了简化MTU发现操作，一个选项是网络管理员在与核心MTU一致的入口6PE面向核心的接口上设计MTU。ICMP“数据包太大”消息可由入口6PE发回，而相应的数据包从未进入MPLS
core. Otherwise, routers in the IPv4 MPLS network have the option to generate an ICMP "Packet Too Big" message using mechanisms as described in Section 2.3.2, "Tunneling Private Addresses through a Public Backbone" of [RFC3032].
果心否则，IPv4 MPLS网络中的路由器可以选择使用[RFC3032]第2.3.2节“通过公共主干的隧道专用地址”中所述的机制生成ICMP“数据包太大”消息。
Note that in the above case, should a core router with an outgoing link with an MTU smaller than 1280 receive an encapsulated IPv6 packet larger than 1280, then the mechanisms of [RFC3032] may result in the "Packet Too Big" message never reaching the sender. This is because, according to [RFC4443], the core router will build an ICMP "Packet Too Big" message filled with the invoking packet up to 1280 bytes, and when forwarding downstream towards the egress PE as per [RFC3032], the MTU of the outgoing link will cause the packet to be dropped. This may cause significant operational problems; the originator of the packets will notice that his data is not getting through, without knowing why and where they are discarded. This issue would only occur if the above recommendation (to configure MTU on MPLS links of at least 1280 octets plus encapsulation overhead) is not adhered to (perhaps by misconfiguration).
注意，在上述情况下，如果具有MTU小于1280的传出链路的核心路由器接收到大于1280的封装IPv6数据包，则[RFC3032]的机制可能导致“数据包太大”消息永远无法到达发送方。这是因为，根据[RFC4443]，核心路由器将构建一个ICMP“Packet Too Big”（数据包太大）消息，该消息中填充了多达1280字节的调用数据包，并且当按照[RFC3032]向出口PE下游转发时，输出链路的MTU将导致数据包被丢弃。这可能导致重大的操作问题；数据包的发起者会注意到他的数据没有通过，而不知道数据包被丢弃的原因和地点。只有在不遵守上述建议（在至少1280个八位字节的MPLS链路上配置MTU加上封装开销）的情况下（可能是由于配置错误），才会出现此问题。
This section discusses the case where two IPv6 islands are connected to different Autonomous Systems (ASes).
本节讨论两个IPv6孤岛连接到不同自治系统（ASE）的情况。
Like in the case of multi-AS backbone operations for IPv4 VPNs described in Section 10 of [RFC4364], three main approaches can be distinguished:
与[RFC4364]第10节中描述的IPv4 VPN的多AS主干操作一样，可以区分三种主要方法：
a. eBGP redistribution of IPv6 routes from AS to neighboring AS
a. 从AS到相邻AS的IPv6路由的eBGP重新分配
This approach is the equivalent for exchange of IPv6 routes to procedure (a) described in Section 10 of [RFC4364] for the exchange of VPN-IPv4 routes.
此方法与[RFC4364]第10节中描述的交换VPN-IPv4路由的过程（a）中的IPv6路由交换等效。
In this approach, the 6PE routers use IBGP (according to [RFC2545] and [RFC3107] and as described in this document for the single-AS situation) to redistribute labeled IPv6 routes either to an Autonomous System Border Router (ASBR) 6PE router, or to a route reflector of which an ASBR 6PE router is a client. The ASBR then uses eBGP to redistribute the (non-labeled) IPv6 routes to an ASBR in another AS, which in turn distributes them to the 6PE routers in that AS as described earlier in this specification, or perhaps to another ASBR, which in turn distributes them etc.
在这种方法中，6PE路由器使用IBGP（根据[RFC2545]和[RFC3107]以及本文档中针对单一as情况所述）将带标签的IPv6路由重新分发到自治系统边界路由器（ASBR）6PE路由器或ASBR 6PE路由器是其客户端的路由反射器。然后，ASBR使用eBGP将（未标记的）IPv6路由重新分配给另一个AS中的ASBR，后者将其分配给该AS中的6PE路由器，如本规范前面所述，或者可能分配给另一个ASBR，后者将其分配给其他AS。
There may be one, or multiple, ASBR interconnection(s) across any two ASes. IPv6 needs to be activated on the inter-ASBR links and each ASBR 6PE router has at least one IPv6 address on the interface to that link.
任何两个ASE之间可能有一个或多个ASBR互连。需要在ASBR间链路上激活IPv6，并且每个ASBR 6PE路由器在该链路的接口上至少有一个IPv6地址。
No inter-AS LSPs are used. There is effectively a separate mesh of LSPs across the 6PE routers within each AS.
由于使用了LSP，因此不使用inter。每个AS内的6PE路由器上都有一个单独的LSP网格。
In this approach, the ASBR exchanging IPv6 routes may peer over IPv6 or IPv4. The exchange of IPv6 routes MUST be carried out as per [RFC2545].
在这种方法中，交换IPv6路由的ASBR可以通过IPv6或IPv4进行对等。IPv6路由的交换必须按照[RFC2545]进行。
Note that the peering ASBR in the neighboring AS to which the IPv6 routes were distributed with eBGP, should in its turn redistribute these routes to the 6PEs in its AS using IBGP and encoding its own IPv4 address as the IPv4-mapped IPv6 BGP Next Hop.
请注意，与eBGP一起分发IPv6路由的相邻AS中的对等ASBR应依次使用IBGP将这些路由重新分发到AS中的6PE，并将其自己的IPv4地址编码为IPv4映射的IPv6 BGP下一跳。
b. eBGP redistribution of labeled IPv6 routes from AS to neighboring AS
b. eBGP将标记的IPv6路由从AS重新分配到相邻AS
This approach is the equivalent for exchange of IPv6 routes to procedure (b) described in Section 10 of [RFC4364] for the exchange of VPN-IPv4 routes.
此方法与[RFC4364]第10节中描述的交换VPN-IPv4路由的过程（b）的IPv6路由交换等效。
In this approach, the 6PE routers use IBGP (as described earlier in this document for the single-AS situation) to redistribute labeled IPv6 routes either to an Autonomous System Border Router (ASBR) 6PE router, or to a route reflector of which an ASBR 6PE router is a client. The ASBR then uses eBGP to redistribute the labeled IPv6 routes to an ASBR in another AS, which in turn distributes them to the 6PE routers in that AS as described earlier in this specification, or perhaps to another ASBR, which in turn distributes them, etc.
在这种方法中，6PE路由器使用IBGP（如本文档前面针对单一as情况所述）将带标签的IPv6路由重新分发到自治系统边界路由器（ASBR）6PE路由器或ASBR 6PE路由器作为客户端的路由反射器。然后，ASBR使用eBGP将标记的IPv6路由重新分配给另一个AS中的ASBR，后者将其分配给该AS中的6PE路由器，如本规范前面所述，或者可能分配给另一个ASBR，后者将其分配，等等。
There may be one, or multiple, ASBR interconnection(s) across any two ASes. IPv6 may or may not be activated on the inter-ASBR links.
任何两个ASE之间可能有一个或多个ASBR互连。IPv6可能在ASBR间链路上激活，也可能不激活。
This approach requires that there be label switched paths established across ASes. Hence the corresponding considerations described for procedure (b) in Section 10 of [RFC4364] apply equally to this approach for IPv6.
这种方法要求在ASE之间建立标签交换路径。因此，[RFC4364]第10节中描述的程序（b）的相应注意事项同样适用于IPv6的这种方法。
In this approach, the ASBR exchanging IPv6 routes may peer over IPv4 or IPv6 (in which case IPv6 obviously needs to be activated on the inter-ASBR link). When peering over IPv6, the exchange of labeled IPv6 routes MUST be carried out as per [RFC2545] and [RFC3107]. When peering over IPv4, the exchange of labeled IPv6
在这种方法中，交换IPv6路由的ASBR可以通过IPv4或IPv6进行对等（在这种情况下，显然需要在ASBR间链路上激活IPv6）。当通过IPv6进行对等时，必须按照[RFC2545]和[RFC3107]交换标记的IPv6路由。通过IPv4进行对等时，交换标记为IPv6的
routes MUST be carried out as per [RFC2545] and [RFC3107] with encoding of the IPv4 address of the ASBR as an IPv4-mapped IPv6 address in the BGP Next Hop field.
必须按照[RFC2545]和[RFC3107]执行路由，并在BGP下一跳字段中将ASBR的IPv4地址编码为IPv4映射的IPv6地址。
c. Multi-hop eBGP redistribution of labeled IPv6 routes between source and destination ASes, with eBGP redistribution of labeled IPv4 routes from AS to neighboring AS.
c. 源和目标ASE之间标记IPv6路由的多跳eBGP重新分配，以及从AS到相邻AS的标记IPv4路由的eBGP重新分配。
This approach is the equivalent for exchange of IPv6 routes to procedure (c) described in Section 10 of [RFC4364] for exchange of VPN-IPv4 routes.
此方法与[RFC4364]第10节中描述的交换VPN-IPv4路由的过程（c）的IPv6路由交换等效。
In this approach, IPv6 routes are neither maintained nor distributed by the ASBR routers. The ASBR routers need not be dual stack, but may be IPv4/MPLS-only routers. An ASBR needs to maintain labeled IPv4 /32 routes to the 6PE 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 /32 routes. This results in the creation of an IPv4 label switched path from the ingress 6PE router to the egress 6PE router. Now 6PE routers in different ASes can establish multi-hop eBGP connections to each other over IPv4, and can exchange labeled IPv6 routes (with an IPv4-mapped IPv6 BGP Next Hop) over those connections.
在这种方法中，IPv6路由既不由ASBR路由器维护也不由ASBR路由器分发。ASBR路由器不需要是双栈，但可以是仅IPv4/MPLS路由器。ASBR需要在其AS中维护到6PE路由器的标记IPv4/32路由。它使用eBGP将这些路由分发给其他ASE。任何传输ASE中的ASBR也必须使用eBGP沿着标记的IPv4/32路由传递。这导致创建从入口6PE路由器到出口6PE路由器的IPv4标签交换路径。现在，不同ASE中的6PE路由器可以通过IPv4相互建立多跳eBGP连接，并可以通过这些连接交换标记的IPv6路由（使用IPv4映射的IPv6 BGP下一跳）。
IPv6 need not be activated on the inter-ASBR links.
无需在ASBR间链路上激活IPv6。
The considerations described for procedure (c) in Section 10 of [RFC4364] with respect to possible use of multi-hop eBGP connections via route-reflectors in different ASes, as well as with respect to the use of a third label in case the IPv4 /32 routes for the PE routers are NOT made known to the P routers, apply equally to this approach for IPv6.
[RFC4364]第10节中程序（c）所述的考虑事项，涉及在不同ASE中通过路由反射器可能使用多跳eBGP连接，以及在P路由器不知道PE路由器的IPv4/32路由的情况下使用第三个标签，同样适用于IPv6的这种方法。
This approach requires that there be IPv4 label switched paths established across the ASes leading from a packet's ingress 6PE router to its egress 6PE router. Hence the considerations described for procedure (c) in Section 10 of [RFC4364], with respect to LSPs spanning multiple ASes, apply equally to this approach for IPv6.
这种方法要求在ASE之间建立IPv4标签交换路径，从数据包的入口6PE路由器到其出口6PE路由器。因此，[RFC4364]第10节中描述的关于跨越多个ASE的LSP的程序（c）的注意事项同样适用于IPv6的这种方法。
Note also that the exchange of IPv6 routes can only start after BGP has created IPv4 connectivity between the ASes.
还请注意，IPv6路由的交换只能在BGP在ASE之间创建IPv4连接后开始。
The extensions defined in this document allow BGP to propagate reachability information about IPv6 routes over an MPLS IPv4 core network. As such, no new security issues are raised beyond those that already exist in BGP-4 and use of MP-BGP for IPv6.
本文档中定义的扩展允许BGP通过MPLS IPv4核心网络传播有关IPv6路由的可达性信息。因此，除了BGP-4和MP-BGP在IPv6中的使用中已经存在的安全问题外，没有提出任何新的安全问题。
The security features of BGP and corresponding security policy defined in the ISP domain are applicable.
BGP的安全特性和ISP域中定义的相应安全策略适用。
For the inter-AS distribution of IPv6 routes according to case (a) of Section 4 of this document, no new security issues are raised beyond those that already exist in the use of eBGP for IPv6 [RFC2545].
对于根据本文件第4节案例（a）的IPv6路由的AS间分发，除了在使用eBGP For IPv6[RFC2545]时已经存在的安全问题外，没有提出任何新的安全问题。
For the inter-AS distribution of IPv6 routes according to case (b) and (c) of Section 4 of this document, the procedures require that there be label switched paths established across the AS boundaries. Hence the appropriate trust relationships must exist between and among the set of ASes along the path. Care must be taken to avoid "label spoofing". To this end an ASBR 6PE SHOULD only accept labeled packets from its peer ASBR 6PE if the topmost label is a label that it has explicitly signaled to that peer ASBR 6PE.
根据本文件第4节案例（b）和（c），对于IPv6路由的AS间分发，程序要求跨AS边界建立标签交换路径。因此，路径上的一组ASE之间必须存在适当的信任关系。必须注意避免“标签欺骗”。为此，ASBR 6PE应仅接受来自其对等ASBR 6PE的标记数据包，前提是最上面的标签是其已明确向该对等ASBR 6PE发出信号的标签。
Note that for the inter-AS distribution of IPv6 routes, according to case (c) of Section 4 of this document, label spoofing may be more difficult to prevent. Indeed, the MPLS label distributed with the IPv6 routes via multi-hop eBGP is directly sent from the egress 6PE to ingress 6PEs in another AS (or through route reflectors). This label is advertised transparently through the AS boundaries. When the egress 6PE that sent the labeled IPv6 routes receives a data packet that has this particular label on top of its stack, it may not be able to verify whether the label was pushed on the stack by an ingress 6PE that is allowed to do so. As such, one AS may be vulnerable to label spoofing in a different AS. The same issue equally applies to the option (c) of Section 10 of [RFC4364]. Just as it is the case for [RFC4364], addressing this particular security issue is for further study.
请注意，对于IPv6路由的AS间分发，根据本文件第4节的案例（c），标签欺骗可能更难防止。实际上，通过多跳eBGP与IPv6路由一起分发的MPLS标签直接从出口6PE发送到另一AS中的入口6PE（或通过路由反射器）。此标签通过AS边界进行透明广告。当发送标记的IPv6路由的出口6PE接收到在其堆栈顶部具有此特定标签的数据包时，它可能无法验证标签是否由允许这样做的入口6PE推送到堆栈上。因此，一个As可能容易受到不同As中标签欺骗的攻击。同样的问题同样适用于[RFC4364]第10节的选项（c）。正如[RFC4364]的情况一样，解决这个特殊的安全问题还有待进一步研究。
We wish to thank Gerard Gastaud and Eric Levy-Abegnoli who contributed to this document. We also wish to thank Tri T. Nguyen, who initiated this document, but unfortunately passed away much too soon. We also thank Pekka Savola for his valuable comments and suggestions.
我们要感谢杰拉德·加斯托德和埃里克·利维·阿贝格诺利对本文件的贡献。我们还要感谢Tri T.Nguyen，他发起了这份文件，但不幸的是，他去世得太快了。我们还感谢佩卡·萨沃拉提出的宝贵意见和建议。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[RFC2545]Marques，P.和F.Dupont，“将BGP-4多协议扩展用于IPv6域间路由”，RFC 25451999年3月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.，和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC3107]Rekhter，Y.和E.Rosen，“在BGP-4中携带标签信息”，RFC 3107，2001年5月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4029]Lind，M.，Ksinant，V.，Park，S.，Baudot，A.，和P.Savola，“将IPv6引入ISP网络的场景和分析”，RFC 40292005年3月。
[RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS Explicit NULL", RFC 4182, September 2005.
[RFC4182]Rosen，E.，“消除对MPLS显式NULL使用的限制”，RFC 41822005年9月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
[RFC4659]De Clercq，J.，Ooms，D.，Carugi，M.，和F.Le Faucheur，“用于IPv6 VPN的BGP-MPLS IP虚拟专用网络（VPN）扩展”，RFC 46592006年9月。
Authors' Addresses
作者地址
Jeremy De Clercq Alcatel-Lucent Copernicuslaan 50 Antwerpen 2018 Belgium
Jeremy De Clercq Alcatel-Lucent Copernicuslaan 50安特卫普2018比利时
EMail: jeremy.de_clercq@alcatel-lucent.be
EMail: jeremy.de_clercq@alcatel-lucent.be
Dirk Ooms OneSparrow Belegstraat 13 Antwerpen 2018 Belgium
Dirk Ooms OneSparrow Belegstraat 13安特卫普2018比利时
EMail: dirk@onesparrow.com
EMail: dirk@onesparrow.com
Stuart Prevost BT Room 136 Polaris House, Adastral Park, Martlesham Heath Ipswich Suffolk IP5 3RE England EMail: stuart.prevost@bt.com
斯图尔特·普雷沃斯特英国电信公司136室，阿达斯特拉尔公园，马特勒沙姆·希思·伊普斯维奇萨福克IP5 3RE英格兰电子邮件：斯图尔特。prevost@bt.com
Francois Le Faucheur Cisco Domaine Green Side, 400 Avenue de Roumanille Biot, Sophia Antipolis 06410 France
法国索菲亚安提波利斯市鲁马尼尔比奥大道400号弗朗索瓦·勒·福舍尔·思科绿边庄园，邮编：06410
EMail: flefauch@cisco.com
EMail: flefauch@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。