簡易ネットワーク管理プロトコル (SNMP) アプリケーション

• ステータス: Internet Standard
• 発行日: December 2002
• ストリーム: IETF
• 廃止: RFC2573
• エラッタ: エラッタなし

---

このメモのステータス

この文書は、インターネットコミュニティのためのインターネット標準化トラックプロトコルを指定し、改善のための議論と提案を求めています。このプロトコルの標準化状態とステータスについては、最新版の「Internet Official Protocol Standards」（STD 1）を参照してください。このメモの配布は無制限です。

概要

この文書は、STD 62、RFC 3411で説明されているSNMPエンジンを使用する5種類の簡易ネットワーク管理プロトコル（SNMP）アプリケーションについて説明します。説明されているアプリケーションの種類は、コマンドジェネレータ、コマンドレスポンダ、通知オリジネータ、通知レシーバ、およびプロキシフォワーダです。

この文書では、管理操作のターゲットを指定するため、通知フィルタリングのため、およびプロキシ転送のための管理情報ベース（MIB）モジュールも定義しています。この文書は、RFC 2573を廃止します。

---

7. プロキシフォワーダアプリケーションにおける管理ターゲット変換

プロキシフォワーダアプリケーションは、SNMPメッセージを転送する際に管理ターゲットの変換を実行します。この変換には、受信メッセージパラメータ（contextEngineID、contextName、securityModel、securityName、securityLevel）をターゲットSNMPエンジンに適した送信メッセージパラメータにマッピングすることが含まれます。

snmpProxyTableは、プロキシフォワーダが使用する変換ルールを定義します。

7.1. リクエスト転送

リクエスト転送には、コマンドジェネレータからコマンドリクエストを受信し、リクエストパラメータを変換し、コマンドレスポンダにリクエストを転送することが含まれます。

7.1.1. 受信リクエストの処理

プロキシフォワーダがリクエストを受信すると：

1. 受信したメッセージから受信パラメータを抽出します：

   • contextEngineID
   • contextName
   • securityModel
   • securityName
   • securityLevel
   • PDUタイプ

2. これらのパラメータをキーとして使用してsnmpProxyTableを検索します。具体的には、次のエントリを検索します：

   • snmpProxyTypeが読み取りクラスPDU（Get、GetNext、GetBulk）の場合はread(1)、書き込みクラスPDU（Set）の場合はwrite(2)
   • snmpProxyContextEngineIDが受信contextEngineIDと一致
   • snmpProxyContextNameが受信contextNameと一致
   • snmpProxyTargetParamsInが受信セキュリティパラメータと一致するターゲットパラメータを参照

3. 一致するエントリが見つからない場合：

   • リクエストを転送できないことを示すエラー応答を生成します。
   • 特定のエラーは、SNMPバージョンと状況に依存します（authorizationError、genErrなど）。

4. 一致するエントリが見つかった場合：

   • snmpProxySingleTargetOutまたはsnmpProxyMultipleTargetOut値を抽出します。

7.1.2. リクエストの転送

一致するsnmpProxyTableエントリを見つけた後：

単一ターゲット転送

snmpProxySingleTargetOutが指定されている場合：

1. snmpProxySingleTargetOutをsnmpTargetAddrNameとして使用してsnmpTargetAddrTableを検索します。

2. ターゲットアドレス情報を抽出します：

   • snmpTargetAddrTDomain（トランスポートドメイン）
   • snmpTargetAddrTAddress（トランスポートアドレス）
   • snmpTargetAddrParams（snmpTargetParamsTableへの参照）

3. snmpTargetAddrParamsを使用してsnmpTargetParamsTableを検索します。

4. ターゲットセキュリティパラメータを抽出します：

   • snmpTargetParamsMPModel（メッセージ処理モデル）
   • snmpTargetParamsSecurityModel
   • snmpTargetParamsSecurityName
   • snmpTargetParamsSecurityLevel

