要約

  • revision 05は、通常の応答元アドレスだけではノードを十分に識別できない場合に、IPアドレス、ノード名、または両方を特定のICMPエラーへ加える方式を提案する。
  • IETF Last Callは2026年9月22日に終了したが、文書はなおIESG審議中のInternet-Draftであり、承認済みRFCでも導入実績でもない。
  • ノード名はトポロジーを漏らし得るため原則として既定で無効が推奨され、拡張そのものに認証機構はない。

同じIPv4アドレスから複数の装置が見える

IPv6だけで構成された転送基盤がIPv4ルートを運ぶとき、中間ノードごとに固有のIPv4アドレスを用意する必然性はない。tracerouteへのICMP応答が共有アドレスから返れば、画面上の一行はホップの存在を示しても、どのノードが処理したかを確定できない。

ICMPノード識別の草案は、この不足を追加オブジェクトで補う。そこには、文脈に応じたスコープのIPv4またはIPv6アドレスと、最大63オクテットの人間可読な名前を格納できる。片方だけでも両方でもよい。

重要なのは、外側の応答元アドレスと追加された識別情報が別の証拠だという点だ。前者はパケットがどう返ってきたかを示し、後者はどのノードがエラーを生成したかについての主張を示す。便利だからといって、この二つを一つの認証済みIDへまとめてはならない。

Last Callの終了は最終状態ではない

IESGは9月8日に最終コメントを募集し、期限を9月22日とした。9月24日のDatatracker APIでは、revision 05はActive、Submitted to IESG for Publication、Waiting for AD Go-Ahead、IANA OK - Actions Neededという状態を持つ。公開ページには10月8日のIESG telechat予定も表示される。

これらは工程の記録であり、承認結果ではない。文書は現在もInternet-Draftで、2027年3月11日に失効する予定だ。telechat後に修正が求められる可能性もある。仮にProposed StandardとしてRFCになっても、特定製品の実装、設定の有効化、運用効果は別途確認する必要がある。

IANAのICMPレジストリにはClass Value 5がNode Identification Objectとして掲載され、以前の個人草案を参照している。番号の存在はパーサー間の調整には役立つが、revision 05の承認や実装の存在を証明しない。

既存のICMP拡張に収まる新しい意味

提案はRFC 4884の拡張構造を使う。対象はICMPv4のTime Exceeded、Destination Unreachable、Parameter Problemと、ICMPv6のTime Exceeded、Destination Unreachableに限られる。

アドレスは運用者が理解できるローカルスコープでもよい。名前にはYANGのsys:hostnameか、別の意味ある名称を使える。アドレスを先、名前を後に置く順序やパディング、切り詰めが規定され、受信側はバイト列を解釈できる。しかし解釈可能性は、値を設定した主体の証明ではない。

RFC 5837が識別するのはインターフェースや次ホップである。今回の対象はエラーを起こしたノードだ。入力インターフェース、出力インターフェース、次ホップ、ノードを別々に残すからこそ、観測の意味を追跡できる。

背景には、IPv6次ホップでIPv4ルートを運ぶ方式と、XLATがダミーIPv4アドレスとノード識別を併用する案がある。RFC 7915とRFC 6877は翻訳処理の土台を説明するが、新オブジェクトの普及状況を示すものではない。

名前を出す相手を決める

装置名は障害対応を速める一方、場所、役割、階層、冗長構成を外部へ伝える可能性がある。草案はこのため、指定されたトランスレーターの例外を除き、追加情報を既定で無効にするよう勧める。宛先アドレスに応じて送る項目を変え、ACLで受信者を制限することも想定している。

実装の有無だけではポリシーにならない。内部コレクターには名前とアドレスを出し、顧客向け診断にはアドレスだけを出し、任意の外部ホストには何も出さないという区分が必要になる。ULAは内部では正確でも外部では意味を失う。切り詰められた名前から識別に必要な末尾が消える場合もある。

正しい形式でも真正とは限らない

草案は認証機構を定義しておらず、ICMPの内容は容易に偽装され得ると明記する。RFC 4884のチェックサムは構造上の破損を検出できても、名前の作成者を証明しない。

運用記録には、生のパケット、時刻、観測地点、元のプローブ、外側の送信元、サブオブジェクト、期待した開示ルール、ソフトウェア版を残すべきだ。認証された管理テレメトリー、設定、別地点からの再試行は照合材料になるが、最初のICMPフィールドを後から暗号学的IDへ変えるわけではない。

Running-Code Primacyは実際に動く系での確認を求める。Minimum Initial Specification and Localized Future Decisionは共通形式と各運用者の将来判断を分ける。Reality Layers and Symbolic Powerは、レジストリの記号が導入や結果を代弁する危険を示す。

出典