[要約] RFC 2329は、OSPF（Open Shortest Path First）の標準化に関する報告書であり、OSPFの設計と実装に関する問題点と解決策を提供しています。このRFCの目的は、OSPFの標準化プロセスを改善し、ネットワークの安定性と互換性を向上させることです。
Network Working Group J. Moy
Request for Comments: 2329 Ascend Communications, Inc.
Category: Informational April 1998
OSPF Standardization Report
OSPF標準化レポート
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This memo documents how the requirements for advancing a routing protocol to Full Standard, set out in [Ref2], have been met for OSPFv2.
このメモは、[Ref2]に記載されているルーティングプロトコルを完全な標準に進めるための要件が、OSPFv2でどのように満たされているかを説明しています。
Please send comments to ospf@gated.cornell.edu.
ospf@gated.cornell.eduにコメントを送ってください。
Table of Contents
目次
1 Introduction ........................................... 2
2 Modifications since Draft Standard status .............. 3
2.1 Point-to-MultiPoint interface .......................... 4
2.2 Cryptographic Authentication ........................... 5
3 Updated implementation and deployment experience ....... 5
4 Protocol Security ...................................... 7
References ............................................. 8
Security Considerations ................................ 8
Author's Address ....................................... 8
Full Copyright Statement ............................... 9
OSPFv2, herein abbreviated simply as OSPF, is an IPv4 routing protocol documented in [Ref8]. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest-path tree. OSPF features include the following:
OSPFv2は、本書では単にOSPFと略され、[Ref8]で文書化されているIPv4ルーティングプロトコルです。 OSPFはリンクステートルーティングプロトコルです。単一の自律システムの内部で実行されるように設計されています。各OSPFルーターは、自律システムのトポロジーを記述する同一のデータベースを維持します。このデータベースから、最短経路ツリーを構築することによってルーティングテーブルが計算されます。 OSPF機能には次のものがあります。
o OSPF responds quickly to topology changes, expending a minimum of network bandwidth in the process.
o OSPFはトポロジーの変更に迅速に応答し、プロセスで最小限のネットワーク帯域幅を消費します。
o Support for CIDR addressing.
o CIDRアドレッシングのサポート。
o OSPF routing exchanges can be authenticated, providing routing security.
o OSPFルーティング交換を認証して、ルーティングセキュリティを提供できます。
o Equal-cost multipath.
o 等コストマルチパス。
o An area routing capability is provided, enabling an Autonomous system to be split into a two level hierarchy to further reduce the amount of routing protocol traffic.
o エリアルーティング機能が提供され、自律システムを2レベルの階層に分割して、ルーティングプロトコルトラフィックの量をさらに削減できます。
o OSPF allows import of external routing information into the Autonomous System, including a tagging feature that can be exploited to exchange extra information at the AS boundary (see [Ref7]).
o OSPFを使用すると、AS境界で追加情報を交換するために利用できるタグ付け機能など、外部ルーティング情報を自律システムにインポートできます（[Ref7]を参照）。
An analysis of OSPF together with a more detailed description of OSPF features was originally provided in [Ref6], as a part of promoting OSPF to Draft Standard status. The analysis of OSPF remains unchanged. Two additional major features have been developed for OSPF since the protocol achieved Draft Standard status: the Point-to-MultiPoint interface and Cryptographic Authentication. These features are described in Sections 2.1 and 2.2 respectively of this memo.
OSPFの分析は、OSPF機能の詳細な説明とともに、もともと[参考文献6]で、OSPFをドラフト標準ステータスに昇格させる一環として提供されました。 OSPFの分析は変更されていません。プロトコルがドラフト標準ステータスを達成して以来、OSPF用に2つの主要な機能が追加されました。ポイントツーマルチポイントインターフェイスと暗号化認証です。これらの機能は、このメモのセクション2.1と2.2でそれぞれ説明されています。
The OSPF MIB is documented in [Ref4]. It is currently at Draft Standard status.
OSPF MIBは[Ref4]に文書化されています。現在、ドラフト標準ステータスです。
OSPF became a Draft Standard with the release of RFC 1583 [Ref3]. Implementations of the new specification in [Ref8] are backward-compatible with RFC 1583. The differences between the two documents are described in the Appendix Gs of [Ref1] and [Ref8]. These differences are listed briefly below. Two major features were also added, the Point-to-MultiPoint interface and Cryptographic Authentication, which are described in separate sections.
OSPFは、RFC 1583 [Ref3]のリリースによりドラフト標準になりました。 [Ref8]の新しい仕様の実装は、RFC 1583と下位互換性があります。2つのドキュメントの違いは、[Ref1]と[Ref8]の付録Gで説明されています。これらの違いを以下に簡単に示します。 2つの主要な機能、ポイントツーマルチポイントインターフェイスと暗号化認証も追加されました。これらについては、個別のセクションで説明します。
o Configuration requirements for OSPF area address ranges have been relaxed to allow greater flexibility in area assignment. See Section G.3 of [Ref1] for details.
o OSPFエリアアドレス範囲の構成要件が緩和され、エリア割り当ての柔軟性が向上しました。詳細については、[Ref1]のセクションG.3を参照してください。
o The OSPF flooding algorithm was modified to a) improve database convergence in networks with low speed links b) resolve a problem where unnecessary LSA retransmissions could occur as a result of differing clock granularities, c) remove race conditions between the flooding of MaxAge LSAs and the Database Exchange process, d) clarify the use of the MinLSArrival constant, and e) rate-limit the response to less recent LSAs received via flooding. See Sections G.4 and G.5 of [Ref1] and Section G.1 of [Ref8] for details.
o OSPFフラッディングアルゴリズムは、a）低速リンクのあるネットワークでのデータベースの収束を改善するために変更されました。b）クロックの粒度が異なるために不要なLSA再送信が発生する可能性がある問題を解決します。c）MaxAge LSAのフラッディングとデータベース交換プロセス、d）MinLSArrival定数の使用を明確化し、e）フラッディングを介して受信した最近のLSAへの応答をレート制限します。詳細については、[Ref1]のセクションG.4およびG.5および[Ref8]のセクションG.1を参照してください。
o To resolve the long-standing confusion regarding representation of point-to-point links in OSPF, the specification now optionally allows advertisement of a stub link to a point-to-point link's subnet, ala RIP. See Section G.6 of [Ref1].
o OSPFでのポイントツーポイントリンクの表現に関する長年の混乱を解決するために、仕様では、オプションでポイントツーポイントリンクのサブネットであるRIPへのスタブリンクのアドバタイズメントを許可しています。 [Ref1]のセクションG.6を参照してください。
o Several problems involving advertising the same external route from multiple areas were found and fixed, as described in Section G.7 of [Ref1] and Section G.2 of [Ref8]. Without the fixes, persistent routing loops could form in certain such configurations. Note that one of the fixes was not backward-compatible, in that mixing routers implementing the fixes with those implementing just RFC 1583 could cause loops not present in an RFC 1583-only configuration. This caused an RFC1583Compatibility global configuration parameter to be added, as described in Section C.1 of [Ref1].
o [Ref1]のセクションG.7および[Ref8]のセクションG.2で説明されているように、複数のエリアから同じ外部ルートをアドバタイズすることに関連するいくつかの問題が見つかり、修正されました。修正がないと、このような特定の構成で永続的なルーティングループが形成される可能性があります。修正の1つは下位互換性がないことに注意してください。修正を実装するルーターとRFC 1583のみを実装するルーターを混在させると、RFC 1583のみの構成にないループが発生する可能性があります。これにより、[Ref1]のセクションC.1で説明されているように、RFC1583Compatibilityグローバル構成パラメーターが追加されました。
o In order to deal with high delay links, retransmissions of initial Database Description packets no longer reset an OSPF adjacency.
o 高遅延リンクを処理するために、最初のデータベース記述パケットの再送信でOSPF隣接がリセットされなくなりました。
o In order to detect link MTU mismatches, which can cause problems both in IP forwarding and in the OSPF routing protocol itself, MTU was added to OSPF's Database Description packets. Neighboring routers refuse to bring up an OSPF adjacency unless they agree on their common link's MTU.
o IP転送とOSPFルーティングプロトコル自体の両方で問題を引き起こす可能性があるリンクMTUの不一致を検出するために、OSPFのデータベース記述パケットにMTUが追加されました。隣接するルーターは、共通のリンクのMTUに同意しない限り、OSPF隣接関係の確立を拒否します。
o The TOS routing option was deleted from OSPF. However, for backward compatibility the formats of OSPF's various LSAs remain unchanged, maintaining the ability to specify TOS metrics in router-LSAs, summary-LSAs, ASBR-summary-LSAs, and AS-external-LSAs.
o TOSルーティングオプションがOSPFから削除されました。ただし、下位互換性のために、OSPFのさまざまなLSAのフォーマットは変更されず、ルーターLSA、サマリーLSA、ASBRサマリーLSA、およびAS外部LSAでTOSメトリックを指定する機能が維持されます。
o OSPF's routing table lookup algorithm was changed to reflect current practice. The "best match" routing table entry is now always selected to be the one providing the most specific (longest) match. See Section G.4 of [Ref8] for details.
o OSPFのルーティングテーブルルックアップアルゴリズムは、現在の慣行を反映するように変更されました。 「最も一致する」ルーティングテーブルエントリは、最も具体的な（最も長い）一致を提供するものとして常に選択されるようになりました。詳細については、[Ref8]のセクションG.4を参照してください。
2.1. Point-to-MultiPoint interface
2.1. ポイントツーマルチポイントインターフェイス
The Point-to-MultiPoint interface was added as an alternative to OSPF's NBMA interface when running OSPF over non-broadcast subnets. Unlike the NBMA interface, Point-to-MultiPoint does not require full mesh connectivity over the non-broadcast subnet. Point-to-MultiPoint is less efficient than NBMA, but is easier to configure (in fact, it can be self-configuring) and is more robust than NBMA, tolerating all failures within the non-broadcast subnet. For more information on the Point-to-MultiPoint interface, see Section G.2 of [Ref1].
ポイントツーマルチポイントインターフェイスは、OSPFを非ブロードキャストサブネット上で実行するときに、OSPFのNBMAインターフェイスの代わりとして追加されました。 NBMAインターフェイスとは異なり、ポイントツーマルチポイントでは、非ブロードキャストサブネットを介したフルメッシュ接続は必要ありません。ポイントツーマルチポイントはNBMAよりも効率的ではありませんが、構成が簡単で（実際には自己構成でもかまいません）、NBMAよりも堅牢で、非ブロードキャストサブネット内のすべての障害を許容します。ポイントツーマルチポイントインターフェイスの詳細については、[Ref1]のセクションG.2を参照してください。
There are at least six independent implementations of the Point-to-MultiPoint interface. Interoperability has been demonstrated between at least two pairs of implementations: between 3com and Bay Networks, and between cisco and Cascade.
ポイントツーマルチポイントインターフェイスには、少なくとも6つの独立した実装があります。相互運用性は、少なくとも2組の実装間（3comとベイネットワーク間、およびciscoとカスケード間）で実証されています。
2.2. Cryptographic Authentication
2.2. 暗号認証
Non-trivial authentication was added to OSPF with the development of the Cryptographic Authentication type. This authentication type uses any keyed message digest algorithm, with explicit instructions included for the use of MD5. For more information on OSPF authentication, see Section 4.
暗号認証タイプの開発に伴い、OSPFに重要な認証が追加されました。この認証タイプでは、MD5を使用するための明示的な指示が含まれ、キー付きのメッセージダイジェストアルゴリズムが使用されます。 OSPF認証の詳細については、セクション4を参照してください。
There are at least three independent implementations of the OSPF Cryptographic authentication type. Interoperability has been demonstrated between the implementations from cisco and Cascade.
OSPF暗号化認証タイプには、少なくとも3つの独立した実装があります。シスコとカスケードの実装間の相互運用性が実証されています。
When OSPF was promoted to Draft Standard Status, a report was issued documenting current implementation and deployment experience (see [Ref6]). That report is now quite dated. In an attempt to get more current data, a questionnaire was sent to OSPF mailing list in January 1996. Twelve responses were received, from 11 router vendors and 1 manufacturer of test equipment. These responses represented 6 independent implementations. A tabulation of the results are presented below.
OSPFがドラフト標準ステータスに昇格したとき、現在の実装と展開の経験を文書化したレポートが発行されました（[参照6]を参照）。その報告は現在かなり古いものです。最新のデータを入手するために、1996年1月にアンケートがOSPFメーリングリストに送信されました。11台のルーターベンダーと1台のテスト機器メーカーから12件の回答が寄せられました。これらの応答は、6つの独立した実装を表しています。結果の表を以下に示します。
Table 1 indicates the implementation, interoperability and deployment of the major OSPF functions. The number in each column represents the number of responses in the affirmative.
表1は、主要なOSPF機能の実装、相互運用性、および展開を示しています。各列の数字は、肯定的回答の数を表します。
Imple- Inter-
Feature mented operated Deployed
_______________________________________________________
OSPF areas 10 10 10
Stub areas 10 10 9
Virtual links 10 9 8
Equal-cost multipath 10 7 8
NBMA support 9 8 7
CIDR addressing 8 5 6
OSPF MIB 8 5 5
Cryptographic auth. 3 2 1
Point-to-Multipoint ifc. 6 3 4
Table 1: Implementation of OSPF features
表1：OSPF機能の実装
Table 2 indicates the size of the OSPF routing domains that vendors have tested. For each size parameter, the number of responders and the range of responses (minimum, mode, mean and maximum) are listed.
表2は、ベンダーがテストしたOSPFルーティングドメインのサイズを示しています。各サイズパラメータについて、応答者の数と応答の範囲（最小、モード、平均、最大）がリストされます。
Parameter Responses Min Mode Mean Max
_________________________________________________________________
Max routers in domain 7 30 240 460 1600
Max routers in single area 7 20 240 380 1600
Max areas in domain 7 1 10 16 60
Max AS-external-LSAs 9 50 10K 10K 30K
Table 2: OSPF domain sizes tested
表2：テストされたOSPFドメインサイズ
Table 3 indicates the size of the OSPF routing domains that vendors have deployed in real networks. For each size parameter, the number of responders and the range of responses (minimum, mode, mean and maximum) are listed.
表3は、ベンダーが実際のネットワークに展開したOSPFルーティングドメインのサイズを示しています。各サイズパラメータについて、応答者の数と応答の範囲（最小、モード、平均、最大）がリストされます。
Parameter Responses Min Mode Mean Max
_________________________________________________________________
Max routers in domain 8 20 350 510 1000
Max routers in single area 8 20 100 160 350
Max areas in domain 7 1 15 23 60
Max AS-external-LSAs 6 50 1K 2K 5K
Table 3: OSPF domain sizes deployed
表3：展開されたOSPFドメインサイズ
In an attempt to ascertain the extent to which OSPF is currently deployed, vendors were also asked in January 1998 to provide deployment estimates. Four vendors of OSPF routers responded, with a total estimate of 182,000 OSPF routers in service, organized into 4300 separate OSPF routing domains.
OSPFが現在展開されている範囲を確認するために、ベンダーは1998年1月にも展開の見積もりを提供するように求められました。 OSPFルーターの4つのベンダーが応答し、合計で182,000のOSPFルーターが稼働中で、4300の個別のOSPFルーティングドメインに編成されました。
All OSPF protocol exchanges are authenticated. OSPF supports multiple types of authentication; the type of authentication in use can be configured on a per network segment basis. One of OSPF's authentication types, namely the Cryptographic authentication option, is believed to be secure against passive attacks and provide significant protection against active attacks. When using the Cryptographic authentication option, each router appends a "message digest" to its transmitted OSPF packets. Receivers then use the shared secret key and received digest to verify that each received OSPF packet is authentic.
すべてのOSPFプロトコル交換が認証されます。 OSPFは複数のタイプの認証をサポートしています。使用する認証のタイプは、ネットワークセグメントごとに設定できます。 OSPFの認証タイプの1つ、つまり暗号化認証オプションは、パッシブ攻撃に対して安全であり、アクティブ攻撃に対して重要な保護を提供すると考えられています。暗号化認証オプションを使用する場合、各ルーターは送信されたOSPFパケットに「メッセージダイジェスト」を追加します。次に、受信者は共有秘密鍵と受信したダイジェストを使用して、受信した各OSPFパケットが本物であることを確認します。
The quality of the security provided by the Cryptographic authentication option depends completely on the strength of the message digest algorithm (MD5 is currently the only message digest algorithm specified), the strength of the key being used, and the correct implementation of the security mechanism in all communicating OSPF implementations. It also requires that all parties maintain the secrecy of the shared secret key.
暗号化認証オプションによって提供されるセキュリティの品質は、メッセージダイジェストアルゴリズムの強度（MD5は現在指定されている唯一のメッセージダイジェストアルゴリズムです）、使用されるキーの強度、およびセキュリティメカニズムの正しい実装に完全に依存します。すべての通信OSPF実装。また、すべての関係者が共有秘密鍵の秘密を保持することも必要です。
None of the OSPF authentication types provide confidentiality. Nor do they protect against traffic analysis. Key management is also not addressed by the OSPF specification.
OSPF認証タイプはどれも機密性を提供しません。また、トラフィック分析に対する保護も行いません。鍵管理についても、OSPF仕様では扱われていません。
For more information, see Sections 8.1, 8.2, and Appendix D of [Ref1].
詳細については、[Ref1]のセクション8.1、8.2、および付録Dを参照してください。
References
参考文献
[Ref1] Moy, J., "OSPF Version 2", RFC 2178, July 1997.
[参照1] Moy、J。、「OSPFバージョン2」、RFC 2178、1997年7月。
[Ref2] Hinden, B., "Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991.
[参照2] Hinden、B。、「インターネットルーティングプロトコル標準化基準」、RFC 1264、1991年10月。
[Ref3] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[参照3] Moy、J。、「OSPFバージョン2」、RFC 1583、1994年3月。
[Ref4] Baker, F., and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1850, November 1995.
[参照4]ベイカー、F。、およびR.コルトゥーン、「OSPFバージョン2管理情報ベース」、RFC 1850、1995年11月。
[Ref5] Moy, J., "OSPF Protocol Analysis", RFC 1245, August 1991.
[参照5] Moy、J。、「OSPFプロトコル分析」、RFC 1245、1991年8月。
[Ref6] Moy, J., "Experience with the OSPF Protocol", RFC 1246, August 1991.
[参照6] Moy、J。、「Experience with the OSPF Protocol」、RFC 1246、1991年8月。
[Ref7] Varadhan, K., Hares S., and Y. Rekhter, "BGP4/IDRP for IP-- -OSPF Interaction", RFC 1745, December 1994.
[参照7] Varadhan、K.、Hares S.、およびY. Rekhter、「BGP4 / IDRP for IP-- -OSPF Interaction」、RFC 1745、1994年12月。
[Ref8] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[参照8] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
Security Considerations
セキュリティに関する考慮事項
Security considerations are addressed in Section 4 of this memo.
セキュリティに関する考慮事項は、このメモのセクション4で扱われています。
Author's Address
著者のアドレス
John Moy Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886
John Moy Ascend Communications、Inc. 1 Robbins Road Westford、MA 01886
Phone: 978-952-1367 Fax: 978-392-2075 EMail: jmoy@casc.com Full Copyright Statement
電話：978-952-1367ファックス：978-392-2075メール：jmoy@casc.com完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。