5. ターゲットコンテキストを決定します：

   • snmpProxyContextEngineIDが空の場合、受信contextEngineIDを使用します。
   • そうでない場合は、snmpProxyContextEngineIDを使用します。
   • snmpProxyContextNameについても同様です。

6. 必要に応じてPDUを変換します：

   • 受信および送信SNMPバージョンが異なる場合、PDU形式とエラーコードを変換します。
   • SNMPv1からSNMPv2へ：エラーコードをマッピング、trap形式を変換します。
   • SNMPv2からSNMPv1へ：エラーコード（noAccess→genErrなど）をマッピング、例外値を処理します。

7. メッセージ処理サブシステムのPDU送信プリミティブを使用して、ターゲットパラメータでリクエストを転送します。

複数ターゲット転送

snmpProxyMultipleTargetOutが指定されている場合：

1. snmpTargetAddrTagListにsnmpProxyMultipleTargetOutで指定されたタグが含まれるsnmpTargetAddrTable内のすべてのエントリを検索します。

2. 一致する各ターゲットアドレスについて：

   • 単一ターゲット転送のステップ2〜7に従います。
   • 元のリクエストが複製され、複数のターゲットアドレスに送信されることに注意してください。

3. 複数ターゲットの応答処理：

   • 複数ターゲット転送は通常、読み取り操作にのみ使用されます。
   • プロキシは応答を集約するか、最初の成功した応答を返す必要がある場合があります。
   • 特定の動作は実装に依存します。

7.1.3. 応答の転送

プロキシフォワーダがターゲットコマンドレスポンダから応答を受信すると：

1. 必要に応じて応答PDUを変換して、元のリクエスタが期待する形式と一致させます。

2. contextEngineIDとcontextNameを元のリクエスタが期待する値にマッピングします。

3. メッセージ処理サブシステムの応答PDU返送プリミティブを使用して応答を返送します。

7.2. 通知転送

通知転送には、通知オリジネータから通知を受信し、1つ以上の通知レシーバに転送することが含まれます。

7.2.1. 受信通知の処理

プロキシフォワーダが通知を受信すると：

1. 受信パラメータを抽出します：

   • contextEngineID
   • contextName
   • securityModel
   • securityName
   • securityLevel
   • 通知タイプ（trapまたはinform）

2. これらのパラメータを使用してsnmpProxyTableを検索します。次のエントリを検索します：

   • snmpProxyTypeがtrap通知の場合はtrap(3)、inform通知の場合はinform(4)
   • snmpProxyContextEngineIDが受信contextEngineIDと一致（または任意に一致するように空）
   • snmpProxyContextNameが受信contextNameと一致（または任意に一致するように空）
   • snmpProxyTargetParamsInが受信セキュリティパラメータと一致するターゲットパラメータを参照（または任意に一致するように空）

3. 一致するエントリが見つからない場合：

   • 通知は転送されません。
   • プロキシはこのイベントをローカルに記録する場合があります。

4. 一致するエントリが見つかった場合：

   • snmpProxyMultipleTargetOut値を抽出します（通知転送は常に複数ターゲット転送を使用します）。

7.2.2. 通知の転送

一致するsnmpProxyTableエントリを見つけた後：

1. snmpTargetAddrTagListにsnmpProxyMultipleTargetOutで指定されたタグが含まれるsnmpTargetAddrTable内のすべてのエントリを検索します。

2. 一致する各ターゲットアドレスについて：

   a. snmpTargetParamsTableでsnmpTargetAddrParamsを検索します。

   b. ターゲットパラメータを抽出します。

   c. snmpNotifyTable（参照されている場合）に基づいてtrapまたはinformとして送信するかどうかを決定するか、受信通知と同じタイプを使用します。

   d. 必要に応じて通知PDUを変換します：

   • SNMPv1 trapからSNMPv2 trapへ：PDU形式を変換し、sysUpTime.0とsnmpTrapOID.0を追加します。
   • SNMPv2 trapからSNMPv1 trapへ：PDU形式を変換し、enterprise、agent-addr、generic-trap、specific-trapを抽出します。

   e. メッセージ処理サブシステムのPDU送信プリミティブを使用して通知を転送します。

