要約

  • RFC 1089 は通常の SNMP メッセージを Ethernet のデータ部へ直接入れ、10 進 33100、16 進 0x814C の EtherType で識別した。リピータや配線集線装置は IP と UDP を実装せずに管理要求を受けられた。
  • 後継の RFC 4789 は、この方式を任意の IEEE 802 トランスポートとして整理し、到達範囲を一つの論理 LAN、ブリッジ LAN または VLAN に限定した。一つのインターフェースで宛先にできる SNMP エンジンも一つだけである。
  • MAC アドレスと種別値が決めるのは配送先と解釈方法である。認証済み主体、許可された MIB ビュー、装置で生じた効果は、それぞれ別の証拠を必要とする。

IP の外にいた、重要な装置

リピータはルータではない。それでも故障すればセグメント全体が止まる。配線集線装置も、IP パケットを終端しなくても多数の接続を左右する。1980 年代末には、こうした機器にもプログラム可能な回路と MAC アドレスが入り始めていたが、MAC サブレイヤより上のプロトコルを備えるとは限らなかった。

管理側から見ると、装置は物理的には最も近く、論理的には見えない。IP アドレスがなければ通常の UDP ベースの SNMP では宛先を作れない。専用管理方式を残すか、小さな装置に一式の Internet スタックを持たせるかという選択に見えた。

RFC 1089 は第三の選択を示した。SNMP が必要とするのは双方向の流れとアドレス可能性であり、それを必ず IP が供給するとは限らない。同じ Ethernet にいるなら、MAC フレームが最短の運搬手段になる。

文書は実験仕様だった。新しい MIB や専用命令を作らず、既存の SNMP メッセージを下から支える封筒だけを替えた。この限定が、後の境界を理解する手掛かりになる。

フレームの中に IP はなかった

割り当てられた Ethernet Type は 33100、16 進で 814C だった。Ethernet ヘッダの後に標準 SNMP メッセージが続く。IPv4 ヘッダも UDP ポートも挟まらない。

宛先 MAC はインターフェースを選び、EtherType は受信側のプロトコル処理を選ぶ。装置は ASN.1/BER と SNMP の要求を理解すればよく、この経路のためだけに IP のアドレス処理やルーティング、フラグメント、UDP の多重化まで実装する必要はない。

RFC 1157 が示す SNMP の設計目標とも一致する。管理エージェント側の機能と複雑さを抑え、各メッセージを独立した交換として扱う。仕様上は UDP を使いながら、仕組み自体はさまざまなトランスポートに適用できるとされた。

ただし、消えた複雑さはゼロにはならない。管理者は装置の MAC だけでなく、それが属する LAN や VLAN、ブリッジ経路、SNMP エンジン、安全方式を把握しなければならない。実装の軽さは、運用台帳の正確さに支えられる。

0x814C が証明したのは形式だけだった

種別値が正しければ、後続バイトを SNMP として解釈できる。それ以上の意味はない。値は送信者の所属を示さず、読み取りや変更の資格を与えず、要求された操作が安全であるとも言わない。

MAC アドレスも同じである。リンク上の配送座標としては不可欠だが、人、組織、所有者、管理担当者の識別子ではない。現在のトポロジーでそのインターフェースに届いた、という観測を、永続的な装置同一性へ広げてはならない。

特に危険なのは「同じ LAN だから信頼できる」という省略である。一つの LAN という制限は、フレームが到達し得る範囲を狭める。誰が何を実行してよいかという権限規則とは別物だ。VLAN を防御の一部として使うことはできるが、それだけを認証に置き換える根拠は RFC にはない。

リンクの近さは配送条件であって、委任関係ではない。この区別を失うと、プロトコルの種類を示す 16 ビットが、存在しない身分証明書として扱われる。

2006 年仕様は到達できる島を明記した

RFC 4789 は RFC 1089 を廃止し、IEEE 802 ネットワーク向けの標準化された任意マッピングを定めた。SNMP メッセージを MAC フレームのデータ部へ収める点と 0x814C は維持された。

