要約

  • RFC 3919はRMON-2エージェントがIPv6とMPLSの解析経路を共通の名前で表せるようにしたが、その名前が運ばれるサービス全体を説明するわけではない。
  • MPLSの定義には明確な限界が記されている。入口ではユニキャストとマルチキャストを区別できる一方、その子プロトコルは「体系的には識別できない」。

遠隔監視の出発点は、プローブがどの種類のパケットを認識できるかという問いだ。RMON-2のプロトコルディレクトリーは、エージェントが監視可能なプロトコルの一覧として答える。管理ソフトウェアは、カウンターやホスト・通信相手別の表を、名前の付いたカプセル化経路に結び付けられる。しかし、これはネットワーク全体のパケット目録ではない。管理者が行を追加しても、プローブが新しいデコーダーを学ぶわけでもない。RFC 2021のいう「限定的な拡張性」では、構成変更で解析を一段先に伸ばせるのは、その分配ロジックをソフトウェアがすでに実装している場合に限られる。

2004年10月に情報提供文書として発行されたRFC 3919は、IPv6とMPLSのプロトコル識別マクロを追加した。狙いはRMON-2エージェント間の相互運用性である。異なるプローブが同じパケット経路に互換性のない名前を付ければ、管理ツールはプロトコル別の結果を適切に比べられない。文書は、これらの識別子がなくてもRMON-2に準拠できると明記している。つまり共通語彙であって、新たな適合要件でも、すべての実装が対応していた証拠でもない。RFC 3919、RFC Editorの記録

文書内の対照が重要だ。IPv6では、次のプロトコルを1オクテットのProtocolフィールドから選べる。RFC 3919はICMPv6を番号58として示し、ネイティブIPv6のUDPと、IPv6をIPv4でトンネルした経路上のUDPとを別のプロトコル経路としている。ether2.ip6.udp と ether2.ip.ipip6.udp は同じ識別子ではない。どちらも終端はUDPだが、解析器が通過するカプセル化が異なるからだ。

一方、MPLSの記述は入口で止まる。RFC 3919は mplsu と mplsm を定義し、EtherType 0x8847 と 0x8848 によってユニキャストとマルチキャストを区別するほか、他のリンク形式の符号化も列挙する。その直後に両方の記述が、MPLSの子は体系的に識別できない、とする。これはMPLSがIPを運べないという意味でも、ラベルの後のパケットが一切解析できないという意味でもない。この識別子群が、MPLS項目の下に汎用の共有プロトコル木を定めていないという、より狭い限界である。RFC 3032

この境界があるから、ディレクトリーの名前が実際以上の約束にならずに済む。プローブが外側のフレームやMPLS入口を認識しても、ラベルスタックの先にある各ペイロードやサービスを、共通かつ安定した名前で表せるとは限らない。ルーティングラベル自体はプロトコル群を宣言しない。その解釈には別の仕組みと文脈が必要だ。RFC 3919はラベルだけから文脈を推定せず、別々のエージェントが同じ行に同一のローカル番号を割り当てるとも約束しない。

プロトコル名とインデックスも区別すべきだ。RFC 2895は protocolDirID とパラメーター文字列の符号化を定める。これに対し、計数テーブルは protocolDirLocalIndex を参照する。RFC 2021によれば、この整数の意味は個々のSNMPエンティティ内に限られる。これはそのプローブのディレクトリーを引くローカルな番号であり、別のプローブに転記して同じ意味だとみなせるグローバル識別子ではない。相互運用性を支えるのは記述規則の共有であって、各実装の番号が一致するという想定ではない。

RFC 3919が示すのは、こうした小さいが重要な境界だ。IPv6が標準化された次ヘッダー値を示すところでは、識別語彙はより深い解析経路を記述できる。一方、MPLSの子について同様の体系的対応がない枠組みでは、名前は外側の入口で止まる。能力一覧は管理者に次の問いを促すが、プローブが実際にパケットを見たこと、正しく解析したこと、特定期間に計数したこと、あるいはラベルの背後にある商用サービスを識別したことを証明しない。それらには実測記録と別の根拠が必要で、表の名前を長くしても補えない。

出典