3. 送信通知がinformリクエストの場合：

   • 各ターゲットからの応答を待ちます。
   • 受信通知もinformであった場合、応答を集約します。
   • すべて（または構成されたサブセット）のターゲットから応答を受信した後にのみ、元の通知オリジネータに応答を返します。

変換例

例1：SNMPv3からSNMPv1へのリクエスト変換

受信リクエスト:

• contextEngineID: 0x80001F8880
• contextName: "publicView"
• securityModel: 3 (USM)
• securityName: "admin"
• securityLevel: authPriv
• PDU: GetRequest

snmpProxyTableエントリ:

• snmpProxyType: read(1)
• snmpProxyContextEngineID: 0x80001F8880
• snmpProxyContextName: "publicView"
• snmpProxyTargetParamsIn: "snmpv3Params"
• snmpProxySingleTargetOut: "legacyDevice"

snmpTargetAddrTableエントリ（legacyDevice）:

• snmpTargetAddrTDomain: snmpUDPDomain
• snmpTargetAddrTAddress: 192.0.2.10:161
• snmpTargetAddrParams: "snmpv1Params"

snmpTargetParamsTableエントリ（snmpv1Params）:

• snmpTargetParamsMPModel: 0 (SNMPv1)
• snmpTargetParamsSecurityModel: 1 (SNMPv1)
• snmpTargetParamsSecurityName: "public"
• snmpTargetParamsSecurityLevel: noAuthNoPriv

送信リクエスト:

• トランスポート: 192.0.2.10:161へのUDP
• SNMPバージョン: SNMPv1
• コミュニティ: "public"
• PDU: GetRequest（同じ変数バインディング）

応答変換:

• 受信SNMPv1応答はSNMPv3形式に変換されます。
• 応答はUSMを使用して暗号化および認証されます。
• 元のリクエスタに返送されます。

例2：SNMPv1 TrapからSNMPv2 Trapへの変換

受信SNMPv1 Trap:

• コミュニティ: "public"
• enterprise: 1.3.6.1.4.1.9
• agent-addr: 192.0.2.1
• generic-trap: linkDown(2)
• specific-trap: 0
• time-stamp: 12345

snmpProxyTableエントリ:

• snmpProxyType: trap(3)
• snmpProxyContextEngineID: ""（任意に一致）
• snmpProxyContextName: ""（任意に一致）
• snmpProxyTargetParamsIn: ""（任意に一致）
• snmpProxyMultipleTargetOut: "snmpv2Targets"

タグ「snmpv2Targets」を持つsnmpTargetAddrTableエントリ: SNMPv2cまたはSNMPv3パラメータを持つ複数のエントリ。

送信SNMPv2/v3 Traps:

• snmpTrapOID.0: 1.3.6.1.6.3.1.1.5.3 (linkDown)
• sysUpTime.0: 12345
• 元のtrapからの追加の変数バインディング。

特別な考慮事項

コンテキスト変換

snmpProxyTableはコンテキスト変換を許可します：

• テーブルエントリ内の空のsnmpProxyContextEngineIDまたはsnmpProxyContextNameは、「受信値を使用する」ことを意味します。
• 空でない値は、「受信コンテキストをこの送信コンテキストにマッピングする」ことを意味します。

これにより、プロキシは複数の受信コンテキストを単一の送信コンテキストにマッピングしたり、その逆を行ったりできます。

セキュリティダウングレードの防止

より高いセキュリティレベルからより低いセキュリティレベルに変換する場合（SNMPv3 authPrivからSNMPv1 noAuthNoPrivなど）、プロキシは次のことを行う必要があります：

