要約

  • RFC 3419では、トランスポートのエンドポイントは型と値の組だった。TransportAddressは、対応するTransportDomainまたはTransportAddressTypeがあって初めて解釈できる。
  • 不明は長さゼロとして保存され、スコープ付きIPv6にはゾーン索引が付き、SCTPの値は通常プライマリアドレスだけを示す。仕様は欠けた事実を推測で埋めなかった。

「六オクテットだからUDP」という近道

管理表から六オクテットの値を取り出したプログラムが、四オクテットをIPv4アドレス、残りをポートとして表示する。形式はもっともらしい。しかし同じ配置はUDPにもTCPにも使える。ドメインを捨てた瞬間、表示は具体的になっても、記録の意味は薄くなる。

2002年11月の RFC 3419 は、この小さな落差を標準化の対象にした。IPアドレスを新設した文書でも、SNMPの新しい配送方式を定めた文書でもない。MIB内のアドレスを、それを解釈する型と離さないためのテキスト規約である。

この設計では、バイト列は値にすぎない。ドメインがアドレス族、トランスポート、ポート配置を与える。後から観測したパケット、成立した接続、認証済みの相手、稼働中のサービスは、さらに別の記録である。画面上の一つの欄に収まるからといって、同じ証拠にはならない。

拡張できるOIDと小さな列挙値

RFC 3419は型の表現を二つ用意した。TransportDomainはオブジェクト識別子であり、新しいドメインを別のOIDとして追加しやすい。TransportAddressTypeは列挙型で、短く扱いやすい反面、新しい値は共有された番号空間で調整しなければならない。

対応するTransportAddressはオクテット列で、基本型は長さゼロから255までを許す。ゼロは未知のアドレスを意味する。ここで空値をエラーにせず、「不明」という状態として保つことに意味がある。入力欄を埋めるために0.0.0.0や既定のアドレス族を作る必要はない。

個別の型は長さと配置を限定する。IPv4とポートは四プラス二の六オクテット、IPv6とポートは十六プラス二の十八オクテットである。UDPとTCPが同じ配置を採っても、異なるドメインである。バイトが一致しても、エンドポイントの同一性までは証明しない。

仕様がMIB作者に対し、各アドレスのそばにドメインまたはアドレス型を置くよう勧めたのは、見栄えのためではない。行ごとに読み方を保てば、一つの表が複数の族とトランスポートを扱っても自己記述性を失わず、将来の拡張が過去の値を変質させない。

ゾーン索引はローカル性を消さないためにある

IPv6のスコープ付きアドレスは、「アドレスだけで十分」という発想の弱点をはっきり示した。複数のリンクやゾーンにつながる装置では、同じリンクローカルアドレスが別々の場所に現れ得る。そこでRFC 3419は、十六オクテットのアドレスと二オクテットのポートに、四オクテットのゾーン索引を付ける形式を定めた。

ゾーン索引は世界共通の名前ではない。解釈する装置や管理文脈にローカルである。だからこそ証拠から落としてはいけない。消せば異なるゾーンが衝突し、そのまま世界共通IDのように外へ出せば別の誤認を生む。RFC 4007 は後にIPv6スコープの体系を詳述し、RFC 4001 は複数のアドレス規約を更新した。それでも原則は変わらない。スコープは完全なアドレスへの注釈ではなく、解釈そのものの一部である。

汎用ドメインとSNMP専用ドメイン

RFC 3419は、一般のトランスポートドメインと、SNMPがそのトランスポート上で動くことを明示するドメインも分けた。汎用のUDP/IPv4とsnmpUDPDomainは似たバイトを扱えても、前者は管理対象サービスのUDP端点を表せるのに対し、後者はSNMPメッセージの運搬を述べる。

相互運用のため両方を受け付ける場面があっても、意味まで同じにはならない。バイト配置だけを根拠に汎用ドメインをSNMPドメインへ変換すれば、「端点が記録された」が「SNMPがここで動く」へ無断で強化される。RFC 3417 はSNMPトランスポート写像を、RFC 3419は再利用できる型を担う。近接した仕様は同一の証拠ではない。

SCTPの主アドレスは経路一覧ではない

SCTPでは、一つのアソシエーションが複数のアドレスを持てる。RFC 3419のSCTP用値が通常示すのはプライマリアドレスであり、マルチホームされた相手の全アドレス一覧ではない。RFC 4960 は後のSCTP基本仕様だが、管理情報の限界は既に明確だった。主ロケータを完全な経路集合へ昇格させてはいけない。

この区別を失うと、フェイルオーバー可能性を見落とし、トポロジーを誤り、障害を違う制御面へ帰属させる。記録は宣言された役割の範囲では正しい。問題はソフトウェアが役割を黙って広げることである。

表記が正しくても接続は証明されない

テキスト規約は表現を定義する。ソケットが待受中であること、パケットが届いたこと、相手が認証されたこと、サービスが成功したことは証明しない。設定上のTCP端点と実際に観測した接続は関連するが、同じ出来事ではない。未知の空値は停止を意味せず、構文が正しいアドレスはヘルスチェックにならない。

RFC 3419の歴史的価値は、ネットワーク管理が「型と値」という最小限の正直な記録を守り、その後の実行事実を別の受領書にした点にある。

資料と限界

一次資料は RFC Editor HTML、テキスト版、RFC Editor情報ページ、IETF Datatracker本文、履歴、参照関係、RFC Editor正誤表検索で確認できる。

SMIと適合性の背景は RFC 2578、RFC 2579、RFC 2580、SNMP枠組みの RFC 3410を用いた。アドレス史は RFC 3417、先行規約 RFC 3291、後継 RFC 4001、IPv6スコープ RFC 4007、URI構文 RFC 2396、SCTP RFC 4960、IANA SMI Numbersレジストリと照合した。分析上はHeng Luの実行コードを第一証拠とする論考と最小初期仕様の論考を参照した。

これらは定義と文書の継承関係を示すが、実装普及率、現在の到達性、製品動作、型を失ったために起きた事故件数は測定しない。