Network Working Group D. Harrington Request for Comments: 2571 Cabletron Systems, Inc. Obsoletes: 2271 R. Presuhn Category: Standards Track BMC Software, Inc. B. Wijnen IBM T. J. Watson Research April 1999 SNMP管理フレームワークの記述のためのアーキテクチャー このメモの位置付け この文書はインターネットコミュニティのためにインターネット標準トラッ クプロトコルを示し、改善のために議論と提案を求めるものである。このプ ロトコルの標準化の実状と現状のために「インターネット公式プロトコル標 準」(STD 1)の現在のバージョンに対する意見を求める。このメモの配布は制 限されない。 Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 要約 この文書ではSNMP管理フレームワークを示すためのアーキテクチャーを示す。 このアーキテクチャーはSNMPプロトコル標準が何度でも進化できるようにモ ジュラー型に設計されている。アーキテクチャの主要な部分はメッセージ処 理サブシステム、セキュリティサブシステム、そしてアクセス制御サブシス テムを含むSNMPエンジンと管理データの特別な処理機能を提供する様々な SNMPアプリケーションである。 目次 1. はじめに 1.1. 概要 1.2. SNMP 1.3. このアーキテクチャーの目標 1.4. このアーキテクチャーのセキュリティの要求仕様 1.5. 設計の決定 2. 文書概要 2.1. 文書ロードマップ 2.2. 適用性の宣言 2.3. 共存と移行 2.4. トランスポートマッピング 2.5. メッセージ処理 2.6. セキュリティ 2.7. アクセス制御 2.8. プロトコルオペレーション 2.9. アプリケーション 2.10. 管理情報構造(SMI : Structure of Management Information) 2.11. 文字列表記法 2.12. 準拠宣言 2.13. 管理情報ベースモジュール 2.13.1. SNMP計測MIB 2.14. SNMPフレームワーク文書 3. アーキテクチャーの要素 3.1. エンティティの命名 3.1.1. SNMPエンジン 3.1.1.1. snmpEngineID 3.1.1.2. ディスパッチャ 3.1.1.3. メッセージ処理サブシステム 3.1.1.3.1. メッセージ処理モデル 3.1.1.4. セキュリティサブシステム 3.1.1.4.1. セキュリティモデル 3.1.1.4.2. セキュリティプロトコル 3.1.2. アクセス制御サブシステム 3.1.2.1. アクセス制御モデル 3.1.3. アプリケーション 3.1.3.1. SNMPマネージャ 3.1.3.2. SNMPエージェント 3.2. 識別子の命名 3.2.1. 主体 3.2.2. securityName 3.2.3. モデル依存のsecurity ID 3.3. 管理情報の命名 3.3.1. SNMPコンテキスト 3.3.2. contextEngineID 3.3.3. contextName 3.3.4. scopedPDU 3.4. Other Constructs 3.4.1. maxSizeResponseScopedPDU 3.4.2. ローカル設定データストア 3.4.3. securityLevel 4. 抽象サービスインターフェース 4.1. ディスパッチャプリミティブ 4.1.1. 出力するリクエストや通知の生成 4.1.2. 入力してくるリクエストや通知のPDUの処理 4.1.3. 出力する応答の生成 4.1.4. 入力してくる応答PDUの処理 4.1.5. SNMP PDUを扱うための責任の登録 4.2. メッセージ処理サブシステムのプリミティブ 4.2.1. 出力するSNMPリクエストや通知メッセージの準備 4.2.2. 出力するSNMP応答メッセージの準備 4.2.3. 入力してくるSNMPメッセージからデータ要素の準備 4.3. アクセス制御サブシステムプリミティブ 4.4. セキュリティサブシステムプリミティブ 4.4.1. リクエストや通知メッセージの生成 4.4.2. 入力してくるメッセージの処理 4.4.3. 応答メッセージの生成 4.5. 共通のプリミティブ 4.5.1. 状態を参照している情報の解放 4.6. シナリオダイアグラム 4.6.1. コマンド生成機能や通知発信機能 4.6.2. コマンド応答機能アプリケーションのシナリオダイアグラム 5. SNMP管理フレームワークの管理オブジェクト定義 6. IANAの考慮 6.1. セキュリティモデル 6.2. メッセージ処理モデル 6.3. SnmpEngineIDフォーマット 7. 知的財産 8. 謝辞 9. セキュリティの考慮 10. 参考文献 11. 著者アドレス A. モデル設計者へのガイドライン A.1. セキュリティモデル設定の要件 A.1.1. 脅威 A.1.2. セキュリティ処理 A.1.3. 受信したメッセージにあるセキュリティのスタンプの正当性の評価 A.1.4. セキュリティMIB A.1.5. キャッシュされたセキュリティデータ A.2. メッセージ処理モデルの設計の要件 A.2.1. ネットワークからのSNMPメッセージの受信 A.2.2. SNMPメッセージのネットワークへの送信 A.3. アプリケーション設計の要件 A.3.1. メッセージを初期化するアプリケーション A.3.2. 応答を受信するアプリケーション A.3.3. 非同期メッセージを受信するアプリケーション A.3.4. 応答を送信するアプリケーション A.4. アクセス制御モデルの設計の要件 B. 著作権全文 1. はじめに 1.1. 概要 この文書ではSNMP管理フレームワークの用語と主要な部分のアーキテクチャー を定義する。 この文書ではSNMPの全般的な情報について提供しない。他の文書や本がSNMP に関する詳細な情報を提供することができる。この文書ではSNMPの歴史につ いても提供しない。これについても本や他の文書を参考にすることができる。 1章では、このアーキテクチャーの目的、目標と設計の決定について説明する。 2章では、SNMPフレームワーク(の要素)を定義する様々な文書の種類とそれら がこのアーキテクチャーにどのように合わせるのかについて説明する。また、 以前のSNMPフレームワークを定義した文書への最小のロードマップについて も提供する。 3章では、このアーキテクチャーや断片の用語を詳しく説明する。この章は後 の章を理解するために、また、このアーキテクチャーに合わせるために書か れた文書を理解するために重要である。 4章では、様々なサブシステムやモデルとこのアーキテクチャーのアプリケー ション間の抽象的なサービスインターフェースで使われる原理を説明する。 5章では、このアーキテクチャー内のSNMPエンティティを操作するために用い られる管理オブジェクトの集合を定義する。 6、7、8、9、10、11章では将来の運用について述べる。 付録Aでは、このアーキテクチャー内に適応させるように期待されているモデ ルの設計を行う人のためのガイドラインを含む。 この文書中の"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、 "SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、"OPTIONAL"という単語は [RFC2119]で説明されている通りに解釈されるべきである。 1.2. SNMP SNMP管理システムは以下のものを含む。 - いくつか(おそらくたくさん)のノード。それぞれがコマンド応答機能 と通知発信機能を持ち、管理機能(伝統的にエージェントと呼ばれる) へのアクセス機能があるSNMPエンティティを持っている。 - 少なくともコマンド生成機能と/あるいは通知受信機能を含んだ(伝統 的にマネージャと呼ばれる)一つのSNMPエンティティ。 - 管理プロトコル。SNMPエンティティ間で管理情報を伝えるのに用いら れる。 コマンド生成機能と通知受信機能のアプリケーションを実行しているSNMPエ ンティティは管理要素を監視し、制御する。管理要素はホストやルータ、ター ミナルサーバなどのデバイスであり、これらは管理情報へのアクセスを経由 して監視・制御される。 多様な設定と環境の管理を効果的に実現するように進化することができるアー キテクチャーを定義することがこの文書の目的である。アーキテクチャーは 以下の実装要求を満たすように設計されている。 - 最低でも、コマンド応答機能と通知発信機能のアプリケーションを持 つSNMPエンティティ(伝統的にSNMPエージェントと呼ばれる)。 - プロキシ転送アプリケーション(伝統的にSNMPプロキシエージェントと 呼ばれる)を持つSNMPエンティティ。 - コマンド生成機能と通知受信機能のアプリケーション(伝統的にSNMPコ マンドラインマネージャと呼ばれる)を持つ、コマンドラインで実行さ れるSNMPエンティティ。 - コマンド生成機能と通知受信機能に加え、コマンド応答機能と通知送 信機能のアプリケーション(伝統的にSNMP中間レベルマネージャ、ある いはデュアルエンティティと呼ばれる)を持つSNMPエンティティ。 - コマンド生成機能と通知受信機能、そして大多数の管理対象ノードを 管理することが可能なアプリケーション(伝統的に(ネットワーク)管理 ステーションと呼ばれる)を持つSNMPエンティティ。 1.3. アーキテクチャーの目標 このアーキテクチャーは以下の目標によって前進させられています。 - 可能な限り既存のものを用いること。これはSNMPv2pに基づいている SNMPv2uやSNMPv2*として知られている以前の成果に強く基づいている。 - 安全なSETサポートの必要性を表記すること。これはSNMPv1とSNMPv2c にもっとも重要な欠点を考慮される。 - たとえ、標準化トラックにおいて全ての部分に関して総意に達しな い場合でも、アーキテクチャーの一部分を先送りにすることを可能 にすること。 - 今まで定義されてきて、これからも定義されるSNMPフレームワークが 長く利用されることを可能にするアーキテクチャーを定義すること。 - できるかぎりSNMPをシンプルに保つこと。 - 最小限の実装へ準拠することを相対的に高くないように保つこと。 - 新しいアプローチが利用可能となったら、SNMPフレームワーク全体を 壊すことなく、SNMPの一部分をアップグレードするのを可能にするこ と。 - 大規模ネットワークで要求される機能のサポートを可能にすること。 しかし、機能のサポートに直接関連する機能をサポートすることに費 やす。 1.4. 本アーキテクチャーのセキュリティ要件 ネットワークプロトコルへの古典的な脅威は管理の懸案にも当てはまり、そ れゆえにSNMP管理フレームワークで用いられるあらゆるセキュリティモデル にも当てはまる。他の脅威は管理の懸案には当てはまらない。この章ではもっ とも重要な脅威、二次的な脅威、そして重要ではない脅威について論じる。 本アーキテクチャーで用いられるあらゆるセキュリティモデルが保護「すべ き」ものに対するもっとも重要な脅威は以下の通りである。 情報の改竄 改竄の脅威は、権限の与えられていないエンティティが、オブジェク トの値の改竄を含む、権限の与えられていない管理オペレーションを 行うようなやりかたで、権限の与えられたエンティティに代わって、 生成された遷移状態のSNMPメッセージを変えるかも知れないという危 険である。 なりすまし なりすましの脅威は、エンティティに対して権限を与えられていない 管理オペレーションが、適した権限を持つ他のエンティティの身元を 偽ることにより、企てられるかもしれないという危険である。 本アーキテクチャーで用いられるあらゆるセキュリティモデルが保護「すべ き」ものに対する二次的な脅威は以下の通りである。 メッセージストリーム改竄 SNMPプロトコルは典型的にあらゆるサブネットワークから操作するか も知れないコネクションレスのトランスポートサービスに基づいてい る。メッセージの再命令や遅延、再送はそのような多くのサブネット ワークのサービスで普通の操作を通じて起こるかも知れないし、起こ る。メッセージストリーム改竄の脅威は、権限を与えられていない管 理オペレーションに影響するために、メッセージが悪意によってサブ ネットワークでのサービスの普通の操作を通じて起こすことができる ものより大きなところまで再命令や遅延、再送されるかもしれないと いう危険である。 隠蔽 隠蔽の脅威はSNMPエンジン間でのやり取りでの軒先の危険である。こ の脅威から保護することはローカルプライバシーの問題として要求さ れるかもしれない。 本アーキテクチャー内で保護を必要としないセキュリティモデルに対する少 なくとも二つの脅威がある。これらは本アーキテクチャーにおいてはあまり 重要ではないと考えられている。 サービス不能 セキュリティモデルは権限の与えられたユーザに代わるサービスによ る広範囲に渡る攻撃を送ろうと試みる必要がない。※ 実に、そのようなサービス不能攻撃はあらゆる管理プロトコルが当然 のこととして処理するに違いないネットワークの不具合と見分けるこ とができない多くのケースで行われる。 トラフィック解析 セキュリティモデルはトラフィック分析攻撃を送ろうと試みる必要が ない。多くのトラフィックパターンが予言することが可能 - エンティ ティは相対的に少数の管理ステーションによって正規の方法で管理さ れるだろう - であり、それゆえ、トラフィック分析攻撃に対して防御 することによって与えられる重大な長所がない。 1.5. 設計の決定 アーキテクチャーとセキュリティへの要求の結論をサポートするために様々 な設計の決定が行われた。 - アーキテクチャー アーキテクチャーは文書間での概念的な範囲を識別するものが定義さ れるべきである。サブシステムはSNMPフレームワークの特定の部分に よって提供される抽象的なサービスを説明するものが定義されるべき である。抽象的なサービスインターフェースはサービスの原始に記述 されているような文書間の抽象的な範囲と、SNMPフレームワークの概 念的なサブシステムによって提供される抽象的なサービスを定義する。 - 自己を含むドキュメント 手続きの要素とMIBオブジェクトを加えた要素はSNMPフレームワークの 特定の部分の処理を行うのに必要とされ、同じ文書に定義されるべき であり、さらにできる限り他の文書から参照されるべきでない。これ により、それぞれが独立し、自己を含んだ部分として設計され、文書 化されることが可能となる。これは汎用のSNMP MIB モジュールアプロー チと一致したものである。SNMPの部分が時を越えて変わっても、SNMP の他の部分を説明している文書は直接影響を受けない。このモジュラー 性により、ニーズが生じると、例えばセキュリティモデル、権限、プ ライバシーメカニズム、そしてメッセージフォーマットが向上し、補 うことが可能になった。自己を含むドキュメントは異なる時間軸の標 準化トラックに沿って動議することができる。 このモジュラー機能の仕様はどんな特定の要求も実装に押しつけられるよ うなことを意味するものではない。 - 脅威 セキュリティサブシステムにおけるセキュリティモデルはもっとも重 要な脅威と次の脅威から保護すべきである : 情報の改竄、なりすまし、 メッセージストリーム改竄、そして隠蔽である。サービス不能やトラ フィック解析から保護する必要はない。 - リモート設定 セキュリティとアクセス制御サブシステムはSNMP設定パラメータの完 全に新しいセットを追加する。また、セキュリティサブシステムは様々 なSNMPエンティティの秘密の変更も頻繁に要求する。大規模なオペレー ション環境においてこれを使えるようにするためには、これらのSNMP パラメータがリモートから設定可能でなければならない。 - 制御された複雑さ シンプルな管理デバイスの製作者がSNMPに使用されるリソースを最小 限、押さえておきたいということが認識されている。同時に、SNMPに より多くのリソースを費やすような複雑な設定に対するニーズがあり、 そのため、より多くの機能を提供する。設計はバランスの点でこれら の環境への要求を競い続けようとし、さらに複雑な環境がシンプルな 環境を論理的に広げる。 2. ドキュメンテーション概要 以下の図はSNMPアーキテクチャーに当てはめた文書のセットを示している。 +------------------------- Document Set ----------------------------+ | | | +----------+ +-----------------+ +----------------+ | | | Document | | Applicability * | | Coexistence | | | | Roadmap | | Statement | | & Transition | | | +----------+ +-----------------+ +----------------+ | | | | +---------------------------------------------------------------+ | | | Message Handling | | | | +----------------+ +-----------------+ +-----------------+ | | | | | Transport | | Message | | Security | | | | | | Mappings | | Processing and | | | | | | | | | | Dispatcher | | | | | | | +----------------+ +-----------------+ +-----------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | PDU Handling | | | | +----------------+ +-----------------+ +-----------------+ | | | | | Protocol | | Applications | | Access | | | | | | Operations | | | | Control | | | | | +----------------+ +-----------------+ +-----------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | Information Model | | | | +--------------+ +--------------+ +---------------+ | | | | | Structure of | | Textual | | Conformance | | | | | | Management | | Conventions | | Statements | | | | | | Information | | | | | | | | | +--------------+ +--------------+ +---------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | MIB Modules written in various formats, e.g.: | | | | +-------------+ +-------------+ +----------+ +----------+ | | | | | Standard v1 | | Standard v1 | | Historic | | Draft v2 | | | | | | RFC 1157 | | RFC 1212 | | RFC 14xx | | RFC 19xx | | | | | | format | | format | | format | | format | | | | | +-------------+ +-------------+ +----------+ +----------+ | | | +---------------------------------------------------------------+ | | | +-------------------------------------------------------------------+ アスタリスク(*)は将来書かれることが期待されている。これらの文書は置き 換えられるか補足される。このアーキテクチャーの文書では、特にどのよう に新しい文書を今までのメッセージとPDU操作の領域の文書セットに当てはめ るかを記している。 2.1. 文書ロードマップ 一つ以上の文書では、一緒にされた文書セットがどのように特定のフレーム ワークを形作るかを説明するために書かれるかもしれない。文書セットの設 定が何度も変更するかも知れない。そのため、「ロードマップ」は標準の文 書自身とは別の文書で整備されるべきである。 そのようなロードマップの例は「インターネット標準ネットワーク管理フレー ムワーク第三版の紹介」[RFC2570]である。 2.2. 適用性の宣言 SNMPは規模や複雑さが大きく変化するネットワークで、管理の要求が大きく 変化する組織によって使われる。モデルはメッセージのセキュリティのよう な特定の管理の問題を処理するように設計される。 一つ以上の文書では、あるバージョンのSNMPやSNMP内のモデルが適切に当て はめられている、そして、与えられたモデルが不適切に当てはめられている 環境を説明するために記述されるかもしれない。 2.3. 共存と移行 進化的なアーキテクチャーの目的は既存のモデルを置き換える、あるいは補 足するために新しいモデルを許すことである。モデル間の相互作用は非互換 性、セキュリティホール、そして他の望まれない効果に帰着することができ る。 共存の文書の目的は認識された例外を詳述し、アーキテクチャーにおけるモ デル間の相互作用を解決するために要求され推奨された動作を説明すること である。 共存の文書は、モデルの定義と一つ以上の他のモデルの定義の間の相互作用 の例外を説明し、解決するためにモデルを定義する文書と別に用意されるか もしれない。 加えて、モデル間の移行の推奨も、共存の文書か別の文書で説明されるだろ う。 一つのそのような共存の文書は[SNMP-COEX]、「インターネット標準ネットワー ク管理フレームワークのバージョン1、2、そして3の共存」である。 2.4. トランスポートマッピング SNMPメッセージは様々なトランスポート上で送られる。どのようにSNMPとト ランスポート間のマッピングが行われるかを定義することがトランスポート マッピングの文書の目的である。 2.5. メッセージ処理 メッセージ処理モデルの文書ではメッセージフォーマットを定義している。 フォーマットは典型的にSNMPメッセージヘッダのバージョンフィールドによっ て識別される。文書でも、メッセージ処理の利用やバージョン別の相互作用 の命令のためのMIBモジュールを定義するかもしれない。 SNMPエンジンは一つ以上のメッセージ処理モデルを含み、それゆえ、様々な バージョンのSNMPメッセージの送信と受信をサポートするかも知れない。 2.6. セキュリティ 環境にはセキュアなプロトコルの相互作用を要求するものもある。セキュリ ティは通常、二つの異なる段階で適用される。 - メッセージの伝達/受信 - メッセージ内容の処理 この文書の目的の「セキュリティ」ではメッセージレベルのセキュリティに 言及している。「アクセス制御」ではプロトコルオペレーションに適用され るセキュリティに言及している。 認証、暗号化、即時性チェックはメッセージレベルのセキュリティの共通機 能である。 セキュリティの文書では、セキュリティモデル、モデルが保護する脅威、セ キュリティモデルの目標、その目標に到達するために用いられるプロトコル について説明しており、処理の間に用いられるデータを説明し、キーのよう なメッセージレベルのセキュリティパラメータのリモート設定を行うことを 可能とするMIBモジュールを定義しているかも知れない。 SNMPエンジンは様々なセキュリティモデルを同時にサポートするかもしれな い。 2.7. アクセス制御 処理中にオペレーションのために管理オブジェクトのアクセスを制御するこ とが要求されるかもしれない。 アクセス制御モデルは管理オブジェクトへのアクセスが許されるかどうかを 決定するためのメカニズムを定義している。アクセス制御モデルは処理中に 用いられるMIBモジュールを定義し、アクセス制御ポリシーのリモート設定を 許すかも知れない。 2.8. プロトコルオペレーション SNMPメッセージはSNMPプロトコルデータユニット(PDU)をカプセル化する。 SNMP PDUはそれを受信するSNMPエンジンによって行われるオペレーションを 定義している。PDUの処理に関してプロトコルのオペレーションを定義するこ とはプロトコルオペレーションの文書の目的である。あらゆるPDUは以下に定 義された一つ以上のPDUクラスに属する。 1) 読み取りクラス 読み取りクラスは管理情報の検索を行うプロトコルオペレーションを 含む。例えば、RFC 1905では読み取りクラスのための下記のプロトコ ルオペレーションを定義している。GetRequest-PDU、 GetNextRequest-PDU、GetBulkRequest-PDU。 2) 書き込みクラス 書き込みクラスは管理情報を修正しようとするプロトコルオペレーショ ンを含む。例えば、RFC 1905では書き込みクラスのための下記のプロ トコルオペレーションを定義している。SetRequest-PDU。 3) 応答クラス 応答クラスは前のリクエストに応答するために送信されるプロトコル オペレーションを含む。例えば、RFC 1905では応答クラスのための下 記のプロトコルオペレーションを定義している。Response-PDU、 Report-PDU。 4) 通知クラス 通知クラスは通知受信アプリケーションへ通知を送るプロトコルオペ レーションを含む。例えば、RFC 1905では通知クラスのための下記の オペレーションを定義している。Trapv2-PDU、InformRequest-PDU。 5) 内部クラス 内部クラスはSNMPエンジン間で内部的に交換されるプロトコルオペレー ションを含む。例えば、RFC 1905では内部クラスのための下記のオペ レーションを定義している。Report-PDU。 前項の5つの分類はPDUの機能的なプロパティに基づいている。応答が期待さ れるかどうかに基づいたPDUを分類することも有効である。 6) 確定クラス 確定クラスは受信したSNMPエンジンが応答を送り返す全てのプロトコ ルオペレーションを含む。例えば、RFC 1905では下記のプロトコルオ ペレーションを定義している。GetRequest-PDU、GetNextRequest-PDU、 GetBulkRequest-PDU、SetRequest-PDU、InformRequest-PDU。 7) 未確定クラス 未確定クラスは肯定応答されない全てのプロトコルオペレーションを 含む。例えば、RFC 1905では未確定クラスのための下記のオペレーショ ンを定義している。Report-PDU、Trapv2-PDU、GetResponse-PDU。 アプリケーションの文書はアプリケーションによってサポートされているプ ロトコルオペレーションを定義している。 2.9. アプリケーション SNMPエンティティは通常、多くのアプリケーションを含んでいる。アプリケー ションは特定の業務を完遂するためにSNMPエンジンのサービスを利用する。 それらは管理情報のオペレーションの処理を整合し、他のSNMPエンティティ と通信するためにSNMPメッセージを使用するだろう。 アプリケーションの文書ではアプリケーションの目的、連携するSNMPエンジ ンに要求されるサービス、アプリケーションが管理オペレーションを行うた めに利用するプロトコルオペレーションと情報モデルを説明する。 アプリケーションの文書では特に管理情報構造、文字列表記法、準拠仕様、 そしてアプリケーションにサポートされるオペレーションを定義するのに用 いられる文書セットを定義している。 2.10. 管理情報構造 管理情報は管理情報ベース(MIB : Management Information Base)と呼ばれる 仮想情報記憶装置にある管理オブジェクトの集合として調べられる。関連す るオブジェクトの集合はMIBモジュールに定義されている。 オブジェクト、モジュール、そして管理情報の他の要素を定義するための表 記法を定めるのは管理情報構造の文書の目的である。 2.11. 文字列表記法 MIBモジュールを設計する時には、SMIで定義されている型に似ている新しい 型を定義することはしばしば有効であるが、しかし、より正確なセマンティ クスを使うか、関連づけられた特別なセマンティクスを持つものを用いる。 新しく定義された型は文字列表記法と呼ばれ、分割した文書かMIBモジュー ル内に定義されるかもしれない。 2.12. 準拠宣言 達成可能な実状の実装レベルに沿って、実装可能な最低限の境界を定義す ることは有益であろう。これらの目的に使われる表記法を定義することは 準拠宣言の文書の目的である。 2.13. 管理情報ベースモジュール MIB文書では管理ノードの様子を計測する管理オブジェクトの集合を説明し ている。 2.13.1. SNMP計測MIBs SNMP MIB文書ではSNMPプロトコル自身を計測する管理オブジェクトの集合 を定義するかも知れない。加えて、MIBモジュールはSNMPアーキテクチャー 部を説明する文書、それらのモデルを計測したり、モデルのリモート設定 を可能にするために、メッセージ処理モデルやセキュリティモデルなどの 中で定義されるかも知れない。 2.14. SNMPフレームワーク文書 このアーキテクチャーはSNMPフレームワーク部の整然とした進化が可能な ように設計されている。 この文書の残りを通じて、「サブシステム」という用語は抽象的で不完全 なフレームワーク部の仕様に言及しており、これはモデルの仕様により更 に洗練されている。 「モデル」は準拠のための付加的な制約と規則を定義している特定の設計 のサブシステムを説明している。モデルは仕様を実装するのに充分なほど、 詳細に説明されている。 「実装」はサブシステムの具体化された形であり、一つ以上の特定のモデ ルに準じている。 SNMP初版(SNMPv1)は、最初のインターネット標準ネットワーク管理フレー ムワークとしてRFC 1155、1157、1212に記述されている。 SNMP第二版(SNMPv2)は、SNMPv1フレームワークから来たSNMPv2フレームワー クであり、STD 58、RFC 2578、2579、2580、1905-1907に記述されている。 SNMPv2はメッセージ定義を持たない。 コミュニティベースのSNMP第二版(SNMPv2c)はSNMPv2フレームワークを追加 する実験的なSNMPフレームワークであり、RFC 1901に記述されている。こ こでは、SNMPv1メッセージフォーマットに近いSNMPv2cメッセージフォーマッ トを追加している。 SNMP第三版(SNMPv3)は、SNMPv2フレームワークに以下のサポートを追加す る拡張可能なSNMPフレームワークである。 - 新しいSNMPメッセージフォーマット - メッセージに対するセキュリティ - アクセス制御 - SNMPパラメータのリモート設定 他のSNMPフレームワーク、例えば実装されたサブシステムの他の設定はこ のアーキテクチャーと辻褄があっていることもまた期待されている。 3. アーキテクチャーの要素 この章ではアーキテクチャーの様々な要素とそれらがどう命名されたかを 説明する。これには3種類の命名がある。 1) エンティティの命名 2) 識別子の命名 3) 管理情報の命名 このアーキテクチャーはこの文書で使われる構造の命名も定義する。 3.1. エンティティの命名 SNMPエンティティはこのアーキテクチャーの実装である。それぞれのSNMP エンティティはSNMPエンジンと一つ以上の関連するアプリケーションから 成る。 下の図はSNMPエンティティとそれに含まれるコンポーネントについての詳 細を表す。 +-------------------------------------------------------------------+ | SNMP entity | | | | +-------------------------------------------------------------+ | | | SNMP engine (snmpEngineIDにより識別される) | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | | | | | | | | | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | | | | | | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | Application(s) | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Proxy | | | | | | Generator | | Receiver | | Forwarder | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Other | | | | | | Responder | | Originator | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+ 3.1.1. SNMPエンジン SNMPエンジンはメッセージ、認証、そして暗号化したメッセージの送受信 と管理オブジェクトへのアクセス制御のためのサービスを提供する。SNMP エンジンとそれを含むSNMPエンティティとの間は1対1の関係がある。 エンジンは以下のものを含む。 1) ディスパッチャ 2) メッセージ処理サブシステム 3) セキュリティサブシステム 4) アクセス制御サブシステム 3.1.1.1. snmpEngineID 運用ドメイン内では、snmpEngineIDは一意であいまいでないSNMPエンジン の識別子である。そのため、SNMPエンジンとSNMPエンティティとの間には、 一対一の関係があり、また、運用ドメイン内においてSNMPエンティティを 一意で明確に識別する。SNMPエンティティが異なる運用ドメインでは、同 じ値のsnmpEngineIDを持つことができる点に注意が必要である。運用ドメ インの連合は新しい値の割り当てを必要とするだろう。 3.1.1.2. ディスパッチャ SNMPエンジンにはディスパッチャが一つだけ存在する。これにより、SNMP エンジン内で様々なバージョンのSNMPメッセージの同時サポートを可能に する。これは以下の機能によって提供される。 - ネットワークへ/からSNMPメッセージを送受信すること - SNMPメッセージのバージョンを決定し、対応したメッセージ生成モ デルと協調すること - PDUをSNMPアプリケーションへ配送するための抽象化インターフェー スを提供すること - SNMPアプリケーションが遠隔のSNMPエンティティへPDUを送るための 抽象化インターフェースを提供すること 3.1.1.3. メッセージ処理サブシステム メッセージ処理サブシステムは、送信のためのメッセージの準備と受信し たメッセージからデータを展開するためのものである。 メッセージ処理サブシステムは、次の図で示すように、潜在的に様々なメッ セージ処理モデルを含む。 * 一つ以上のメッセージ処理モデルを表している。 +------------------------------------------------------------------+ | | | Message Processing Subsystem | | | | +------------+ +------------+ +------------+ +------------+ | | | * | | * | | * | | * | | | | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | | | | Message | | Message | | Message | | Message | | | | Processing | | Processing | | Processing | | Processing | | | | Model | | Model | | Model | | Model | | | | | | | | | | | | | +------------+ +------------+ +------------+ +------------+ | | | +------------------------------------------------------------------+ 3.1.1.3.1. メッセージ処理モデル それぞれのメッセージ処理モデルはSNMPメッセージの特定のバージョンの フォーマットを定義しており、それぞれのバージョン特有のメッセージフォー マットの準備と展開を調和して行う。 3.1.1.4. セキュリティサブシステム セキュリティサブシステムはメッセージの認証とプライバシーのようなセ キュリティサービスを提供し、潜在的に次の図に示される様々なセキュリ ティモデルを含む。 * 一つ以上のセキュリティモデルを表している。 +------------------------------------------------------------------+ | | | Security Subsystem | | | | +----------------+ +-----------------+ +-------------------+ | | | * | | * | | * | | | | User-Based | | Other | | Other | | | | Security | | Security | | Security | | | | Model | | Model | | Model | | | | | | | | | | | +----------------+ +-----------------+ +-------------------+ | | | +------------------------------------------------------------------+ 3.1.1.4.1. セキュリティモデル セキュリティモデルは脅威と保護の対象、サービスの目標、そして認証や プライバシーのようなセキュリティサービスを提供するためのセキュリティ プロトコルを特定している。 3.1.1.4.2. セキュリティプロトコル セキュリティプロトコルはメカニズム、手続き、そして認証やプライバシー のようなセキュリティサービスを提供するのに用いられるMIBオブジェクト を特定している。 3.1.2. アクセス制御サブシステム アクセス制御サブシステムは一つ以上のアクセス制御モデル(*)によって権 限サービスを提供する。 +------------------------------------------------------------------+ | | | Access Control Subsystem | | | | +---------------+ +-----------------+ +------------------+ | | | * | | * | | * | | | | View-Based | | Other | | Other | | | | Access | | Access | | Access | | | | Control | | Control | | Control | | | | Model | | Model | | Model | | | | | | | | | | | +---------------+ +-----------------+ +------------------+ | | | +------------------------------------------------------------------+ 3.1.2.1. アクセス制御モデル アクセス制御モデルは、アクセス権に関する決定をサポートするための特 定のアクセス決定機能を定義している。 3.1.3. アプリケーション アプリケーションには以下のようにいくつかの種類がある。 - 管理データの監視と操作を行うコマンド生成機能 - 管理データへのアクセスを提供するコマンド応答機能 - 非同期のメッセージを開始する通知発信機能 - 非同期のメッセージを処理する通知受信機能 - エンティティ間でメッセージを転送するプロキシ転送機能 これらのアプリケーションはSNMPエンジンによって提供されるサービスを 利用する。 3.1.3.1. SNMPマネージャ 一つ以上のコマンド生成機能と/や(関連するSNMPエンジンとともに)通知受 信機能アプリケーションを含むSNMPエンティティは、伝統的にSNMPマネー ジャと呼ばれる。 * 一つ以上のモデルが表されている。 (traditional SNMP manager) +-------------------------------------------------------------------+ | +--------------+ +--------------+ +--------------+ SNMP entity | | | NOTIFICATION | | NOTIFICATION | | COMMAND | | | | ORIGINATOR | | RECEIVER | | GENERATOR | | | | applications | | applications | | applications | | | +--------------+ +--------------+ +--------------+ | | ^ ^ ^ | | | | | | | v v v | | +-------+--------+-----------------+ | | ^ | | | +---------------------+ +----------------+ | | | | Message Processing | | Security | | | Dispatcher v | Subsystem | | Subsystem | | | +-------------------+ | +------------+ | | | | | | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | | | | | | | +------------+ | | | Other | | | | | | | | +------------+ | | | Security | | | | | | | +->| v2cMP * |<--->| | Model | | | | | Message | | | +------------+ | | +------------+ | | | | Dispatcher <--------->+ | | | | | | | | | +------------+ | | +------------+ | | | | | | +->| v3MP * |<--->| | User-based | | | | | Transport | | | +------------+ | | | Security | | | | | Mapping | | | +------------+ | | | Model | | | | | (e.g RFC1906) | | +->| otherMP * |<--->| +------------+ | | | +-------------------+ | +------------+ | | | | | ^ +---------------------+ +----------------+ | | | | | v | +-------------------------------------------------------------------+ +-----+ +-----+ +-------+ | UDP | | IPX | . . . | other | +-----+ +-----+ +-------+ ^ ^ ^ | | | v v v +------------------------------+ | Network | +------------------------------+ 3.1.3.2. SNMPエージェント 一つ以上のコマンド応答機能と/や(関連するSNMPエンジンとともに)通知発 信機能アプリケーションを含むSNMPエンティティは伝統的にSNMPエージェ ントと呼ばれる。 +------------------------------+ | Network | +------------------------------+ ^ ^ ^ | | | v v v +-----+ +-----+ +-------+ | UDP | | IPX | . . . | other | +-----+ +-----+ +-------+ (traditional SNMP agent) +-------------------------------------------------------------------+ | ^ | | | +---------------------+ +----------------+ | | | | Message Processing | | Security | | | Dispatcher v | Subsystem | | Subsystem | | | +-------------------+ | +------------+ | | | | | | Transport | | +->| v1MP * |<--->| +------------+ | | | | Mapping | | | +------------+ | | | Other | | | | | (e.g. RFC1906) | | | +------------+ | | | Security | | | | | | | +->| v2cMP * |<--->| | Model | | | | | Message | | | +------------+ | | +------------+ | | | | Dispatcher <--------->| +------------+ | | +------------+ | | | | | | +->| v3MP * |<--->| | User-based | | | | | | | | +------------+ | | | Security | | | | | PDU Dispatcher | | | +------------+ | | | Model | | | | +-------------------+ | +->| otherMP * |<--->| +------------+ | | | ^ | +------------+ | | | | | | +---------------------+ +----------------+ | | v | | +-------+-------------------------+---------------+ | | ^ ^ ^ | | | | | | | v v v | | +-------------+ +---------+ +--------------+ +-------------+ | | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY * | | | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | | | application | | | | applications | | application | | | +-------------+ +---------+ +--------------+ +-------------+ | | ^ ^ | | | | | | v v | | +----------------------------------------------+ | | | MIB instrumentation | SNMP entity | +-------------------------------------------------------------------+ 3.2. 識別子の命名 principal ^ | | +----------------------------|-------------+ | SNMP engine v | | +--------------+ | | | | | | +-----------------| securityName |---+ | | | Security Model | | | | | | +--------------+ | | | | ^ | | | | | | | | | v | | | | +------------------------------+ | | | | | | | | | | | Model | | | | | | Dependent | | | | | | Security ID | | | | | | | | | | | +------------------------------+ | | | | ^ | | | | | | | | +-------------------------|----------+ | | | | | | | +----------------------------|-------------+ | v network 3.2.1. 主体 主体は提供されたサービスや処理が生じたサービスの対象となる「人」で ある。 A principal is the "who" on whose behalf services are provided or processing takes place. 主体は特定の役割の中で振舞う個人であり、特定の役割の中で振舞う個人 の集合であり、アプリケーションやアプリケーションの集合であり、それ らの組み合わせであろう。 3.2.2. securityName securityNameは人間が読むことのできる主体を表している文字列である。 これはモデルに依存しないフォーマットを持ち、特定のセキュリティモデ ル外で用いられるだろう。 3.2.3. モデル依存のsecurity ID モデル依存のsecurity IDは特定のモデル内で使われるモデル特有の securityNameの表現である。 モデル依存のsecurity IDは人間が読むことができるかも知れないし、でき ないかも知れない。そして、モデル依存のシンタックスを持つ。例はコミュ ニティ名とユーザ名を含む。 モデル依存のsecuirty IDのsecurityNameへの変換とその逆は関連するセキュ リティモデルに責任がある。 3.3. 管理情報の命名 管理情報はコマンド応答アプリケーションが潜在的に様々なコンテキスト へのローカルアクセスを持ったSNMPエンティティにある。このアプリケー ションはSNMPエンジンに関連するsnmpEngineIDに等しいcontextEngineIDを 用いる。 +-----------------------------------------------------------------+ | SNMP entity (identified by snmpEngineID, example: abcd) | | | | +------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +-------------+ +------------+ +-----------+ +-----------+ | | | | | | | | | | | | | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | | | | | | | | | | | | | +-------------+ +------------+ +-----------+ +-----------+ | | | | | | | +------------------------------------------------------------+ | | | | +------------------------------------------------------------+ | | | Command Responder Application | | | | (contextEngineID, example: abcd) | | | | | | | | example contextNames: | | | | | | | | "bridge1" "bridge2" "" (default) | | | | --------- --------- ------------ | | | | | | | | | | +------|------------------|-------------------|--------------+ | | | | | | | +------|------------------|-------------------|--------------+ | | | MIB | instrumentation | | | | | | +---v------------+ +---v------------+ +----v-----------+ | | | | | context | | context | | context | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | bridge MIB | | | | bridge MIB | | | | some MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | | | | | +------------+ | | | | | | | | | | | other MIB | | | | | | | | | | | +------------+ | | | | | | | | | | | | | +-----------------------------------------------------------------+ 3.3.1. SNMPコンテキスト SNMPコンテキスト、あるいは省略してただ「コンテキスト」、はSNMPエン ティティによってアクセス可能な管理情報の集合である。管理情報の項目 は一つ以上のコンテキストに存在するかもしれない。SNMPエンティティは 潜在的に多くのコンテキストへのアクセスを持つ。 典型的に、管理ドメイン内にはそれぞれの管理オブジェクトの型の多くの インスタンスがある。簡潔さのため、MIBモジュールによって特定されたイ ンスタンスを識別するためのメソッドは、管理ドメイン内の全てのインス タンスの集合の中からそれぞれのインスタンスを区別することはできない。 それどころか、それぞれのインスタンスはある範囲や「コンテキスト」内、 管理ドメイン内の様々なコンテキストがあるところだけで識別される。し ばしば、コンテキストは物理的なデバイスであったり、あるいは、おそら く論理的なデバイスであるが、コンテキストは様々なデバイスや単一のデ バイスのサブセットや様々なデバイスのサブセットでさえも網羅すること もできる。しかし、コンテキストは常に単一のSNMPエンティティのサブセッ トとして定義されている。それゆえ、管理ドメイン内の管理情報の個々の 項目を識別するために、オブジェクトの型とインスタンスに加えて contextNameとcontextEngineIDが識別されなければならない。 例えば、管理オブジェクト型のifDescr [RFC2233]はネットワークインター フェースの説明として定義されている。デバイスXの最初のネットワークイ ンターフェースの説明を識別するために、4個の情報が必要となる。デバイ スXの管理情報へのアクセスを提供するSNMPエンティティのsnmpEngineID、 デバイスXのcontextName、管理オブジェクト型(ifDescr)、そしてインスタ ンス("1")である。 それぞれのコンテキストは管理ドメイン内で(少なくとも)一つの一意な識 別子を持つ。管理情報の同じ項目は様々なコンテキスト内に存在すること ができる。管理情報の一つの項目が様々な一意の識別子を持つかもしれな い。これは管理情報の項目が様々なコンテキスト内に存在する時に起こる。 そして、これはコンテキストが様々な一意の識別子を持つ時にも起こる。 contextEngineIDとcontextNameの組み合わせが運用ドメイン内のコンテキ ストを明確に識別する。ただし、同じコンテキストを明確に識別する contextEngineIDとcontextNameの様々で一意な組み合わせが存在するかも 知れない点に注意が必要である。 3.3.2. contextEngineID 運用ドメイン内において、特定のcontextNameを用いたコンテキストのイン スタンスを実現するかもしれないSNMPエンティティをcontextEngineIDが一 意に識別する。 3.3.3. contextName contextNameはcontextを命名するために用いられる。それぞれの contextNameはSNMPエンティティ内で一意で「なければならない」。 3.3.4. scopedPDU scopedPDUはcontextEngineID、contextName、そしてPDUを含んだデータブ ロックである。 PDUは、運用ドメイン内でcontextEngineIDとcontextNameの組み合わせによっ て明確に識別されたコンテキスト内の命名された情報を含むSNMPのプロト コルデータユニットである。SNMP PDUについての詳細な情報は例えば RFC1905を参照のこと。 3.4. Other Constructs 3.4.1. maxSizeResponseScopedPDU maxSizeResponseScopedPDUはPDUの送信側が受信することを望むであろう scopedPDUの最大サイズである。scopedPDUのサイズはSNMPメッセージのヘッ ダのサイズを含まないという点に注意が必要である。 3.4.2. ローカル設定データストア SNMPエンティティ内にあるサブシステム、モデル、そしてアプリケーショ ンは自身の設定情報の集合を保持することを必要とするかもしれない。 設定情報には管理オブジェクトとしてアクセス可能な部分があるかもしれ ない。 これらの情報の集合はエンティティのローカル設定データストアとして参 照される。 3.4.3. securityLevel このアーキテクチャーは3つのレベルのセキュリティを認識する。それは - 認証なし、プライバシーなし(noAuthNoPriv) - 認証あり、プライバシーなし(authNoPriv) - 認証あり、プライバシーあり(authPriv) これらの3つの値はnoAuthNoPrivはauthNoPrivより低く、authNoPrivは authPrivより低いというように順序づけられる。 全てのメッセージはsecurityLevelに関連させられる。全てのサブシステム (メッセージ処理、セキュリティ、アクセス制御)とアプリケーションは、 メッセージとコンテンツの処理をしている間にsecurityLevelの値を与える か、与えられたsecurityLevelの値によって従うことのどちらかを「要求」 される。 4. 抽象サービスインターフェース 抽象サービスインターフェースはSNMPエンティティ内の様々なサブシステ ム間の概念上のインターフェースを説明するために定義されている。抽象 サービスインターフェースは外に観察できるSNMPエンティティの振舞いを 明らかにするのを助けることを意図されており、無理に実装の構造や組織 を抑制するようには全く意図されていない。さらに明確に、それらはAPIや APIの要求の宣言として受けとられるべきではない。 これらの抽象サービスインターフェースは提供されるサービスを定義する プリミティブとサービスが実行される時に渡されるべき抽象データ要素の 集合によって定義されている。この章では様々なサブシステムのために定 義されているプリミティブを示す。 4.1. ディスパッチャプリミティブ ディスパッチャは典型的にPDUディスパッチャを経由してSNMPアプリケーショ ンにサービスを提供する。この章ではPDUディスパッチャによって提供され るプリミティブを説明する。 4.1.1. 出力するリクエストや通知の生成 PDUディスパッチャはSNMPアプリケーションが他のSNMPエンティティにSNMP リクエストや通知を送るために以下のプリミティブを提供する。 statusInformation = -- 成功したらsendPduHandle -- 失敗したらerrorIndication sendPdu( IN transportDomain -- 使用されるtransportドメイン IN transportAddress -- 使用されるtransportアドレス IN messageProcessingModel -- 典型的にSNMPのバージョン IN securityModel -- 使用するセキュリティモデル IN securityName -- この主体の代表 IN securityLevel -- 要求されたセキュリティレベル IN contextEngineID -- このエンティティから/でのデータ IN contextName -- このコンテキストから/へのデータ IN pduVersion -- PDUのバージョン IN PDU -- SNMP Protocol Data Unit IN expectResponse -- 真か偽 ) 4.1.2. 入力してくるリクエストや通知のPDUの処理 PDUディスパッチャは入力してくるSNMP PDUをアプリケーションに渡すため に以下のプリミティブを提供する。 processPdu( -- リクエスト/通知PDUの処理 IN messageProcessingModel -- 典型的にSNMPのバージョン IN securityModel -- 使用しているセキュリティモデル IN securityName -- この主体の代表 IN securityLevel -- セキュリティレベル IN contextEngineID -- このエンティティから/でのデータ IN contextName -- このコンテキストから/へのデータ IN pduVersion -- PDUのバージョン IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- リクエストPDUの最大サイズ IN stateReference -- 応答送信時に必要とされる状態の ) -- 情報への参照 4.1.3. 出力する応答の生成 PDUディスパッチャはアプリケーションがSNMP応答PDUをPDUディスパッチャ に返すために以下のプリミティブを提供する。 result = -- 成功か失敗 returnResponsePdu( IN messageProcessingModel -- 典型的にSNMPのバージョン IN securityModel -- 使用しているセキュリティモデル IN securityName -- この主体の代表 IN securityLevel -- 入ってきているリクエストと同じ IN contextEngineID -- このエンティティから/でのデータ IN contextName -- このコンテキストから/へのデータ IN pduVersion -- PDUのバージョン IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- 送信側が受信できる最大サイズ IN stateReference -- リクエストについて示された情報 -- への参照 IN statusInformation -- 成功か、エラーの場合には ) -- errorIndicationのOIDかその値 4.1.4. 入力してくる応答PDUの処理 PDUディスパッチャは入力してくるSNMPリクエストPDUをアプリケーション に渡すために以下のプリミティブを提供する。 processResponsePdu( -- 応答PDUを処理する IN messageProcessingModel -- 典型的にSNMPのバージョン IN securityModel -- 使用しているセキュリティモデル IN securityName -- この主体の代表 IN securityLevel -- セキュリティモデル IN contextEngineID -- このエンティティから/でのデータ IN contextName -- このコンテキストから/へのデータ IN pduVersion -- PDUのバージョン IN PDU -- SNMP Protocol Data Unit IN statusInformation -- 成功かerrorIndication IN sendPduHandle -- sendPduから処理する ) 4.1.5. SNMP PDUを扱うための責任の登録 アプリケーションは以下のプリミティブに従ったPDUディスパッチャによっ て特定のcontextEngineIDやpduTypeのための責任を登録/削除することがで きる。アプリケーションが登録することができる特定のpduTypeの表は、 PDUディスパッチャを含むSNMPエンティティによってサポートされるメッセー ジ処理モデルによって決定される。 statusInformation = -- 成功かerrorIndication registerContextEngineID( IN contextEngineID -- 責任を追う対象のcontextEngineID IN pduType -- 登録されるべきpduType ) unregisterContextEngineID( IN contextEngineID -- このcontextEngineIDの責任を返上 IN pduType -- 削除されるべきpduType ) registerContextEngineIDとunregisterContextEngineIDの抽象サービスイ ンターフェースの実現は、アプリケーションが全ての考えられる contextEngineIDとpduTypeのパラメータの値の責任を登録/削除するための 実装に依存する方法を提供するかもしれない点に注意が必要である。 4.2. メッセージ処理サブシステムのプリミティブ ディスパッチャはメッセージ処理モデルと相互作用してSNMPメッセージの 特定のバージョンを処理する。この章ではメッセージ処理サブシステムに よって提供されるプリミティブを説明する。 4.2.1. 出力するSNMPリクエストや通知メッセージの準備 メッセージ処理サブシステムは出力するSNMPリクエストや通知メッセージ のためにこのサービスプリミティブを提供する。 statusInformation = -- 成功かerrorIndication prepareOutgoingMessage( IN transportDomain -- 使用されるtransportドメイン IN transportAddress -- 使用されるtransportアドレス IN messageProcessingModel -- 典型的にSNMPのバージョン IN securityModel -- 使用するセキュリティモデル IN securityName -- この主体の代表 IN securityLevel -- 要求されたセキュリティレベル IN contextEngineID -- このエンティティから/でのデータ IN contextName -- このコンテキストから/へのデータ IN pduVersion -- PDUのバージョン IN PDU -- SNMP Protocol Data Unit IN expectResponse -- 真か偽 IN sendPduHandle -- 入力してくる応答を比較するため -- の手がかり OUT destTransportDomain -- 受信transportドメイン OUT destTransportAddress -- 受信transportアドレス OUT outgoingMessage -- 送信するメッセージ OUT outgoingMessageLength -- その長さ ) 4.2.2. 出力するSNMP応答メッセージの準備 メッセージ処理サブシステムは出力するSNMPレスポンスメッセージを準備 するためにこのサービスプリミティブを提供する。 result = -- 成功か失敗 prepareResponseMessage( IN messageProcessingModel -- 典型的にSNMPのバージョン IN securityModel -- 入力してくるリクエストと同じ IN securityName -- 入力してくるリクエストと同じ IN securityLevel -- 入力してくるリクエストと同じ IN contextEngineID -- このエンティティから/でのデータ IN contextName -- このコンテキストから/へのデータ IN pduVersion -- PDUのバージョン IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- 受信可能な最大サイズ IN stateReference -- リクエストについて示された情報 -- への参照 IN statusInformation -- 成功か、エラーの場合には -- errorIndicationのOIDかその値 OUT destTransportDomain -- 受信transportドメイン OUT destTransportAddress -- 受信transportアドレス OUT outgoingMessage -- 送信するメッセージ OUT outgoingMessageLength -- その長さ ) 4.2.3. 入力してくるSNMPメッセージからデータ要素の準備 メッセージ処理サブシステムは入力してくるSNMPメッセージから抽象デー タ要素を準備するためにこのサービスプリミティブを提供する。 result = -- 成功かerrorIndication prepareDataElements( IN transportDomain -- もともとのtransportドメイン IN transportAddress -- もともとのtransportアドレス IN wholeMsg -- ネットワークから受信したときの IN wholeMsgLength -- ネットワークから受信したときの OUT messageProcessingModel -- 典型的にSNMPのバージョン OUT securityModel -- 使用するセキュリティモデル OUT securityName -- この主体の代表 OUT securityLevel -- 要求されたセキュリティレベル OUT contextEngineID -- このエンティティから/でのデータ OUT contextName -- このコンテキストから/へのデータ OUT pduVersion -- PDUのバージョン OUT PDU -- SNMP Protocol Data Unit OUT pduType -- SNMP PDUタイプ OUT sendPduHandle -- 一致したリクエストの手がかり OUT maxSizeResponseScopedPDU -- 送信側が受信できる最大サイズ OUT statusInformation -- 成功か、エラーの場合には -- errorIndicationのOIDかその値 OUT stateReference -- 可能な応答のために使われる状態 -- の情報への参照 ) 4.3. アクセス制御サブシステムプリミティブ アプリケーションはアクセス制御サブシステムのサービスの典型的なクラ イアントである。 以下のプリミティブはアクセスが許可されるかどうかをチェックするため に、アクセス制御サブシステムによって提供される。 statusInformation = -- 成功かerrorIndication isAccessAllowed( IN securityModel -- 使用しているセキュリティモデル IN securityName -- アクセスしようとする主体の代表 IN securityLevel -- セキュリティレベル IN viewType -- 読み、書き、通知のビュー IN contextName -- variableNameを含むcontext IN variableName -- 管理オブジェクトのOID ) 4.4. セキュリティサブシステムプリミティブ メッセージ処理サブシステムはセキュリティサブシステムのサービスの典 型的なクライアントである。 4.4.1. リクエストや通知メッセージの生成 セキュリティサブシステムはリクエストや通知メッセージを生成するため に以下のプリミティブを提供する。 statusInformation = generateRequestMsg( IN messageProcessingModel -- 典型的にSNMPのバージョン IN globalData -- メッセージヘッダ、管理データ IN maxMessageSize -- 送信側のSNMPエンティティの IN securityModel -- 出力するメッセージのための IN securityEngineID -- SNMPエンティティの権限 IN securityName -- この主体の代表 IN securityLevel -- 要求されたセキュリティレベル IN scopedPDU -- メッセージ(平文)ペイロード OUT securityParameters -- セキュリティモデルによって満た -- された OUT wholeMsg -- 完全に生成されたメッセージ OUT wholeMsgLength -- 生成されたメッセージの長さ ) 4.4.2. 入力してくるメッセージの処理 セキュリティサブシステムは入力してくるメッセージを処理するために、 以下のプリミティブを提供する。 statusInformation = -- 成功か、エラーの場合には -- errorIndicationのOIDかその値 processIncomingMsg( IN messageProcessingModel -- 典型的にSNMPのバージョン IN maxMessageSize -- 送信側のSNMPエンティティの IN securityParameters -- 受信したメッセージのための IN securityModel -- 受信したメッセージのための IN securityLevel -- セキュリティレベル IN wholeMsg -- ネットワークから受信したときの IN wholeMsgLength -- ネットワークから受信したときの長さ OUT securityEngineID -- この主体の識別子 OUT securityName -- この主体の識別子 OUT scopedPDU, -- メッセージ(平文)ペイロード OUT maxSizeResponseScopedPDU -- 送信側が扱うことができる最大サ -- イズ OUT securityStateReference -- 応答に必要とされるセキュリティ -- 状態の情報への参照 4.4.3. 応答メッセージの生成 セキュリティサブシステムは応答メッセージを生成するために、以下のプ リミティブを提供する。 statusInformation = generateResponseMsg( IN messageProcessingModel -- 典型的にSNMPのバージョン IN globalData -- メッセージヘッダ、管理データ IN maxMessageSize -- 送信側のSNMPエンティティの IN securityModel -- 出力するメッセージのための IN securityEngineID -- SNMPエンティティの権限 IN securityName -- この主体の代表 IN securityLevel -- 出力するメッセージのための IN scopedPDU -- メッセージ(平文)ペイロード IN securityStateReference -- もとのリクエストからセキュリティ -- の状態の情報への参照 OUT securityParameters -- セキュリティモデルによって満た -- された OUT wholeMsg -- 完全に生成されたメッセージ OUT wholeMsgLength -- 生成されたメッセージの長さ ) 4.5. 共通のプリミティブ これらのプリミティブは様々なサブシステムによって提供されている。 4.5.1. 状態を参照している情報の解放 stateReference情報を渡す全てのサブシステムは参照された状態の情報を 持つメモリを解放するためのプリミティブも提供する。 stateRelease( IN stateReference -- 解放される参照のてがかり ) 4.6. シナリオ・ダイアグラム 4.6.1. コマンド生成機能や通知発信機能 このダイアグラムはコマンド生成機能や通知発信機能のアプリケーション が送られるPDUのリクエストをどのように行うのかとどのように(同期して) アプリケーションへ応答が返されるのかを示している。 コマンド ディスパッチャ メッセージ セキュリティ 生成機能 | 処理モデル モデル | | | | | sendPdu | | | |------------------->| | | | | prepareOutgoingMessage | | : |----------------------->| | : | | generateRequestMsg | : | |-------------------->| : | | | : | |<--------------------| : | | | : |<-----------------------| | : | | | : |------------------+ | | : | Send SNMP | | | : | Request Message | | | : | to Network | | | : | v | | : : : : : : : : : : : : : : : : | | | | : | Receive SNMP | | | : | Response Message | | | : | from Network | | | : |<-----------------+ | | : | | | : | prepareDataElements | | : |----------------------->| | : | | processIncomingMsg | : | |-------------------->| : | | | : | |<--------------------| : | | | : |<-----------------------| | | processResponsePdu | | | |<-------------------| | | | | | | 4.6.2. コマンド応答機能アプリケーションのシナリオ・ダイアグラム このダイアグラムはコマンド応答機能や通知受信機能のアプリケーション がpduTypeを扱うためにどのように登録するかと、SNMPメッセージが受信さ れた後にどのようにPDUがアプリケーションに送られるのか、そしてどのよ うに(同期して)応答がネットワークへ返されるのかを示している コマンド ディスパッチャ メッセージ セキュリティ 生成機能 | 処理モデル モデル | | | | | registerContextEngineID | | | |------------------------>| | | |<------------------------| | | | | | Receive SNMP | | | : | Message | | | : | from Network | | | : |<-------------+ | | : | | | : |prepareDataElements | | : |------------------->| | : | | processIncomingMsg | : | |------------------->| : | | | : | |<-------------------| : | | | : |<-------------------| | | processPdu | | | |<------------------------| | | | | | | : : : : : : : : | returnResponsePdu | | | |------------------------>| | | : | prepareResponseMsg | | : |------------------->| | : | |generateResponseMsg | : | |------------------->| : | | | : | |<-------------------| : | | | : |<-------------------| | : | | | : |--------------+ | | : | Send SNMP | | | : | Message | | | : | to Network | | | : | v | | 5. SNMP管理フレームワークの管理オブジェクト定義 SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, snmpModules FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; snmpFrameworkMIB MODULE-IDENTITY LAST-UPDATED "9901190000Z" -- 19 January 1999 ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-EMail: snmpv3@tis.com Subscribe: majordomo@tis.com In message body: subscribe snmpv3 Chair: Russ Mundy TIS Labs at Network Associates postal: 3060 Washington Rd Glenwood MD 21738 USA EMail: mundy@tis.com phone: +1 301-854-6889 Co-editor Dave Harrington Cabletron Systems, Inc. postal: Post Office Box 5005 Mail Stop: Durham 35 Industrial Way Rochester, NH 03867-5005 USA EMail: dbh@ctron.com phone: +1 603-337-7357 Co-editor Randy Presuhn BMC Software, Inc. postal: 965 Stewart Drive Sunnyvale, CA 94086 USA EMail: randy_presuhn@bmc.com phone: +1 408-616-3100 Co-editor: Bert Wijnen IBM T.J. Watson Research postal: Schagen 33 3461 GL Linschoten Netherlands EMail: wijnen@vnet.ibm.com phone: +31 348-432-794 " DESCRIPTION "SNMP管理アーキテクチャーMIB" -- Revision History REVISION "9901190000Z" -- 19 January 1999 DESCRIPTION "著者の住所を更新、誤植を修正。 RFC2571として公開。 " REVISION "9711200000Z" -- 20 November 1997 DESCRIPTION "初版。RFC 2271として公開。 " ::= { snmpModules 10 } -- SNMP管理アーキテクチャーで用いられる文字列表記法 SnmpEngineID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "SNMPエンジンの運用的に一意な識別子。この型のオブジェ クトは識別子用で、表記のためではない、たとえ、表記 が特定の値の生成に使われるかもしれないことが可能で あったとしても。 このオブジェクトの値は全てゼロや全て'ff'Hや空(長さ 0)の文字列でないとは限らないかもしれない。 このオブジェクトの初期値はオペレータコンソールの入 力やアルゴリズムの関数経由で設定されるかもしれない。 後者の場合、以下の例のアルゴリズムが推奨される。 単一のシステムに様々なエンジンがある場合、このアル ゴリズムの使用は「適切ではない」。全てのエンジンが 同じID値を持つという結果になるからである。 1) まさに最初のbitがどのくらいのデータの残りが組み 立てられているのかを指し示すのに使われている。 0 - SNMPv3以前に存在していた方式を使って企業に よって定義されている。下記の項目2を参照。 1 - このアーキテクチャーで定義されている。下記 の項目3を参照。 これは存在しているengineID(AgentIDとしても知ら れている [RFC1910])の利用が他の新しい利用と共存 することができることに注意が必要である。 2) snmpEngineIDは12オクテット長を持つ。 最初の4オクテットはIANAによって割り当てられたエー ジェントのSNMP管理プライベートエンタープライズ 番号のバイナリ値にセットされる。 例えば、Acme Networksは{ enterprises 696 }を割 り当てられており、最初の4オクテットは '000002b8'Hに割り当てられるだろう。 残りの8オクテットは一つ以上のエンタープライズ特 有の方式で決定される。そのような方式はこのオブ ジェクトの値がエージェントの運用ドメイン内で一 意であるであろう可能性を最大にするために設計さ れていなければならない。 例えば、それはSNMPエンティティのIPアドレスかも しれないし、それぞれのアドレスに適切にランダム のオクテットが詰められたインターフェースのMACア ドレスかもしれない。 3) オクテット文字列の長さが変わる。 最初の4オクテットはIANAによって割り当てられたエー ジェントのSNMP管理プライベートエンタープライズ 番号のバイナリ値にセットされる。 例えば、Acme Networksは{ enterprises 696 }を割 り当てられており、最初の4オクテットは '000002b8'Hに割り当てられるだろう。 まさに最初のbitは1にセットされる。例えば、上の Acme Networksを表す値は今度は'800002b8'Hに変わ る。 5オクテットはフォーマットされた残り(6番目以降の オクテット)を指し示す。5オクテットの値は 0 - 予約済、未使用。 1 - IPv4アドレス(4オクテット) 最も小さな普通のIPアドレス。 2 - IPv6アドレス(16オクテット) 最も小さな普通のIPアドレス。 3 - MACアドレス(6オクテット) 最も小さなIEEE MACアドレス。正順。 4 - テキスト。運用上、割り当てられた最大 残り長 27。 5 - オクテット。運用上、割り当てられた最 大残り長 27。 6-127 - 予約済、未使用。 127-255 - 企業に定義された最大残り長 27。 " SYNTAX OCTET STRING (SIZE(5..32)) SnmpSecurityModel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "SNMP管理アーキテクチャー内のセキュリティサブシステ ムのsecurityModelを一意に識別する識別子。 securityModelを示す値は以下のように割り当てられて いる。 - 0は予約されている。 - 1から255の値は標準化トラックのセキュリティモデル のために包含的に予約されており、IANAによって管理 されている。 - 255より大きい値は企業特有のセキュリティモデルに 包含的に割り当てられている。企業特有のセキュリティ モデルの値は下記を満たすように定義されている。 enterpriseID * 256 + 企業内のセキュリティモデル 例えば、enterpriseIDが1の企業によって定義された4 番目のセキュリティモデルの値は260となる。 このセキュリティモデルの値の割り当てスキーマは最大 255の標準に基づいたセキュリティモデルと、企業に対 して最大255のセキュリティモデルを考慮する。 新しいセキュリティモデルの値の割り当てが実際は滅多 にないということが信じられている。なぜなら同時に利 用されるセキュリティモデルの数が増えると、相互運用 性が損なわれる機会が増えるからであろう。 よって、そのような範囲は充分であるだろうと信じられ る。 標準委員会がこの番号が時が経つにつれ不充分になると いうことに気づいたという見込みのない出来事の中で、 enterprise番号はさらに255の可能な値を得るために割 り当てられるかもしれない。 最上位のビットは0でなければならない点に注意が必要 である。そのため、23ビットは様々な組織が標準でない セキュリティモデルを設計し定義するために割り当てら れる。これはセキュリティモデルの新しい所有者の実装 を定義する能力を最初の8,388,608の企業に制限する。 符号化された形式でセキュリティモデルの値は通常1バ イトだけを必要とする。そのため、実際にはほとんどの メッセージでは最も左のビットは0になり、記号の拡張 は符号規則によって抑えられる。以上に注意することは 価値がある。 今まで述べてきたように、セキュリティモデルの値には、 SNMPで使うために定義されたもの、あるいはサポートさ れるMIBオブジェクトで使うために予約されたものがあ る。それは下記の通りである。 0 'any'として予約 1 SNMPv1用に予約 2 SNMPv2c用に予約 3 User-Based Security Model (USM) " SYNTAX INTEGER(0 .. 2147483647) SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "SNMP管理アーキテクチャー内のメッセージ処理サブシス テムのメッセージ処理モデルを一意に識別する識別子。 messageProcessingModelの値は下記のように割り当てら れる。 - 0から255の値は標準化トラックのメッセージ処理モデ ルのために包含的に予約されており、IANAによって管 理されている。 - 255より大きな値は企業特有のメッセージ処理モデル のために割り当てられている。企業特有の messageProcessingModelの値は下記を満たすように定 義されている。 enterpriseID * 256 + messageProcessingModelがenterprise内に収ま る 例えば、enterpriseIDが1の企業によって定義された4 番目のメッセージ処理モデルの値は260となる。 このmessageProcessingModelの値の割り当てスキーマは 最大255の標準に基づいたメッセージ処理モデルと、企 業に対して最大255のメッセージ処理モデルを考慮する。 新しいmessageProcessingModelの値の割り当てが実際は 滅多にないということが信じられている。なぜなら、同 時に利用されるメッセージ処理モデルの数が増えると相 互運用性が損なわれる機会が増えるからであろう。よっ て、そのような範囲は充分であろうと信じられている。 標準委員会がこの番号が時が経つにつれ不充分になると いうことに気づいた見込みの中でenterprise番号はさら に256の可能な値を得るために割り当てるかもしれない。 最上位のビットは0でなければならない点に注意が必要 である。そのため、23ビットは様々な組織が標準でない messageProcessingModelsを設計し定義するために割り 当てられる。これはメッセージ処理モデルの所有者の実 装を定義する能力を最初の8,388,608の企業に制限する。 符号化された形式では、messageProcessingModelの値は 通常1バイトだけを必要とする。そのため、実際にはほ とんどのメッセージでは最も左のビットは0となり、記 号の拡張は符号規則によって抑えられる。以上に注意す ることは価値がある。 以上のように、SNMPで使うために定義された messageProcessingModelは様々な値をとる。それは下記 の通りである。 0 SNMPv1用に予約 1 SNMPv2c用に予約 2 SNMPv2uとSNMPv2*用に予約 3 SNMPv3用に予約 " SYNTAX INTEGER(0 .. 2147483647) SnmpSecurityLevel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "SNMPメッセージが送信される、あるいは処理されるオペ レーションのセキュリティレベル。以下の値をとる。 noAuthNoPriv - 認証なし、プライバシーなし authNoPriv - 認証あり、プライバシーなし authPriv - 認証あり、プライバシーあり これらの3つの値はnoAuthNoPrivはauthNoPrivよりも弱 く、authNoPrivはauthPrivよりも弱いというように順序 づけられる。 " SYNTAX INTEGER { noAuthNoPriv(1), authNoPriv(2), authPriv(3) } SnmpAdminString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "運用情報を含むオクテット文字列で、人が読むことので きる形式が好ましい。 国際化を推進するために、この情報はISO/IEC IS文字セッ トを使って表される。これは[RFC2279]で説明されてい るUTF-8変換フォーマットを用いたオクテット文字列と して符号化される。 時々、10646標準への修正案によって付加コード番号が 追加されているので、実装は0x00000000から0x7fffffff までのあらゆるコード番号に遭遇する準備がされなけれ ばならない。 コード番号の妥当なUTF-8符号化に対応しない、あるい はこの範囲外のバイトシーケンスは禁止される。 制御コードの使用は避けるべきである。 改行を表す必要がある時、制御コードのシーケンスであ るCR LFが使われるべきである。 先頭や最後のスペースは避けるべきである。 ユーザインターフェースハードウェアやソフトウェアに よって直接サポートされていないコード番号のために、 16進法のような入力や表示の大体手段が提供されるかも 知れない。 7ビットUS-ASCIIで符号化された情報のために、UTF-8符 号化はUS-ASCII符号化と全く同じである。 UTF-8は1文字/コード番号を表すために複数バイトを必 要とするかもしれない。したがって、このオクテットに よるこのオブジェクトの長さは符号化された文字数とは 異なるかも知れない。同様に、長さの制約は符号化され たオクテット、符号化によって表された文字列の数では ない、に言及するかも知れない、 インデックスとして使われる、あるいは使われようと考 えられているオブジェクトを表すのにこのTCが使われる時、 オブジェクトインスタンスを表すサブ識別子の数が [RFC1905]で定義されている128という制限を越えないよ うにサイズ制限が「指定されなければならない」。 SnmpAdminStringオブジェクトのサイズはオクテットで 計算され、文字列としてではないことに注意が必要であ る。 " SYNTAX OCTET STRING (SIZE (0..255)) -- Administrative assignments *************************************** snmpFrameworkAdmin OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 } snmpFrameworkMIBObjects OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 } snmpFrameworkMIBConformance OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 } -- the snmpEngine Group ******************************************** snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 } snmpEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "SNMPエンジンの運用上、一意な識別子。 " ::= { snmpEngine 1 } snmpEngineBoots OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "snmpEngineIDが最後に設定されて以来、SNMPエンジンが (再)初期化された回数。 " ::= { snmpEngine 2 } snmpEngineTime OBJECT-TYPE SYNTAX INTEGER (0..2147483647) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "snmpEngineBootsの値が最後に設定されて以来の秒数。 このオブジェクトの値は増加していくと最大値を越える。 snmpEngineBootsはあたかも再初期化が行われたように 増加し、このオブジェクトの値は結果として0に戻る。 " ::= { snmpEngine 3 } snmpEngineMaxMessageSize OBJECT-TYPE SYNTAX INTEGER (484..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "SNMPエンジンが送受信し処理することのできるSNMPメッ セージのオクテットの最大長で、全てのトランスポート が送受信・処理可能な最大メッセージサイズの値の最小 値として決定される。 " ::= { snmpEngine 4 } -- Registration Points for Authentication and Privacy Protocols ** snmpAuthProtocols OBJECT-IDENTITY STATUS current DESCRIPTION "SNMP管理フレームワークで使われる標準化トラックの 認証プロトコルの登録箇所 " ::= { snmpFrameworkAdmin 1 } snmpPrivProtocols OBJECT-IDENTITY STATUS current DESCRIPTION "SNMP管理フレームワークで使われる標準化トラックの プライバシープロトコルの登録箇所 " ::= { snmpFrameworkAdmin 2 } -- Conformance information ****************************************** snmpFrameworkMIBCompliances OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1} snmpFrameworkMIBGroups OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2} -- compliance statements snmpFrameworkMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "SNMP管理フレームワークMIBを実装するSNMPエンジンの 応諾宣言 " MODULE -- this module MANDATORY-GROUPS { snmpEngineGroup } ::= { snmpFrameworkMIBCompliances 1 } -- units of conformance snmpEngineGroup OBJECT-GROUP OBJECTS { snmpEngineID, snmpEngineBoots, snmpEngineTime, snmpEngineMaxMessageSize } STATUS current DESCRIPTION "設定を識別し決定するオブジェクトと現在の即時のSNMP エンジンの値の集合 " ::= { snmpFrameworkMIBGroups 1 } END 6. IANAの考慮 この文書はIANAによって管理されている3つの番号空間を定義しており、1 つ目はセキュリティモデルに、2つ目はメッセージ処理モデルに、そして3 つ目はSnmpEngineIDフォーマットに割り当てられている。 6.1. セキュリティモデル SnmpSecurityModelのTEXTUAL-CONVENTIONの値はIANAによって管理されてお り、0から255までの範囲を包含的に含む。そしてこれらは標準化トラック のセキュリティモデルのために予約されている。もしこの範囲が将来、不 充分であることが分かるだろう。そのような時にはenterprise番号が割り 当てられることができ、追加の255の可能な値を得る。 このように、SNMPと使うために定義されたり、サポートするMIBオブジェク トと使うために予約されたsecurityModelはいくつかの値をとる。それは次 の通りである。 0 'any'のために予約 1 SNMPv1のために予約 2 SNMPv2cのために予約 3 User-Based Security Model (USM) 6.2. メッセージ処理モデル SnmpMessageProcessingModelのTEXTUAL-CONVENTIONの値はIANAによって管 理されており、0から255までの範囲を包含的に含む。それぞれの値は標準 化トラックのSNMP管理アーキテクチャー内のメッセージ処理サブシステム のメッセージ処理モデルを一意に識別する 将来、この値が不充分であることが分かったら、標準委員会が追加の256の 可能な値を得るためにenterprise番号が得られるかもしれない。 このように、SNMPと使うために定義されたmessageProcessingModelはいく つかの値をとる。それは次の通りである。 0 SNMPv1のために予約 1 SNMPv2cのために予約 2 SNMPv2uとSNMPv2*のために予約 3 SNMPv3のために予約 6.3. SnmpEngineIDフォーマット SnmpEngineIDのTEXTUAL-CONVENTIONの5オクテットはフォーマットの識別子 を含む。IANAによって管理されている値は包含的な6から127の範囲である。 それぞれの値は標準化トラックのSnmpEngineIDフォーマットを一意に識別 する。 7. 知的財産 IETFは知的財産の正当性や範囲、この文書で述べられる技術の実装や使用 に関わると主張される他の権利、そして有効であろうとなかろうとそのよ うな権利の元でのライセンスの範囲については、それがそのようなあらゆ る権利を識別するためのあらゆる努力を示していても、どんな立場もとら ない。標準化トラックのIETFの手続きでの情報の権利の尊重と標準化に関 した文書はBCP-11で見ることができる。 利用可能になった出版のためのコピーの権利の主張、利用可能となったあ らゆるライセンスの保証、そしてこの仕様の実装や利用によるそのような 正しい権利の仕様のための通常のライセンスや許可を得ようという試みの 結果はIETF事務局から得ることができる。 IETFは興味を持ったあらゆる団体にその注意をあらゆるコピーライト、パ テント、パテントのアプリケーション、そしてこの標準化を実行するのに 求められるかも知れない技術を網羅するであろうその他の妥当な権利に持っ ていくように勧める。IETFの実行委員長に情報を送って下さい。 8. 謝辞 この文書はSNMPv3 Working Groupの努力の結果である。下記のSNMPv3 WG メンバーには特に感謝を示す。 Harald Tveit Alvestrand (Maxware) Dave Battle (SNMP Research, Inc.) Alan Beard (Disney Worldwide Services) Paul Berrevoets (SWI Systemware/Halcyon Inc.) Martin Bjorklund (Ericsson) Uri Blumenthal (IBM T.J. Watson Research Center) Jeff Case (SNMP Research, Inc.) John Curran (BBN) Mike Daniele (Compaq Computer Corporation) T. Max Devlin (Eltrax Systems) John Flick (Hewlett Packard) Rob Frye (MCI) Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) David Harrington (Cabletron Systems Inc.) Lauren Heintz (BMC Software, Inc.) N.C. Hien (IBM T.J. Watson Research Center) Michael Kirkham (InterWorking Labs, Inc.) Dave Levi (SNMP Research, Inc.) Louis A Mamakos (UUNET Technologies Inc.) Joe Marzot (Nortel Networks) Paul Meyer (Secure Computing Corporation) Keith McCloghrie (Cisco Systems) Bob Moore (IBM) Russ Mundy (TIS Labs at Network Associates) Bob Natale (ACE*COMM Corporation) Mike O'Dell (UUNET Technologies Inc.) Dave Perkins (DeskTalk) Peter Polkinghorne (Brunel University) Randy Presuhn (BMC Software, Inc.) David Reeder (TIS Labs at Network Associates) David Reid (SNMP Research, Inc.) Aleksey Romanov (Quality Quorum) Shawn Routhier (Epilogue) Juergen Schoenwaelder (TU Braunschweig) Bob Stewart (Cisco Systems) Mike Thatcher (Independent Consultant) Bert Wijnen (IBM T.J. Watson Research Center) この文書はSNMP Advisory TeamへのIETFのセキュリティと運用フレームワー クの進化の推奨に基づいている。SNMP Advisory Teamのメンバーは以下の 通りである。 David Harrington (Cabletron Systems Inc.) Jeff Johnson (Cisco Systems) David Levi (SNMP Research Inc.) John Linn (Openvision) Russ Mundy (Trusted Information Systems) chair Shawn Routhier (Epilogue) Glenn Waters (Nortel) Bert Wijnen (IBM T. J. Watson Research Center) Advisory TeamとSNMPv3 Working Group Charterによって薦められたように、 設計はできるだけ以前のRFCやドラフトからの実用を織り込んだ。結果とし て、SNMPv2u、SNMPv2*として知られている以前の設計の著者たちにも特に 感謝を捧げる。 Jeff Case (SNMP Research, Inc.) David Harrington (Cabletron Systems Inc.) David Levi (SNMP Research, Inc.) Keith McCloghrie (Cisco Systems) Brian O'Keefe (Hewlett Packard) Marshall T. Rose (Dover Beach Consulting) Jon Saperia (BGS Systems Inc.) Steve Waldbusser (International Network Services) Glenn W. Waters (Bell-Northern Research Ltd.) 9. セキュリティの考慮 この文書はどのようにして実装が管理メッセージを保護するためにセキュ リティモデルを含み、管理情報へのアクセスを制御するためにアクセス制 御モデルを含むのか説明する。 提供されるセキュリティのレベルは、使われている特定のセキュリティモ デルの実装と特定のアクセス制御モデルの実装によって決定される。 アプリケーションはセキュアでないデータへアクセスする。アプリケーショ ンはデータの暴露から守るために正当な段階を取る「べきである」。 以下を行うことはは実装の購入者の責任である。 1) 実装はこのアーキテクチャーで定義された規則に応じる。 2) 利用されるセキュリティとアクセス制御モデルは組織に必要とされ るセキュリティとアクセス制御要求を満足させる。 3) モデルとアプリケーションの実装はモデルとアプリケーションの仕 様に応じる。 4) そして実装は不注意な情報開示から設定の機密を保護する。 この文書はまた、MIB定義モジュールも含んでいる。定義されたオブジェク トは書き込み可能ではなく、それらが示す情報は特に実用的であるとは考 えられない。しかしながら、それらが特定の環境において実用的であると 考えられても、それらへのアクセスは適切なセキュリティとアクセス制御 モデルの使用を通して制限されるべきである。 10. 参考文献 [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP- based internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., M. Fedor, M. Schoffstall and J. Davin, "The Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder,, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907 January 1996. [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the SNMP-standard Network Management Framework", RFC 1908, January 1996. [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure for SNMPv2", RFC 1909, February 1996. [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2", RFC 1910, February 1996. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January, 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [BCP-11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2233] McCloghrie, K. and F. Kastenholz. "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997. [RFC2572] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2573] Levi, D. B., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [SNMP-COEX] Frye, R., Levi, D. and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet- standard Network Management Framework", Work in Progress. 11. 著者アドレス Bert Wijnen IBM T.J. Watson Research Schagen 33 3461 GL Linschoten Netherlands Phone: +31 348-432-794 EMail: wijnen@vnet.ibm.com Dave Harrington Cabletron Systems, Inc Post Office Box 5005 Mail Stop: Durham 35 Industrial Way Rochester, NH 03867-5005 USA Phone: +1 603-337-7357 EMail: dbh@ctron.com Randy Presuhn BMC Software, Inc. 965 Stewart Drive Sunnyvale, CA 94086 USA Phone: +1 408-616-3100 Fax: +1 408-616-3101 EMail: randy_presuhn@bmc.com 付録 A A. モデル設計者へのガイドライン この付録はこの文書で定義されたアーキテクチャーに適合することが期待 されるモデルの設計者のためにガイドラインを説明する。 SNMPv1とSNMPv2cはささやかな認証とアクセス制御を提供するためにコミュ ニティを使う二つのSNMPフレームワークである。SNMPv1とSNMPv2cのフレー ムワークはこのアーキテクチャーに沿って設計されたフレームワークと共 存することができる。そして、SNMPv1とSNMPv2cのフレームワークの変更さ れたバージョンはこのアーキテクチャーを満たすように設計される。しか し、この文書は共存のためのガイドラインについては提供しない。 あらゆるサブシステムのモデル内には、他のサブシステムの特定のモデル や、他のサブシステムの特定のモデルで定義されたデータへの参照は、ど のようなものでもあるべきではない。 サブシステム間のデータ転送は熟考の上、固定した抽象データ要素と様々 なモデルの定義の要求を満たすためにオーバーロードされるプリミティブ な機能の集まりとして説明される。 このアーキテクチャー内で使われるモデルを定義する文書は、抽象データ 要素をモデルで利用可能なフォーマットへ変換するための特定の機構を定 義しているサブシステム間の標準のプリミティブを使う「べきである」。 この制約はサブシステムとモデルの文書が共通の境界を認識して書かれる ように存在する。ベンダーは自分たちの実装において、これらの境界を認 識する制約を受けない。 このアーキテクチャーはサブシステム間で提供されるある標準のサービス を定義し、更に、これらのサービスにリクエストするための抽象サービス インターフェースを定義する。 それぞれのサブシステムのモデル定義は標準サービスインターフェースを サポート「すべきである」。しかし、どうやって、あるいはどの程度、 サービスがモデル定義に依存して振舞うのか。 A.1. セキュリティモデル設定の要件 A.1.1. 脅威 セキュリティモデルを説明する文書は、セクション1.4の「このアーキテク チャーのセキュリティ要件」で説明された脅威に対して、どのようにモデ ルが保護するのかを「説明しなければならない。」 A.1.2. セキュリティ処理 受信したメッセージはセキュリティサブシステムのモデルによって正当で あると評価され「なければならない。」正当であるかどうかの評価は、そ れが必要であれば認証とプライバシーの処理を含む。しかし、それは明白 に認証やプライバシーを必要としないメッセージを送ることを許す。 受信したメッセージは処理の過程で必要とされる指定されたセキュリティ レベルを含む。プライバシーを必要とする全てのメッセージも認証を必要 と「しなければならない。」 セキュリティモデルは認証とプライバシーが満たされる規則を指定する。 モデルは追加のセキュリティの特徴を提供するための機構を定義するかも しれない。しかし、モデル定義はサブシステム間でデータ転送をするため にこの文書で定義された抽象データ要素の(可能なサブセット)を使うよう に制約される。 それぞれのセキュリティモデルはモデルの実装内で同時に様々なセキュリ ティプロトコルが使われることが可能になるかもしれない。それぞれのセ キュリティモデルは、与えられたセキュリティレベルとメッセージに関連 するセキュリティパラメータから、使用するプロトコルをどのように決定 するかを定義する。 それぞれのセキュリティモデルは、関連したプロトコルについて送受信す るエンティティがどのように識別されるかとどのように機密が設定される かを定義する。 セキュリティモデルによってサポートされる認証とプライバシープロトコ ルは、オブジェクト識別子によって一意に識別される。認証やプライバシー のためのIETF標準プロトコルはsnmpAuthProtocolsやサブツリーの snmpPrivProtocols内で定義された識別子を持つべきである。Enterprise特 定プロトコル識別子はenterpriseサブツリー内に定義されるべきである。 プライバシーのために、セキュリティモデルはメッセージのどの部分が暗 号化されるかを定義する。 セキュリティに用いられる永続的なデータはSNMPで管理可能であるべきで ある。しかし、セキュリティモデルはMIBのインスタンスが順応の要求であ るかどうかを定義する。 セキュリティモデルはセキュリティサブシステム内で入れ換え可能である。 様々なセキュリティモデルの実装はSNMPエンジン内に同時に存在するかも しれない。SNMPコミュニティによって定義されたセキュリティモデルの数 は、相互運用性を促進するために小さなままであるべきである。 A.1.3. 受信したメッセージにあるセキュリティのスタンプの正当性の評価 メッセージ処理モデルは以下のようなセキュリティモデルを求める。 - メッセージが変更されていないことを確かめる。 - メッセージが生成された主体の識別子を認証する。 - メッセージが暗号化されていればそれを復号する。 追加の要求はモデルによって定義されるかもしれない。そして、追加のサー ビスはモデルによって提供されるかもしれない。しかし、モデルはサブシ ステム間でデータを転送するために以下のプリミティブを使うことを制約 される。実装については制約を受けない。 メッセージ処理モデルは4.4.2章に説明されているように processIncomingMsgプリミティブを用いる。 A.1.4. セキュリティMIB それぞれのセキュリティモデルはサポートされるセキュリティプロトコル のために必要とされるあらゆるMIBモジュールを含むセキュリティの処理に 必要とされるMIBモジュールを定義する。MIBモジュールはMIBモジュールを 利用する手続きに関して同時に定義される「べきである」。MIBモジュール は通常のアクセス制御の規則に依存する。 モデルに依存するセキュリティIDとsecurityName間のマッピングは、もし、 アクセス制御ポリシーがアクセスを認めるのであれば、SNMPを使うことを 決断されるべきである。 A.1.5. キャッシュされたセキュリティデータ 受信したメッセージのために、セキュリティモデルは応答のメッセージが 同じセキュリティ情報を用いて生成される状態の情報をキャッシュする。 たとえ、ローカルの設定データストアが入力のリクエストの時刻と出力の 応答の時間の間に更新されたとしても。 もし、そのようなデータが全く必要とされない場合、メッセージ処理モデ ルには明らかにキャッシュデータを手放す責任がある。これを可能とする ためには、抽象データ要素のsecurityStateReferenceがセキュリティモデ ルからメッセージ処理モデルへ渡される。 キャッシュされたセキュリティデータは応答の世代経由で明らかに手放さ れるかもしれない。あるいは、4.5.1にあるように、stateReleaseプリミティ ブを使うことによって手放される。 A.2. メッセージ処理モデルの設計の要件 SNMPエンジンは様々なメッセージ処理モデルを含むかもしれないメッセー ジ処理サブシステムを含む。 メッセージ処理モデルは常に(概念上)完全なPDUを渡さなければ「ならな い。」すなわち、varBindsの完全なリストを転送しないとは限らない。 The Message Processing Model MUST always (conceptually) pass the complete PDU, i.e., it never forwards less than the complete list of varBinds. A.2.1. ネットワークからのSNMPメッセージの受信 ネットワークからのメッセージを受信した上に、SNMPエンジンのディスパッ チャはSNMPメッセージのバージョンを決定し、抽象データ要素を決定する ためにメッセージ処理モデルに相当するものと協調する。 メッセージ処理モデルは(msgID、msgMaxSize、msgFlags、 msgSecurityParameters、securityModel、そしてsecurityLevelなど)の抽 象データ要素の値をどのように決定するのかをサポートし説明するSNMPメッ セージフォーマットを特定する。メッセージ処理モデルは、4.4.2章に説明 されているように、processIncomingMsgプリミティブを使ってメッセージ にセキュリティ処理を提供するためにセキュリティモデルと協調する。 A.2.2. SNMPメッセージのネットワークへの送信 SNMPエンジン内のディスパッチャは出力するメッセージを用意するために、 メッセージ処理モデルと協調する。そのために、以下のプリミティブを利 用する。 - リクエストと通知のためには、4.2.1で説明した prepareOutgoingMessageを使う。 - メッセージの応答のためには、4.2.2で説明した prepareResponseMessageを使う。 メッセージ処理モデルは、出力するSNMPメッセージを用意する時に、メッ セージをセキュアにするためにセキュリティモデルと協調する。そのため に、以下のプリミティブを利用する。 - リクエストと通知のためには、4.4.1で説明したgenerateRequestMsg を使う。 - メッセージの応答のためには、4.4.3で説明した generateResponseMsgを使う。 いったん、メッセージ処理モデルによってSNMPメッセージが用意される と、ディスパッチャは望まれるアドレスに適当なトランスポートを用い てメッセージを送信する。 A.3. アプリケーション設計の要件 アプリケーション内では、特定のSNMPメッセージバージョン、すなわち、 特定のメッセージ処理モデルと特定のアクセス制御モデルへの明示的なバ インディングがあるかも知れない。そして、特定のメッセージ処理モデル やアクセス制御モデルによって定義されたどんなデータへの参照はすべき ではない。 アプリケーション内では、特定のセキュリティモデルや特定のセキュリティ モデルによって定義されたあらゆるデータへの参照はすべきではない。 アプリケーションは明示的な、あるいは暗黙のアクセス制御がオペレーショ ンに適用されるべきかどうか、そして、もしアクセス制御が必要であれば、 どのアクセス制御モデルが使われるべきかを決定する。 アプリケーションはアプリケーションに固有のサービスが提供されるのに 用いられるあらゆるMIBモジュールを定義する責任がある。 アプリケーションはメッセージを初期化し、応答を受信し、非同期メッセー ジを受信し、そして応答を送信するためにSNMPエンジンと協調する。 A.3.1. メッセージを初期化するアプリケーション アプリケーションは4.1.1で説明したように、SNMPエンジンがsendPduプリ ミティブをSNMPのコマンドや通知を含むメッセージを送信することをリク エストするかも知れない。 もし、メッセージが様々な相手へ送信されることが望まれているなら、イ テレーションを提供するのはアプリケーションの責任である。 SNMPエンジンは必要なアクセス制御がPDUへ適用されているものとし、アク セス制御サービスを提供しない。 SNMPエンジンは「expectResponse」パラメータを見て、もし応答が期待さ れていれば、その時は後の応答がこのメッセージに関係づけられ、アプリ ケーションに返されるように適切な情報がキャッシュされる。 sendPduHandleはアプリケーションに返されるので、アプリケーションは後 でこのメッセージに対する応答に答えることができる。 A.3.2. 応答を受信するアプリケーション SNMPエンジンは入力してくる応答メッセージをこのSNMPエンジンによって 送られた未完成のメッセージに調和させる。そして、4.1.4で説明されてい るprocessResponsePduプリミティブを使っている関連するアプリケーショ ンに応答を転送する。 A.3.3. 非同期メッセージを受信するアプリケーション SNMPエンジンがSNMPエンジンからのリクエストに対する応答ではないメッ セージを受信した時、どのアプリケーションにメッセージが与えられるべ きかを決定しなければならない。 非同期のメッセージを受信したいと思うアプリケーションは、4.1.5で説明 されているように、registerContextEngineIDプリミティブを使っているエ ンジンに自身を登録する。 非同期のメッセージを受信することを停止したいと思うアプリケーション は、4.1.5で説明されているように、unregisterContextEngineIDプリミティ ブを使っているSNMPエンジンに自身を登録解除するべきである。 PDUタイプとcontextEngineIDの組み合わせに対する一つの登録だけが同時 に許される。二重登録は無視される。errorIndicationは二重登録しようと したアプリケーションに返されるだろう。 登録されたPDUタイプとcontextEngineIDの組み合わせを含む、非同期に受 信したメッセージは全て、その組み合わせをサポートするために登録され たアプリケーションへ送られる。 4.1.2で説明されているように、エンジンはprocessPduプリミティブを使っ て登録されたアプリケーションへPDUを転送する。 A.3.4. 応答を送信するアプリケーション リクエストオペレーションは応答を要求する。4.1.3で説明されているよう に、アプリケーションはreturnResponsePduプリミティブ経由で応答を送信 する。 contextEngineID、contextName、securityModel、securityName、 securityLevel、そしてstateReferenceパラメータは初期のprocessPduプリ ミティブからある。PDUとstatusInformationは処理の結果である。 A.4. アクセス制御モデルの設計の要件 アクセス制御モデルは指定されたsecurityNameが指定された管理オブジェ クトへの要求されたオペレーションを行うことが許されているかどうかを 決定する。アクセス制御モデルは決定されるアクセス制御によって規則を 指定する。 アクセス制御のために使われる永続データはSNMPを使って管理可能である べきである。しかし、アクセス制御モデルはMIBのインスタンス化が準拠の 要件であるかどうかを定義する。 アクセス制御モデルはisAccessAllowedプリミティブを提供しなければなら ない。 B. 著作権全文 Copyright (C) The Internet Society (1999). All Rights Reserved. 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. 謝辞 Funding for the RFC Editor function is currently provided by the Internet Society.