1. セキュリティダウングレードを記録して監査目的で保管します。
2. 追加のアクセス制御を適用して、ダウングレード可能な操作を制限します。
3. トランスポートの暗号化を検討（IPsecやTLSを使用など）して、SNMPレイヤーのセキュリティの低下を補償します。

エラー処理

プロキシはエラーを慎重に処理する必要があります：

• 変換エラー: PDUを変換できない場合（SNMPv1のSNMPv2例外値など）、適切なエラーを返します。
• 転送エラー: ターゲットに到達できない場合、元のリクエスタにタイムアウトまたはネットワークエラーを返します。
• 応答変換エラー: 応答を変換できない場合、エラーを記録し、元のリクエスタにgenErrを返します。

パフォーマンスの最適化

プロキシ転送は、次の方法で最適化できます：

1. テーブルルックアップのキャッシュ: 頻繁に使用されるパスのsnmpProxyTable、snmpTargetAddrTable、およびsnmpTargetParamsTableルックアップをキャッシュします。
2. ルールの事前コンパイル: 構成時にテーブルエントリを最適化された内部形式に変換します。
3. 接続プーリング: TCPベースのトランスポートの場合、頻繁にアクセスされるターゲットへの永続的な接続を維持します。

---

5. 通知オリジネータにおける管理ターゲットの識別

通知オリジネータアプリケーションは、snmpTargetAddrTableとsnmpTargetParamsTableを使用して、通知を送信する必要がある管理ターゲットを識別し、通知を送信する際に使用するSNMPバージョンとセキュリティパラメータを決定します。

通知の生成をトリガーするイベントが発生すると、通知オリジネータは：

1. snmpNotifyTableを参照して、この通知に使用する必要がある通知タグを決定します。snmpNotifyTable内の各エントリは、タグ値を通知タイプ（trapまたはinform）に関連付けます。

2. 通知タグを照合してsnmpTargetAddrTableからターゲットアドレスを選択します。snmpTargetAddrTable内の各エントリについて：

   a. snmpTargetAddrTagListオブジェクトにはタグ値のリストが含まれています。

   b. snmpTargetAddrTagList内のいずれかのタグ値がsnmpNotifyTableで指定されたタグと一致する場合、このターゲットアドレスが選択されます。

3. 選択された各ターゲットアドレスのトランスポートパラメータを取得します：

   a. snmpTargetAddrTDomainはトランスポートドメインを指定します（例：snmpUDPDomain、snmpTCPDomain）。

   b. snmpTargetAddrTAddressはトランスポートアドレスを指定します（例：IPアドレスとポート）。

4. 選択された各ターゲットアドレスのSNMPパラメータを取得します：

   a. snmpTargetAddrParamsオブジェクトはsnmpTargetParamsTable内のエントリを参照します。

   b. 参照されたsnmpTargetParamsTableエントリから、通知オリジネータは以下を取得します：

   • snmpTargetParamsMPModel（メッセージ処理モデル）
   • snmpTargetParamsSecurityModel（セキュリティモデル）
   • snmpTargetParamsSecurityName（セキュリティ名）
   • snmpTargetParamsSecurityLevel（セキュリティレベル）

5. 取得したパラメータを使用して、選択された各管理ターゲットに通知を生成して送信します。

構成例

linkDown通知を送信する必要がある通知オリジネータを考えてみましょう。構成には以下が含まれる場合があります：

snmpNotifyTableエントリ:

• snmpNotifyName: "linkDownNotify"
• snmpNotifyTag: "criticalDevices"
• snmpNotifyType: trap(1)

snmpTargetAddrTableエントリ:

エントリ1:

• snmpTargetAddrName: "mgmtStation1"
• snmpTargetAddrTDomain: snmpUDPDomain
• snmpTargetAddrTAddress: 192.0.2.1:162
• snmpTargetAddrTagList: "criticalDevices monitoring"
• snmpTargetAddrParams: "snmpv3Params"

