[要約] RFC 6565は、OSPFv3をProvider Edge to Customer Edge（PE-CE）ルーティングプロトコルとして使用するためのガイドラインです。このRFCの目的は、IPv6ネットワークにおけるPE-CE間のルーティングを効果的に実現するための手法を提供することです。
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）は、カスタマーエッジ（CE）ルーターがプロバイダーエッジ（PE）ルーターのルーティングピアである技術を使用して、顧客に仮想プライベートネットワーク（VPN）サービスを提供しています。ボーダーゲートウェイプロトコル（BGP）は、プロバイダーのIPバックボーンネットワーク全体に顧客のルートを配布するために使用され、マルチプロトコルラベルスイッチング（MPLS）は、プロバイダーのバックボーン全体に顧客パケットをトンネリングするために使用されます。現在、IPv4とIPv6の両方のVPNがサポートされています。ただし、PE-CEプロトコルとしてOpen Shortest Path Firstバージョン2（OSPFv2）のみが指定されています。このドキュメントでは、PE-CEルーティングプロトコルとしてOSPFバージョン3（OSPFv3）をサポートするようにこれらの仕様を拡張しています。 OSPFv3 PE-CE機能は、このドキュメントで説明されている違いを除いて、OSPFv2の機能と同じです。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
[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 as the Provider / Customer Edge Protocol仕様[RFC4577]は、OSPFv2ベースのカスタマーサイト間のドメイン内ルーティング接続を可能にする追加の拡張機能を詳述することにより、PE-CEルーティングプロトコルとしての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に拡張します。 OSPFv2がIPv4 VPNに使用されたのと同様に、OSPFv3が一部のIPv6 VPNのIGPとして使用されることが予想されます。 OSPF-v3を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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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.
PE-CEルーティングプロトコルとしてのOSPFv3の導入に関連する利点と考慮事項は、[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]は、IPv6をサポートするためにOSPFに必要な変更について説明しています。その仕様では、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到達可能性情報がAS-External 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は、IPサブネットごとに動作するOSPFv2とは対照的に、リンクごとに動作します。リンク上の複数の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インスタンスへのエリア内接続を個別に確立できるようになります。模造リンクを介した複数のOSPFv3インスタンスのサポートについては、セクション5で説明します。
The relationship between VRFs, interfaces, and OSPFv3 instances on a PE router is described in the following section.
VRF、インターフェイス、およびPEルータ上の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ルータは1つ以上のVRFで構成できます。 PEに設定された各VRFはカスタマーVPNに対応し、そのVPN内で到達可能な宛先を保持します。各VRFは1つ以上のインターフェイスに関連付けることができるため、複数のサイトが同じVPNに参加できます。 OSPFv3がVRFに関連付けられたインターフェイスでインスタンス化される場合、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インスタンスを使用して（たとえば、レイヤー2スイッチを介して）PEルーターの同じインターフェイスに接続する可能性があります。 PEインターフェイスは1つの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ドメインに対して少なくとも1つの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インスタンスを1つの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インスタンスの管理ドメインを示します。これはAS全体で重要であり、VPN-IPv6ルートをエリアプレフィックスLSAとして変換するか外部LSAとして変換するかを決定するために使用されるパラメーターの1つです。各OSPFv3インスタンスには、VPNバックボーン上のBGP属性のVPN-IPv6ルートとともに転送されるプライマリドメインIDが必要です。各OSPFv3インスタンスには、その管理ドメイン内の他のOSPFv3インスタンスに適用されるセカンダリドメインIDのセットがある場合があります。
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は、構成するか、NULLの値に設定できます。セカンダリドメインIDは、NULL以外のプライマリドメインIDが構成されている場合にのみ許可されます。ドメインIDは、OSPFv3インスタンスごとに構成する必要があります。
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インスタンスと同じドメインに属しているかどうかを判断するために使用されます。 NULL以外の着信ドメインIDがローカルプライマリまたはセカンダリドメインIDのいずれかに一致する場合、着信VPN-IPv6ルートは同じドメインに属していると言います。ローカルドメインIDと受信ドメインIDがNULLの場合、一致と見なされます。
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に異なるルートがインストールされる可能性があるため、ドメインのCEの観点からは、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を使用してルートをCEに配布し、MP-BGP [RFC4760]はVPN-IPv6ルートを他の（リモート）PEルーターに配布します[RFC4659]で定義されています。 [RFC4659]のセクション2で説明されているように、OSPFv3によってVRFにインストールされたIPv6プレフィックスは、8オクテットルート識別子（RD）の追加によってVPN-IPv6プレフィックスに変更されます。次に、このVPN-IPv6ルートは、ネットワークターゲット到達可能性情報（NLRI）[RFC4360]にルートターゲット（RT）拡張コミュニティ属性を追加するエクスポートポリシーに従ってMP-BGPに再配布できます。
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に再配布されると、ドメインID、OSPFv3ルーターID、エリア、OSPFv3ルートタイプ、およびオプションフィールド（外部ルートタイプ）も、MP-BGPルートの拡張コミュニティ属性で伝達されます。
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 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.
MP-BGPからVPN-IPv6 NLRIを受信するPEは、インポートポリシーを使用して、RTに基づいて、ルートがローカルVRFの1つにインストールする資格があるかどうかを判断します。 BGP決定プロセスは、関連するVRFにインストールする適格なルートを選択し、選択したVPN-IPv6ルートのセットは、インストール前にRDを削除することによって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に配布されます。これらのリモートPEでは、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はリモートPEで検査されます。ルートをインポートするには、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:
ルートはまた、リモートPEにアドバタイズされるようにMP-BGPに再配布されます。リモートPEによる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が構成されていない場合は、NULL識別子が使用されます。
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に再配布される場合、Multi-Exit-Discriminator（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との関連付けを識別した場合、PEは以下を決定する必要があります。
Whether a route to the corresponding IPv6 prefix is to be installed in the VRF;
対応するIPv6プレフィックスへのルートをVRFにインストールするかどうか。
Whether the installed IPv6 route is to be redistributed to one or more local OSPFv3 instances; and
インストールされているIPv6ルートを1つ以上のローカル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はMP-BGPから学習したIPv6ルートをOSPFv3経由で接続されたCEにアドバタイズします。
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がLSAをCEに送信すると、ループを防止するために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が学習したのと同じエリア番号にルートがアドバタイズされているかどうかに関係なく、PEは自身をエリア境界ルーター（ABR）として表すことに注意してください（つまり、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）。 ）または外部/ Not-So-Stubby Area（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 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インスタンスのドメインとは異なります（ドメインIDによって決定されます）。またはルートが学習されたOSPFv3ドメインが、再配布先のOSPFv3インスタンスのドメインと同じであり、かつAS-External-LSA（タイプ0x4005）またはNSSA-LSAのリモートPEにアドバタイズされた（タイプ0x2007）;または
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がNULL（すべてゼロ）です。
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がない場合（つまり、どちらの場合も）、ルートはNULLドメイン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.
外部と判断されたIPv6ルートは、PE-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-External-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ルートのメトリックタイプはデフォルトでタイプ2に設定されます。ローカルポリシーで特に指定されていない限り、デフォルトでは、IPv6ルートのドメインIDがローカルOSPFv3インスタンスと異なる場合、PEはタイプ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.
1つのサイトからの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ルートが検査され、対応するVPN-IPv6ルートがBGPに作成されます。各OSPFv3ルートは、元のOSPFv3ルートのOSPFv3情報を含み、保持する、対応するBGP拡張コミュニティ属性を持つ必要があります。 [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が必要です。ドメインIDは、OSPFv3インスタンスごとに構成されます。 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. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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です。ドメインIDは、OSPFv3インスタンスごとに構成されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ルートタイプ拡張コミュニティ属性が存在する必要があります。これには、値0x0306でエンコードされた2バイトのタイプフィールドが含まれています。残りの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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 To accommodate OSPFv3 LSA types (as registered by [RFC5340]), the Route Type field is encoded as follows:
ルートタイプ：1バイト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 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 |
+---+---+---+---+---+---+---+---+
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.
一部のトポロジでは、ルート到達可能性の伝播の性質と方法が原因でルーティングループが発生する可能性があります。このような例の1つは、2つの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トポロジのループシナリオと同じです。前述のセクションで説明した2つのループ防止メカニズムのうち、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ビットの使用法を説明しており、エリア間プレフィックスLSA、NSSA LSA、および外部LSAのOSPFv3に適用できます。同様に、これらのプレフィックスがBGPに再アドバタイズされないようにするために、これらがPEからCEに発信される場合、DNビットはエリア間プレフィックスLSA、NSSA LSA、およびAS外部LSAで設定する必要があります。 [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タイプでクリアされている必要があります。 OSPFv3 DNビット形式は、[RFC5340]の付録A.4.1.1で説明されています。
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.
このドキュメントのセクション4.5.1で説明されているメカニズムは、プレフィックスに添付されたDNビット情報がOSPFドメインで保持されている場合、ループを防ぐのに十分です。 [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.
このセクションでは、OSPFv3をサポートするようにOSPFv2模造リンクの仕様（[RFC4577]のセクション4.2.7で定義）を変更します。 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バックボーンをエリア内リンクとして機能させることができます。これは、2つのサイトがエリア内「バックドア」リンクで接続されており、OSPFルートプリファレンスルールにより、エリア間VPNバックボーンルートがあまり望ましくない場合に必要です。次の図は、2つのVPNサイト間の模造リンクのインスタンス化を示しています。
(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の模造リンクと模造リンクの主な違いの1つは、複数の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に関連付けられている場合でも、模造リンクは2つの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模造リンクのもう1つの変更は、OSPFv3模造リンクが128ビットのエンドポイントアドレスで識別されるようになったことです。模造リンクのエンドポイントアドレスが128ビットになったため、32ビットの数値であるルーターIDをデフォルトにすることができなくなりました。模造リンクのエンドポイントアドレスを設定する必要があります。
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.
模造リンクのエンドポイントアドレスは、ルーティング可能なVPN IPv6アドレスとしてBGPによって配布される必要があり、それぞれに128ビット長のIPv6アドレスプレフィックスが付いています。 [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 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.
[RFC4577]のセクション4.2.7.3で説明されているように、模造リンクを介したOSPFv3の操作の多くは、模造リンクを介したOSPFv2の操作と意味的に同じです。これには、模造リンクを介してOSPFv3パケットを送受信する方法や、Hello / Router Dead Intervalsが含まれます。さらに、模造リンクメトリックの割り当てに関連する手順は、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インスタンスがこのリンクを介してインスタンス化される場合があります。模造リンクを介して複数のインスタンスをインスタンス化することにより、エンドポイントアドレスに関連付けられた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.
たとえば、2つのOSPFv3インスタンス（O1、O2）がVRF V1に接続し、リモートPEでは、他の2つのOSPFv3インスタンス（O3、O4）がVRF V2に接続している場合、O1とO3をエリア内リンク、およびエリア内リンクを持つO2とO4。これは、V1とV2を接続する模造リンクを介して2つのOSPFv3インスタンスをインスタンス化することで実現できます。 O1とO3は、模造リンクのOSPFv3インスタンスの1つにマッピングできます。 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に再配布すべきではありません（SHOULD NOT）。
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でアドバタイズされる他のルートも、（偽のリンクを介してLSAをフラッディングするPEによって）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に再配布する場合、これらはこのドキュメントのセクション4.4で定義されているように、BGP拡張コミュニティ属性でエンコードされます。
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.
OSPFv3での複数のアドレスファミリ（AF）のサポートは、[RFC5838]で説明されています。 [RFC5838]は、AFごとにインスタンスIDの予約された範囲を使用することにより、AFを区別します。
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バックボーン全体で複数のアドレスファミリをサポートできます。 OSPFv3からPEのBGPに再配布されるすべてのAFには、セクション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].
このドキュメントで説明されている拡張機能は、PE-CEプロトコルとしてのOSPFv3の使用に固有のものであり、[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.
著者は、この仕事をサポートしてくれたケルビン・アプソン、岡野聖子、マシュー・エヴェレット、ビニート・メタ博士、ポール・ウェルズ、マレク・カラセクに感謝します。 Last Callのコメントを提供してくれた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 Extended Communities Attribute」、RFC 4360、2006年2月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E。およびY.レクター、「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、「Link State Advertisement（LSA）オプションビットを使用して、BGP / MPLS IP仮想プライベートネットワーク（VPN）でのループを防止する」、RFC 4576、 2006年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 as the Provider / Customer Edge Protocol for BGP / MPLS IP Virtual Private Networks（VPNs）」、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、「BGP-MPLS IP Virtual Private Network（VPN）Extension for IPv6 VPN」、RFC 4659、2006年9月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「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、「OSPF for IPv6」、RFC 5340、2008年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、「Support of Address Families in OSPFv3」、RFC 5838、2010年4月。
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[RFC2547]ローゼン、E。およびY.レクター、「BGP / MPLS VPNs」、RFC 2547、1999年3月。
Authors' Addresses
著者のアドレス
Padma Pillay-Esnault Cisco Systems 510 McCarty Blvd. Milpitas, CA 95035 USA
Padma Pillay-Esnault Cisco Systems 510 McCarty Blvd.ミルピタス、カリフォルニア州95035米国
EMail: ppe@cisco.com
Peter Moyer Pollere, Inc. 325M Sharon Park Drive #214 Menlo Park, CA 94025 USA
ピーターモイヤーポレール社325M Sharon Park Drive＃214 Menlo Park、CA 94025 USA
EMail: pete@pollere.net
Jeff Doyle Jeff Doyle and Associates 9878 Teller Ct. Westminster, CO 80021 USA
ジェフドイルジェフドイルアンドアソシエイツ9878 Teller Ct。 Westminster、CO 80021 USA
EMail: jdoyle@doyleassociates.net
Emre Ertekin Booz Allen Hamilton 5220 Pacific Concourse Drive Los Angeles, CA 90045 USA
Emre Ertekin Boozアレンハミルトン5220 Pacific Concourse Driveロサンゼルス、カリフォルニア州90045米国
EMail: ertekin_emre@bah.com
Michael Lundberg Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 USA
マイケルランドバーグブーズアレンハミルトン8283 Greensboro Drive McLean、VA 22102 USA
EMail: lundberg_michael@bah.com