要約

  • RFC 1449は一つのSNMPv2メッセージをUDP、OSI、AppleTalk DDP、IPXで運べるようにした。ただし、配送先を一つの万能アドレスにせず、ドメインOIDが対応する文法を選ぶ構造にした。
  • 4種類のアドレスはすべてASN.1のOCTET STRINGだったが、UDPの6オクテットは4+2、IPXの12オクテットは4+6+2に分かれ、OSIとNBPは内部の長さフィールドで境界を定めた。
  • ドメインと値の組が正しければ、バイト列を解釈できる。それでも割り当て、経路、待受け、相手の身元、操作権限、応答、装置への効果は別々に観測しなければならない。

データは残ったのに、読み方が消える

同じカラムに入るものを、同じ意味のものだと考えるのは危険だ。OCTET STRINGは、順序を持つオクテット列を表現する。それは保存と転送に便利な共通の器であり、内部の各位置が何を意味するかまでは決めない。

1993年4月に刊行されたRFC 1449は、まさにその境界を扱った。当時のネットワーク管理は、TCP/IPだけを前提にできなかった。OSI、AppleTalk、IPXを使う機器やネットワークにも、同じSNMPv2の操作を届ける必要があった。

仕様はすべてを文字列へ変換して見かけ上そろえる道を選ばなかった。snmpDomainsの下にUDP、CLNS、CONS、DDP、IPXを表す別々のOIDを置き、それぞれにアドレス規約を割り当てた。CLNSとCONSは同じOSIアドレス型を使うため、5つのドメインが4つの文法を選ぶ。

ここで保存すべき対象は、ドメインとアドレス値の対である。OIDは単なる分類ラベルではない。どのデコーダーを適用できるかを決める判別子だ。値だけを残した台帳は、ビットを一つも失っていなくても、事実の一部を失っている。

最も見慣れた6オクテット

SnmpUDPAddressは固定長だった。最初の4オクテットがネットワーク・バイト・オーダーのIPアドレス、残り2オクテットがUDPポートである。表示ヒントを使えば、運用者が見慣れた点区切りのアドレスとポートにできる。

RFC 1449は、エージェント役のSNMPv2エンティティがUDPポート161、通知の受け手が162を使うよう勧めた。UDPは優先されるマッピングでもあった。別のマッピングを実装するシステムには、相互運用性のためUDPへのプロキシを用意することが勧められた。

この親しみやすさが誤読を招く。末尾が161に見える6オクテットを見つければ、現代の解析者はUDPだと推測したくなる。しかし、長さは既知の型を検証する条件であって、失われた型を復元する証拠ではない。切断された値や私有形式でも6オクテットになり得る。

また、UDPが優先されたことは、他のドメインをUDPとして保存してよいという意味ではない。プロキシが変換したなら、入口のドメインと値、出口のドメインと値を両方残す必要がある。出口だけで入口を上書きすれば、変換という出来事が消えてしまう。

OSIでは先頭オクテットが境界を指示した

SnmpOSIAddressは可変長である。第1オクテットがNSAPの長さを示し、その後にNSAP、さらに残りにトランスポート・セレクターTSELが続く。NSAP長は0、または3から20まで。全体は1オクテットだけの場合と、4から85オクテットまでの場合がある。

この文法では、先頭オクテットはアドレス本体の一部として直接読む値ではない。後続区間の終点を示す制御情報だ。ドメインを取り違えると、先頭の解釈だけでなく、その後のすべての境界がずれる。

CLNSとCONSが同じSnmpOSIAddressを使うことにも意味がある。アドレスの構造が同じでも、トランスポート・ドメインは同一ではない。アドレス文法、サービス形態、実際の経路は関連するが、互いの代わりにはならない。

表示ヒントは、人が値を読むための投影だった。区切り記号や16進表記の大小、先頭ゼロの扱いはツールで変わり得る。画面上の文字列だけを恒久保存すると、元の型より表示ソフトの癖が強い証拠になってしまう。

DDPは構造化された名前、IPXは別の固定配置

DDPドメインに対応するSnmpNBPAddressは、直接の配送タプルではなくNBP名を格納した。object、type、zoneの三つの文字列がそれぞれ長さを伴って並ぶ。全体は3から99オクテットで、比較は大文字と小文字を区別せず、各文字列に255番のオクテットを含められない。