エントリ2:

• snmpTargetAddrName: "mgmtStation2"
• snmpTargetAddrTDomain: snmpUDPDomain
• snmpTargetAddrTAddress: 192.0.2.2:162
• snmpTargetAddrTagList: "criticalDevices"
• snmpTargetAddrParams: "snmpv2cParams"

snmpTargetParamsTableエントリ:

エントリsnmpv3Params:

• snmpTargetParamsMPModel: 3 (SNMPv3)
• snmpTargetParamsSecurityModel: 3 (USM)
• snmpTargetParamsSecurityName: "operator"
• snmpTargetParamsSecurityLevel: authPriv(3)

エントリsnmpv2cParams:

• snmpTargetParamsMPModel: 1 (SNMPv2c)
• snmpTargetParamsSecurityModel: 2 (SNMPv2c)
• snmpTargetParamsSecurityName: "public"
• snmpTargetParamsSecurityLevel: noAuthNoPriv(1)

linkDownイベントが発生すると：

1. 通知オリジネータはsnmpNotifyTableを参照し、「criticalDevices」タグを持つ通知をtrapとして送信する必要があることを確認します。

2. snmpTargetAddrTableをスキャンし、タグリストに「criticalDevices」を含む2つのエントリを見つけます：「mgmtStation1」と「mgmtStation2」。

3. mgmtStation1の場合、USMセキュリティ、authPrivレベル、およびセキュリティ名「operator」を使用して、192.0.2.1:162にSNMPv3 trapを送信します。

4. mgmtStation2の場合、コミュニティ文字列「public」を使用して、192.0.2.2:162にSNMPv2c trapを送信します。

Informリクエストのタイムアウトと再試行

通知タイプがinform（InformRequest-PDU）の場合、snmpTargetAddrTableはタイムアウトと再試行パラメータも提供します：

• snmpTargetAddrTimeout: リクエストをタイムアウトと見なす前に応答を待機する時間（100分の1秒単位）を指定します。

• snmpTargetAddrRetryCount: 応答が受信されない場合にinformリクエストの送信を再試行する回数を指定します。

通知オリジネータは、これらのパラメータを使用して、informリクエストの信頼性の高い通知配信を実装します。

たとえば、snmpTargetAddrTimeoutが1500（15秒）で、snmpTargetAddrRetryCountが3の場合、通知オリジネータは：

1. informリクエストを送信します。
2. 応答を受信するために最大15秒待機します。
3. 応答が受信されない場合、最大3回再試行します。
4. 合計4回の試行（初期試行＋3回の再試行）または60秒（4×15秒）の後に諦めます。先に到達した方が優先されます。

管理ターゲット識別のセキュリティに関する考慮事項

通知の管理ターゲットを識別する際：

1. 構成の認証: 管理ターゲットの構成（snmpTargetAddrTable、snmpTargetParamsTable、およびsnmpNotifyTable）は、未承認の変更を防ぐためにアクセス制御によって保護する必要があります。

2. 機密情報: セキュリティ名、特にSNMPv1またはSNMPv2c（コミュニティ文字列）と一緒に使用される場合は、開示から保護する必要があります。snmpTargetParamsTableは、承認されたユーザーのみがアクセスできる必要があります。

3. 通知フィルタリング: 適切な通知フィルタリング（次のセクションで説明）がない場合、構成されたすべての管理ターゲットがすべての通知を受信し、機密情報が未承認の受信者に開示される可能性があります。

4. タグの選択: タグを使用すると、管理ターゲットを柔軟にグループ化できますが、誤った方向への通知を防ぐためにタグが正しく適用されるように注意する必要があります。

---

6. 通知フィルタリング

通知フィルタリングは、通知の内容に基づいて管理ターゲットに選択的に通知を送信するメカニズムを提供します。これにより、どの管理ターゲットがどのタイプの通知を受信するかをきめ細かく制御できます。

