[要約] RFC 8770は、OSPFv2のホストルーターサポートに関する要件を定義しています。このRFCの目的は、ホストルーターがOSPFv2をサポートするためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) K. Patel
Request for Comments: 8770 Arrcus
Updates: 6987 P. Pillay-Esnault
Category: Standards Track PPE Consulting
ISSN: 2070-1721 M. Bhardwaj
S. Bayraktar
Cisco Systems
April 2020
Host Router Support for OSPFv2
OSPFv2のホストルーターサポート
Abstract
概要
The Open Shortest Path First Version 2 (OSPFv2) protocol does not have a mechanism for a node to repel transit traffic if it is on the shortest path. This document defines a bit called the Host-bit (H-bit). This bit enables a router to advertise that it is a non-transit router. This document also describes the changes needed to support the H-bit in the domain. In addition, this document updates RFC 6987 to advertise Type 2 External and Not-So-Stubby Area (NSSA) Link State Advertisements (LSAs) (RFC 3101) with a high cost in order to repel traffic effectively.
Open Shortest Path Firstバージョン2（OSPFv2）プロトコルには、ノードが最短パス上にある場合、通過トラフィックをはじくメカニズムがありません。このドキュメントでは、ホストビット（Hビット）と呼ばれるビットを定義しています。このビットにより、ルーターは非中継ルーターであることを通知できます。このドキュメントでは、ドメインでHビットをサポートするために必要な変更についても説明しています。さらに、このドキュメントは、トラフィックを効果的にはじくために、タイプ2の外部およびNot-So-Stubbyエリア（NSSA）リンクステートアドバタイズメント（LSA）（RFC 3101）を高コストでアドバタイズするようにRFC 6987を更新しています。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8770.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8770で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Requirements Language
3. Host-Bit Support
4. SPF Modifications
5. Autodiscovery and Backward Compatibility
6. OSPF AS-External-LSAs / NSSA-LSAs with Type 2 Metrics
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
The OSPFv2 protocol specifies a Shortest Path First (SPF) algorithm that identifies transit vertices based on their adjacencies. Therefore, OSPFv2 does not have a mechanism to prevent traffic transiting a participating node if it is a transit vertex in the only existing or shortest path to the destination. The use of metrics to make the node undesirable can help to repel traffic only if an alternative better route exists.
OSPFv2プロトコルは、隣接に基づいて通過頂点を識別する最短パス優先（SPF）アルゴリズムを指定します。したがって、OSPFv2には、宛先への既存のパスまたは最短パスの唯一のトランジット頂点であるトラフィックが参加ノードを通過するのを防ぐメカニズムがありません。メトリックを使用してノードを望ましくないものにすることは、より良い代替ルートが存在する場合にのみ、トラフィックを撃退するのに役立ちます。
A mechanism to move traffic away from the shortest path is particularly useful for a number of use cases:
トラフィックを最短経路から遠ざけるメカニズムは、多くのユースケースで特に役立ちます。
1. Graceful isolation of a router, to avoid blackhole scenarios when there is a reload and possible long reconvergence times.
1. ルーターの優雅な分離。リロードが発生し、再収束時間が長くなる可能性がある場合のブラックホールシナリオを回避します。
2. Closet switches that are not usually used for transit traffic but need to participate in the topology.
2. トランジットトラフィックには通常使用されないが、トポロジーに参加する必要があるクローゼットスイッチ。
3. Overloaded routers that could use such a capability to temporarily repel traffic until they stabilize.
3. このような機能を使用して、トラフィックが安定するまで一時的にトラフィックをはじく可能性のある過負荷のルーター。
4. BGP route reflectors, known as virtual Route Reflectors, that are not in the forwarding path but are in central locations such as data centers. Such route reflectors are typically used for route distribution and are not capable of forwarding transit traffic. However, they need to learn the OSPF topology to perform SPF computation for optimal routes and reachability resolution for their clients [BGP-ORR].
4. 仮想ルートリフレクターと呼ばれるBGPルートリフレクター。転送パスではなく、データセンターなどの中央の場所にあります。このようなルートリフレクタは、通常、ルート配布に使用され、通過トラフィックを転送できません。ただし、クライアントの最適なルートと到達可能性の解決のためにSPF計算を実行するには、OSPFトポロジを学習する必要があります[BGP-ORR]。
This document describes the functionality provided by the Host-bit (H-bit); this functionality prevents other OSPFv2 routers from using the host router by excluding it in path calculations for transit traffic in OSPFv2 routing domains. If the H-bit is set, then the calculation of the shortest-path tree for an area, as described in Section 16.1 of [RFC2328], is modified by including a check to verify that transit vertices DO NOT have the H-bit set (see Section 4). Furthermore, in order to repel traffic effectively, this document updates [RFC6987] so that Type 2 External and Not-So-Stubby Area (NSSA) Link State Advertisements (LSAs) [RFC3101] are advertised with a high cost (see Section 6). OSPFv3 [RFC5340] defines an option bit, known as the R-bit, for router-LSAs; the H-bit supports similar functionality.
このドキュメントでは、ホストビット（Hビット）によって提供される機能について説明します。この機能は、OSPFv2ルーティングドメインのトランジットトラフィックのパス計算で除外することにより、他のOSPFv2ルーターがホストルーターを使用できないようにします。 Hビットが設定されている場合、[RFC2328]のセクション16.1で説明されているように、エリアの最短経路ツリーの計算は、通過頂点にHビットが設定されていないことを確認するチェックを含めることによって変更されます（セクション4を参照）。さらに、トラフィックを効果的にはじくために、このドキュメントは[RFC6987]を更新して、タイプ2の外部およびNot-So-Stubbyエリア（NSSA）リンク状態アドバタイズ（LSA）[RFC3101]が高コストでアドバタイズされるようにします（セクション6を参照）。 。 OSPFv3 [RFC5340]は、ルーターLSAのRビットと呼ばれるオプションビットを定義しています。 Hビットは同様の機能をサポートします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document defines a new router-LSA bit, known as the Host-bit or the H-bit. An OSPFv2 router advertising a router-LSA with the H-bit set indicates that it MUST NOT be used as a transit router (see Section 4) by other OSPFv2 routers in the area that support the H-bit functionality.
このドキュメントでは、ホストビットまたはHビットと呼ばれる新しいルーターLSAビットを定義します。 Hビットが設定されたルーターLSAをアドバタイズするOSPFv2ルーターは、Hビット機能をサポートするエリア内の他のOSPFv2ルーターが中継ルーター（セクション4を参照）として使用してはならないことを示します。
If the H-bit is not set, then backward compatibility is achieved, as the behavior will be the same as in [RFC2328].
Hビットが設定されていない場合、動作は[RFC2328]と同じになるため、下位互換性が実現されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H|0|0|N|W|V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | TOS metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Figure 1: OSPF Router-LSA
図1：OSPFルーターLSA
Bit H is the high-order bit of the OSPF flags, as shown below.
ビットHは、次に示すように、OSPFフラグの上位ビットです。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|H|0|0|N|W|V|E|B|
+-+-+-+-+-+-+-+-+
Figure 2: OSPF Router-LSA Option Bits
図2：OSPFルーターLSAオプションビット
When the H-bit is set, the OSPFv2 router is a host (non-transit) router and is incapable of forwarding transit traffic. In this mode, the other OSPFv2 routers in the area MUST NOT use the host router for transit traffic but may send traffic to its local destinations.
Hビットが設定されている場合、OSPFv2ルーターはホスト（非トランジット）ルーターであり、トランジットトラフィックを転送できません。このモードでは、エリア内の他のOSPFv2ルーターは通過トラフィックにホストルーターを使用してはなりませんが、ローカルの宛先にトラフィックを送信できます。
An OSPFv2 router originating a router-LSA with the H-bit set MUST advertise all its non-stub links with a link cost of MaxLinkMetric [RFC6987].
Hビットが設定されたルーターLSAを発信するOSPFv2ルーターは、リンクコストがMaxLinkMetric [RFC6987]のすべての非スタブリンクをアドバタイズする必要があります。
When the H-bit is set, an Area Border Router (ABR) MUST advertise the same H-bit setting in its self-originated router-LSAs for all attached areas. The consistency of the setting will prevent inter-area traffic transiting through the router by suppressing advertisements of prefixes from other routers in the area in its summary-LSAs. Only IPv4 prefixes associated with its local interfaces MUST be advertised in summary-LSAs to provide reachability to end hosts attached to a router with the H-bit set.
Hビットが設定されている場合、エリア境界ルーター（ABR）は、接続されているすべてのエリアの自己発信ルーターLSAで同じHビット設定をアドバタイズする必要があります。設定の一貫性は、サマリーLSAでエリア内の他のルーターからのプレフィックスのアドバタイズを抑制することにより、ルーターを通過するエリア間トラフィックを防ぎます。 Hビットが設定されたルーターに接続されたエンドホストへの到達可能性を提供するために、そのローカルインターフェイスに関連付けられたIPv4プレフィックスのみをサマリーLSAでアドバタイズする必要があります。
When the H-bit is set, the host router cannot act as an Autonomous System Border Router (ASBR). Indeed, ASBRs are transit routers to prefixes that are typically imported through redistribution of prefixes from other routing protocols. Therefore, non-local IPv4 prefixes, e.g., those imported from other routing protocols, SHOULD NOT be advertised in AS-external-LSAs if the H-bit is set. Some use cases, such as an overloaded router or a router being gracefully isolated, may benefit from continued advertisements of non-local prefixes. In these cases, the Type 2 metric in AS-external-LSAs MUST be set to LSInfinity [RFC2328] to repel traffic (see Section 6 of this document).
Hビットが設定されている場合、ホストルーターは自律システム境界ルーター（ASBR）として機能できません。実際、ASBRは、他のルーティングプロトコルからのプレフィックスの再配布を通じて通常インポートされるプレフィックスへの中継ルーターです。したがって、他のルーティングプロトコルからインポートされたものなど、非ローカルIPv4プレフィックスは、Hビットが設定されている場合、AS-external-LSAでアドバタイズされるべきではありません（SHOULD NOT）。過負荷のルーターや正常に分離されたルーターなどの一部の使用例では、非ローカルプレフィックスの継続的なアドバタイズが役立つ場合があります。これらの場合、AS-external-LSAのタイプ2メトリックをLSInfinity [RFC2328]に設定して、トラフィックをはじく必要があります（このドキュメントのセクション6を参照）。
The SPF calculation described in Section 16.1 of [RFC2328] is modified to ensure that the routers originating router-LSAs with the H-bit set will not be used for transit traffic. Step (2) is modified to include a check on the H-bit, as shown below. (Please note that all of the sub-procedures of Step (2) remain unchanged and are not included in the excerpt below.)
[RFC2328]のセクション16.1で説明されているSPF計算が変更され、Hビットが設定されたルーターLSAを発信するルーターがトランジットトラフィックに使用されないようになりました。ステップ（2）は、以下に示すように、Hビットのチェックを含むように変更されています。 （ステップ（2）のすべてのサブプロシージャは変更されず、以下の抜粋には含まれていません。）
(2) Call the vertex just added to the tree "vertex V". Examine the LSA associated with vertex V. This is a lookup in Area A's link state database based on the Vertex ID. If this is a router-LSA, and the H-bit of the router-LSA is set, and vertex V is not the root, then the router should not be used for transit and Step (3) should be executed immediately. If this is a router-LSA and bit V of the router-LSA (see Appendix A.4.2) is set, set Area A's TransitCapability to TRUE. In any case, each link described by the LSA gives the cost to an adjacent vertex. For each described link (say it joins vertex V to vertex W):
（2）ツリーに追加した頂点を「頂点V」と呼びます。頂点Vに関連付けられたLSAを調べます。これは、頂点IDに基づくエリアAのリンク状態データベースのルックアップです。これがルーターLSAであり、ルーターLSAのHビットが設定されていて、頂点Vがルートでない場合は、ルーターを通過に使用せず、ステップ（3）をすぐに実行する必要があります。これがルーターLSAであり、ルーターLSAのビットV（付録A.4.2を参照）が設定されている場合は、エリアAのTransitCapabilityをTRUEに設定します。いずれの場合でも、LSAによって記述される各リンクは、隣接する頂点にコストを与えます。記述されたリンクごとに（たとえば、頂点Vを頂点Wに結合するとします）：
To reduce the possibility of any routing loops due to partial deployment, this document defines an OSPF Router Information (RI) LSA capability bit [RFC7770]. See Section 7 (Table 2).
部分的な展開によるルーティングループの可能性を減らすために、このドキュメントではOSPFルーター情報（RI）LSA機能ビット[RFC7770]を定義しています。セクション7（表2）を参照してください。
The RI LSA MUST be area-scoped.
RI LSAはエリアスコープでなければなりません。
Autodiscovery via announcement of the OSPF Host Router capability (Section 7) ensures that the H-bit functionality and its associated SPF changes MUST only take effect if all the routers in a given OSPF area support this functionality.
OSPFホストルーター機能のアナウンスによる自動検出（セクション7）により、Hビット機能とそれに関連するSPFの変更は、特定のOSPFエリア内のすべてのルーターがこの機能をサポートする場合にのみ有効になる必要があります。
In normal operation, it is possible that the RI LSA will fail to reach all routers in an area in a timely manner. For example, if a new router without H-bit support joins an area that previously had only H-bit-capable routers with the H-bit set, then it may take some time for the RI LSA to propagate to all routers. While it is propagating, the routers in the area will gradually detect the presence of a router that does not support the capability and will revert back to the normal SPF calculation. During the propagation time, the area as a whole is unsure of the status of the new router; this type of situation can cause temporary transient loops.
通常の運用では、RI LSAがエリア内のすべてのルーターにタイムリーに到達できない可能性があります。たとえば、Hビットをサポートしていない新しいルーターが、以前Hビットが設定されたHビット対応ルーターしかなかったエリアに参加した場合、RI LSAがすべてのルーターに伝達されるまでに時間がかかることがあります。伝播している間、エリア内のルーターは、機能をサポートしないルーターの存在を徐々に検出し、通常のSPF計算に戻ります。伝播時間中、エリア全体では新しいルーターのステータスがわかりません。このような状況では、一時的な一時的なループが発生する可能性があります。
The following recommendations will mitigate transient routing loops:
次の推奨事項は、一時的なルーティングループを軽減します。
* Implementations are RECOMMENDED to provide a configuration parameter to manually override enforcement of the H-bit functionality in partial deployments where the topology guarantees that OSPFv2 routers not supporting the H-bit do not compute routes resulting in routing loops.
* 実装は、トポロジーがHビットをサポートしていないOSPFv2ルーターがルートを計算してルーティングループを生じさせないことを保証する部分的な展開におけるHビット機能の実施を手動で上書きする構成パラメーターを提供することを推奨します。
* All routers with the H-bit set MUST advertise all of the router's non-stub links with a metric equal to MaxLinkMetric [RFC6987] in its LSAs in order to prevent OSPFv2 routers (unless a last-resort path) that do not support the H-bit from attempting to use the non-stub links for transit traffic.
* HビットをサポートしないOSPFv2ルーター（ラストリゾートパスを除く）を防止するために、Hビットが設定されたすべてのルーターは、LSAでMaxLinkMetric [RFC6987]に等しいメトリックを持つルーターのすべての非スタブリンクをアドバタイズする必要があります-transitトラフィックに非スタブリンクを使用しようとすることからのビット。
* All routers supporting the H-bit MUST check the RI LSAs of all nodes in the area to verify that all nodes support the H-bit before actively using the H-bit feature. If any router does not advertise the OSPF Host Router capability (Section 7), then the SPF modifications described in Section 4 MUST NOT be used in the area.
* Hビットをサポートするすべてのルーターは、Hビット機能をアクティブに使用する前に、エリア内のすべてのノードのRI LSAをチェックして、すべてのノードがHビットをサポートしていることを確認する必要があります。いずれかのルーターがOSPFホストルーター機能をアドバタイズしない場合（セクション7）、セクション4で説明されているSPFの変更をエリアで使用してはなりません（MUST NOT）。
When calculating the path to a prefix in an OSPF AS-external-LSA or NSSA-LSA [RFC3101] with a Type 2 metric, the advertised Type 2 metric is taken as more significant than the OSPF intra-area or inter-area path. Hence, advertising the links with MaxLinkMetric as specified in [RFC6987] does not discourage transit traffic when calculating AS-external or NSSA routes with Type 2 metrics.
タイプ2メトリックでOSPF AS-external-LSAまたはNSSA-LSA [RFC3101]のプレフィックスへのパスを計算する場合、アドバタイズされたタイプ2メトリックは、OSPFのエリア内パスまたはエリア間パスよりも重要度が高いと見なされます。したがって、[RFC6987]で指定されているようにMaxLinkMetricを使用してリンクをアドバタイズしても、タイプ2メトリックでAS外部ルートまたはNSSAルートを計算するときにトランジットトラフィックが妨げられることはありません。
Consequently, this document updates [RFC6987] so that the Type 2 metric in any self-originated AS-external-LSAs or NSSA-LSAs is advertised as LSInfinity-1 [RFC2328]. If the H-bit is set, then the Type 2 metric MUST be set to LSInfinity.
したがって、このドキュメントは[RFC6987]を更新し、自己生成のAS-external-LSAまたはNSSA-LSAのタイプ2メトリックがLSInfinity-1 [RFC2328]としてアドバタイズされるようにします。 Hビットが設定されている場合、タイプ2メトリックはLSInfinityに設定する必要があります。
IANA has registered the following value in the "OSPFv2 Router Properties Registry".
IANAは、「OSPFv2ルータープロパティレジストリ」に以下の値を登録しています。
+-------+--------------+-----------+
| Value | Description | Reference |
+=======+==============+===========+
| 0x80 | Host (H-bit) | RFC 8770 |
+-------+--------------+-----------+
Table 1: H-Bit
表1：Hビット
IANA has registered the following in the "OSPF Router Informational Capability Bits" registry.
IANAは、「OSPFルーター情報機能ビット」レジストリに以下を登録しています。
+------------+------------------+-----------+
| Bit Number | Capability Name | Reference |
+============+==================+===========+
| 7 | OSPF Host Router | RFC 8770 |
+------------+------------------+-----------+
Table 2: OSPF Host Router Capability Bit
表2：OSPFホストルーター機能ビット
This document introduces the H-bit, which is a capability feature that restricts the use of a router for transit, while only its local destinations are reachable. This is a subset of the operations of a normal router and therefore should not introduce new security considerations beyond those already known in OSPFv2 [RFC2328]. The feature introduces the advertisement of host router capability information to all OSPFv2 routers in an area. This information can be leveraged for discovery and verification that all routers in the area support the capability before the feature is turned on. In the event that a rogue or buggy router incorrectly advertises its capability, possible scenarios are as follows:
このドキュメントでは、H-ビットを紹介します。これは、ローカルの宛先のみが到達可能である一方で、ルーターの転送への使用を制限する機能機能です。これは通常のルーターの操作のサブセットであるため、OSPFv2 [RFC2328]ですでに知られているものを超える新しいセキュリティの考慮事項を導入しないでください。この機能により、エリア内のすべてのOSPFv2ルーターにホストルーター機能情報のアドバタイズが導入されます。この情報を利用して、エリア内のすべてのルーターが機能をオンにする前にその機能をサポートしていることを検出および検証できます。不正またはバグのあるルーターがその機能を誤ってアドバタイズした場合、考えられるシナリオは次のとおりです。
* The router does not have the capability but sends the H-bit set in its LSAs. In this case, a routing loop is possible. However, this is mitigated by the fact that this router should be avoided anyway. Moreover, the link metrics cost (MaxLinkMetric) of this router will mitigate this situation. In any case, a router advertising the H-bit capability without its link metrics cost equal to MaxLinkMetric could be a rogue router and should be avoided.
* ルータにはその機能はありませんが、LSAでHビットセットを送信します。この場合、ルーティングループが発生する可能性があります。ただし、これは、このルーターを回避する必要があるという事実によって緩和されます。さらに、このルーターのリンクメトリックコスト（MaxLinkMetric）は、この状況を緩和します。いずれの場合も、MaxLinkMetricに等しいリンクメトリックコストなしでHビット機能をアドバタイズするルーターは不正なルーターである可能性があるため、回避する必要があります。
* The router has the capability but sends the H-bit clear in its LSAs. In this case, the router merely prevents the support of other H-bit routers in the area and prevents all the routers from running the modified SPF. Any impacts are also mitigated in this scenario, as other H-bit routers in the area also advertise the MaxLinkMetric cost, so they will still be avoided unless they are the last-resort path.
* ルータには機能がありますが、LSAでHビットクリアを送信します。この場合、ルーターは、エリア内の他のHビットルーターのサポートを妨げ、すべてのルーターが変更されたSPFを実行するのを防ぎます。このシナリオでは、エリア内の他のHビットルーターもMaxLinkMetricコストをアドバタイズするため、影響は軽減されます。そのため、最後のリゾートパスでない限り、これらのルーターは回避されます。
* The rogue router is on the only transit path for some destinations and sends the H-bit set (for no good/valid reason) in its LSAs, and effectively partitions the network. This case is indistinguishable from the normal case where an operator may consciously decide to set the H-bit to perform maintenance on a router that is on the only transit path. The OSPF protocol will continue to function within the partitioned domains.
* 不正なルーターは一部の宛先の唯一の中継パス上にあり、LSAでHビットセットを送信し（正当な理由がないため）、ネットワークを効果的に分割します。このケースは、オペレーターが意識的にHビットを設定して、唯一のトランジットパス上にあるルーターのメンテナンスを実行することを決定する通常のケースと区別がつきません。 OSPFプロトコルは、分割されたドメイン内で機能し続けます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<https://www.rfc-editor.org/info/rfc2328>。
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI 10.17487/RFC6987, September 2013, <https://www.rfc-editor.org/info/rfc6987>.
[RFC6987] Retana、A.、Nguyen、L.、Zinin、A.、White、R。、およびD. McPherson、「OSPF Stub Router Advertisement」、RFC 6987、DOI 10.17487 / RFC6987、2013年9月、<https：/ /www.rfc-editor.org/info/rfc6987>。
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[RFC7770] Lindem、A.、Ed。、Shen、N.、Vasseur、JP。、Aggarwal、R.、and S. Shaffer、 "Extensions to OSPF for Advertising Optional Router Capabilities"、RFC 7770、DOI 10.17487 / RFC7770、 2016年2月、<https://www.rfc-editor.org/info/rfc7770>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[BGP-ORR] Raszuk, R., Ed., Cassar, C., Aman, E., Decraene, B., and K. Wang, "BGP Optimal Route Reflection (BGP-ORR)", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-optimal-route-reflection-20, 8 January 2020, <https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-20>.
[BGP-ORR] Raszuk、R.、Ed。、Cassar、C.、Aman、E.、Decraene、B。、およびK. Wang、「BGP Optimal Route Reflection（BGP-ORR）」、Work in Progress、インターネット-Draft、draft-ietf-idr-bgp-optimal-route-reflection-20、2020年1月8日、<https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection- 20>。
[RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, DOI 10.17487/RFC3101, January 2003, <https://www.rfc-editor.org/info/rfc3101>.
[RFC3101]マーフィー、P。、「OSPF Not-So-Stubby Area（NSSA）オプション」、RFC 3101、DOI 10.17487 / RFC3101、2003年1月、<https://www.rfc-editor.org/info/rfc3101 >。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、DOI 10.17487 / RFC5340、2008年7月、<https：//www.rfc-editor .org / info / rfc5340>。
Acknowledgements
謝辞
The authors would like to acknowledge Hasmit Grover for discovering the limitation in [RFC6987], and Acee Lindem, Abhay Roy, David Ward, Burjiz Pithawala, and Michael Barnes for their comments.
著者は、[RFC6987]の制限を発見したHasmit Grover、およびコメントについては、Acee Lindem、Abhay Roy、David Ward、Burjiz Pithawala、およびMichael Barnesに感謝します。
Authors' Addresses
著者のアドレス
Keyur Patel Arrcus
キールパテルが再発
Email: keyur@arrcus.com
Padma Pillay-Esnault PPE Consulting
Padma Pillay-Esnault PPEコンサルティング
Email: padma.ietf@gmail.com
Manish Bhardwaj Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 United States of America
Manish Bhardwaj Cisco Systems 170 W. Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: manbhard@cisco.com
Serpil Bayraktar Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 United States of America
Serpil Bayraktar Cisco Systems 170 W. Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: serpil@cisco.com