要約

  • RFC 2011 は MIB-II の残る IP/ICMP オブジェクトを SMIv2 で定義し直し、ipGroup と icmpGroup を必須とした。一方、IESG Note は IpAddress が4オクテットで IPv4 にしか対応しないと明記した。
  • 表を読めることやカウンタが増えることは、その定義済み集合の内部では証拠になる。IPv6 のアドレス、プレフィックス、経路、隣接、設定結果、障害原因まで見えた証拠にはならない。
  • RFC 2465 は IPv6 用の別の管理面を設け、RFC 4001 はアドレス種別と値を対にし、RFC 4293 は両系統を統合した。いずれも実装、索引、収集側の移行を必要とした。

「見えない」をエラーにしないモデル

RFC 2011 の冒頭には珍しく率直な IESG Note がある。当時の IP、UDP、TCP MIB は IPv4 のみを扱う。SMIv2 の IpAddress が32ビットのアドレスを4オクテットで表すため、128ビットの IPv6 は扱えない、と説明する。

重要なのは、IPv6 を問い合わせてエラーになる、という話ではない。ipAddrTable は ipAdEntAddr を行の索引に使い、ネットマスクも同じ IpAddress 型で持つ。ipNetToMediaTable の行もネットワークアドレスをこの型で識別する。表の世界に IPv6 の行を表す座席がない。従って、空欄や警告が返るとは限らない。問い合わせ自体が、その不在を問えないのである。

ここに「適合」の落とし穴がある。モジュールが正しく読み込まれ、必須グループが実装され、認可された GET に値が返れば、RFC 2011 に対する適合判定は妥当だ。それをノード全体の IP 可視性へ拡張した瞬間に、判定の主語が入れ替わる。

何を数えたかを忘れない

この RFC は SNMP の全史を作り直した文書ではない。MIB-II の IP/ICMP オブジェクトのうち、経路管理を除く残りを SNMPv2 の枠組みに移した。経路は RFC 1354 で別に更新されており、IP-MIB の説明にも route management を除外するとある。

適合条件は ipGroup と icmpGroup だった。転送可否、既定 TTL、入出力、再構成、断片化、アドレス、メディア対応、経路エントリ破棄、ICMP の各種メッセージを観測できる。幅広い。しかし各カウンタには別の母集団がある。

例えば ipInReceives はエラーを含む受信データグラムを数える。ipInDiscards は処理上の問題がないのに捨てたデータグラムを数えるが、再構成待ちの破棄を含まない。ipOutNoRoutes は経路が見つからない場合に限る。ipReasmFails は失われたフラグメント数と一致するとは限らない。数字の増加は、定義された現象の発生を示す。パケットの身元、アドレスファミリ、サービス影響、原因は別の証拠である。

書き込み可能な値も同様だ。ipForwarding、ipDefaultTTL やネットワーク‐メディア対応行への操作が受理されても、誰の承認か、再起動後も残るか、どのスタックが利用したか、実際の転送や到達性が変わったかは、応答だけから決まらない。

二つの管理面をどう結び直したか

RFC 2465 は4オクテット型を延命せず、IPv6 General group を別に定義した。インターフェース、統計、プレフィックス、アドレス、経路、ネットワーク‐メディア対応の六表を持ち、IPv6 アドレスは16オクテットで表した。SMIv2 自体を変更しなくても実装できる構成だった。

その結果、デュアルスタック運用では「両方があるか」を管理する必要が生じた。エージェントがどの MIB を実装するか、コレクタがどの OID を歩くか、インターフェース ID をどう対応させるか、統計をファミリ別に保持するか。RFC 2011 適合は IPv4 側の証拠として残るが、IPv6 側の存在証明にはならない。

RFC 4001 はアドレスを InetAddressType と InetAddress の対として扱った。索引では種別が先に置かれ、値の長さとオクテットが続く。これは形式を明示する改善だが、compliance statement が一部のアドレス種別だけを要求することも許す。汎用型を採用したという宣言と、全ファミリが実装されたという事実は、なお分かれている。

RFC 4293 は2006年、RFC 2011 と IPv6 MIB 群を廃止して、IP バージョン非依存の一つの MIB に統合した。統計はアドレス種別で分けられ、アドレス、プレフィックス、既定ルータ、物理隣接の表も組み直された。

文書は移行費用を隠していない。旧 ipAddrTable と新 ipAddressTable の差は大きく、新規コードの方が修正より容易かもしれない。新しい索引を扱う SNMP ルーチンと、新しいカウンタ用の計装が必要だという。標準化は目的地を示したが、エージェント、収集設定、保存形式、アラート、手順書を自動で移したわけではない。

出典

証拠の限界

確認できるのは仕様の状態、型、適合グループ、後継設計である。特定ベンダーの欠陥、普及率、現在の障害、実ネットワークの監視範囲、SLA、移行日を示す資料ではない。