通知フィルタリングは3つのMIBテーブルを使用します：

• snmpNotifyFilterProfileTable: フィルタープロファイル名を一連のターゲットパラメータに関連付けます。
• snmpNotifyFilterTable: 通知内容に基づいて実際のフィルタールールを定義します。
• snmpTargetParamsTable: フィルタープロファイルテーブルによって参照されるターゲットパラメータ名を含みます。

フィルター処理アルゴリズム

通知オリジネータが管理ターゲットの通知を生成するとき、次のように通知フィルタリングを適用します：

1. 管理ターゲットのsnmpTargetAddrParamsオブジェクトからターゲットパラメータ名を取得します。

2. ターゲットパラメータ名をインデックスとして使用して、snmpNotifyFilterProfileTableでフィルタープロファイルを検索します。

3. フィルタープロファイルが見つからない場合、通知が送信されます（フィルタリングは適用されません）。

4. フィルタープロファイルが見つかった場合、snmpNotifyFilterProfileNameがsnmpNotifyFilterTable内の一連のフィルターエントリを識別します。

5. 通知内の各変数バインディングについて：

   a. フィルタープロファイル名と一致するsnmpNotifyFilterTableのエントリを検索します。

   b. エントリはインデックスの辞書順に処理されます。

   c. 各フィルターエントリについて、snmpNotifyFilterSubtreeで指定されたサブツリーが変数のオブジェクト識別子と一致するかどうかを確認します。

   d. 変数のOIDがフィルターサブツリー内またはそれと等しい場合（指定されている場合はsnmpNotifyFilterMaskを考慮して）、一致が発生します。

   e. 一致が見つかった場合：

   • snmpNotifyFilterTypeがincluded(1)の場合、他の変数のチェックを続けます。
   • snmpNotifyFilterTypeがexcluded(2)の場合、この管理ターゲットに通知を送信しません。

   f. すべてのフィルターエントリをチェックした後に変数の一致が見つからない場合、通知を送信しません。

6. すべての変数バインディングがフィルターを通過した場合、管理ターゲットに通知を送信します。

フィルターマスクのセマンティクス

snmpNotifyFilterMaskオブジェクトは、サブツリーマッチングに対するビットレベルの制御を提供します。これは、次のセマンティクスを持つビットマスクです：

• マスク内の各オクテットは、フィルターサブツリーOID内のサブ識別子に対応します。
• オクテット内の各ビットは、サブ識別子内のビットに対応します。
• マスク内のビットが1の場合、サブ識別子内の対応するビットは変数のOIDと一致する必要があります。
• マスク内のビットが0の場合、サブ識別子内の対応するビットは無視されます（ワイルドカード）。

ゼロ長マスク（デフォルト）は、すべてのサブ識別子が完全に一致する必要があることを意味します。

マスク使用例：

フィルターサブツリー: 1.3.6.1.2.1.2.2.1.8
マスク: 0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFE

このマスクは、最後のサブ識別子の最後のビットがワイルドカードであるため、1.3.6.1.2.1.2.2.1.8（ifOperStatus）と1.3.6.1.2.1.2.2.1.9（ifLastChange）の両方のマッチングを許可します。

構成例

例1：管理ターゲットへのすべての通知の送信

フィルタリングなしで管理ターゲットにすべての通知を送信するには：

1. ターゲットのパラメータ名のsnmpNotifyFilterProfileTableにエントリを作成しません。

または

2. 単一の包含フィルターを持つフィルタープロファイルを作成します：
   • snmpNotifyFilterSubtree: 1（または任意のルートOID）
   • snmpNotifyFilterMask: ""（空）
   • snmpNotifyFilterType: included(1)

例2：インターフェース関連の通知のみの送信

インターフェース（ifTable）に関連する通知のみを送信するには：

