Internet Engineering Task Force (IETF) P. Pillay-Esnault
Request for Comments: 6565 Cisco Systems
Category: Standards Track P. Moyer
ISSN: 2070-1721 Pollere, Inc.
J. Doyle
Jeff Doyle and Associates
E. Ertekin
M. Lundberg
Booz Allen Hamilton
June 2012
Internet Engineering Task Force (IETF) P. Pillay-Esnault
Request for Comments: 6565 Cisco Systems
Category: Standards Track P. Moyer
ISSN: 2070-1721 Pollere, Inc.
J. Doyle
Jeff Doyle and Associates
E. Ertekin
M. Lundberg
Booz Allen Hamilton
June 2012
OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol
OSPFv3作为提供商边缘到客户边缘（PE-CE）路由协议
Abstract
摘要
Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. Support currently exists for both IPv4 and IPv6 VPNs; however, only Open Shortest Path First version 2 (OSPFv2) as PE-CE protocol is specified. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document.
许多服务提供商（SP）使用一种技术向其客户提供虚拟专用网络（VPN）服务，其中客户边缘（CE）路由器是提供商边缘（PE）路由器的路由对等方。边界网关协议（BGP）用于在提供商的IP主干网络上分发客户的路由，多协议标签交换（MPLS）用于在提供商的主干网络上传输客户数据包。目前支持IPv4和IPv6 VPN；但是，仅指定开放最短路径第一版本2（OSPFv2）作为PE-CE协议。本文档扩展了这些规范，以支持OSPF版本3（OSPFv3）作为PE-CE路由协议。OSPFv3 PE-CE功能与OSPFv2相同，但本文档中描述的不同之处除外。
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/rfc6565.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6565.
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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
2. Specification of Requirements ...................................4
3. Requirements ....................................................4
3.1. OSPFv3 Specificities .......................................5
4. BGP/OSPFv3 Interaction Procedures for PE Routers ................5
4.1. VRFs and OSPFv3 Instances ..................................5
4.1.1. Independent OSPFv3 Instances in PEs .................6
4.1.2. OSPFv3 Domain Identifier ............................6
4.2. OSPFv3 Areas ...............................................7
4.3. VRFs and Routes ............................................7
4.3.1. OSPFv3 Routes on PEs ................................8
4.3.2. VPN-IPv6 Routes Received from MP-BGP ................9
4.4. BGP Extended Communities Attribute ........................12
4.5. Loop Prevention Techniques ................................14
4.5.1. OSPFv3 Down Bit ....................................15
4.5.2. Other Possible Loops ...............................15
5. OSPFv3 Sham Links ..............................................15
5.1. Creating a Sham Link ......................................16
5.2. OSPF Protocol on Sham Link ................................16
5.3. OSPF Packet Forwarding on Sham Link .......................17
6. Multiple Address Family Support ................................17
7. Security Considerations ........................................18
8. IANA Considerations ............................................18
9. Acknowledgments ................................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
1. Introduction ....................................................4
2. Specification of Requirements ...................................4
3. Requirements ....................................................4
3.1. OSPFv3 Specificities .......................................5
4. BGP/OSPFv3 Interaction Procedures for PE Routers ................5
4.1. VRFs and OSPFv3 Instances ..................................5
4.1.1. Independent OSPFv3 Instances in PEs .................6
4.1.2. OSPFv3 Domain Identifier ............................6
4.2. OSPFv3 Areas ...............................................7
4.3. VRFs and Routes ............................................7
4.3.1. OSPFv3 Routes on PEs ................................8
4.3.2. VPN-IPv6 Routes Received from MP-BGP ................9
4.4. BGP Extended Communities Attribute ........................12
4.5. Loop Prevention Techniques ................................14
4.5.1. OSPFv3 Down Bit ....................................15
4.5.2. Other Possible Loops ...............................15
5. OSPFv3 Sham Links ..............................................15
5.1. Creating a Sham Link ......................................16
5.2. OSPF Protocol on Sham Link ................................16
5.3. OSPF Packet Forwarding on Sham Link .......................17
6. Multiple Address Family Support ................................17
7. Security Considerations ........................................18
8. IANA Considerations ............................................18
9. Acknowledgments ................................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
[RFC4364] offers Service Providers (SPs) a method for providing Layer 3 Virtual Private Network (VPN) services to subtending customer networks. Using the procedures defined in [RFC4364], Provider Edge (PE) routers separate customer VPN routing information into Virtual Routing and Forwarding (VRF) tables. The Border Gateway Protocol (BGP) is used to disseminate customer network VPN routes between PE VRFs configured in the same VPN.
[RFC4364]为服务提供商（SP）提供了一种向子终端客户网络提供第3层虚拟专用网络（VPN）服务的方法。使用[RFC4364]中定义的过程，提供商边缘（PE）路由器将客户VPN路由信息分离到虚拟路由和转发（VRF）表中。边界网关协议（BGP）用于在同一VPN中配置的PE VRF之间传播客户网络VPN路由。
The initial BGP/MPLS IP VPN specification enabled PE routers to learn routes within customer sites through static routing, or through a dynamic routing protocol instantiated on the PE-CE link. Specifically, [RFC4364] (and its predecessor, [RFC2547]) included support for dynamic routing protocols such as BGP, RIP, and OSPFv2. The OSPFv2 as the Provider/Customer Edge Protocol specification [RFC4577] further updates the operation of OSPFv2 as the PE-CE routing protocol by detailing additional extensions to enable intra-domain routing connectivity between OSPFv2-based customer sites.
最初的BGP/MPLS IP VPN规范使PE路由器能够通过静态路由或PE-CE链路上实例化的动态路由协议了解客户站点内的路由。具体而言，[RFC4364]（及其前身，[RFC2547]）包括对动态路由协议（如BGP、RIP和OSPFv2）的支持。作为提供商/客户边缘协议规范的OSPFv2[RFC4577]进一步更新了作为PE-CE路由协议的OSPFv2的操作，详细说明了其他扩展，以实现基于OSPFv2的客户站点之间的域内路由连接。
While [RFC4364] was defined for IPv4-based networks, [RFC4659] extends support to IPv6 VPNs. It is expected that OSPFv3 will be used as the IGP for some IPv6 VPNs just as the OSPFv2 was used for IPv4 VPNs. The advantages of using OSPFv3 as a PE-CE protocol are the same as for the IPv4 VPN deployment.
虽然[RFC4364]是为基于IPv4的网络定义的，但[RFC4659]扩展了对IPv6 VPN的支持。预计OSPFv3将用作某些IPv6 VPN的IGP，就像OSPFv2用于IPv4 VPN一样。将OSPFv3用作PE-CE协议的优点与IPv4 VPN部署相同。
This document defines the mechanisms required to enable the operation of OSPFv3 as the PE-CE routing protocol. In doing so, it reuses, and extends where necessary, methods defined in [RFC4659] and [RFC4577]. This document also includes the specifications for maintaining intra-domain routing connectivity between OSPFv3-based customer sites across an SP backbone.
本文件定义了使OSPFv3作为PE-CE路由协议运行所需的机制。在此过程中，它重用并在必要时扩展[RFC4659]和[RFC4577]中定义的方法。本文档还包括跨SP主干网维护基于OSPFv3的客户站点之间的域内路由连接的规范。
We presuppose familiarity with the contents of [RFC4364], [RFC4659], [RFC4577], [RFC4576], [RFC5340], and [RFC2328].
我们假设熟悉[RFC4364]、[RFC4659]、[RFC4577]、[RFC4576]、[RFC5340]和[RFC2328]的内容。
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 benefits and considerations associated with deploying OSPFv3 as the PE-CE routing protocol are similar to those described in [RFC4577]. The requirements described in Section 3 of [RFC4577] remain semantically identical for the deployment of OSPFv3.
将OSPFv3部署为PE-CE路由协议的好处和注意事项与[RFC4577]中描述的类似。[RFC4577]第3节中描述的要求在语义上与OSPFv3的部署保持一致。
[RFC5340] describes the modifications required to OSPF to support IPv6. In that specification, many of the fundamental mechanisms associated with OSPFv2 remain unchanged for OSPFv3. Consequently, the operation of OSPFv3 as the PE-CE routing protocol is very similar to OSPFv2 as the PE-CE protocol.
[RFC5340]描述了OSPF支持IPv6所需的修改。在该规范中，与OSPFv2相关的许多基本机制对于OSPFv3保持不变。因此，作为PE-CE路由协议的OSPFv3的操作与作为PE-CE协议的OSPFv2非常相似。
Section 2 of [RFC5340] describes the differences between OSPFv3 and OSPFv2. Several of these changes will require modifications to the architecture described in [RFC4577]. These differences and their corresponding impact to [RFC4577] are described below:
[RFC5340]第2节描述了OSPFv3和OSPFv2之间的区别。其中一些更改需要对[RFC4577]中描述的体系结构进行修改。这些差异及其对[RFC4577]的相应影响如下所述：
New LSA types:
新的LSA类型：
For an IPv6 VPN architecture where customers interface with providers through OSPFv3, traditional BGP/OSPF interactions specify that VPN-IPv6 reachability information redistributed into OSPFv3 will be expressed as AS-External OSPFv3 LSAs. Instead, it may be desirable to view these LSAs as inter-area-prefix LSAs. The OSPF Route Type Extended Communities attribute defined in [RFC4577] is extended to include OSPFv3 route types. These new encodings are defined in Section 4.4.
对于客户通过OSPFv3与提供商交互的IPv6 VPN体系结构，传统的BGP/OSPF交互指定重新分发到OSPFv3的VPN-IPv6可达性信息将表示为外部OSPFv3 LSA。相反，可能希望将这些lsa视为区域间前缀lsa。[RFC4577]中定义的OSPF路由类型扩展社区属性被扩展以包括OSPFv3路由类型。第4.4节定义了这些新编码。
Multiple instances over a link:
链接上的多个实例：
OSPFv3 operates on a per-link basis as opposed to OSPFv2, which operates on a per-IP-subnet basis. The support of multiple OSPFv3 protocol instances on a link changes the architecture described in [RFC4577]. [RFC4577] specifies that each interface belongs to no more than one OSPF instance. For OSPFv3, multiple instances can be established over a single interface and associated with the same VRF.
OSPFv3基于每条链路运行，而OSPFv2基于每条IP子网运行。链路上支持多个OSPFv3协议实例改变了[RFC4577]中描述的体系结构。[RFC4577]指定每个接口不属于多个OSPF实例。对于OSPFv3，可以通过单个接口建立多个实例，并与同一VRF关联。
In addition to establishing multiple OSPFv3 instances over a single PE-CE link, multiple OSPFv3 instances can also be established across a sham link. This enables multiple OSPFv3 instances associated with a VRF to independently establish intra-area connectivity to other OSPFv3 instances attached to a remote PE VRF. Support for multiple OSPFv3 instances across the sham link is described in Section 5.
除了在单个PE-CE链路上建立多个OSPFv3实例外，还可以跨假链路建立多个OSPFv3实例。这使得与VRF关联的多个OSPFv3实例能够独立地建立与连接到远程PE VRF的其他OSPFv3实例的区域内连接。第5节描述了对sham链路上多个OSPFv3实例的支持。
The relationship between VRFs, interfaces, and OSPFv3 instances on a PE router is described in the following section.
PE路由器上VRF、接口和OSPFv3实例之间的关系将在下一节中描述。
As defined in [RFC4364], a PE router can be configured with one or more VRFs. Each VRF configured on the PE corresponds to a customer VPN and retains the destinations that are reachable within that VPN. Each VRF may be associated with one or more interfaces, which allows multiple sites to participate in the same VPN. If OSPFv3 is instantiated on an interface associated with a VRF, the VRF will be populated with OSPFv3 routing information.
如[RFC4364]中所定义，PE路由器可以配置一个或多个VRF。PE上配置的每个VRF对应于客户VPN，并保留该VPN内可访问的目的地。每个VRF可与一个或多个接口相关联，从而允许多个站点参与同一VPN。如果在与VRF相关联的接口上实例化OSPFv3，则VRF将填充OSPFv3路由信息。
As OSPFv3 supports multiple instances on a single interface, it is therefore possible that multiple customer sites can connect to the same interface of a PE router (e.g., through a Layer 2 switch) using distinct OSPFv3 instances. A PE interface can be associated with only one VRF, and all OSPFv3 instances running on the same interface MUST be associated with the same VRF. Configurations where a PE interface is associated with multiple VRFs are out of scope for this document.
由于OSPFv3支持单个接口上的多个实例，因此多个客户站点可以使用不同的OSPFv3实例连接到PE路由器的同一接口（例如，通过第2层交换机）。PE接口只能与一个VRF关联，在同一接口上运行的所有OSPFv3实例必须与同一VRF关联。PE接口与多个VRF关联的配置不在本文档范围内。
Similar to [RFC4577], the PE must associate at least one OSPFv3 instance for each OSPFv3 domain to which it attaches, and each instance of OSPFv3 MUST be associated with a single VRF.
与[RFC4577]类似，PE必须为其连接的每个OSPFv3域关联至少一个OSPFv3实例，并且OSPFv3的每个实例必须与单个VRF关联。
The support of multiple PE-CE OSPFv3 instances per PE interface does not change the paradigm that an OSPF instance can be associated with only a single VRF. Furthermore, for each instance instantiated on the interface, the PE establishes adjacencies with corresponding CEs associated with the instance. Note that although multiple instances may populate a common VRF, they do not leak routes to one another, unless configured to do so.
每个PE接口支持多个PE-CE OSPFv3实例并不会改变一个OSPF实例只能与一个VRF关联的模式。此外，对于接口上实例化的每个实例，PE与与实例关联的相应CE建立邻接。请注意，尽管多个实例可能会填充一个公共VRF，但它们不会相互泄漏路由，除非配置为这样做。
The OSPFv3 Domain ID describes the administrative domain of the OSPF instance that originated the route. It has an AS-wide significance and is one of the parameters used to determine whether a VPN-IPv6 route should be translated as an Inter-area-prefix LSA or External LSA. Each OSPFv3 instance MUST have a primary Domain ID that is transported along with the VPN-IPv6 route in a BGP attribute over the VPN backbone. Each OSPFv3 instance may have a set of secondary Domain IDs that applies to other OSPFv3 instances within its administrative domain.
OSPFv3域ID描述发起路由的OSPF实例的管理域。它具有同样广泛的意义，是用于确定VPN-IPv6路由应转换为区域间前缀LSA还是外部LSA的参数之一。每个OSPFv3实例必须具有一个主域ID，该ID与VPN主干上BGP属性中的VPN-IPv6路由一起传输。每个OSPFv3实例可能有一组辅助域ID，这些ID应用于其管理域内的其他OSPFv3实例。
The primary Domain ID may either be configured or be set to a value of NULL. The secondary Domain IDs are only allowed if a non-NULL primary Domain ID is configured. The Domain ID MUST be configured on a per-OSPFv3 instance basis.
主域ID可以配置或设置为空值。仅当配置了非空的主域ID时，才允许使用辅助域ID。必须基于每个OSPFv3实例配置域ID。
The Domain ID is used to determine whether an incoming VPN-IPv6 route belongs to the same domain as the receiving OSPFv3 instance. An incoming VPN-IPv6 route is said to belong to the same domain if a non-NULL incoming Domain ID matches either the local primary or one of the secondary Domain IDs. If the local Domain ID and incoming Domain ID are NULL, it is considered a match.
域ID用于确定传入VPN-IPv6路由是否属于与接收OSPFv3实例相同的域。如果非空传入域ID与本地主域ID或其中一个辅助域ID匹配，则传入VPN-IPv6路由称为属于同一域。如果本地域ID和传入域ID为空，则认为匹配。
Sections 4.1.4 and 4.2.3 of [RFC4577] describe the characteristics of a PE router within an OSPFv2 domain. The mechanisms and expected behavior described in [RFC4577] are applicable to an OSPFv3 domain.
[RFC4577]第4.1.4节和第4.2.3节描述了OSPFv2域内PE路由器的特性。[RFC4577]中描述的机制和预期行为适用于OSPFv3域。
From the perspective of the CE, the PE appears as any other OSPFv3 neighbor. There is no requirement for the CE to support any mechanisms of IPv6 BGP/MPLS VPNs or for the CE to have any awareness of the VPNs, thereby enabling any OSPFv3 implementation to be used on a CE.
从CE的角度来看，PE显示为任何其他OSPFv3邻居。不要求CE支持IPv6 BGP/MPLS VPN的任何机制，也不要求CE了解VPN，从而允许在CE上使用任何OSPFv3实现。
Because the export and import policies might cause different routes to be installed in different VRFs of the same OSPFv3 domain, the VPN backbone cannot be considered as a single router from the perspective of the domain's CEs. Rather, each CE should view its connected PE as a separate router.
由于导出和导入策略可能会导致在同一OSPFv3域的不同VRF中安装不同的路由，因此从域的CEs的角度来看，VPN主干不能被视为单个路由器。相反，每个CE应将其连接的PE视为单独的路由器。
The PE uses OSPFv3 to distribute routes to CEs, and MP-BGP [RFC4760] to distribute VPN-IPv6 routes to other (remote) PE routers as defined in [RFC4659]. An IPv6 prefix installed in the VRF by OSPFv3 is changed to a VPN-IPv6 prefix by the addition of an 8-octet Route Distinguisher (RD) as discussed in Section 2 of [RFC4659]. This VPN-IPv6 route can then be redistributed into MP-BGP according to an export policy that adds a Route Target (RT) Extended Communities attribute to the Network Layer Reachability Information (NLRI) [RFC4360].
PE使用OSPFv3将路由分配给CEs，MP-BGP[RFC4760]将VPN-IPv6路由分配给[RFC4659]中定义的其他（远程）PE路由器。如[RFC4659]第2节所述，通过添加8-octet路由识别器（RD），将OSPFv3安装在VRF中的IPv6前缀更改为VPN-IPv6前缀。然后，可以根据向网络层可达性信息（NLRI）添加路由目标（RT）扩展社区属性的导出策略将此VPN-IPv6路由重新分配到MP-BGP中[RFC4360]。
Domain IDs are used to distinguish between OSPFv3 instances. When an OSPFv3 distributed route is redistributed into MP-BGP, the Domain ID, OSPFv3 Router ID, Area, OSPFv3 Route Type, and Options fields (External Route Type) are also carried in Extended Community Attributes of the MP-BGP route.
域ID用于区分OSPFv3实例。当OSPFv3分布式路由重新分配到MP-BGP中时，MP-BGP路由的扩展社区属性中还包含域ID、OSPFv3路由器ID、区域、OSPFv3路由类型和选项字段（外部路由类型）。
A PE receiving a VPN-IPv6 NLRI from MP-BGP uses an import policy to determine, based on the RT, whether the route is eligible to be installed in one of its local VRFs. The BGP decision process selects
从MP-BGP接收VPN-IPv6 NLRI的PE使用导入策略根据RT确定路由是否符合安装在其本地VRF中的条件。BGP决策过程选择
which of the eligible routes are to be installed in the associated VRF, and the selected set of VPN-IPv6 routes are converted into IPv6 routes by removing the RD before installation.
将在关联的VRF中安装哪些符合条件的路由，并且通过在安装之前删除RD，将选定的VPN-IPv6路由集转换为IPv6路由。
An IPv6 route learned from MP-BGP and installed in a VRF might or might not be redistributed into OSPFv3, depending on the local configuration. For example, the PE might be configured to advertise only a default route to CEs of a particular OSPFv3 instance. Further, if the route is to be redistributed into multiple OSPFv3 instances, the route might be advertised using different LSA types in different instances.
根据本地配置，从MP-BGP学习并安装在VRF中的IPv6路由可能会也可能不会重新分配到OSPFv3中。例如，PE可能被配置为仅通告到特定OSPFv3实例的CE的默认路由。此外，如果要将路由重新分配到多个OSPFv3实例中，则可以在不同实例中使用不同的LSA类型来通告路由。
If an IPv6 route learned from MP-BGP is to be redistributed into a particular OSPFv3 instance, the OSPF Domain Identifier Extended Communities attribute of the VPN-IPv6 route is used to determine whether the OSPFv3 instance from which the route was learned is the same as the OSPFv3 instance into which the route is to be redistributed.
如果从MP-BGP学习的IPv6路由要重新分配到特定的OSPFv3实例中，则VPN-IPv6路由的OSPF域标识符扩展社区属性用于确定从中学习路由的OSPFv3实例是否与要重新分配路由的OSPFv3实例相同。
VRFs may be populated by both OSPFv3 routes from a CE or VPN-IPv6 routes from other PEs via MP-BGP. OSPFv3 routes are installed in a VRF using the OSPFv3 decision process. They may be redistributed into BGP and disseminated to other PEs participating in the VPN. At these remote PEs, the VPN-IPv6 routes may be imported into a VRF and redistributed into the OSPFv3 instance(s) associated with that VRF.
VRF可由来自CE的OSPFv3路由或通过MP-BGP来自其他PE的VPN-IPv6路由填充。OSPFv3路由使用OSPFv3决策流程安装在VRF中。它们可以重新分发到BGP中，并分发给参与VPN的其他PE。在这些远程PEs，VPN-IPv6路由可以导入到VRF中，并重新分发到与该VRF相关联的OSPFv3实例中。
As specified in [RFC4659], routes imported and exported into a VRF are controlled by the Route Target (RT) Extended Communities attribute. OSPFv3 routes that are redistributed into BGP are given an RT that corresponds to the VRF. This RT is examined at remote PEs. In order to import a route, a VRF must have an import RT that is identical to the route's RT. For routes that are eligible to be imported into the VRF, the standard BGP decision process is used to choose the "best" route(s).
如[RFC4659]所述，导入和导出到VRF中的路由由路由目标（RT）扩展社区属性控制。重新分配到BGP中的OSPFv3路由将获得与VRF相对应的RT。此RT在远程PEs进行检查。为了导入路由，VRF的导入RT必须与路由的RT相同。对于有资格导入VRF的路由，使用标准BGP决策流程选择“最佳”路由。
When a route is advertised from a CE to a PE via OSPFv3 and that route is installed in the VRF associated with the CE, the route is advertised to other locally attached CEs under normal OSPFv3 procedures.
当通过OSPFv3将路由从CE播发到PE，并且该路由安装在与CE相关联的VRF中时，根据正常OSPFv3程序将该路由播发到其他本地连接的CE。
The route is also redistributed into MP-BGP to be advertised to remote PEs. The information necessary for accurate redistribution back into OSPFv3 by the remote PEs is carried in the OSPF Route Type, OSPF Domain ID, and OSPF Router ID Extended Communities attributes (Section 4.4). The relevant local OSPFv3 information encoded into these attributes are as follows:
该路由也被重新分配到MP-BGP中，以向远程PE播发。远程PEs准确重新分配回OSPFv3所需的信息包含在OSPF路由类型、OSPF域ID和OSPF路由器ID扩展社区属性中（第4.4节）。编码到这些属性中的相关本地OSPFv3信息如下：
The Area ID of the PE-CE link.
PE-CE链路的区域ID。
The Route Type, as determined by the LSA type from which the route was learned.
路由类型，由从中学习路由的LSA类型确定。
The Options fields (External metric-type).
选项字段（外部度量类型）。
The Domain ID of the OSPFv3 process. If no Domain ID is configured, the NULL identifier is used.
OSPFv3进程的域ID。如果未配置域ID，则使用空标识符。
The PE's Router ID associated with the OSPFv3 instance.
与OSPFv3实例关联的PE路由器ID。
A Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the value of the OSPFv3 metric associated with the route plus 1, when the OSPFv3 route is redistributed into the MP-BGP.
当OSPFv3路由重新分配到MP-BGP中时，还应将多出口鉴别器（MED）属性设置为与路由相关联的OSPFv3度量值加1。
When a PE receives a valid VPN-IPv6 route from MP-BGP and has identified an association with a local VRF, it must determine:
当PE从MP-BGP接收到有效的VPN-IPv6路由并已识别出与本地VRF的关联时，它必须确定：
Whether a route to the corresponding IPv6 prefix is to be installed in the VRF;
是否在VRF中安装到相应IPv6前缀的路由；
Whether the installed IPv6 route is to be redistributed to one or more local OSPFv3 instances; and
是否将已安装的IPv6路由重新分发到一个或多个本地OSPFv3实例；和
What OSPFv3 LSA type is to be used when advertising the route into each OSPFv3 instance.
向每个OSPFv3实例播发路由时要使用什么OSPFv3 LSA类型。
An IPv6 route derived from a received VPN-IPv6 route is not installed in the associated local VRF if:
从接收到的VPN-IPv6路由派生的IPv6路由未安装在关联的本地VRF中，如果：
The BGP decision process identifies a better route to the destination NLRI; or
BGP决策过程识别到目的NLRI的更好路由；或
A configured import policy prohibits the installation of the route.
配置的导入策略禁止安装路由。
The PE advertises the IPv6 route learned from MP-BGP to attached CEs via OSPFv3 if:
在以下情况下，PE通过OSPFv3向连接的CE播发从MP-BGP学到的IPv6路由：
No configured filtering prohibits redistributing the route to OSPFv3;
没有配置的过滤禁止将路由重新分配到OSPFv3；
No configured policy blocks the route in favor of a less-specific summary route; and
没有配置的策略阻止路由，以支持不太特定的摘要路由；和
Redistribution of a BGP learned IPv6 route into OSPF is based on local policy.
将BGP学习到的IPv6路由重新分配到OSPF是基于本地策略的。
The subsequent sections discuss the advertisement of routes learned from MP-BGP and the rules for determining to which LSA types and to which CEs to advertise the routes.
接下来的章节将讨论从MP-BGP学习到的路由公告，以及确定向哪些LSA类型和向哪些CE公告路由的规则。
When the PE sends an LSA to a CE, it sets the DN-bit in the LSA to prevent looping. The DN-bit is discussed in Section 4.5.1.
当PE向CE发送LSA时，它在LSA中设置DN位以防止循环。DN位在第4.5.1节中讨论。
A PE advertises an IPv6 route using an Inter-Area-Prefix (type 0x2003) LSA under the following circumstances:
PE在以下情况下使用区域间前缀（类型0x2003）LSA播发IPv6路由：
The OSPFv3 domain from which the IPv6 route was learned is the same (as determined by the Domain ID) as the domain of the OSPFv3 instance into which it is to be redistributed; and
从中学习IPv6路由的OSPFv3域与要将其重新分发到的OSPFv3实例的域相同（由域ID确定）；和
The IPv6 route was advertised to a remote PE in an Intra-Area-Prefix (type 0x2009) OR an Inter-Area-Prefix (type 0x2003) LSA.
IPv6路由以区域内前缀（类型0x2009）或区域间前缀（类型0x2003）LSA播发给远程PE。
Note that under these rules, the PE represents itself as an Area Border Router (ABR) regardless of whether or not the route is being advertised into the same area number from which the remote PE learned it (that is, whether the VPN-IPv6 route carries the same or different area numbers).
请注意，根据这些规则，PE将自己表示为区域边界路由器（ABR），而不管路由是否被播发到远程PE从中得知它的相同区域号（即，VPN-IPv6路由是否携带相同或不同的区域号）。
A route is advertised as an intra-area route using an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used, as described in Section 5. Otherwise, routes are advertised as either inter-area (Section 4.3.2.1) or external / Not-So-Stubby Area (NSSA) (Section 4.3.2.3) routes.
如第5节所述，仅当使用假链路时，使用区域内前缀（类型0x2009）LSA将路由作为区域内路由进行广告。否则，路线将被宣传为区域间（第4.3.2.1节）或外部/非短截区（NSSA）（第4.3.2.3节）路线。
A PE considers an IPv6 route to be external under the following circumstances:
在以下情况下，PE将IPv6路由视为外部路由：
The OSPFv3 domain from which the route was learned is different (as determined by the Domain ID) from the domain of the OSPFv3 instance into which it is redistributed; or
从中学习路由的OSPFv3域与重新分配路由的OSPFv3实例的域不同（由域ID确定）；或
The OSPFv3 domain from which the route was learned is the same as the domain of the OSPFv3 instance into which it is redistributed, AND it was advertised to the remote PE in an AS-External-LSA (type 0x4005) or an NSSA-LSA (type 0x2007); or
从中学习路由的OSPFv3域与将其重新分发到的OSPFv3实例的域相同，并且在as外部LSA（类型0x4005）或NSSA-LSA（类型0x2007）中将其通告给远程PE；或
The route was not learned from an OSPFv3 instance.
未从OSPFv3实例学习路由。
To determine if the learned route is from a different domain, the Domain ID associated with the VPN-IPv6 route (in the OSPF Domain ID Extended Communities attribute or attributes) is compared with the local OSPFv3 Domain ID, if configured. Compared Domain IDs are considered identical if:
为了确定学习到的路由是否来自不同的域，将与VPN-IPv6路由相关联的域ID（在OSPF域ID扩展社区属性中）与本地OSPFv3域ID（如果已配置）进行比较。在以下情况下，比较的域ID被视为相同：
1. All 8 bytes are identical; or
1. 所有8个字节都是相同的；或
2. Both Domain IDs are NULL (all zeroes).
2. 两个域ID都为空（全部为零）。
Note that if the VPN-IPv6 route does not have a Domain ID in its attributes, or if the local OSPFv3 instance does not have a configured Domain ID (i.e., in either case), the route is considered to have a NULL Domain ID.
请注意，如果VPN-IPv6路由的属性中没有域ID，或者如果本地OSPFv3实例没有配置的域ID（即，在这两种情况下），则该路由被视为具有空域ID。
An IPv6 route that is determined to be external might or might not be advertised to a connected CE, depending on the type of area to which the PE-CE link belongs and whether there is a configured policy restricting its advertisement.
根据PE-CE链路所属区域的类型以及是否存在限制其播发的已配置策略，确定为外部的IPv6路由可能会播发到连接的CE，也可能不会播发到连接的CE。
If there are multiple external routes to the same prefix, the standard OSPFv3 decision process is used to select the "best" route.
如果有多条外部路由指向同一前缀，则使用标准OSPFv3决策过程选择“最佳”路由。
If the external route is to be advertised and the area type of the PE-CE link is NSSA, the PE advertises the route in an NSSA-LSA (type 0x2007); otherwise, the external route is advertised in an AS-External-LSA (type 0x4005).
如果要通告外部路由且PE-CE链路的区域类型为NSSA，则PE在NSSA-LSA中通告路由（类型0x2007）；否则，外部路由在AS外部LSA（类型0x4005）中播发。
The DN-bit of the LSA advertising the external route MUST be set, as described in Section 4.5.1.
如第4.5.1节所述，必须设置外部路由的LSA的DN位。
If the VPN-IPv6 route indicates a route Type-1 metric, the PE should advertise the external route with that metric-type; otherwise, the metric-type of the external IPv6 route is set to Type-2 by default. Note that, by default, a PE should advertise an external route with a Type-2 metric if the IPv6 route's Domain ID is different than the local OSPFv3 instance, unless specified otherwise by local policy.
如果VPN-IPv6路由指示路由类型1度量，则PE应使用该度量类型公布外部路由；否则，外部IPv6路由的度量类型默认设置为type-2。请注意，默认情况下，如果IPv6路由的域ID不同于本地OSPFv3实例，则PE应使用Type-2度量播发外部路由，除非本地策略另有规定。
OSPFv3 routes from one site are translated and delivered transparently to the remote site as BGP VPN-IPv6 routes. The original OSPFv3 routes carry OSPFv3-specific information that needs to be communicated to the remote PE to ensure transparency. BGP Extended Communities are used to carry the needed information to enable the receiving side to reconstruct a database just as in the OSPFv2 case.
来自一个站点的OSPFv3路由作为BGP VPN-IPv6路由被转换并透明地传递到远程站点。原始OSPFv3路由携带OSPFv3特定信息，需要与远程PE通信以确保透明度。BGP扩展社区用于承载所需的信息，使接收方能够像OSPFv2一样重建数据库。
All OSPFv3 routes added to the VRF routing table on a PE router are examined to create a corresponding VPN-IPv6 route in BGP. Each of the OSPFv3 routes MUST have the corresponding BGP Extended Communities Attributes that contain and preserve the OSPFv3 information of the original OSPFv3 route. The BGP Extended Communities attributes defined in [RFC4577] are reused for convenience.
检查添加到PE路由器上VRF路由表的所有OSPFv3路由，以在BGP中创建相应的VPN-IPv6路由。每个OSPFv3路由必须具有相应的BGP扩展社区属性，这些属性包含并保留原始OSPFv3路由的OSPFv3信息。为方便起见，[RFC4577]中定义的BGP扩展社区属性被重用。
OSPF Domain Identifier Extended Communities Attribute
OSPF域标识符扩展社区属性
Each OSPFv3 Instance within a VRF MUST have a Domain ID. The Domain ID is configured per OSPFv3 Instance. The OSPFv3 Domain ID is a 6-byte number, and its default value is 0. This attribute has a 2-byte type field, encoded with a value of 0x0005, 0x0105, or 0x0205.
VRF中的每个OSPFv3实例都必须有一个域ID。每个OSPFv3实例都配置了域ID。OSPFv3域ID是一个6字节的数字，其默认值为0。此属性有一个2字节类型的字段，用值0x0005、0x0105或0x0205编码。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Value | Domain Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Identifier Cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Value | Domain Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Identifier Cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Domain Identifier Extended Communities Attribute
OSPF域标识符扩展社区属性
OSPFv3 Domain IDs field : 6 bytes
OSPFv3域ID字段：6字节
Each OSPFv3 Instance within a VRF MUST have a Domain ID and its default value (if none is configured) is 0. The Domain ID is configured per OSPFv3 Instance.
VRF中的每个OSPFv3实例必须具有域ID，并且其默认值（如果未配置）为0。每个OSPFv3实例配置域ID。
OSPF Router ID Extended Communities Attribute
OSPF路由器ID扩展社区属性
The OSPFv3 Router ID is a 32-bit number as in OSPFv2. This attribute has a 2-byte type field, encoded with a value of 0x0107.
OSPFv3路由器ID是与OSPFv2相同的32位数字。此属性有一个2字节类型的字段，用值0x0107编码。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Value | Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID Cont. | UNUSED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Value | Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID Cont. | UNUSED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Router ID Extended Communities Attribute
OSPF路由器ID扩展社区属性
OSPFv3 Router ID field : 4 bytes
OSPFv3路由器ID字段：4字节
The OSPFv3 Router ID is a 32-bit number as in OSPFv2. Setting this field is OPTIONAL, and its default value is 0.
OSPFv3路由器ID是与OSPFv2相同的32位数字。设置此字段是可选的，其默认值为0。
OSPF Route Type Extended Communities Attribute
OSPF路由类型扩展社区属性
The OSPF Route Type Extended Communities Attribute MUST be present. It contains a 2-byte type field, encoded with a value of 0x0306. The remaining 6 bytes are divided into 3 fields, an Area Number, a Route Type, and an Options field.
OSPF路由类型扩展社区属性必须存在。它包含一个2字节类型的字段，用值0x0306编码。剩余的6个字节分为3个字段：区域号、路由类型和选项字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Value | Area Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area Number Cont. | Route Type | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Value | Area Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area Number Cont. | Route Type | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Route Type Extended Communities Attribute
OSPF路由类型扩展社区属性
Area Number : 4 bytes
区域编号：4字节
The area number indicates the 32-bit Area ID to which the route belongs.
区域编号表示路由所属的32位区域ID。
Route Types : 1 byte
路由类型：1字节
To accommodate OSPFv3 LSA types (as registered by [RFC5340]), the Route Type field is encoded as follows:
为适应OSPFv3 LSA类型（由[RFC5340]注册），路由类型字段编码如下：
Route Type Route Type LSA Type Description
Code
-----------------------------------------------------------
3 Inter-area-prefix 0x2003 Inter-Area-Prefix-LSA
5 External 0x4005 AS-External-LSA
7 NSSA 0x2007 NSSA-LSA
1 or 2 Intra-area-prefix 0x2009 Intra-Area-Prefix-LSA
Route Type Route Type LSA Type Description
Code
-----------------------------------------------------------
3 Inter-area-prefix 0x2003 Inter-Area-Prefix-LSA
5 External 0x4005 AS-External-LSA
7 NSSA 0x2007 NSSA-LSA
1 or 2 Intra-area-prefix 0x2009 Intra-Area-Prefix-LSA
Route Type Field Encoding
路由类型字段编码
Options : 1 byte
选项：1字节
The Options field indicates the options that are associated with the OSPFv3 route.
选项字段指示与OSPFv3路由相关的选项。
8 7 6 5 4 3 2 1
+---+---+---+---+---+---+---+---+
| | | | | | | | E |
+---+---+---+---+---+---+---+---+
8 7 6 5 4 3 2 1
+---+---+---+---+---+---+---+---+
| | | | | | | | E |
+---+---+---+---+---+---+---+---+
The OSPFv3 Route Options Field
OSPFv3路由选项字段
The least significant bit (i.e., bit E) in this field designates the external metric-type. If the bit is clear, the route carries a Type-1 external metric; if the bit is set, the route carries a Type-2 external metric.
该字段中的最低有效位（即位e）指定外部度量类型。如果位是清除的，则路由携带类型1外部度量；如果设置了位，则路由携带类型2外部度量。
In some topologies, it is possible for routing loops to occur due to the nature and manner of route reachability propagation. One such example is the case of a dual-homed CE router connected to two PEs; those PE routers would receive reachability information both through their CE and their peer PE. As there is transparent transport of OSPFv3 routes over the VPN backbone, it is not possible for the PE routers to determine whether they are within a loop.
在某些拓扑中，由于路由可达性传播的性质和方式，可能会发生路由循环。一个这样的例子是连接到两个PE的双宿CE路由器的情况；这些PE路由器将通过其CE和对等PE接收可达性信息。由于VPN主干上存在OSPFv3路由的透明传输，因此PE路由器无法确定它们是否在环路内。
The loop scenarios in OSPFv3 topologies are identical to those in the OSPFv2 topologies described in Sections 4.2.5.1 and 4.2.5.2 of [RFC4577]. Of the two loop prevention mechanisms described in the aforementioned sections, only the DN-bit option will be supported in the OSPFv3 implementation.
OSPFv3拓扑中的环路场景与[RFC4577]第4.2.5.1节和第4.2.5.2节中描述的OSPFv2拓扑中的环路场景相同。在上述章节中描述的两种环路预防机制中，OSPFv3实现中仅支持DN位选项。
[RFC4576] describes the usage of the DN-bit for OSPFv2 and is applicable for OSPFv3 for Inter-area-prefix LSAs, NSSA LSAs, and External LSAs. Similarly, the DN-bit MUST be set in Inter-area-prefix LSAs, NSSA LSAs, and AS-External LSAs, when these are originated from a PE to a CE, to prevent those prefixes from being re-advertised into BGP. As in [RFC4577], any LSA with the DN-bit set must not be used for route calculations on PE routers.
[RFC4576]描述了OSPFv2的DN位的用法，适用于OSPFv3的区域间前缀LSA、NSSA LSA和外部LSA。类似地，当区域间前缀LSA、NSSA LSA和外部LSA来自PE到CE时，必须将DN位设置在区域间前缀LSA、NSSA LSA和外部LSA中，以防止这些前缀重新播发到BGP中。与[RFC4577]一样，任何设置了DN位的LSA都不得用于PE路由器上的路由计算。
The DN-bit MUST be clear in all other LSA types. The OSPFv3 DN-bit format is described in Appendix A.4.1.1 of [RFC5340].
DN位必须在所有其他LSA类型中清除。[RFC5340]的附录A.4.1.1中描述了OSPFv3 DN位格式。
The mechanism described in Section 4.5.1 of this document is sufficient to prevent looping if the DN-bit information attached to a prefix is preserved in the OSPF domain. As described in Section 4.2.5.3 of [RFC4577], caution must be exercised if mutual redistribution that is performed on a PE causes loss of loop prevention information.
如果附加到前缀的DN位信息保留在OSPF域中，则本文件第4.5.1节中描述的机制足以防止循环。如[RFC4577]第4.2.5.3节所述，如果在PE上执行的相互重新分配导致环路预防信息丢失，则必须小心。
This section modifies the specification of OSPFv2 sham links (defined in Section 4.2.7 of [RFC4577]) to support OSPFv3. Support for OSPFv3 sham links is an OPTIONAL feature of this specification.
本节修改了OSPFv2假链路规范（定义见[RFC4577]第4.2.7节），以支持OSPFv3。支持OSPFv3假链路是本规范的可选功能。
A sham link enables a VPN backbone to act as an intra-area link. It is needed when two sites are connected by an intra-area "backdoor" link and the inter-area VPN backbone route would be less preferable due to OSPF route preference rules. The figure below shows the instantiation of a sham link between two VPN sites.
假链路使VPN主干能够充当区域内链路。当两个站点通过区域内的“后门”链路连接时，需要使用该方法，并且由于OSPF路由偏好规则，区域间VPN主干路由将不太可取。下图显示了两个VPN站点之间假链接的实例化。
(VPN backbone)
(site-1) <-------- sham link --------> (site-2)
CE1 -------- PE1 -------- P ---------- PE2 -------- CE2
| |
|___________________________________________________|
<------------ backdoor link -------------->
(OSPF intra-area link)
(VPN backbone)
(site-1) <-------- sham link --------> (site-2)
CE1 -------- PE1 -------- P ---------- PE2 -------- CE2
| |
|___________________________________________________|
<------------ backdoor link -------------->
(OSPF intra-area link)
Sham Link
假链接
Much of the operation of sham links remains semantically identical to what was previously specified. There are, however, several differences that need to be defined to ensure the proper operation of OSPFv3 sham links.
假链接的大部分操作在语义上与之前指定的相同。然而，有几个差异需要定义，以确保OSPFv3假链路的正确运行。
One of the primary differences between sham links for OSPFv3 and sham links as specified in [RFC4577] is for configurations where multiple OSPFv3 instances populate a VRF. It may be desirable to provide separate intra-area links between these instances over the same sham link. To achieve this, multiple OSPFv3 instances may be established across the PE-PE sham link to provide intra-area connectivity between PE-CE OSPFv3 instances.
[RFC4577]中规定的OSPFv3假链路和假链路之间的主要区别之一是多个OSPFv3实例填充VRF的配置。可能希望通过相同的假链路在这些实例之间提供单独的区域内链路。为了实现这一点，可以跨PE-PE假链路建立多个OSPFv3实例，以提供PE-CE OSPFv3实例之间的区域内连接。
Note that even though multiple OSPFv3 instances may be associated with a VRF, a sham link is still thought of as a relation between two VRFs.
请注意，即使多个OSPFv3实例可能与VRF关联，仍将假链接视为两个VRF之间的关系。
Another modification to OSPFv2 sham links is that OSPFv3 sham links are now identified by 128-bit endpoint addresses. Since sham link endpoint addresses are now 128 bits, they can no longer default to the RouterID, which is a 32-bit number. Sham link endpoint addresses MUST be configured.
OSPFv2假链路的另一个修改是，OSPFv3假链路现在由128位端点地址标识。由于假链接端点地址现在是128位，它们不能再默认为RouterID，这是一个32位的数字。必须配置假链接终结点地址。
Sham link endpoint addresses MUST be distributed by BGP as routeable VPN IPv6 addresses, each with an IPv6 address prefix that is 128 bits long. As specified in Section 4.2.7.1 of [RFC4577], these endpoint addresses MUST NOT be advertised by OSPFv3; if there is no BGP route to the sham link endpoint address, that address is to appear unreachable, so that the sham link appears to be down.
伪链路端点地址必须由BGP作为可路由VPN IPv6地址分发，每个地址的IPv6地址前缀长度为128位。按照[RFC4577]第4.2.7.1节的规定，OSPFv3不得公布这些端点地址；如果没有到假链接端点地址的BGP路由，则该地址将显示为不可访问，因此假链接似乎已关闭。
If there is a BGP route to the remote sham link endpoint address, the sham link appears to be up. Conversely, if there is no BGP route to the sham link endpoint address, the sham link appears to be down.
如果存在到远程假链接端点地址的BGP路由，则假链接似乎已启动。相反，如果没有到假链接端点地址的BGP路由，则假链接似乎已关闭。
The procedures for creating an OSPFv3 sham link are identical to those specified in Section 4.2.7.2 of [RFC4577]. Note that the creation of OSPFv3 sham links requires the configuration of both local and remote 128-bit sham link endpoint addresses. The local sham link endpoint address associated with a VRF MAY be used by all OSPFv3 instances that are attached to that VRF. The OSPFv3 PE-PE "link" Instance ID in the protocol packet header is used to demultiplex multiple OSPFv3 instance protocol packets exchanged over the sham link.
创建OSPFv3假链路的程序与[RFC4577]第4.2.7.2节中规定的程序相同。请注意，创建OSPFv3假链接需要配置本地和远程128位假链接端点地址。与VRF关联的本地假链路端点地址可由连接到该VRF的所有OSPFv3实例使用。协议分组报头中的OSPFv3 PE-PE“链路”实例ID用于对通过假链路交换的多个OSPFv3实例协议分组进行解复用。
Much of the operation of OSPFv3 over a sham link is semantically the same as the operation of OSPFv2 over a sham link, as described in Section 4.2.7.3 of [RFC4577]. This includes the methodology for sending and receiving OSPFv3 packets over sham links, as well as
如[RFC4577]第4.2.7.3节所述，OSPFv3在假链路上的大部分操作在语义上与OSPFv2在假链路上的操作相同。这包括通过假链路发送和接收OSPFv3数据包的方法，以及
Hello/Router Dead Intervals. Furthermore, the procedures associated with the assignment of sham link metrics adhere to those set forth for OSPFv2. OSPFv3 sham links are treated as on-demand circuits.
你好/路由器死区。此外，与假链路度量的分配相关的程序遵守为OSPFv2规定的程序。OSPFv3假链路被视为按需电路。
Although the operation of the OSPFv3 protocol over the sham link is the same as OSPFv2, multiple OSPFv3 instances may be instantiated across this link. By instantiating multiple instances across the sham link, distinct intra-area connections can be established between PE-PE OSPFv3 instances associated with the endpoint addresses.
尽管OSPFv3协议在假链路上的操作与OSPFv2相同，但可以通过该链路实例化多个OSPFv3实例。通过在sham链路上实例化多个实例，可以在与端点地址相关联的PE-PE OSPFv3实例之间建立不同的区域内连接。
For example, if two OSPFv3 instances (O1, O2) attach to a VRF V1, and on a remote PE, two other OSPFv3 instances (O3, O4) attach to a VRF V2, it may be desirable to connect O1 and O3 with an intra-area link, and O2 and O4 with an intra-area link. This can be accomplished by instantiating two OSPFv3 instances across the sham link, which connects V1 and V2. O1 and O3 can be mapped to one of the sham link OSPFv3 instances; O2 and O4 can be mapped to the other sham link OSPFv3 instance.
例如，如果两个OSPFv3实例（O1，O2）连接到VRF V1，并且在远程PE上，另外两个OSPFv3实例（O3，O4）连接到VRF V2，则可能需要将O1和O3连接到区域内链路，将O2和O4连接到区域内链路。这可以通过在连接V1和V2的sham链路上实例化两个OSPFv3实例来实现。O1和O3可映射到假链路OSPFv3实例之一；O2和O4可以映射到另一个假链接OSPFv3实例。
The rules associated with route redistribution, stated in Section 4.2.7.4 of [RFC4577], remain unchanged in this specification. Specifically:
[RFC4577]第4.2.7.4节中规定的与路线再分配相关的规则在本规范中保持不变。明确地：
If the next-hop interface for a particular route is a sham link, then the PE SHOULD NOT redistribute that route into BGP as a VPN-IPv6 route.
如果特定路由的下一跳接口是假链路，则PE不应将该路由作为VPN-IPv6路由重新分配到BGP中。
Any other route advertised in an LSA that is transmitted over a sham link MUST also be redistributed (by the PE flooding the LSA over the sham link) into BGP.
通过假链路传输的LSA中公布的任何其他路由也必须重新分配（通过PE通过假链路将LSA淹没）到BGP中。
When redistributing these LSAs into BGP, they are encoded with the BGP Extended Communities Attributes, as defined in Section 4.4 of this document.
当将这些LSA重新分发到BGP中时，它们使用BGP扩展社区属性进行编码，如本文件第4.4节所定义。
When forwarding a packet, if the preferred route for that packet has the sham link as its next-hop interface, then the packet MUST be forwarded according to the corresponding BGP route (as defined in [RFC4364] and [RFC4659]).
转发数据包时，如果该数据包的首选路由具有假链路作为其下一跳接口，则必须根据相应的BGP路由（如[RFC4364]和[RFC4659]中所定义）转发该数据包。
The support of multiple address families (AFs) in OSPFv3 is described in [RFC5838]. [RFC5838] differentiates between AFs by using reserved ranges of Instance IDs for each AF.
[RFC5838]中描述了OSPFv3中对多地址族（AFs）的支持。[RFC5838]通过为每个AF使用实例ID的保留范围来区分AFs。
The architecture described in this document is fully compatible with [RFC5838]. The OSPFv3 PE-CE protocol can support multiple address families across a VPN backbone. All AFs redistributed from OSPFv3 into BGP on a PE MUST contain the BGP Extended Communities Attributes as described in Section 4.4.
本文档中描述的体系结构与[RFC5838]完全兼容。OSPFv3 PE-CE协议可以支持跨VPN主干的多个地址族。PE上从OSPFv3重新分配到BGP的所有AFs必须包含第4.4节所述的BGP扩展社区属性。
The extensions described in this document are specific to the use of OSPFv3 as the PE-CE protocol and do not introduce any new security concerns other than those already defined in Section 6 of [RFC4577].
本文件中描述的扩展特定于将OSPFv3用作PE-CE协议，除了[RFC4577]第6节中已经定义的安全问题外，不会引入任何新的安全问题。
An early version of this document resulted in the allocation of OSPFv3 Route Attributes (0x0004) entry in the BGP IPv6 Address Specific Extended Community. This allocation is no longer required. IANA has marked the OSPFv3 Route Attributes (0x0004) entry in the BGP IPv6 Address Specific Extended Community registry as deprecated. The BGP Extended Communities Attributes in this document have already been registered by IANA.
本文档的早期版本导致在BGP IPv6地址特定扩展社区中分配OSPFv3路由属性（0x0004）条目。不再需要这种分配。IANA已将BGP IPv6特定地址扩展社区注册表中的OSPFv3路由属性（0x0004）项标记为已弃用。本文档中的BGP扩展社区属性已由IANA注册。
The authors would like to thank Kelvin Upson, Seiko Okano, Matthew Everett, Dr. Vineet Mehta, Paul Wells, and Marek Karasek for their support of this work. Thanks to Peter Psenak, Abhay Roy, Acee Lindem, Nick Weeds, Robert Hanzl, and Daniel Cohn for their Last Call comments. Special thanks to Stewart Bryant, Stephen Farrel, and Fred Baker for their thorough review.
作者要感谢Kelvin Upson、Seiko Okano、Matthew Everett、Vinet Mehta博士、Paul Wells和Marek Karasek对这项工作的支持。感谢Peter Psenak、Abhay Roy、Acee Lindem、Nick Weeds、Robert Hanzl和Daniel Cohn的最后一次通话评论。特别感谢Stewart Bryant、Stephen Farrel和Fred Baker的全面回顾。
[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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[RFC4360]Sangli，S.，Tappan，D.和Y.Rekhter，“BGP扩展社区属性”，RFC 4360，2006年2月。
[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月。
[RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576, June 2006.
[RFC4576]Rosen，E.，Psenak，P.，和P.Pillay Esnault，“使用链路状态公告（LSA）选项位防止BGP/MPLS IP虚拟专用网络（VPN）中的循环”，RFC 45762006年6月。
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4577, June 2006.
[RFC4577]Rosen，E.，Psenak，P.，和P.Pillay Esnault，“OSPF作为BGP/MPLS IP虚拟专用网络（VPN）的提供商/客户边缘协议”，RFC 4577，2006年6月。
[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月。
[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月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010.
[RFC5838]Lindem，A.，Ed.，Mirtorabi，S.，Roy，A.，Barnes，M.，和R.Aggarwal，“OSPFv3中地址家庭的支持”，RFC 5838，2010年4月。
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[RFC2547]Rosen，E.和Y.Rekhter，“BGP/MPLS VPN”，RFC 2547，1999年3月。
Authors' Addresses
作者地址
Padma Pillay-Esnault Cisco Systems 510 McCarty Blvd. Milpitas, CA 95035 USA
帕德玛·皮莱·埃斯纳尔特思科系统公司，麦卡蒂大道510号。美国加利福尼亚州米尔皮塔斯95035
EMail: ppe@cisco.com
EMail: ppe@cisco.com
Peter Moyer Pollere, Inc. 325M Sharon Park Drive #214 Menlo Park, CA 94025 USA
Peter Moyer Pollere，Inc.位于美国加利福尼亚州门罗公园214号沙龙公园大道325米处，邮编94025
EMail: pete@pollere.net
EMail: pete@pollere.net
Jeff Doyle Jeff Doyle and Associates 9878 Teller Ct. Westminster, CO 80021 USA
Jeff Doyle Jeff Doyle及其同事9878 Teller Ct。美国科罗拉多州威斯敏斯特80021
EMail: jdoyle@doyleassociates.net
EMail: jdoyle@doyleassociates.net
Emre Ertekin Booz Allen Hamilton 5220 Pacific Concourse Drive Los Angeles, CA 90045 USA
美国加利福尼亚州洛杉矶太平洋广场大道5220号埃姆雷·埃尔特金·博斯·艾伦·汉密尔顿，邮编90045
EMail: ertekin_emre@bah.com
EMail: ertekin_emre@bah.com
Michael Lundberg Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 USA
美国弗吉尼亚州麦克莱恩格林斯博格博斯艾伦汉密尔顿8283格林斯博罗大道22102号
EMail: lundberg_michael@bah.com
EMail: lundberg_michael@bah.com