LLC でプロトコルを識別する IEEE 802 LAN では SNAP カプセル化を使う。文書が例に挙げる 802.11 を含め、媒体が異なっても割り当て済みの種別を伝えられるようにした。

運用上の核心は範囲である。この方式のメッセージは、一つの論理 IEEE 802 LAN、ブリッジされた LAN、または VLAN に限られる。ブリッジは同じ論理島を延ばせるが、ルータが IP データグラムのように別ネットワークへ運ぶわけではない。

装置の MAC が変わらなくても、スイッチポートを別 VLAN へ移せば管理路は消える。逆にブリッジ領域を広げれば、同じチャネルに届き得る範囲が変わる。管理の可達性は装置だけの属性ではなく、トポロジーの状態である。

この制約は方式の欠陥ではなく、IP を省ける理由そのものでもある。遠隔からの到達が必要なら、対象 LAN 内の管理局、制御されたプロキシ、または通常の IP マッピングが要る。

ポートのない入口は一つだった

RFC 4789 は、一つの IEEE 802 インターフェースでアドレス可能な SNMP エンジンを一つに限定する。コマンド生成、通知受信、コマンド応答、通知送信は、同じトランスポートエンドポイントを共有する。

UDP なら IP アドレスとポートが宛先を構成し、一般に 161 と 162 が役割を分ける。直接マッピングには MAC とプロトコル種別しかなく、トランスポートポートがない。到着後に SNMP メッセージの種類を判別できても、リンク封筒だけで複数エンジンを選び分けられない。

内部実装が複雑であることは禁止されない。しかし標準が外部へ見せる入口は一つである。どのエンジンがその位置を占めるかは、アドレス自動割当ではなく設計と設定の判断になる。

受信能力にも下限がある。484 オクテットまでを必ず受け入れ、1472 オクテットまでの対応が推奨され、より大きいものも奨励される。RFC 3417 は SNMP の各トランスポートに同じ基準を置き、IPv4 を実装するシステムには UDP/IPv4 マッピングを必須かつ優先とした。IEEE 802 方式は補完であり、通常経路の置き換えではない。

トランスポートドメインが住所の意味を守った

汎用 MIB がリンク層の endpoint を参照できるよう、RFC 4789 は snmpIeee802Domain を登録した。対応するアドレス型は MacAddress である。

ドメインがあるから、同じバイト列を勝手に別の住所へ読み替えずに済む。UDP/IPv4 の住所は IP とポートを含み、IEEE 802 の住所は MAC である。いずれも当該トランスポート内の座標であって、利用者名や法的主体、普遍的な機器 ID ではない。

記録では、ドメインとアドレスに加えて VLAN、ブリッジ経路、物理インターフェース、エンジンの時期を残す必要がある。MAC だけでは可達範囲が消え、ユーザー名だけではメッセージが入った経路が消える。

権限判定は配送の後に始まる

RFC 4789 は SNMPv1 と SNMPv2c のメッセージを安全とはみなさず、SNMPv3 の USM と VACM を検討するよう勧めた。リンク層の近接が安全性なら、この注意は不要だったはずである。

RFC 3414 の USM は、メッセージ認証、時刻上の新鮮さ、必要に応じた秘匿を扱う。RFC 3415 の VACM は、認証された security name が、ある context で、どの MIB ビューにどの操作を行えるかを判断する。

証拠は段階ごとに違う。フレームがインターフェースへ届く。エンジンが保護を検証する。アクセス制御が対象オブジェクトを許可する。装置の計測・制御部分が作用する。前段の成功は次段の結果を保証しない。

成功応答にも限界がある。エンジンが要求を処理し、値や状態を返したことは示せる。しかしポートが実際に転送を始めた、リレーが動いた、再起動後も設定が残った、と証明するには、再読出しや独立カウンタ、物理観測が必要になる。

RFC 1089 が残したのは、単なる EtherType ではない。必要なスタックを短くしても、配送、本人性、権限、効果の責任境界まで短くなるわけではない、という設計上の節度である。

出典