snmpNotifyFilterProfileTableエントリ:

• snmpNotifyFilterProfileName: "interfaceFilter"
• ターゲットパラメータ名に関連付け: "stationAParams"

snmpNotifyFilterTableエントリ:

エントリ1:

• snmpNotifyFilterProfileName: "interfaceFilter"
• snmpNotifyFilterSubtree: 1.3.6.1.2.1.2
• snmpNotifyFilterMask: ""
• snmpNotifyFilterType: included(1)

この構成により、interfacesグループ（1.3.6.1.2.1.2）からの変数を含む通知の送信が許可され、他のすべての通知がフィルタリングされます。

例3：特定の通知の除外

TCP接続テーブルに関連する通知を除くすべての通知を送信するには：

snmpNotifyFilterProfileTableエントリ:

• snmpNotifyFilterProfileName: "noTcpConnections"
• ターゲットパラメータ名に関連付け: "stationBParams"

snmpNotifyFilterTableエントリ:

エントリ1:

• snmpNotifyFilterProfileName: "noTcpConnections"
• snmpNotifyFilterSubtree: 1
• snmpNotifyFilterMask: ""
• snmpNotifyFilterType: included(1)

エントリ2:

• snmpNotifyFilterProfileName: "noTcpConnections"
• snmpNotifyFilterSubtree: 1.3.6.1.2.1.6.13
• snmpNotifyFilterMask: ""
• snmpNotifyFilterType: excluded(2)

この構成はすべての通知を含みますが（エントリ1）、tcpConnTableからの変数を含む通知は明示的に除外します（エントリ2）。

実装に関する考慮事項

パフォーマンス

通知フィルタリングには、各変数バインディングについて、潜在的に複数のフィルターエントリに対するOID比較が必要です。実装はこのプロセスを最適化する必要があります：

• OIDルックアップに効率的なデータ構造（トライやハッシュテーブルなど）を使用します。
• 頻繁に使用される管理ターゲットのフィルタープロファイルルックアップをキャッシュします。
• 構成時にフィルタールールを事前コンパイルすることを検討します。

フィルター順序

フィルターエントリはインデックスの辞書順に処理されます。これは以下を意味します：

• より広い包含に対して、より具体的な（より長いOID）除外を適切に構成する必要があります。
• フィルターエントリの順序がフィルタリングの結果に影響を与える可能性があります。

デフォルトの動作

ターゲットのパラメータにフィルタープロファイルが存在しない場合：

• デフォルトの動作は通知を送信することです（フィルタリングなし）。
• これにより、通知フィルタリングを使用しないシステムとの下位互換性が確保されます。

変数バインディング要件

RFC 3416では、通知に少なくとも2つの変数バインディングを含める必要があります：

1. sysUpTime.0
2. snmpTrapOID.0

これらの必須の変数バインディングは、通知を送信するためにフィルターを通過する必要があります。フィルターがこれらのOIDを除外する場合、その管理ターゲットに通知は送信されません。

セキュリティに関する考慮事項

通知フィルタリングは、いくつかの方法でセキュリティに影響を与える可能性があります：

1. 情報開示の防止: フィルタリングにより、機密情報が未承認の管理ステーションに送信されるのを防ぐことができます。

2. 構成の保護: フィルター構成テーブル（snmpNotifyFilterProfileTableとsnmpNotifyFilterTable）は、未承認の変更を防ぐためにアクセス制御によって保護する必要があります。

3. フィルターのバイパス: 不適切なフィルター構成（過度に広い包含ルールなど）により、意図しない通知が送信される可能性があります。

4. サービス拒否: 過度に複雑なフィルタールールは過剰な処理リソースを消費し、サービス拒否を引き起こす可能性があります。

包括的なセキュリティを確保するために、適切なアクセス制御（VACMなど）およびSNMPv3セキュリティ機能と組み合わせて通知フィルタリングを使用することをお勧めします。