Network Working Group E. Rosen
Request for Comments: 4576 P. Psenak
Category: Standards Track P. Pillay-Esnault
Cisco Systems, Inc.
June 2006
Using a Link State Advertisement (LSA) Options Bit to
Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides "BGP/MPLS IP VPN" service to a customer and the customer uses OSPFv2 to advertise its routes to the SP. In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFv2 from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of this conversion, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE that receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it.
このドキュメントでは、サービスプロバイダ（SP）は、お客様に「BGP / MPLS IP VPN」サービスを提供し、顧客がSPにそのルートをアドバタイズするのOSPFv2を使用するときに発生する可能性のある特定の問題を扱う手順を指定します。この状況では、カスタマエッジ（CE）ルータとプロバイダエッジ（PE）ルータがOSPFピア、および顧客の経路であるPEにCEからのOSPFv2を介して送信されます。顧客ルートは、BGPルートに変換され、BGPは、他のPEルータにバックボーン上にそれらを運びます。ルートは、他のCEルータにOSPFを介して送信されるOSPFルートに変換されます。この変換の結果として、ループを防止するために必要な情報の一部が失われる可能性があります。手順は、ルートがCEにPEから送信されると、ルートバックCEから、それを受信し、任意のPEによって無視されることを保証するために必要とされます。この文書では、LSAが既にPEによって転送されており、それを参照して、他のPEによって無視されるべきであることを示すために、LSAのオプションビット（リンクステートアドバタイズメント）のいずれかを使用して、必要な手続きを指定します。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Information Loss and Loops ......................................3
4. Using the LSA Options to Prevent Loops ..........................4
5. Security Considerations .........................................5
6. Acknowledgements ................................................5
7. Normative References ............................................6
[VPN] describes a method by which a Service Provider (SP) can use its IP backbone to provide an "IP VPN" service to customers. In that sort of service, a customer's edge devices (CE devices) are connected to the provider's edge routers (PE routers). Each CE device is in a single Virtual Private Network (VPN). Each PE device may attach to multiple CEs of the same or of different VPNs. A VPN thus consists of a set of "network segments" connected by the SP's backbone.
[VPN]サービスプロバイダ（SP）は、お客様に「IP VPN」サービスを提供するために、そのIPバックボーンを使用することができる方法を説明します。サービスの一種では、顧客のエッジ機器（CE機器）は、プロバイダのエッジルータ（PEルータ）に接続されています。各CEデバイスは、単一の仮想プライベートネットワーク（VPN）です。各PEデバイスは、同一の又は異なるVPNの複数のCEに取り付けることができます。 VPNは、このようにSPのバックボーンによって接続された「ネットワークセグメント」の組から成ります。
A CE exchanges routes with a PE, using a routing protocol to which the customer and the SP jointly agree. The PE runs that routing protocol's decision process (i.e., it performs the routing computation) to determine the set of IP address prefixes for which the following two conditions hold:
ルーティングプロトコルを使用して、PEとCE交換経路は、その顧客とSPが共同で合意します。 PEは、ルーティングプロトコルの決定プロセス（すなわち、それは、ルーティング計算を実行する）次の2つの条件を保持するためのIPアドレスプレフィクスのセットを決定することを実行します。
- Each address prefix in the set can be reached via that CE.
- セット内の各アドレスプレフィックスは、そのCEを介して到達することができます。
- The path from that CE to each such address prefix does NOT include the SP backbone (i.e., it does not include any PE routers).
- このような各アドレスプレフィックスへのCEからパス（すなわち、それは任意のPEルータを含まない）SP骨格を含みません。
The PE routers that attach to a particular VPN redistribute routes to these address prefixes into BGP, so that they can use BGP to distribute the VPN's routes to each other. BGP carries these routes in the "VPN-IPv4 address family", so that they are distinct from ordinary Internet routes. The VPN-IPv4 address family also extends the IP addresses on the left so that address prefixes from two different VPNs are always distinct to BGP, even if both VPNs use the same piece of the private RFC 1918 address space. Thus, routes from different VPNs can be carried by a single BGP instance and can be stored in a common BGP table without fear of conflict.
それらはお互いにVPNのルートを配布するためにBGPを使用できるように、特定のVPNに接続PEルータは、BGPにこれらのアドレスプレフィックスへのルートを再配布します。彼らは通常のインターネットルートとは区別されるように、BGPは、「VPN-IPv4アドレスファミリ」にこれらのルートを運びます。 2つの異なるVPNからのアドレスプレフィックスは、両方のVPNはプライベートRFC 1918アドレス空間の同じ部分を使用している場合でも、常にBGPに異なっているように、VPN-IPv4アドレスファミリは、左のIPアドレスを拡張します。したがって、異なるVPNからのルートは、単一のBGPインスタンスによって実施することが可能であり、衝突の恐れなしに共通のBGPテーブルに格納することができます。
If a PE router receives a particular VPN-IPv4 route via BGP, and if that PE is attached to a CE in the VPN to which the route belongs, then BGP's decision process may install that route in the BGP route table. If so, the PE translates the route back into an IP route and redistributes it to the routing protocol that is running on the link to that CE.
PEルータは、BGPを介して特定のVPN-IPv4ルートを受信し、そのPEは、ルートが属するVPNにおけるCEに接続されている場合、その後、BGPの決定プロセスは、BGPルートテーブル内のその経路をインストールすることができる場合。そうである場合、PEは、バックIPルートにルートを変換し、そのCEへのリンク上で実行されているルーティングプロトコルにそれを再分配します。
This methodology provides a "peer model". CE routers peer with PE routers, but CE routers at different sites do not peer with each other.
この方法論は、「ピア・モデル」を提供します。 CEルータはPEルータとピアリングが、別のサイトのCEルータは、相互にピアはありません。
If a VPN uses OSPFv2 as its internal routing protocol, it is not necessarily the case that the CE routers of that VPN use OSPFv2 to peer with the PE routers. Each site in a VPN can use OSPFv2 as its intra-site routing protocol while using BGP or RIP (for example) to distribute routes to a PE router. However, it is certainly convenient when OSPFv2 is being used intra-site to use it on the PE-CE link as well, and [VPN] explicitly allows this. In this case, a PE will run a separate instance of OSPFv2 for each VPN that is attached to the PE; the PE will in general have multiple VPN-specific OSPFv2 routing tables.
VPNは、その内部ルーティングプロトコルとしてのOSPFv2を使用する場合、そのVPNのCEルータがPEルータとピアにはOSPFv2を使用することは必ずしも当てはまりません。 PEルータへのルートを配布するBGPまたは（例えば）RIPを使用しながら、VPN内の各サイトは、そのサイト内のルーティングプロトコルとしてのOSPFv2を使用することができます。 OSPFv2には、サイト内には、同様PE-CEリンク上でそれを使用するために使用されている場合しかし、それは確かに便利で、[VPN]明示的にこれができます。この場合、PEは、PEに取り付けられている各VPNのためのOSPFv2の別のインスタンスを実行します。 PEは、一般的に、複数のVPN固有のOSPFv2ルーティングテーブルを有するであろう。
When OSPFv2 is used on a PE-CE link that belongs to a particular VPN, the PE router must redistribute to that VPN's OSPFv2 instance certain routes that have been installed in the BGP routing table. Similarly, a PE router must redistribute to BGP routes that have been installed in the VPN-specific OSPF routing tables. Procedures for this are specified in [VPN-OSPF].
OSPFv2のは、特定のVPNに属するPE-CEリンク上で使用される場合、PEルータはそのVPNのOSPFv2インスタンスにBGPルーティングテーブルにインストールされている特定のルートを再配布しなければなりません。同様に、PEルータはVPN固有のOSPFルーティングテーブルにインストールされているBGPルートを再配布しなければなりません。このための手順は、[VPN-OSPF]で指定されています。
The routes that are redistributed from BGP to OSPFv2 are advertised in LSAs that are originated by the PE. The PE acts as an OSPF border router, advertising some of these routes in AS-external LSAs, and some in summary LSAs, as specified in [VPN-OSPF].
OSPFv2のにBGPから再配布されるルートがPEによって発信されたLSAでアドバタイズされます。 [VPN-OSPF]で指定されたPEは、サマリーLSAにおけるAS-外部LSAにおけるこれらの経路の一部、およびいくつかの広告、OSPF境界ルータとして働きます。
Similarly, when a PE router receives an LSA from a CE router, it runs the OSPF routing computation. Any route that gets installed in the OSPF routing table must be translated into a VPN-IPv4 route and then redistributed into BGP. BGP will then distribute these routes to the other PE routers.
PEルータは、CEルータからLSAを受信した場合同様に、それはOSPFルーティング計算を実行します。 OSPFルーティングテーブルにインストールされる任意の経路は、VPN-IPv4ルートに翻訳した後、BGPに再配布されなければなりません。 BGPは、他のPEルータにこれらのルートを配布します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
A PE, say PE1, may learn a route to a particular VPN-IPv4 address prefix via BGP. This may cause it to generate a summary LSA or an AS-external LSA in which it reports that address prefix. This LSA may then be distributed to a particular CE, say CE1. The LSA may then be distributed throughout a particular OSPF area, reaching another CE, say CE2. CE2 may then distribute the LSA to another PE, say PE2.
PEは、BGPを介して特定のVPN-IPv4アドレスプレフィックスへのルートを学習することができる、PE1を言います。これは、要約LSAか、そのアドレスプレフィックスを報告しているAS外部LSAを生成することがあります。このLSAには、特定のCEに配布することができる、CE1は言います。 LSAは、その後、特定のOSPFエリア全体に分散別のCEに到達することができる、CE2を言います。 CE2は、別のPEにLSAを配布することができ、PE2を言います。
As stated in the previous section, PE2 must run the OSPF routing computation to determine whether a particular address prefix, reported in an LSA from CE2, is reachable from CE2 via a path that does not include any PE router. Unfortunately, there is no standard way to do this. The OSPFv2 LSAs do not necessarily carry the information needed to enable PE2 to determine that the path to address prefix X in a particular LSA from CE2 is actually a path that includes, say PE1. If PE2 then leaks X into BGP as a VPN-IPv4 route, then PE2 is violating one of the constraints for loop-freedom in BGP; viz., that routes learned from a particular BGP domain are not redistributed back into that BGP domain. This could cause a routing loop to be created.
前節で述べたように、PE2はCE2からLSAに報告特定のアドレスプレフィックスは、任意のPEルータを含まない経路を介してCE2から到達可能であるかどうかを決定するためにOSPFルーティング計算を実行する必要があります。残念ながら、これを行うための標準的な方法はありません。 OSPFv2のLSAは必ずしもパスが実際に含まれるパスですCE2から特定のLSAにプレフィックスXに対処することを決定するために、PE2を有効にするために必要な情報を運ばない、PE1を言います。 PE2は、次にVPN-IPv4ルートとしてBGPにXが漏れた場合、PE2はBGPのループ自由度の制約のいずれかに違反しています。すなわち、特定のBGPドメインから学習したルートをバックそのBGPドメインに再配布されていないこと。これは、ルーティングループが作成される可能性があります。
It is therefore necessary to have a means by which an LSA may carry the information that a particular address prefix has been learned from a PE router. Any PE router that receives an LSA with this information would omit the information in this LSA from its OSPF routing computation, and thus it would not leak the information back into BGP.
LSAは、特定のアドレスプレフィックスがPEルータから学習されたという情報を運ぶことができる手段を有することが必要です。この情報をLSAを受信する任意のPEルータは、OSPFルーティング計算からこのLSAの情報を省略することになるので、それがバックBGPに情報を漏洩しないであろう。
When a PE generates an AS-external LSA, it could use a distinct tag value to indicate that the LSA is carrying information about an address prefix for whom the path includes a PE router. However, this method is not available in the case where the PE generates a Summary LSA. Per [VPN-OSPF], each PE router must function as an OSPF area 0 router. If the PE-CE link is an area 0 link, then it is possible for the PE to receive, over that link, a summary LSA that originated at another PE router. Thus, we need some way of marking a summary LSA to indicate that it is carrying information about a path via a PE router.
PEは、AS外部LSAを生成するとき、それは、LSAは経路がPEルータを含む誰のためのアドレスプレフィックス情報を運んでいることを示すために、異なるタグ値を使用することができます。しかし、この方法では、PEは、サマリLSAを生成する場合に使用できません。 [VPN-OSPF]あたり、各PEルータは、OSPFエリア0ルータとして機能しなければなりません。 PE-CEリンクが領域0リンクであればPEは、そのリンクを介して、別のPEルータで発生要約LSAを受信するために、それが可能です。したがって、我々はそれがPEルータを介したパスに関する情報を伝送していることを示すために、サマリーLSAをマーキングいくつかの方法が必要です。
The high-order bit of the LSA Options field (a previously unused bit) is used to solve the problem described in the previous section. We refer to this bit as the DN bit. When a type 3, 5, or 7 LSA is sent from a PE to a CE, the DN bit MUST be set. The DN bit MUST be clear in all other LSA types.
LSAオプションフィールド（未使用ビット）の上位ビットは、前のセクションで説明した問題を解決するために使用されます。私たちは、DNビットとしてこのビットを参照してください。タイプ3,5、又は7 LSAをCEにPEから送信されると、DNビットがセットされなければなりません。 DNビットは、他のすべてのLSAタイプで明確でなければなりません。
+-------------------------------------+
| DN | * | DC | EA | N/P | MC | E | * |
+-------------------------------------+
Options Field with DN Bit
(RFC 2328, Section A.2)
When the PE receives, from a CE router, a type 3, 5, or 7 LSA with the DN bit set, the information from that LSA MUST NOT be used during the OSPF route calculation. As a result, the LSA is not translated into a BGP route. The DN bit MUST be ignored in all other LSA types.
PEを受信すると、DNビットが設定されたCEルータ、タイプ3,5、又は7 LSAから、そのLSAからの情報は、OSPF経路計算中に使用してはいけません。その結果、LSAは、BGPルートに翻訳されていません。 DNビットは、他のすべてのLSAタイプで無視しなければなりません。
This prevents routes learned via BGP from being redistributed to BGP. (This restriction is analogous to the usual OSPF restriction that inter-area routes that are learned from area 0 are not passed back to area 0.)
これは、BGPに再配布されることからBGP経由で学習したルートを防ぎます。 （この制限は、エリア0から学習されたエリア間のルートは領域0に戻されていないことを、通常のOSPF制限に類似しています）
Note that the DN bit has no other effect on LSA handling. In particular, an LSA with the DN bit set will be put in the topological database, aged, flooded, etc., just as if DN were not set.
DNビットはLSAの取り扱い上の他の影響を与えないことに注意してください。具体的には、DNビットがセットされたLSAは、DNが設定されていなかったかのように、など、浸水、老人、トポロジカルデータベースに置かれます。
An attacker may cause the DN bit to be set, in an LSA traveling from CE to PE, when the DN bit should really be clear. This may cause the address prefixes mentioned in that LSA to be unreachable from other sites of the VPN. Similarly, an attacker may cause the DN bit to be clear, in an LSA traveling in either direction, when the DN bit should really be set. This may cause routing loops for traffic that is destined to the address prefixes mentioned in that LSA.
攻撃者は、DNビットが本当に明確にする必要がありCEからPEへの旅行LSAで、DNビットがセットされる可能性があります。これは、LSAで言及アドレスプレフィックスは、VPNの他のサイトから到達不可能であることを引き起こす可能性があります。同様に、攻撃者は、DNビットは、DNビットが実際に設定する必要があり、いずれかの方向に走行するLSAで、明確にすることが原因となることがあります。これは、LSAで言及アドレスプレフィックスを宛先とするトラフィックのためのルーティングループを引き起こす可能性があります。
These possibilities may be eliminated by using cryptographic authentication as specified in Section D of [OSPFv2].
これらの可能性は、[のOSPFv2]のセクションDで指定された暗号認証を使用して除去することができます。
The idea of using the high-order options bit for this purpose is due to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this work. We also wish to thank Acee Lindem for his helpful comments.
この目的のために、高次のオプションビットを使用してのアイデアは、デレク・ヨンによるものです。この作品への彼の貢献のためのヤコフ・レックターに感謝します。我々はまた、彼の役に立つコメントをACEE Lindemに感謝したいです。
[OSPFv2] Postel, J., "Suggested Telnet Protocol Changes", RFC 328, April 1972.
[OSPFv2の]ポステル、J.は、RFC 328、1972年4月 "のTelnetプロトコルの変更提案します"。
[VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[VPN]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[VPN-OSPF] 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.
[VPN-OSPF]ローゼン、E.、Psenak、P.、およびP. Pillay-Esnault、RFC 4577、2006年6月 "OSPF、BGP / MPLS IP仮想プライベートネットワーク（VPN）用プロバイダ/カスタマーエッジプロトコルとして"。
Authors' Addresses
著者のアドレス
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
Peter Psenak Cisco Systems BA Business Center, 9th Floor Plynarenska 1 Bratislava 82109 Slovakia
ピーターPsenakシスコシステムズBAビジネスセンター、9階のPlynarenska 1ブラチスラバ82109スロバキア
EMail: ppsenak@cisco.com
メールアドレス：ppsenak@cisco.com
Padma Pillay-Esnault Cisco Systems 3750 Cisco Way San Jose, CA 95134
パドマPillay-Esnaultシスコシステムズ3750のCiscoウェイサンノゼ、CA 95134
EMail: ppe@cisco.com
メールアドレス：ppe@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。