[要約] RFC 2370は、OSPFのOpaque LSAオプションに関する仕様を定めたものであり、LSAの拡張性と柔軟性を向上させることを目的としています。
Network Working Group R. Coltun
Request for Comments: 2370 FORE Systems
See Also: 2328 July 1998
Category: Standards Track
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Table Of Contents
目次
1.0 Abstract ................................................. 1
2.0 Overview ................................................. 2
2.1 Organization Of This Document ............................ 2
2.2 Acknowledgments .......................................... 3
3.0 The Opaque LSA ........................................... 3
3.1 Flooding Opaque LSAs ..................................... 4
3.2 Modifications To The Neighbor State Machine .............. 5
4.0 Protocol Data Structures ................................. 6
4.1 Additions To The OSPF Neighbor Structure ................. 6
5.0 Management Considerations ................................ 7
6.0 Security Considerations .................................. 9
7.0 IANA Considerations ...................................... 10
8.0 References ............................................... 10
9.0 Author's Information ..................................... 11
Appendix A: OSPF Data Formats ................................ 12
A.1 The Options Field ........................................ 12
A.2 The Opaque LSA ........................................... 13
Appendix B: Full Copyright Statment .......................... 15
This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) 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.
このメモは、OSPFプロトコルの拡張を定義して、不透明なLSAと呼ばれる新しいクラスのリンクステートアドバタイズメント（LSA）をサポートします。 Opaque LSAは、OSPFの将来の拡張性を可能にする一般化されたメカニズムを提供します。不透明なLSAは、標準のLSAヘッダーとそれに続くアプリケーション固有の情報で構成されます。情報フィールドは、OSPFまたは他のアプリケーションで直接使用できます。標準のOSPFリンク状態データベースフラッディングメカニズムは、OSPFトポロジのすべてまたは一部の部分にOpaque LSAを配布するために使用されます。
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 memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) 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. For example, the OSPF LSA may be used by routers to distribute IP to link-layer address resolution information (see [ARA] for more information). The exact use of Opaque LSAs is beyond the scope of this memo.
このメモは、OSPFプロトコルの拡張を定義して、不透明なLSAと呼ばれる新しいクラスのリンクステートアドバタイズメント（LSA）をサポートします。 Opaque LSAは、OSPFの将来の拡張性を可能にする一般化されたメカニズムを提供します。 Opaque LSAに含まれる情報は、OSPFが直接使用することも、OSPFドメイン全体に情報を配布したいアプリケーションが間接的に使用することもできます。たとえば、OSPF LSAはルーターによってIPをリンク層アドレス解決情報に配布するために使用されます（詳細については[ARA]を参照してください）。 Opaque LSAの正確な使用は、このメモの範囲を超えています。
Opaque LSAs consist of a standard LSA header followed by a 32-bit qaligned 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ビットのqalignedアプリケーション固有の情報フィールドで構成されます。他の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にパケット形式を示します。
The author would like to thank Dennis Ferguson, Acee Lindem, John Moy, Sandra Murphy, Man-Kit Yeung, Zhaohui "Jeffrey" Zhang and the rest of the OSPF Working Group for the ideas and support they have given to this project.
著者は、このプロジェクトに与えたアイデアとサポートについて、Dennis Ferguson、Acee Lindem、John Moy、Sandra Murphy、Man-Kit Yeung、Zhaohui "Jeffrey" Zhangおよび残りのOSPFワーキンググループに感謝します。
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 from the backbone and 3) not originated by routers into their connected stub areas. As with type-5 LSAs, if a type-11 Opaque LSA is received in a stub area from a neighboring router within the stub area the LSA is rejected.
o リンクステートタイプ11は、LSAが自律システム（AS）全体にフラッディングすることを示します。タイプ11 LSAのフラッディングスコープは、AS外部（タイプ5）LSAのフラッディングスコープと同等です。具体的には、タイプ11の不透明LSAは、1）すべてのトランジットエリア全体にフラッディングされる、2）バックボーンからスタブエリアにフラッディングされない、3）接続されたスタブエリアにルータから発信されない。タイプ5 LSAと同様に、タイプ11の不透明LSAがスタブエリア内の隣接ルータからスタブエリアで受信された場合、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.0 describes Opaque type allocation and assignment.
Opaque LSAのリンクステートIDは、Opaqueタイプフィールド（最初の8ビット）とタイプ固有のID（残りの24ビット）に分かれています。 Opaque LSAのパケット形式は、付録Aに記載されています。セクション7.0では、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). The flooding scope effects both the synchronization of the link-state database and the flooding procedure.
Opaque LSAのフラッディングスコープを適切に処理する責任は、LSAの送信側と受信側の両方にあります。受信者は常に、受信した有効な不透明LSAをリンク状態データベースに保存する必要があります。受信側は、フラッディングスコープに違反する不透明LSAを受け入れてはなりません（たとえば、タイプ11（ドメイン全体）の不透明LSAはスタブエリアでは受け入れられません）。フラッディングスコープは、リンクステートデータベースの同期とフラッディング手順の両方に影響します。
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. 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 not be flooded out that interface (or to that neighbor). An implementation should keepk 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インターフェイスを追跡する必要があります。
o If the Opaque LSA is type 10 (the flooding scope is area-local) and the area associated with Opaque LSA (upon reception) is not the same as the area associated with the target interface, the Opaque LSA must not be flooded out the interface. 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に関連付けられているエリア（受信時）がターゲットインターフェイスに関連付けられているエリアと同じでない場合、Opaque LSAはインターフェイスからフラッディングされないようにする必要があります。 。実装では、エリアローカルフラッディングスコープを持つ各Opaque LSAに関連付けられたOSPFエリアを追跡する必要があります。
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 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 must be discarded and not acknowledged (the neighboring router has flooded the LSA in error).
o Opaque LSAがタイプ11（LSAがAS全体にフラッディングされる）であり、ターゲットインターフェイスがスタブエリアに関連付けられている場合、Opaque LSAはインターフェイスからフラッディングされてはなりません。スタブエリアに関連付けられたインターフェイスで受信されたタイプ11 Opaque LSAは破棄され、確認されない必要があります（隣接ルーターがエラーでLSAをフラッディングしました）。
When opaque-capable routers and non-opaque-capable OSPF routers are mixed together in a routing domain, the Opaque LSAs are 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], receiving Database Description packets from a 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 is not set in packets other than Database Description packets. Then, 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]) if and only if the neighbor is opaque capable.
不透明対応ルーターは、「データベース交換プロセス」の開始時にネイバーの不透明機能を学習します（[OSPF]のセクション10.6を参照して、ExStart状態のネイバーからデータベース記述パケットを受信します）。ネイバーは、データベース記述パケットのオプションフィールドにOビットを設定する場合にのみ不透明になります。 Oビットは、データベース記述パケット以外のパケットには設定されません。次に、データベース交換プロセスの次のステップで、ネイバーが不透明に対応している場合にのみ、ネイバーに送信されるデータベースサマリリストに不透明LSAが含まれます（以下のセクション3.2および[OSPF]の10.3を参照）。
When flooding Opaque-LSAs to adjacent neighbors, a 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 are only placed on the link-state retransmission lists of opaque-capable neighbors. However, when send ing 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], receiving LSAs having unknown LS types).
Opaque-LSAを隣接ネイバーにフラッディングする場合、不透明対応のルーターはネイバーの不透明機能を調べます。不透明LSAは、不透明対応のネイバーにのみフラッディングされます。より正確には、[OSPF]のセクション13.3で、不透明LSAは不透明対応ネイバーのリンク状態再送信リストにのみ配置されます。ただし、リンク状態更新パケットをマルチキャストとして送信する場合、不透明ではないネイバーが（不注意で）不透明LSAを受信することがあります。不透明でないルーターは、LSAを単に破棄します（[OSPF]のセクション13を参照してください。LSタイプが不明な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 and types 9 and 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 are omitted from a virtual neighbor's Database summary list. AS External LSAs and type-11 Opaque LSAs are omitted from the Database summary list if the area has been configured as a stub area (see Section 3.6 of [OSPF]).
処置：ルーターは、エリアリンク状態データベース全体の内容をネイバーデータベースの要約リストにリストする必要があります。エリアリンクステートデータベースは、エリア構造に含まれるルーターLSA、ネットワークLSA、サマリーLSA、タイプ9および10の不透明LSAと、グローバル構造に含まれるAS外部およびタイプ11の不透明LSAで構成されます。 AS外部およびタイプ11の不透明LSAは、仮想ネイバーのデータベースサマリーリストから省略されます。エリアがスタブエリアとして構成されている場合（[OSPF]のセクション3.6を参照）、AS外部LSAとタイプ11の不透明LSAはデータベースサマリーリストから省略されます。
Type-9 Opaque LSAs are 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 is omitted from the Database summary list. It is instead 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. Each Database Description Packet has a DD sequence number, and is explicitly acknowledged. 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と等しい広告はすべて、データベースサマリーリストから除外されます。代わりに、ネイバーのリンクステート再送信リストに追加されます。データベースサマリーリストのサマリーは、データベース記述パケットでネイバーに送信されます。各データベース記述パケットにはDDシーケンス番号があり、明示的に確認されます。一度に未処理にできるのは、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, and 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 inter-operate 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 which 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を参照してください。
This section identifies the current OSPF MIB [OSPFMIB] capabilities that are applicable to the Opaque option and lists the additional management information which is required for its support.
このセクションでは、Opaqueオプションに適用可能な現在のOSPF MIB [OSPFMIB]機能を識別し、そのサポートに必要な追加の管理情報をリストします。
Opaque LSAs are types 9, 10 and 11 link-state advertisements. 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. The range of topological distribution (i.e., the flooding scope) of an Opaque LSA is identified by its link-state type.
不透明LSAは、タイプ9、10、および11のリンクステートアドバタイズメントです。 Opaque LSAのリンクステートIDは、Opaqueタイプフィールド（最初の8ビット）とタイプ固有のID（残りの24ビット）に分かれています。 Opaque LSAのパケット形式は付録Aに記載されています。OpaqueLSAのトポロジ分布の範囲（つまり、フラッディングスコープ）は、リンク状態タイプによって識別されます。
o Link-State type 9 Opaque LSAs have a link-local scope. Type-9 Opaque LSAs are flooded on a single local (sub)network but are not flooded beyond the local (sub)network.
o リンクステートタイプ9の不透明LSAには、リンクローカルスコープがあります。タイプ9の不透明LSAは単一のローカル（サブ）ネットワークでフラッディングされますが、ローカル（サブ）ネットワークを超えてフラッディングされることはありません。
o Link-state type 10 Opaque LSAs have an area-local scope. Type-10 Opaque LSAs are flooded throughout a single area but are not flooded beyond the borders of the associated area.
o リンクステートタイプ10の不透明LSAには、エリアローカルスコープがあります。タイプ10の不透明LSAは、単一のエリア全体にフラッディングされますが、関連エリアの境界を越えてフラッディングされることはありません。
o Link-state type 11 Opaque LSAs have an Autonomous-System-wide scope. The flooding scope of type-11 LSAs are equivalent to the flooding scope of AS-external (type-5) LSAs.
o リンクステートタイプ11の不透明LSAには、自律システム全体のスコープがあります。タイプ11 LSAのフラッディングスコープは、AS外部（タイプ5）LSAのフラッディングスコープと同等です。
The OSPF MIB provides a number of objects that can be used to manage and monitor an OSPF router's Link-State Database. The ones that are relevant to the Opaque option are as follows.
OSPF MIBは、OSPFルーターのリンク状態データベースの管理および監視に使用できる多数のオブジェクトを提供します。 Opaqueオプションに関連するものは次のとおりです。
The ospfGeneralGroup defines two objects for keeping track of newly originated and newly received LSAs (ospfOriginateNewLsas and ospfRxNewLsas respectively).
ospfGeneralGroupは、新しく発信され、新しく受信されたLSAを追跡するための2つのオブジェクトを定義します（それぞれospfOriginateNewLsasおよびospfRxNewLsas）。
The OSPF MIB defines a set of optional traps. The ospfOriginateLsa trap signifies that a new LSA has been originated by a router and the ospfMaxAgeLsa trap signifies that one of the LSAs in the router's link-state database has aged to MaxAge.
OSPF MIBは、オプションのトラップのセットを定義します。 ospfOriginateLsaトラップは、新しいLSAがルーターによって発信されたことを示し、ospfMaxAgeLsaトラップは、ルーターのリンク状態データベース内のLSAの1つがMaxAgeまでエージングしたことを示します。
The ospfAreaTable describes the configured parameters and cumulative statistics of the router's attached areas. This table includes a count of the number of LSAs contained in the area's link-state database (ospfAreaLsaCount), and a sum of the LSA's LS checksums contained in this area (ospfAreaLsaCksumSum). This sum can be used to determine if there has been a change in a router's link-state database, and to compare the link-state database of two routers.
ospfAreaTableは、ルーターの接続されたエリアの構成済みパラメーターと累積統計を記述します。このテーブルには、領域のリンク状態データベースに含まれているLSAの数（ospfAreaLsaCount）と、この領域に含まれているLSAのLSチェックサムの合計（ospfAreaLsaCksumSum）が含まれています。この合計を使用して、ルーターのリンク状態データベースに変更があったかどうかを判断し、2つのルーターのリンク状態データベースを比較できます。
The ospfLsdbTable describes the OSPF Process's link-state database (excluding AS-external LSAs). Entries in this table are indexed with an Area ID, a link-state type, a link-state ID and the originating router's Router ID.
ospfLsdbTableは、OSPFプロセスのリンク状態データベース（AS外部LSAを除く）を記述します。このテーブルのエントリには、エリアID、リンク状態タイプ、リンク状態ID、および発信元ルーターのルーターIDでインデックスが付けられます。
The management objects that are needed to support the Opaque option are as follows.
Opaqueオプションをサポートするために必要な管理オブジェクトは次のとおりです。
An Opaque-option-enabled object is needed to indicate if the Opaque option is enabled on the router.
ルーターで不透明オプションが有効になっているかどうかを示すには、不透明オプションが有効なオブジェクトが必要です。
The origination and reception of new Opaque LSAs should be reflected in the counters ospfOriginateNewLsas and ospfRxNewLsas (inclusive for types 9, 10 and 11 Opaque LSAs).
新しい不透明LSAの発生と受信は、カウンターospfOriginateNewLsasおよびospfRxNewLsas（タイプ9、10、および11の不透明LSAを含む）に反映されます。
If the OSPF trap option is supported, the origination of new Opaque LSAs and purging of MaxAge Opaque LSAs should be reflected in the ospfOriginateLsa and ospfMaxAgeLsa traps (inclusive for types 9, 10 and 11 Opaque LSAs).
OSPFトラップオプションがサポートされている場合、新しいOpaque LSAの生成とMaxAge Opaque LSAのパージは、ospfOriginateLsaおよびospfMaxAgeLsaトラップ（タイプ9、10、11の不透明LSAを含む）に反映される必要があります。
The number of type-10 Opaque LSAs should be reflected in ospfAreaLsaCount; the checksums of type-10 Opaque LSAs should be included in ospfAreaLsaChksumSum.
タイプ10の不透明LSAの数は、ospfAreaLsaCountに反映されます。タイプ10の不透明LSAのチェックサムは、ospfAreaLsaChksumSumに含める必要があります。
Type-10 Opaque LSAs should be included in the ospfLsdbTable. Note that this table does not include a method of examining the Opaque type field (in the Opaque option this is a sub-field of the link-state ID).
タイプ10の不透明LSAがospfLsdbTableに含まれている必要があります。この表には、不透明タイプのフィールドを調べる方法が含まれていないことに注意してください（不透明オプションでは、これはリンク状態IDのサブフィールドです）。
Up until now, LSAs have not had a link-local scope so there is no method of requesting the number of, or examining the LSAs that are associated with a specific OSPF interface. A new group of management objects are required to support type-9 Opaque LSAs. These objects should include a count of type-9 Opaque LSAs, a checksum sum and a table for displaying the link-state database for type-9 Opaque LSAs on a per-interface basis. Entries in this table should be indexed with an Area ID, interface's IP address, Opaque type, link-state ID and the originating router's Router ID.
これまで、LSAにはリンクローカルスコープがなかったため、特定のOSPFインターフェイスに関連付けられているLSAの数を要求したり、LSAを調べたりする方法はありませんでした。タイプ9の不透明LSAをサポートするには、管理オブジェクトの新しいグループが必要です。これらのオブジェクトには、タイプ9の不透明LSAの数、チェックサムの合計、およびインターフェイスごとにタイプ9の不透明LSAのリンク状態データベースを表示するためのテーブルを含める必要があります。このテーブルのエントリには、エリアID、インターフェイスのIPアドレス、不透明タイプ、リンク状態ID、および発信元ルーターのルーターIDでインデックスを付ける必要があります。
Prior to the introduction of type-11 Opaque LSAs, AS-External (type-5) LSAs have been the only link-state types which have an Autonomous-System-wide scope. A new group of objects are required to support type-11 Opaque LSAs. These objects should include a count of type-11 Opaque LSAs, a type-11 checksum sum and a table for displaying the type-11 link-state database. Entries in this table should be indexed with the Opaque type, link-state ID and the originating router's Router ID. The type-11 link-state database table will allow type-11 LSAs to be displayed once for the router rather than once in each non-stub area.
タイプ11の不透明LSAが導入される前は、AS-External（タイプ5）LSAが自律システム全体のスコープを持つ唯一のリンクステートタイプでした。タイプ11の不透明LSAをサポートするには、オブジェクトの新しいグループが必要です。これらのオブジェクトには、タイプ11不透明LSAの数、タイプ11チェックサムの合計、およびタイプ11リンク状態データベースを表示するためのテーブルが含まれている必要があります。このテーブルのエントリには、不透明タイプ、リンク状態ID、および発信元ルーターのルーターIDでインデックスを付ける必要があります。タイプ11リンクステートデータベーステーブルを使用すると、タイプ11 LSAを、各非スタブエリアに1回表示するのではなく、ルータに1回表示できます。
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 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を参照してください。
[DIGI] describes the extensions to OSPF required to add digital signature authentication to Link State data and to provide a certification mechanism for router data. [DIGI] also describes the added LSA processing and key management as well as a method for migration from, or co-existence with, standard OSPF V2.
[DIGI]は、リンク状態データにデジタル署名認証を追加し、ルーターデータの認証メカニズムを提供するために必要なOSPFの拡張機能について説明しています。 [DIGI]では、追加されたLSA処理とキー管理、および標準のOSPF V2からの移行、またはそれと共存するための方法についても説明しています。
Repetitive origination of advertisements are 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]).
アドバタイズの繰り返し発生は、フラッディング手順中に特定のLSAの新しいインスタンスを発生させて受け入れる頻度の制限を義務付けることにより、OSPFによって対処されます。新しい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]は、予期しないデータベースオーバーフローを適切に処理する方法を詳しく説明しています。
Opaque types are maintained by the IANA. Extensions to OSPF which require a new Opaque type must be reviewed by the OSPF working group. In the event that the OSPF working group has disbanded the review shall be performed by a recommended Designated Expert.
不透明タイプはIANAによって維持されます。新しい不透明タイプを必要とするOSPFの拡張機能は、OSPFワーキンググループによってレビューされる必要があります。 OSPFワーキンググループが解散した場合、レビューは推奨される専門家によって行われるものとします。
Following the policies outlined in [IANA], Opaque type values in the range of 0-127 are allocated through an IETF Consensus action and Opaque type values in the range of 128-255 are reserved for private and experimental use.
[IANA]で概説されているポリシーに従って、0〜127の範囲の不透明タイプの値はIETFコンセンサスアクションを通じて割り当てられ、128〜255の範囲の不透明タイプの値は、プライベートおよび実験用に予約されています。
[ARA] Coltun, R., and J. Heinanen, "The OSPF Address Resolution Advertisement Option", Work in Progress.
[ARA] Coltun、R。、およびJ. Heinanen、「OSPFアドレス解決アドバタイズメントオプション」、作業中。
[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月。
[DIGI] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[DIGI] Murphy、S.、Badger、M。、およびB. Wellington、「OSPF with Digital Signatures」、RFC 2154、1997年6月。
[IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", Work in Progress.
[IANA] Narten、T。、およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、Work in Progress。
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[MOSPF] Moy、J。、「OSPFへのマルチキャスト拡張」、RFC 1584、1994年3月。
[NSSA] Coltun, R., and V. Fuller, "The OSPF NSSA Option", RFC 1587, March 1994.
[NSSA] Coltun、R。、およびV. Fuller、「OSPF NSSAオプション」、RFC 1587、1994年3月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[OSPFMIB] Baker, F., and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1850, November 1995.
[OSPFMIB]ベイカー、F。、およびR.コルトゥーン、「OSPFバージョン2管理情報ベース」、RFC 1850、1995年11月。
[OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.
[OVERFLOW] Moy、J。、「OSPFデータベースオーバーフロー」、RFC 1765、1995年3月。
Rob Coltun FORE Systems
Rob Coltun FORE Systems
Phone: (703) 245-4543 EMail: rcoltun@fore.com
電話：（703）245-4543メール：rcoltun@fore.com
Appendix A: OSPF Data formats
付録A：OSPFデータ形式
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 forward 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パケットで使用すると、ルータは機能の不一致のためにネイバーを拒否できます。または、機能がデータベース記述パケットで交換されるとき、ルーターは、機能が低下しているため、特定のリンク状態アドバタイズをネイバーに転送しないことを選択できます。最後に、リンクステートアドバタイズメントに機能をリストすると、ルーターはルーティングテーブルの計算の一部から除外することで、機能が低下したルーターの周囲にトラフィックを転送できます。
Six bits of the OSPF Options field have been assigned, although only the O-bit is described completely by this memo. 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オプションフィールドの6ビットが割り当てられていますが、このメモではOビットのみが完全に説明されています。以下に、各ビットについて簡単に説明します。ルーターは、Helloパケットまたはデータベース記述パケットを送信するとき、およびリンク状態アドバタイズメントを発信するときに、オプションフィールドの認識されないビットをリセット（つまり、クリア）する必要があります。逆に、受信したHelloパケット、データベース記述パケット、またはリンク状態アドバタイズメントで認識されないオプションビットに遭遇したルーターは、機能を無視して、パケット/アドバタイズメントを通常どおり処理する必要があります。
+------------------------------------+
| * | O | DC | EA | N/P | MC | E | * |
+------------------------------------+
The Options Field
オプションフィールド
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, as specified in [EAL].
EAビットこのビットは、[EAL]で指定されているように、External-Attributes-LSAを受信して転送するルーターの意思を示します。
O-bit This bit describes the router's willingness to receive and forward Opaque-LSAs as specified in this document.
Oビットこのビットは、このドキュメントで指定されているように、ルーターがOpaque LSAを受信して転送する意欲を示します。
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 extensibility of OSPF.
不透明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 are not flooded beyond the local (sub)network.
o 値9は、リンクローカルスコープを示します。リンクローカルスコープを持つ不透明LSAは、ローカル（サブ）ネットワークを超えてフラッディングされません。
o A value of 10 denotes an area-local scope. Opaque LSAs with a area-local scope are not flooded beyond the area that they are originated into.
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 are not flooded into stub areas.
o 値11は、LSAが自律システム全体にフラッディングされることを示します（たとえば、タイプ5 LSAと同じスコープを持つ）。 AS全体のスコープを持つ不透明LSAは、スタブエリアにフラッディングされません。
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.0 of this document for a description of Opaque type allocation and assignment.
Opaque LSAのリンクステートIDは、Opaque Typeフィールド（最初の8ビット）とOpaque ID（残りの24ビット）に分かれています。 Opaqueタイプの割り当てと割り当ての説明については、このドキュメントのセクション7.0を参照してください。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。