[要約] RFC 5250は、OSPFのOpaque LSAオプションに関する仕様を定義しています。この仕様の目的は、OSPFのリンクステートデータベースに追加の情報を提供するための拡張機能を提供することです。
Network Working Group L. Berger
Request for Comments: 5250 LabN
Obsoletes: 2370 I. Bryskin
Category: Standards Track Adva
A. Zinin
Alcatel-Lucent
R. Coltun
Acoustra Productions
July 2008
The OSPF Opaque LSA Option
OSPF Opaque LSAオプション
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
概要
This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology.
このドキュメントでは、不透明LSAと呼ばれる新しいクラスのリンク状態アドバタイズメント（LSA）をサポートするためのOSPFプロトコルの拡張機能を定義します。 Opaque LSAは、OSPFの将来の拡張性を可能にする一般化されたメカニズムを提供します。不透明なLSAは、標準のLSAヘッダーとそれに続くアプリケーション固有の情報で構成されます。情報フィールドは、OSPFまたは他のアプリケーションで直接使用できます。標準のOSPFリンク状態データベースフラッディングメカニズムは、OSPFトポロジのすべてまたは一部の部分にOpaque LSAを配布するために使用されます。
This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs originated outside of the router's OSPF area.
このドキュメントは、RFC 2370に代わるものであり、OSPFルーターが自律システム（AS）スコープのルーターのOSPFエリア外から発信された不透明LSAを検証できるようにするメカニズムを追加します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Organization of This Document ..............................3
1.2. Acknowledgments ............................................3
2. Conventions Used in This Document ...............................4
3. The Opaque LSA ..................................................4
3.1. Flooding Opaque LSAs .......................................5
3.2. Modifications to the Neighbor State Machine ................6
4. Protocol Data Structures ........................................7
4.1. Additions to the OSPF Neighbor Structure ...................8
5. Inter-Area Considerations .......................................8
6. Management Considerations .......................................9
7. Backward Compatibility ..........................................9
8. Security Considerations .........................................9
9. IANA Considerations ............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
Appendix A. OSPF Data formats .....................................13
A.1. The Options Field .........................................13
A.2. The Opaque LSA ............................................14
Over the last several years, the OSPF routing protocol [OSPF] has been widely deployed throughout the Internet. As a result of this deployment and the evolution of networking technology, OSPF has been extended to support many options; this evolution will obviously continue.
過去数年にわたって、OSPFルーティングプロトコル[OSPF]はインターネット全体に広く導入されてきました。この導入とネットワークテクノロジーの進化の結果として、OSPFは多くのオプションをサポートするように拡張されました。この進化は明らかに続くでしょう。
This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. The information contained in Opaque LSAs may be used directly by OSPF or indirectly by some application wishing to distribute information throughout the OSPF domain. The exact use of Opaque LSAs is beyond the scope of this document.
このドキュメントでは、不透明LSAと呼ばれる新しいクラスのリンク状態アドバタイズメント（LSA）をサポートするためのOSPFプロトコルの拡張機能を定義します。 Opaque LSAは、OSPFの将来の拡張性を可能にする一般化されたメカニズムを提供します。 Opaque LSAに含まれる情報は、OSPFが直接使用することも、OSPFドメイン全体に情報を配布したいアプリケーションが間接的に使用することもできます。 Opaque LSAの正確な使用は、このドキュメントの範囲を超えています。
Opaque LSAs consist of a standard LSA header followed by a 32-bit aligned application-specific information field. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. The link-state type field of the Opaque LSA identifies the LSA's range of topological distribution. This range is referred to as the flooding scope.
不透明なLSAは、標準のLSAヘッダーと、それに続く32ビットのアプリケーション固有の情報フィールドで構成されます。他のLSAと同様に、Opaque LSAはリンクステートデータベース分散メカニズムを使用して、この情報をトポロジ全体にフラッディングします。 Opaque LSAのリンクステートタイプフィールドは、LSAのトポロジ分布の範囲を識別します。この範囲は、フラッディングスコープと呼ばれます。
It is envisioned that an implementation of the Opaque option provides an application interface for 1) encapsulating application-specific information in a specific Opaque type, 2) sending and receiving application-specific information, and 3) if required, informing the application of the change in validity of previously received information when topological changes are detected.
Opaqueオプションの実装は、1）特定のOpaqueタイプにアプリケーション固有の情報をカプセル化し、2）アプリケーション固有の情報を送受信し、3）必要に応じて、アプリケーションに変更を通知するためのアプリケーションインターフェイスを提供することが想定されています。トポロジーの変化が検出されたとき、以前に受信した情報の有効性。
This document first defines the three types of Opaque LSAs followed by a description of OSPF packet processing. The packet processing sections include modifications to the flooding procedure and to the neighbor state machine. Appendix A then gives the packet formats.
このドキュメントでは、最初に3種類の不透明LSAを定義してから、OSPFパケット処理について説明します。パケット処理セクションには、フラッディング手順とネイバーステートマシンへの変更が含まれています。次に、付録Aにパケット形式を示します。
We would like to thank Acee Lindem for his detailed review and useful feedback. The handling of AS-scope Opaque LSAs described in this document is taken from "Validation of OSPF AS-scope opaque LSAs" (April 2006).
Acee Lindem氏の詳細なレビューと有益なフィードバックに感謝します。このドキュメントで説明されているASスコープの不透明LSAの処理は、「OSPF ASスコープの不透明LSAの検証」（2006年4月）から引用したものです。
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]で説明されているように解釈されます。
Opaque LSAs are types 9, 10, and 11 link state advertisements. Opaque LSAs consist of a standard LSA header followed by a 32-bit aligned application-specific information field. Standard link-state database flooding mechanisms are used for distribution of Opaque LSAs. The range of topological distribution (i.e., the flooding scope) of an Opaque LSA is identified by its link-state type. This section documents the flooding of Opaque LSAs.
不透明LSAは、タイプ9、10、および11のリンク状態アドバタイズメントです。不透明なLSAは、標準のLSAヘッダーと、それに続く32ビットのアプリケーション固有の情報フィールドで構成されます。 Opaque LSAの配布には、標準のリンクステートデータベースフラッディングメカニズムが使用されます。 Opaque LSAのトポロジー分布の範囲（つまり、フラッディングスコープ）は、そのリンクステートタイプによって識別されます。このセクションでは、不透明LSAのフラッディングについて説明します。
The flooding scope associated with each Opaque link-state type is defined as follows.
各不透明リンク状態タイプに関連付けられたフラッディングスコープは、次のように定義されます。
o Link-state type-9 denotes a link-local scope. Type-9 Opaque LSAs are not flooded beyond the local (sub)network.
o リンクステートタイプ9は、リンクローカルスコープを示します。 Type-9 Opaque LSAは、ローカル（サブ）ネットワークを超えてフラッディングされません。
o Link-state type-10 denotes an area-local scope. Type-10 Opaque LSAs are not flooded beyond the borders of their associated area.
o リンクステートタイプ10は、エリアローカルスコープを示します。 Type-10 Opaque LSAは、関連するエリアの境界を越えてフラッディングされません。
o Link-state type-11 denotes that the LSA is flooded throughout the Autonomous System (AS). The flooding scope of type-11 LSAs are equivalent to the flooding scope of AS-External (type-5) LSAs. Specifically, type-11 Opaque LSAs are 1) flooded throughout all transit areas, 2) not flooded into stub areas or Not-So-Stubby Areas (NSSAs), see [NSSA], from the backbone, and 3) not originated by routers into their connected stub areas or NSSAs. As with type-5 LSAs, if a type-11 Opaque LSA is received in a stub area or NSSA from a neighboring router within the stub area or NSSA, the LSA is rejected.
o リンクステートタイプ11は、LSAが自律システム（AS）全体にフラッディングすることを示します。タイプ11 LSAのフラッディングスコープは、AS-External（タイプ5）LSAのフラッディングスコープと同等です。具体的には、タイプ11の不透明LSAは、1）すべてのトランジットエリア全体にフラッディングされる、2）スタブエリアまたはNot-So-Stubbyエリア（NSSA）にフラッディングされない、[NSSA]を参照、バックボーンから、および3）ルーターから発信されない接続されたスタブエリアまたはNSSAに。タイプ5 LSAと同様に、タイプ11の不透明LSAがスタブエリアまたはNSSA内で、スタブエリアまたはNSSA内の隣接ルーターから受信された場合、LSAは拒否されます。
The link-state ID of the Opaque LSA is divided into an Opaque type field (the first 8 bits) and a type-specific ID (the remaining 24 bits). The packet format of the Opaque LSA is given in Appendix A. Section 7 describes Opaque type allocation and assignment.
Opaque LSAのリンクステートIDは、Opaqueタイプフィールド（最初の8ビット）とタイプ固有のID（残りの24ビット）に分かれています。 Opaque LSAのパケット形式は、付録Aに記載されています。セクション7では、Opaqueタイプの割り当てと割り当てについて説明します。
The responsibility for proper handling of the Opaque LSA's flooding scope is placed on both the sender and receiver of the LSA. The receiver must always store a valid received Opaque LSA in its link-state database. The receiver must not accept Opaque LSAs that violate the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA is not accepted in a stub area or NSSA). The flooding scope affects both the synchronization of the link-state database and the flooding procedure.
Opaque LSAのフラッディングスコープを適切に処理する責任は、LSAの送信側と受信側の両方にあります。受信者は常に、受信した有効な不透明LSAをリンク状態データベースに保存する必要があります。受信側は、フラッディングスコープに違反する不透明LSAを受け入れてはなりません（たとえば、タイプ11（ドメイン全体）の不透明LSAは、スタブエリアまたはNSSAでは受け入れられません）。フラッディングスコープは、リンクステートデータベースの同期とフラッディング手順の両方に影響します。
The following describes the modifications to these procedures that are necessary to insure conformance to the Opaque LSA's Scoping Rules.
以下では、Opaque LSAのスコープルールへの準拠を保証するために必要なこれらの手順の変更について説明します。
The flooding of Opaque LSAs MUST follow the rules of flooding scope as specified in this section. Section 13 of [OSPF] describes the OSPF flooding procedure. Those procedures MUST be followed as defined except where modified in this section. The following describes the Opaque LSA's type-specific flooding restrictions.
Opaque LSAのフラッディングは、このセクションで指定されているフラッディングスコープのルールに従う必要があります。 [OSPF]のセクション13では、OSPFフラッディング手順について説明しています。これらの手順は、このセクションで変更されている場合を除き、定義されているとおりに実行する必要があります。以下は、Opaque LSAのタイプ固有のフラッディング制限について説明しています。
o If the Opaque LSA is type-9 (the flooding scope is link-local) and the interface that the LSA was received on is not the same as the target interface (e.g., the interface associated with a particular target neighbor), the Opaque LSA MUST be discarded and not acknowledged. An implementation SHOULD keep track of the IP interface associated with each Opaque LSA having a link-local flooding scope.
o Opaque LSAがタイプ9（フラッディングスコープがリンクローカル）であり、LSAが受信されたインターフェイスがターゲットインターフェイス（たとえば、特定のターゲットネイバーに関連付けられているインターフェイス）と同じでない場合、Opaque LSA破棄する必要があり、承認されません。実装は、リンクローカルフラッディングスコープを持つ各Opaque LSAに関連付けられたIPインターフェースを追跡する必要があります（SHOULD）。
o If the Opaque LSA is type-10 (the flooding scope is area-local) and the area associated with the Opaque LSA (as identified during origination or from a received LSA's associated OSPF packet header) is not the same as the area associated with the target interface, the Opaque LSA MUST be discarded and not acknowledged. An implementation SHOULD keep track of the OSPF area associated with each Opaque LSA having an area-local flooding scope.
o Opaque LSAがタイプ10（フラッディングスコープはエリアローカル）であり、Opaque LSAに関連付けられたエリア（発信時に識別された、または受信したLSAの関連付けられたOSPFパケットヘッダーから識別されたもの）が、ターゲットインターフェイス、Opaque LSAは破棄され、確認されない必要があります。実装は、エリアローカルフラッディングスコープを持つ各Opaque LSAに関連付けられたOSPFエリアを追跡する必要があります（SHOULD）。
o If the Opaque LSA is type-11 (the LSA is flooded throughout the AS) and the target interface is associated with a stub area or NSSA, the Opaque LSA MUST NOT be flooded out the interface. A type-11 Opaque LSA that is received on an interface associated with a stub area or NSSA MUST be discarded and not acknowledged (the neighboring router has flooded the LSA in error).
o Opaque LSAがタイプ11（LSAがAS全体にフラッディングされる）であり、ターゲットインターフェイスがスタブエリアまたはNSSAに関連付けられている場合、Opaque LSAがインターフェイスからフラッディングされてはなりません。スタブエリアまたはNSSAに関連付けられたインターフェイスで受信されたタイプ11の不透明LSAは破棄され、確認されない必要があります（隣接ルーターが誤ってLSAをフラッディングした）。
When opaque-capable routers and non-opaque-capable OSPF routers are mixed together in a routing domain, the Opaque LSAs are typically not flooded to the non-opaque-capable routers. As a general design principle, optional OSPF advertisements are only flooded to those routers that understand them.
不透明な対応ルーターと不透明でない対応OSPFルーターがルーティングドメインで混在している場合、通常、不透明なLSAは不透明でない対応ルーターにフラッディングされません。一般的な設計原則として、オプションのOSPFアドバタイズは、それらを理解するルーターにのみフラッディングされます。
An opaque-capable router learns of its neighbor's opaque capability at the beginning of the "Database Exchange Process" (see Section 10.6 of [OSPF] regarding receiving Database Description packets from a
不透明対応ルータは、「データベース交換プロセス」の開始時にネイバーの不透明機能を学習します（[OSPF]のセクション10.6を参照）。
neighbor in state ExStart). A neighbor is opaque-capable if and only if it sets the O-bit in the Options field of its Database Description packets; the O-bit SHOULD NOT be set and MUST be ignored when received in packets other than Database Description packets. Using the O-bit in OSPF packets other than Database Description packets will result in interoperability issues. The setting of the O-bit is a "SHOULD NOT" rather than a "MUST NOT" to remain compatible with earlier specifications.
状態ExStartのネイバー）。ネイバーは、データベース記述パケットのオプションフィールドにOビットを設定する場合にのみ不透明になります。 Oビットは設定しないでください。データベース記述パケット以外のパケットで受信した場合は無視してください。データベース記述パケット以外のOSPFパケットでOビットを使用すると、相互運用性の問題が発生します。 O-bitの設定は、以前の仕様との互換性を保つために、「MUST NOT」ではなく「SHOULD NOT」です。
In the next step of the Database Exchange process, Opaque LSAs are included in the Database summary list that is sent to the neighbor (see Sections 3.2 below and 10.3 of [OSPF]) when the neighbor is opaque capable.
データベース交換プロセスの次のステップでは、ネイバーが不透明に対応している場合、ネイバーに送信されるデータベースサマリリストに不透明LSAが含まれます（以下のセクション3.2および[OSPF]の10.3を参照）。
When flooding Opaque LSAs to adjacent neighbors, an opaque-capable router looks at the neighbor's opaque capability. Opaque LSAs are only flooded to opaque-capable neighbors. To be more precise, in Section 13.3 of [OSPF], Opaque LSAs MUST be placed on the link-state retransmission lists of opaque-capable neighbors and MUST NOT be placed on the link-state retransmission lists of non-opaque-capable neighbors. However, when sending Link State Update packets as multicasts, a non-opaque-capable neighbor may (inadvertently) receive Opaque LSAs. The non-opaque-capable router will then simply discard the LSA (see Section 13 of [OSPF] regarding receiving LSAs having unknown LS types).
Opaque LSAを隣接ネイバーにフラッディングするとき、不透明対応ルーターはネイバーの不透明機能を調べます。不透明LSAは、不透明対応のネイバーにのみフラッディングされます。より正確には、[OSPF]のセクション13.3で、不透明LSAは不透明対応ネイバーのリンク状態再送信リストに配置する必要があり、非不透明対応ネイバーのリンク状態再送信リストに配置してはなりません（MUST NOT）。ただし、リンク状態更新パケットをマルチキャストとして送信する場合、不透明でない対応ネイバーが（不注意で）不透明LSAを受信することがあります。不透明でないルーターは、LSAを単に破棄します（LSタイプが不明なLSAの受信に関しては、[OSPF]のセクション13を参照してください）。
Information contained in received Opaque LSAs SHOULD only be used when the router originating the LSA is reachable. As mentioned in [OSPFv3], reachability validation MAY be done less frequently than every SPF calculation. Additionally, routers processing received Opaque LSAs MAY choose to give priority to processing base OSPF LSA types over Opaque LSA types.
受信した不透明LSAに含まれる情報は、LSAを発信するルーターに到達できる場合にのみ使用してください。 [OSPFv3]で述べたように、到達可能性の検証は、すべてのSPF計算よりも頻繁に行われるとは限りません（MAY）。さらに、受信したOpaque LSAを処理するルーターは、Opaque LSAタイプよりも基本OSPF LSAタイプの処理を優先することを選択できます。
The state machine as it exists in Section 10.3 of [OSPF] remains unchanged except for the action associated with State: ExStart, Event: NegotiationDone, which is where the Database summary list is built. To incorporate the Opaque LSA in OSPF, this action is changed to the following.
[OSPF]のセクション10.3にある状態マシンは、状態に関連付けられているアクション（ExStart、イベント：NegotiationDone）を除いて変更されていません。これは、データベースサマリリストが作成される場所です。 Opaque LSAをOSPFに組み込むには、このアクションを次のように変更します。
State(s): ExStart
状態（s）：ExStart
Event: NegotiationDone
イベント：NegotiationDone
New state: Exchange
新しい状態：交換
Action: The router MUST list the contents of its entire area link-state database in the neighbor Database summary list. The area link-state database consists of the Router LSAs, Network LSAs, Summary LSAs, type-9 Opaque LSAs, and type-10 Opaque LSAs contained in the area structure, along with AS External and type-11 Opaque LSAs contained in the global structure. AS External and type-11 Opaque LSAs MUST be omitted from a virtual neighbor's Database summary list. AS External LSAs and type-11 Opaque LSAs MUST be omitted from the Database summary list if the area has been configured as a stub area or NSSA (see Section 3.6 of [OSPF]).
アクション：ルーターは、隣接するデータベースの要約リストにエリア全体のリンク状態データベースの内容をリストしなければなりません（MUST）。エリアリンクステートデータベースは、エリア構造に含まれるルーターLSA、ネットワークLSA、サマリーLSA、タイプ9不透明LSA、およびタイプ10不透明LSAと、グローバルに含まれるAS外部およびタイプ11不透明LSAで構成されます。構造。 AS外部およびタイプ11の不透明LSAは、仮想ネイバーのデータベースサマリーリストから除外する必要があります。エリアがスタブエリアまたはNSSAとして構成されている場合（[OSPF]のセクション3.6を参照）、AS外部LSAおよびタイプ11不透明LSAをデータベースサマリーリストから省略する必要があります。
Type-9 Opaque LSAs MUST be omitted from the Database summary list if the interface associated with the neighbor is not the interface associated with the Opaque LSA (as noted upon reception).
タイプ9の不透明LSAは、ネイバーに関連付けられているインターフェースが不透明なLSAに関連付けられているインターフェースではない場合（受信時に注記）、データベースサマリーリストから除外する必要があります。
Any advertisement whose age is equal to MaxAge MUST be omitted from the Database summary list. It MUST instead be added to the neighbor's link-state retransmission list. A summary of the Database summary list will be sent to the neighbor in Database Description packets. Only one Database Description Packet is allowed to be outstanding at any one time. For more detail on the sending and receiving of Database Description packets, see Sections 10.6 and 10.8 of [OSPF].
エージがMaxAgeと等しい広告は、データベースサマリーリストから除外する必要があります。代わりに、ネイバーのリンクステート再送信リストに追加する必要があります。データベースサマリーリストのサマリーは、データベース記述パケットでネイバーに送信されます。一度に未処理にできるのは、1つのデータベース記述パケットだけです。データベース記述パケットの送受信の詳細については、[OSPF]のセクション10.6および10.8を参照してください。
The Opaque option is described herein in terms of its operation on various protocol data structures. These data structures are included for explanatory uses only. They are not intended to constrain an implementation. In addition to the data structures listed below, this specification references the various data structures (e.g., OSPF neighbors) defined in [OSPF].
不透明オプションは、さまざまなプロトコルデータ構造での操作に関してここで説明されています。これらのデータ構造は、説明のためにのみ含まれています。それらは実装を制約することを意図していません。以下にリストされているデータ構造に加えて、この仕様は[OSPF]で定義されているさまざまなデータ構造（OSPFネイバーなど）を参照します。
In an OSPF router, the following item is added to the list of global OSPF data structures described in Section 5 of [OSPF]:
OSPFルーターでは、[OSPF]のセクション5で説明されているグローバルOSPFデータ構造のリストに次の項目が追加されます。
o Opaque capability. Indicates whether the router is running the Opaque option (i.e., capable of storing Opaque LSAs). Such a router will continue to interoperate with non-opaque-capable OSPF routers.
o 不透明な機能。ルーターが不透明オプションを実行しているかどうか（つまり、不透明LSAを格納できるかどうか）を示します。このようなルーターは、不透明ではないOSPFルーターと相互運用し続けます。
The OSPF neighbor structure is defined in Section 10 of [OSPF]. In an opaque-capable router, the following items are added to the OSPF neighbor structure:
OSPFネイバー構造は、[OSPF]のセクション10で定義されています。不透明対応ルーターでは、次の項目がOSPFネイバー構造に追加されます。
o Neighbor Options. This field was already defined in the OSPF specification. However, in opaque-capable routers, there is a new option that indicates the neighbor's Opaque capability. This new option is learned in the Database Exchange process through reception of the neighbor's Database Description packets and determines whether Opaque LSAs are flooded to the neighbor. For a more detailed explanation of the flooding of the Opaque LSA, see Section 3 of this document.
o ネイバーオプション。このフィールドは、OSPF仕様ですでに定義されています。ただし、不透明対応のルーターには、ネイバーの不透明機能を示す新しいオプションがあります。この新しいオプションは、ネイバーのデータベース記述パケットの受信を通じてデータベース交換プロセスで学習され、不透明なLSAがネイバーにフラッディングされるかどうかを決定します。 Opaque LSAのフラッディングの詳細については、このドキュメントのセクション3を参照してください。
As defined above, link-state type-11 Opaque LSAs are flooded throughout the Autonomous System (AS). One issue related to such AS-scoped Opaque LSAs is that there must be a way for OSPF routers in remote areas to check availability of the LSA originator. Specifically, if an OSPF router originates a type-11 LSA and, after that, goes out of service, OSPF routers located outside of the originator's OSPF area have no way of detecting this fact and may use the stale information for a considerable period of time (up to 60 minutes). This could prove to be suboptimal for some applications and may result in others not functioning.
上記で定義したように、リンクステートタイプ11の不透明LSAは自律システム（AS）全体にフラッディングされます。このようなASスコープの不透明LSAに関連する1つの問題は、リモートエリアのOSPFルーターがLSA発信元の可用性を確認する方法が必要であることです。具体的には、OSPFルーターがタイプ11 LSAを発信し、その後サービスを停止した場合、発信元のOSPFエリア外にあるOSPFルーターはこの事実を検出できず、古い情報をかなりの期間使用する可能性があります。 （最大60分）。これは、一部のアプリケーションにとって最適ではないことが判明し、他のアプリケーションが機能しなくなる可能性があります。
Type-9 Opaque LSAs and type-10 Opaque LSAs do not have this problem as a receiving router can detect if the advertising router is reachable within the LSA's respective flooding scope. In the case of type-9 LSAs, the originating router must be an OSPF neighbor in Exchange state or greater. In the case of type-10 Opaque LSAs, the intra-area SPF calculation will determine the advertising router's reachability.
タイプ9の不透明LSAおよびタイプ10の不透明LSAは、アドバタイズルーターがLSAのそれぞれのフラッディングスコープ内で到達可能かどうかを検出できるため、この問題はありません。タイプ9 LSAの場合、発信元ルーターは、Exchange状態以上のOSPFネイバーでなければなりません。タイプ10の不透明LSAの場合、エリア内SPF計算により、アドバタイズルータの到達可能性が決定されます。
There is a parallel issue in OSPF for the AS-scoped AS External LSAs (type-5 LSAs). OSPF addresses this by using AS border information advertised in AS boundary router (ASBR) Summary LSAs (type-4 LSAs); see Section 16.4 of [OSPF]. This same mechanism is reused by this document for type-11 Opaque LSAs.
OSPFには、ASスコープのAS外部LSA（タイプ5 LSA）の並列の問題があります。 OSPFは、AS境界ルーター（ASBR）サマリーLSA（タイプ4 LSA）でアドバタイズされるAS境界情報を使用してこれに対処します。 [OSPF]のセクション16.4を参照してください。この同じメカニズムは、タイプ11の不透明LSAに対してこのドキュメントで再利用されています。
To enable OSPF routers in remote areas to check availability of the originator of link-state type-11 Opaque LSAs, the originators advertise themselves as ASBRs. This will enable routers to track the reachability of the LSA originator either directly via the SPF calculation (for routers in the same area) or indirectly via type-4 LSAs originated by ABRs (for routers in other areas). It is important to note that per [OSPF], this solution does not apply to OSPF stub areas or NSSAs as AS-scoped Opaque LSAs are not flooded into these area types.
リモートエリアのOSPFルーターがリンクステートタイプ11不透明LSAの発信元の可用性を確認できるようにするには、発信元がASBRとしてアドバタイズします。これにより、ルーターは、SPF計算を介して直接（同じエリア内のルーターの場合）、またはABRから発信されたタイプ4 LSAを介して間接的に（他のエリアのルーターの場合）、LSA発信元の到達可能性を追跡できます。 [OSPF]によると、ASスコープのOpaque LSAはこれらのエリアタイプにフラッディングされないため、このソリューションはOSPFスタブエリアまたはNSSAには適用されないことに注意することが重要です。
The procedures related to inter-area Opaque LSAs are as follows:
エリア間不透明LSAに関連する手順は次のとおりです。
(1) An OSPF router that is configured to originate AS-scope opaque LSAs will advertise itself as an ASBR and MUST follow the requirements related to setting of the Options field E-bit in OSPF LSA headers as specified in [OSPF].
（1）ASスコープの不透明LSAを発信するように構成されているOSPFルーターは、それ自体をASBRとしてアドバタイズし、[OSPF]で指定されているOSPF LSAヘッダーのオプションフィールドEビットの設定に関連する要件に従う必要があります。
(2) When processing a received type-11 Opaque LSA, the router MUST look up the routing table entries (potentially one per attached area) for the ASBR that originated the LSA. If no entries exist for the ASBR (i.e., the ASBR is unreachable), the router MUST do nothing with this LSA. It also MUST discontinue using all Opaque LSAs injected into the network by the same originator whenever it is detected that the originator is unreachable.
（2）受信したタイプ11の不透明LSAを処理するとき、ルーターはLSAを発信したASBRのルーティングテーブルエントリ（接続された領域ごとに1つである可能性があります）を検索する必要があります。 ASBRのエントリが存在しない場合（つまり、ASBRに到達できない場合）、ルーターはこのLSAに対して何も実行してはなりません（MUST）。また、発信者が到達不能であることが検出された場合は常に、同じ発信者によってネットワークに挿入されたすべての不透明LSAの使用を中止する必要があります。
The updated OSPF MIB, [RFC4750], provides explicit support for Opaque LSAs and SHOULD be used to support implementations of this document. See Section 12.3 of [RFC4750] for details. In addition to that section, implementations supporting [RFC4750] will also include Opaque LSAs in all appropriate generic LSA objects, e.g., ospfOriginateNewLsas and ospfLsdbTable.
更新されたOSPF MIB [RFC4750]は、不透明LSAの明示的なサポートを提供し、このドキュメントの実装をサポートするために使用する必要があります（SHOULD）。詳細については、[RFC4750]のセクション12.3を参照してください。そのセクションに加えて、[RFC4750]をサポートする実装には、ospfOriginateNewLsasやospfLsdbTableなど、適切なすべての汎用LSAオブジェクトに不透明LSAも含まれます。
The solution proposed in this document introduces no interoperability issues. In the case that a non-opaque-capable neighbor receives Opaque LSAs, per [OSPF], the non-opaque-capable router will simply discard the LSA.
このドキュメントで提案されているソリューションでは、相互運用性の問題は発生しません。不透明ではないネイバーが[OSPF]に従って不透明LSAを受信した場合、不透明ではないルーターは単にLSAを破棄します。
Note that OSPF routers that implement [RFC2370] will continue using stale type-11 LSAs even when the LSA originator implements the inter-area procedures described in Section 6 of this document.
[RFC2370]を実装するOSPFルーターは、LSA発信者がこのドキュメントのセクション6で説明されているエリア間手順を実装している場合でも、古いタイプ11 LSAを引き続き使用することに注意してください。
There are two types of issues that need be addressed when looking at protecting routing protocols from misconfigurations and malicious attacks. The first is authentication and certification of routing protocol information. The second is denial-of-service attacks resulting from repetitive origination of the same router advertisement or origination of a large number of distinct advertisements resulting in database overflow. Note that both of these concerns exist independently of a router's support for the Opaque option.
ルーティングプロトコルの設定ミスや悪意のある攻撃からの保護を検討する際に対処する必要がある2種類の問題があります。 1つ目は、ルーティングプロトコル情報の認証と証明です。 2つ目は、同じルーターアドバタイズメントの反復的な発信またはデータベースオーバーフローを引き起こす多数の個別のアドバタイズメントの発信によるサービス拒否攻撃です。これらの問題は両方とも、ルーターによるOpaqueオプションのサポートとは関係なく存在することに注意してください。
To address the authentication concerns, 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. None of the standard OSPF authentication types provide confidentiality. Nor do they protect against traffic analysis. For more information on the standard OSPF security mechanisms, see Sections 8.1, 8.2, and Appendix D of [OSPF].
暗号化認証オプションによって提供されるセキュリティの品質は、メッセージダイジェストアルゴリズムの強度（MD5は現在指定されている唯一のメッセージダイジェストアルゴリズムです）、使用されるキーの強度、およびセキュリティメカニズムの正しい実装に完全に依存します。すべての通信OSPF実装。また、すべての関係者が共有秘密鍵の秘密を保持することも必要です。標準のOSPF認証タイプはどれも機密性を提供しません。また、トラフィック分析に対する保護も行いません。標準のOSPFセキュリティメカニズムの詳細については、[OSPF]のセクション8.1、8.2、および付録Dを参照してください。
Repetitive origination of advertisements is addressed by OSPF by mandating a limit on the frequency that new instances of any particular LSA can be originated and accepted during the flooding procedure. The frequency at which new LSA instances may be originated is set equal to once every MinLSInterval seconds, whose value is 5 seconds (see Section 12.4 of [OSPF]). The frequency at which new LSA instances are accepted during flooding is once every MinLSArrival seconds, whose value is set to 1 (see Section 13, Appendix B, and G.5 of [OSPF]).
OSPFは、フラッディング手順中に特定のLSAの新しいインスタンスを開始して受け入れる頻度の制限を義務付けることにより、アドバタイズの反復的な発生に対処しています。新しいLSAインスタンスが生成される頻度は、値が5秒であるMinLSInterval秒ごとに1回に設定されます（[OSPF]のセクション12.4を参照）。フラッディング中に新しいLSAインスタンスが受け入れられる頻度は、MinLSArrival秒ごとに1回で、その値は1に設定されます（[OSPF]のセクション13、付録B、およびG.5を参照）。
Proper operation of the OSPF protocol requires that all OSPF routers maintain an identical copy of the OSPF link-state database. However, when the size of the link-state database becomes very large, some routers may be unable to keep the entire database due to resource shortages; we term this "database overflow". When database overflow is anticipated, the routers with limited resources can be accommodated by configuring OSPF stub areas and NSSAs. [OVERFLOW] details a way of gracefully handling unanticipated database overflows.
OSPFプロトコルが適切に動作するには、すべてのOSPFルーターがOSPFリンク状態データベースの同一のコピーを維持する必要があります。ただし、リンク状態データベースのサイズが非常に大きくなると、一部のルーターはリソース不足のためにデータベース全体を保持できなくなる可能性があります。これを「データベースオーバーフロー」と呼びます。データベースのオーバーフローが予想される場合は、OSPFスタブエリアとNSSAを構成することで、リソースが制限されたルーターに対応できます。 [OVERFLOW]は、予期しないデータベースオーバーフローを適切に処理する方法を詳しく説明しています。
In the case of type-11 Opaque LSAs, this document reuses an ASBR tracking mechanism that is already employed in basic OSPF for type-5 LSAs. Therefore, applying it to type-11 Opaque LSAs does not create any threats that are not already known for type-5 LSAs.
タイプ11の不透明LSAの場合、このドキュメントでは、タイプ5のLSAの基本的なOSPFですでに採用されているASBRトラッキングメカニズムを再利用しています。したがって、それをタイプ11の不透明LSAに適用しても、タイプ5のLSAではまだ知られていない脅威は発生しません。
This document updates the requirements for the OSPF Opaque LSA type registry. Three following changes have been made:
このドキュメントは、OSPF Opaque LSAタイプレジストリの要件を更新します。次の3つの変更が行われました。
1. References to [RFC2370] have been replaced with references to this document.
1. [RFC2370]への参照は、このドキュメントへの参照に置き換えられました。
2. The Opaque type values in the range of 128-255 have been reserved for "Private Use" as defined in [RFC5226].
2. [RFC5226]で定義されているように、128〜255の範囲の不透明タイプの値は「プライベート使用」のために予約されています。
3. The reference for Opaque type registry value 1, Traffic Engineering LSA, has been updated to [RFC3630].
3. Opaqueタイプのレジストリ値1、Traffic Engineering LSAの参照が[RFC3630]に更新されました。
The registry now reads:
レジストリは次のようになります。
Open Shortest Path First (OSPF) Opaque Link-State Advertisements (LSA) Option Types
Open Shortest Path First（OSPF）Opaque Link-State Advertisements（LSA）オプションタイプ
Registries included below: - Opaque Link-State Advertisements (LSA) Option Types
以下に含まれるレジストリ：-Opaque Link-State Advertisements（LSA）オプションタイプ
Registry Name: Opaque Link-State Advertisements (LSA) Option Types
Reference: [RFC5250]
Range Registration Procedures Notes
-------- ------------------------------------------ --------
0-127 IETF Consensus
128-255 Private Use
Registry:
Value Opaque Type Reference
------- ------------------------------------------ ---------
1 Traffic Engineering LSA [RFC3630]
2 Sycamore Optical Topology Descriptions [Moy]
3 grace-LSA [RFC3623]
4 Router Information (RI) [RFC4970]
5-127 Unassigned
128-255 Private Use
[DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[DEMD] Moy、J。、「Extending OSPF to Support Demand Circuits」、RFC 1793、1995年4月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, December 2006.
[RFC4750] Joyal、D.、Ed。、Galecki、P.、Ed。、Giacarone、S.、Ed。、Coltun、R。、およびF. Baker、「OSPFバージョン2管理情報ベース」、RFC 4750、12月2006年
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[MOSPF] Moy、J。、「OSPFへのマルチキャスト拡張」、RFC 1584、1994年3月。
[NSSA] Murphy P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003.
[NSSA]マーフィーP。、「OSPF Not-So-Stubby Area（NSSA）オプション」、RFC 3101、2003年1月。
[OSPF-MT] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007.
[OSPF-MT] Psenak、P.、Mirtorabi、S.、Roy、A.、Nguyen、L。、およびP. Pillay-Esnault、「OSPFでのマルチトポロジ（MT）ルーティング」、RFC 4915、2007年6月。
[OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, Ed., "OSPF for IPv6", Work in Progress, May 2008.
[OSPFv3] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、編、「OSPF for IPv6」、Work in Progress、2008年5月。
[OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.
[OVERFLOW] Moy、J。、「OSPFデータベースオーバーフロー」、RFC 1765、1995年3月。
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[RFC2370] Coltun、R。、「OSPF Opaque LSAオプション」、RFC 2370、1998年7月。
[RFC3630] Katz, D., Kompella, K., and D. Yeund, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeund、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、2003年9月。
[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月。
This appendix describes the format of the Options Field followed by the packet format of the Opaque LSA.
この付録では、オプションフィールドの形式と、それに続く不透明LSAのパケット形式について説明します。
The OSPF Options field is present in OSPF Hello packets, Database Description packets, and all link state advertisements. The Options field enables OSPF routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPF routers. Through this mechanism, routers of differing capabilities can be mixed within an OSPF routing domain.
OSPFオプションフィールドは、OSPF Helloパケット、データベース記述パケット、およびすべてのリンク状態アドバタイズにあります。 [オプション]フィールドを使用すると、OSPFルーターはオプション機能をサポートする（またはサポートしない）ことができ、その機能レベルを他のOSPFルーターと通信できます。このメカニズムにより、異なる機能のルーターをOSPFルーティングドメイン内に混在させることができます。
When used in Hello packets, the Options field allows a router to reject a neighbor because of a capability mismatch. Alternatively, when capabilities are exchanged in Database Description packets a router can choose not to flood certain link state advertisements to a neighbor because of its reduced functionality. Lastly, listing capabilities in link state advertisements allows routers to forward traffic around reduced functionality routers by excluding them from parts of the routing table calculation.
オプションフィールドをHelloパケットで使用すると、ルータは機能の不一致のためにネイバーを拒否できます。または、機能がデータベース記述パケットで交換される場合、ルーターは、機能が低下しているため、特定のリンク状態のアドバタイズメントをネイバーにフラッディングしないことを選択できます。最後に、リンクステートアドバタイズメントに機能をリストすると、ルーターは、ルーティングテーブル計算の一部から除外することにより、機能が低下したルーターの周囲にトラフィックを転送できます。
All 8 bits of the OSPF Options field have been assigned, although only the O-bit is described completely by this document. Each bit is described briefly below. Routers SHOULD reset (i.e., clear) unrecognized bits in the Options field when sending Hello packets or Database Description packets and when originating link state advertisements. Conversely, routers encountering unrecognized Option bits in received Hello Packets, Database Description packets, or link state advertisements SHOULD ignore the capability and process the packet/advertisement normally.
OSPFオプションフィールドの8ビットすべてが割り当てられていますが、このドキュメントではOビットのみが完全に説明されています。以下に、各ビットについて簡単に説明します。ルータは、Helloパケットまたはデータベース記述パケットを送信するとき、およびリンク状態アドバタイズメントを発信するときに、オプションフィールドの認識されないビットをリセット（つまり、クリア）する必要があります（SHOULD）。逆に、受信したHelloパケット、データベース記述パケット、またはリンクステートアドバタイズメントで認識されないオプションビットに遭遇したルーターは、機能を無視してパケット/アドバタイズメントを通常どおり処理する必要があります。
+--------------------------------------+
| DN | O | DC | EA | N/P | MC | E | MT |
+--------------------------------------+
The Options Field
オプションフィールド
MT-bit This bit describes the router's multi-topology link-excluding capability, as described in [OSPF-MT].
MTビットこのビットは、[OSPF-MT]で説明されているように、ルーターのマルチトポロジリンク除外機能を示します。
E-bit This bit describes the way AS-External LSAs are flooded, as described in Sections 3.6, 9.5, 10.8, and 12.1.2 of [OSPF].
Eビットこのビットは、[OSPF]のセクション3.6、9.5、10.8、および12.1.2で説明されているように、AS外部LSAがフラッディングされる方法を示します。
MC-bit This bit describes whether IP multicast datagrams are forwarded according to the specifications in [MOSPF].
MCビットこのビットは、[MOSPF]の仕様に従ってIPマルチキャストデータグラムを転送するかどうかを示します。
N/P-bit This bit describes the handling of Type-7 LSAs, as specified in [NSSA].
N / Pビットこのビットは、[NSSA]で指定されているタイプ7 LSAの処理を記述します。
DC-bit This bit describes the router's handling of demand circuits, as specified in [DEMD].
DCビットこのビットは、[DEMD]で指定されている、ルーターによるデマンド回線の処理を記述します。
EA-bit This bit describes the router's willingness to receive and forward External-Attributes-LSAs. While defined, the documents specifying this bit have all expired. The use of this bit may be deprecated in the future.
EAビットこのビットは、外部属性LSAを受信して転送するルーターの意欲を表します。定義されている間、このビットを指定するドキュメントはすべて期限切れです。このビットの使用は将来廃止される可能性があります。
O-bit This bit describes the router's willingness to receive and forward Opaque LSAs as specified in this document.
Oビットこのビットは、このドキュメントで指定されているように、ルーターがOpaque LSAを受信して転送する意思を表します。
DN-bit This bit is used to prevent looping in BGP/MPLS IP VPNs, as specified in [RFC4576].
DNビットこのビットは、[RFC4576]で指定されているように、BGP / MPLS IP VPNでのループを防止するために使用されます。
Opaque LSAs are Type 9, 10, and 11 link state advertisements. These advertisements MAY be used directly by OSPF or indirectly by some application wishing to distribute information throughout the OSPF domain. The function of the Opaque LSA option is to provide for future OSPF extensibility.
不透明LSAは、タイプ9、10、および11のリンク状態アドバタイズメントです。これらのアドバタイズは、OSPFによって直接使用される場合と、OSPFドメイン全体に情報を配布したいアプリケーションによって間接的に使用される場合があります。 Opaque LSAオプションの機能は、将来のOSPF拡張性を提供することです。
Opaque LSAs contain some number of octets (of application-specific data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. However, the Opaque LSA has a flooding scope associated with it so that the scope of flooding may be link-local (type-9), area-local (type-10), or the entire OSPF routing domain (type-11). Section 3 of this document describes the flooding procedures for the Opaque LSA.
不透明なLSAには、32ビットアライメントにパディングされた（アプリケーション固有のデータの）いくつかのオクテットが含まれています。他のLSAと同様に、Opaque LSAはリンクステートデータベース分散メカニズムを使用して、この情報をトポロジ全体にフラッディングします。ただし、Opaque LSAにはフラッディングスコープが関連付けられているため、フラッディングのスコープはリンクローカル（タイプ9）、エリアローカル（タイプ10）、またはOSPFルーティングドメイン全体（タイプ11）になります。このドキュメントのセクション3では、不透明LSAのフラッディング手順について説明します。
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 | 9, 10, or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Opaque Information |
+ +
| ... |
Link-State Type
リンクステートタイプ
The link-state type of the Opaque LSA identifies the LSA's range of topological distribution. This range is referred to as the flooding scope. The following explains the flooding scope of each of the link-state types.
Opaque LSAのリンクステートタイプは、LSAのトポロジ分布の範囲を識別します。この範囲は、フラッディングスコープと呼ばれます。次に、各リンクステートタイプのフラッディングスコープについて説明します。
o A value of 9 denotes a link-local scope. Opaque LSAs with a link-local scope MUST NOT be flooded beyond the local (sub)network.
o 値9は、リンクローカルスコープを示します。リンクローカルスコープを持つ不透明LSAは、ローカル（サブ）ネットワークを超えてフラッディングしてはいけません。
o A value of 10 denotes an area-local scope. Opaque LSAs with an area-local scope MUST NOT be flooded beyond their area of origin.
o 値10は、エリアローカルスコープを示します。エリアローカルスコープの不透明なLSAは、元のエリアを超えてフラッディングしてはなりません。
o A value of 11 denotes that the LSA is flooded throughout the Autonomous System (e.g., has the same scope as type-5 LSAs). Opaque LSAs with AS-wide scope MUST NOT be flooded into stub areas or NSSAs.
o 値11は、LSAが自律システム全体にフラッディングされることを示します（たとえば、タイプ5 LSAと同じスコープを持つ）。 AS全体のスコープを持つ不透明LSAは、スタブエリアまたはNSSAにフラッディングしてはいけません。
Syntax of the Opaque LSA's Link-State ID
不透明LSAのリンク状態IDの構文
The link-state ID of the Opaque LSA is divided into an Opaque Type field (the first 8 bits) and an Opaque ID (the remaining 24 bits). See section 7 of this document for a description of Opaque type allocation and assignment.
Opaque LSAのリンクステートIDは、Opaque Typeフィールド（最初の8ビット）とOpaque ID（残りの24ビット）に分かれています。 Opaqueタイプの割り当てと割り当ての説明については、このドキュメントのセクション7を参照してください。
Authors' Addresses
著者のアドレス
Lou Berger LabN Consulting, L.L.C. EMail: lberger@labn.net
Lou Berger LabNコンサルティング、L.L.C。メール：lberger@labn.net
Igor Bryskin ADVA Optical Networking Inc 7926 Jones Branch Drive Suite 615 McLean, VA 22102 EMail: ibryskin@advaoptical.com
Igor Bryskin ADVA Optical Networking Inc 7926 Jones Branch Drive Suite 615 McLean、VA 22102 Eメール：ibryskin@advaoptical.com
Alex Zinin Alcatel-Lucent 750D Chai Chee Rd #06-06 Technopark@ChaiChee Singapore, 469004 EMail: alex.zinin@alcatel-lucent.com
Alex Jeanine Alcatel-Lucent 650 Wanted Rod＃08-06 TechnoparkচাইWanted Singapore、489004 Email：Alex.Jinin：Alcatel-Lucent.com
Rob Coltun Acoustra Productions 3204 Brooklawn Terrace Chevy Chase, MD 20815 USA
Rob Coltun Acoustra Productions 3204 Brooklawn Terrace Chevy Chase、MD 20815 USA
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2008).
Copyright（C）IETF Trust（2008）。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。
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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。