つまりドメインは、アドレス欄を数値的な場所ではなく構造化された名前として読むことまで決めていた。AppleTalkの名前解決、永続キャッシュ、NBP障害時の到達や古いアドレス再利用の危険はRFC 1419の記事が扱っている。RFC 1449についてここで重要なのは、その運用物語ではなく、同じ基底型から別の文法を選ぶ仕組みだ。

SnmpIPXAddressは12オクテットの固定長だった。4オクテットのネットワーク番号、6オクテットの物理アドレス、2オクテットのソケット番号に分かれる。UDPと同じように固定長でも、内部配置はまったく違う。12という数だけでは、その値をIPXとして読む権限は生まれない。

こうして、同じOCTET STRINGに四つの互換性のない意味が共存した。共通型は値の運び方を定め、ドメインは値の意味を定める。両者を混同しないから、システムを拡張できた。

中のメッセージは一つのままだった

外側のアドレスが違っても、SNMPv2メッセージをネットワークごとに作り直す必要はなかった。RFC 1449はメッセージをBERで直列化し、一つの完全なインスタンスを選択したトランスポート単位へ収めた。UDP、DDP、IPXでは一つのデータグラム、OSIでは一つのTSDUである。

BERにも制約が置かれた。長さは確定形式を用い、INTEGER、OCTET STRING、OBJECT IDENTIFIERなどの単純型はプリミティブ形式で符号化する。構成形式はSEQUENCEなどの構造に限る。この規律はメッセージの外枠、PDU、内部オブジェクトまで及んだ。

内側の契約は、管理操作の意味とバイト表現を共通にした。外側の契約は、宛先の文法と配送単位を各ネットワークに任せた。可搬性は、すべてを一つの道路に統一した結果ではない。共通にすべきものと局所に残すものを分けた結果だった。

だから、BERメッセージを取得した事実だけでは、どのドメインを通ったかは分からない。逆に、アドレス対を読めても、メッセージが実際に送られたとは限らない。二つの層は別の観測記録を必要とする。

後継仕様は対応関係を明文化した

1996年のRFC 1906はRFC 1449を置き換えた。各トランスポート・ドメインをOBJECT-IDENTITYとして記述し、その説明文で対応するアドレス型を明示した。UDPはSnmpUDPAddress、OSIはSnmpOSIAddress、DDPはSnmpNBPAddress、IPXはSnmpIPXAddressである。

これは単なる読みやすさの改善ではない。実装に対して、OIDと値の間に検証可能な関係があることを示した。二つのカラムを別々に保存できるだけでは不十分で、その組み合わせが許されたものかを確かめなければならない。

RFC 3417はさらにこの系譜を引き継ぎ、UDPマッピングを「UDP over IPv4」と明確に呼んだ。モジュールの改訂履歴には1993年の初版と1996年の明確化が残る。識別子が継続することで、古い値を新しい読者が勝手に別の意味へ変えずに済む。

ただし、仕様上の継続は導入の証拠ではない。IPXやDDPのドメインが標準に残っていても、調査対象の環境でそのスタックが動いているとは言えない。規格は「現れたときの読み方」を示す。稼働状況は現場が観測する。

解読の成功から装置の効果までは遠い

ドメインと値がそろえば、まず「このオクテット列は規約上このアドレスに展開できる」と言える。その次には、時点付きの割り当て記録が必要だ。経路を語るには転送判断、到達を語るには送受信の観測、相手を語るには交換に結び付いた認証が要る。

さらにアクセス制御が、どの主体にどの管理オブジェクトと操作を許したかを決める。応答が返っても、設定が永続化されたとは限らない。装置内部の値が変わっても、利用者が期待したサービス結果まで保証されない。

証拠の階段は次のようになる。

生のオクテット → ドメイン → 型付きアドレス → 選ばれたトランスポート → 観測された交換 → 認証された相手 → 許可された操作 → 測定された効果

左側の記録は右側の記録を代行しない。RFC 1449が解決したのは最初の型付けであり、ネットワーク全体の真実ではなかった。

特に深刻なのはドメインの恒久的な欠落だ。落ちた経路は後で再測定できる。誤ったデコーダーも、元のOIDとオクテットが残っていれば交換できる。判別子を捨てた歴史データは、当時どの文法が使われたかを後から検証できない。

典拠と限界

刊行状態と継承関係はRFC 1449のRFC Editor記録で確認でき、初期仕様はRFC 1449にある。次の改訂はRFC 1906、後継標準の状態はRFC 3417の記録とRFC 3417に示される。これらは型、マッピング、改訂史を裏付けるが、製品実装、現在の導入、通信量、障害、成功結果を証明しない。