[要約] 要約： RFC 4576は、BGP/MPLS IP仮想プライベートネットワーク（VPN）でのループを防ぐために、リンクステート広告（LSA）オプションビットの使用方法を提案しています。目的： このRFCの目的は、BGP/MPLS IP VPNでのループを防ぐために、LSAオプションビットを使用する方法を提案し、ネットワークの安定性と信頼性を向上させることです。
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)
Link State Advertisement（LSA）オプションを使用して、BGP/MPLS IP仮想プライベートネットワーク（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).
Copyright（c）The Internet Society（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」サービスを提供するときに発生する可能性のある特定の問題を扱う手順を指定し、顧客はOSPFV2を使用してSPへのルートを宣伝します。この状況では、顧客エッジ（CE）ルーターとプロバイダーエッジ（PE）ルーターがOSPFピアであり、顧客ルートはCEからPEにOSPFv2を介して送信されます。顧客ルートはBGPルートに変換され、BGPはバックボーンを横切って他のPEルーターに運びます。ルートは、OSPFを介して他のCEルーターに送信されるOSPFルートに変換されます。この変換の結果、ループを防ぐために必要な情報の一部が失われる可能性があります。ルートがPEからCEに送信されると、ルートがCEから受信するPEによってルートが無視されるようにするための手順が必要です。このドキュメントは、LSA（Link State Advertisements）のオプションビットのいずれかを使用して、LSAがすでにPEによって転送されており、それを見る他のPESによって無視されるべきであることを示す必要な手順を指定します。
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バックボーンを使用して「IP VPN」サービスを顧客に提供できる方法を説明しています。そのようなサービスでは、顧客のエッジデバイス（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:
CEは、顧客とSPが共同で同意するルーティングプロトコルを使用して、PEとルートを交換します。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から各アドレスプレフィックスへのパスには、SPバックボーンが含まれていません（つまり、PEルーターは含まれません）。
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に接続するPEルーターは、これらのアドレスプレフィックスにBGPに再配布するため、BGPを使用してVPNのルートを互いに分配できるようにします。BGPは、これらのルートを「VPN-IPV4アドレスファミリ」に携帯しているため、通常のインターネットルートとは異なります。VPN-IPV4アドレスファミリも左側のIPアドレスを拡張するため、2つの異なるVPNのアドレスのプレフィックスがBGPに常に異なるようになります。したがって、異なる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ルーターがOSOSPFV2を使用してPEルーターをピアに使用することは必ずしもそうではありません。VPN内の各サイトは、BGPまたはRIP（たとえば）を使用してPEルーターにルートを配布する際に、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ルーターは、BGPルーティングテーブルにインストールされている特定のルートをVPNのOSPFV2インスタンスに再配布する必要があります。同様に、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].
BGPからOSPFV2に再分配されるルートは、PEから発信されるLSAで宣伝されています。PEはOSPFボーダールーターとして機能し、これらのルートのいくつかを、[vpn-sospf]で指定されているように、これらのルートの一部を宣伝し、いくつかの要約LSAを宣伝します。
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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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、たとえばPE1は、BGPを介して特定のVPN-IPV4アドレスプレフィックスへのルートを学習する場合があります。これにより、概要LSAまたはそのアドレスのプレフィックスを報告する概要As-External LSAを生成する可能性があります。このLSAは、特定のCE、たとえばCE1に分配される可能性があります。その後、LSAは特定のOSPFエリア全体に分布し、別のCEに到達する可能性があります。CE2は、LSAを別のPEに分配する場合があります。たとえば、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はOSPFルーティング計算を実行して、CE2からLSAで報告された特定のアドレスプレフィックスが、PEルーターを含まないパスを介してCE2から到達できるかどうかを判断する必要があります。残念ながら、これを行う標準的な方法はありません。OSPFV2 LSAは、PE2がCE2の特定のLSAの接頭辞Xに対処するパスが実際にはPE1を含むパスであると判断できるようにするために必要な情報を必ずしも伝えるとは限りません。PE2がVPN-IPV4ルートとしてXをBGPに漏れた場合、PE2はBGPのループフリードムの制約の1つに違反しています。つまり、特定の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ルーターは、このLSAの情報をOSPFルーティング計算から省略するため、情報を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-pernal 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がPEからCEに送信される場合、DNビットを設定する必要があります。DNビットは、他のすべてのLSAタイプで明確でなければなりません。
+-------------------------------------+
| DN | * | DC | EA | N/P | MC | E | * |
+-------------------------------------+
Options Field with DN Bit (RFC 2328, Section A.2)
DNビットのあるオプションフィールド（RFC 2328、セクション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.
CEルーターからPEがDNビットセットを使用してタイプ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ビットを実際に設定する場合、どちらの方向にも移動するLSAで、DNビットを明確にする可能性があります。これにより、その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.
この目的のために高次のオプションビットを使用するという考えは、デレク・ヨンによるものです。Yakov Rekhterに、この仕事に貢献してくれたことに感謝します。また、彼の有益なコメントについてAcee Lindemに感謝したいと思います。
[OSPFv2] Postel, J., "Suggested Telnet Protocol Changes", RFC 328, April 1972.
[OSPFV2] Postel、J。、「提案されたTelnetプロトコルの変更」、RFC 328、1972年4月。
[VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[VPN] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、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] Rosen、E.、Psenak、P。、およびP. Pillay-Esnault、「BGP/MPLS IP仮想ネットワーク（VPNS）のプロバイダー/顧客エッジプロトコルとしてのOSPF」、RFC 4577、2006年6月。
Authors' Addresses
著者のアドレス
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ、1414マサチューセッツアベニューボックスボロー、マサチューセッツ州01719
EMail: erosen@cisco.com
Peter Psenak Cisco Systems BA Business Center, 9th Floor Plynarenska 1 Bratislava 82109 Slovakia
Peter Psenak Cisco Systems BA Business Center、9階のPlynarenska 1 Bratislava 82109スロバキア
EMail: ppsenak@cisco.com
Padma Pillay-Esnault Cisco Systems 3750 Cisco Way San Jose, CA 95134
Padma Pillay-Esnault Cisco Systems 3750 Cisco Way San Jose、CA 95134
EMail: ppe@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。