要約

  • draft-ietf-intarea-extended-icmp-nodeid-05は、担当Area Directorのレビューを受けて2026年9月7日に公開された。Datatrackerの状態はLast Call Requestedであり、Last Call完了でもRFC化でもない。
  • 新文面は、通常の応答IPアドレスだけではノード識別に足りない可能性がある場合、ローカル方針またはセキュリティ上の判断が優先しない限り、識別オブジェクトを必須とした。一方、IP/ICMP変換器を除き、既定では無効にすべきだという記述も残る。
  • 一方は開示機能をどの範囲で有効にするか、他方は許可された範囲の各パケットをどう扱うかを定める。どちらも、運ばれた名前を認証情報にはしない。
  • Daniel Kadeは、設定、適用条件、例外、宛先、MTU、送信バイト列、観測バイト列を結ぶ版管理された実装判断表を提案する。これはIETFの現行要件ではない。

レビューがSHOULDを問い直した

9月7日のI-D告知は、第05版をInternet Area Working Groupの作業項目として掲載した。DatatrackerではActive Internet-Draft、想定ステータスはProposed Standard、WG側はIESGへ出版申請済み、IESG側はLast Call Requestedとなっている。telechat日は未設定だ。現時点のニュースは標準の成立ではなく、次の審査へ向けた本文の更新である。

変更の起点は、Éric Vynckeが2025年10月に送ったArea Directorレビューにある。第3節のSHOULDについて、従わなくてよい条件を説明するよう求めた。さらにdomainの意味、将来ビットの処理、MTUとフラグメントの扱い、IANAサブタイプ登録簿の明示的な新設要求も論点にした。

04版と05版の差分を見ると、応答は具体的だ。04版は、ノード識別に必要で、方針やセキュリティが優先しない場合に拡張を付けるべきだとしていた。05版は、応答IPアドレスだけでは足りない可能性があるとき、同じ例外がなければオブジェクトを付けなければならない、と改めた。無条件での付加も認め、「ドメイン内」は「適切なスコープ」へ置き換えられた。

規範語は強くなったが、裁量が消えたわけではない。「アドレスが十分か」という条件と、方針・セキュリティという例外に移った。その判定履歴がなければ、MUSTを試験することも、例外の正当な利用を説明することもできない。

名前を運ぶ仕組みと、身元を証明する仕組みは別だ

Node Identification Objectは、RFC 4884のマルチパートICMPを使う。対象となるICMPv4のTime Exceeded、Destination Unreachable、Parameter Problemと、ICMPv6のTime Exceeded、Destination Unreachableに、Class 5のオブジェクトを追加できる。中身はIP Addressサブオブジェクト、Nameサブオブジェクト、またはその両方だ。

ビット配置は、インターフェースとネクストホップを扱うRFC 5837に合わせ、生成・解析コードを再利用しやすくしている。IPアドレスは「適切なスコープ」でノードを見分けられればよい。IPv6 ULAのようにローカルでしか意味を持たないアドレスも、その運用ドメインに対応表があるなら利用できる。

Nameは、パディングを含め64オクテット以下、実質の名前は最大63オクテットである。適切ならRFC 7317のYANG sys:hostnameを使い、別の人間可読名も許す。05版は、UTF-8の複数オクテット文字を途中で切らないという規則を追加した。

用途は明確だ。IPv6だけを使う中継ノードがIPv4 tracerouteに答える場面では、ノードごとに異なるIPv4アドレスがないことがある。IP/ICMP変換器が変換前の送信元アドレスを添えれば、ドメイン運用者は通常の応答アドレスだけより詳しく発信元を対応付けられる。

しかし、対応付けと認証は違う。草案は認証機構を規定しておらず、ICMPメッセージとその内容は容易に偽装できると明記する。資産台帳に似た名前が入っていても、それは未認証メッセージの自己申告だ。Class 5は読み方を定めるだけで、装置の所有者、運用主体、経路権限、障害責任を証明しない。

入口の設定と、入口を通った後の義務

「既定で無効」はセキュリティ節にある。意味を含むノード名は内部情報を漏らし得るため、追加動作は設定可能で、IP/ICMP変換器を除けば既定で止めるべきだという。宛先IPアドレスやACLに応じて送るサブオブジェクトを変えることもできる。これは、誰に何を見せるかという入口の統治である。

第3節のMUSTは、その入口を通るメッセージに働く。通常の応答IPではノード識別に足りない可能性があれば、方針またはセキュリティの優先判断がない限り追加する。こちらは個々のパケット処理だ。

この二段階の読み方は本稿の分析であり、IETFによる正式な適合性解釈ではない。草案は「十分」を計算式にせず、組織内で例外を承認する役職を指定せず、欠落理由をパケットに載せない。結果が同じ「オブジェクトなし」でも、通った枝は異なり得る。

空欄を一つの意味に固定してはいけない

収集装置がNode-IDのないTime Exceededを受け取ったとする。通常の送信元アドレスが十分だったのかもしれない。既定値のまま機能が止まっていた可能性もある。外部宛てを止めるセキュリティ方針、管理用宛先だけを許すACL、未実装のソフトウェア、復路上のフィルタリングも、それぞれ別の説明になる。

変換器にはMTUという明文の分岐がある。オブジェクト追加で下位MTUを超えるなら、RFC 4884の制約内で引用された元データグラムを短くする。それでも収まらなければ、オブジェクトを付けてはならない。この正しい省略も、受信側からはプライバシー方針による省略と同じに見える。

存在する場合も過信できない。名前が本当にsys:hostname由来か、最新か、一意か、その名の装置から送られたかは、構文だけでは分からない。観測基盤は、受信した自己申告値、ローカル台帳との照合、運用主体の推定、認証結果を別々に保持すべきである。

現在のIANA ICMP ParametersはClass 5をNode Identification Objectとして掲載し、参照先は古い個人草案のままだ。05版はサブタイプ登録簿の作成を求め、将来ビットをRFC 8126のStandards Actionに委ねる。コード割当ての統制は相互運用性を守るが、値の出所を認証するものではない。

実装判断表はネットワーク秘密の公開表ではない

必要なのは、製品版と方針版に結び付いた試験表だ。各行に、発信元ノードか変換器か、アドレスファミリー、ICMPタイプ、通常の応答アドレスを十分と判断する規則、機能設定、方針・セキュリティ例外、その決定責任者を記す。

続けて、宛先またはACLの区分、許可されるサブオブジェクトとスコープ、MTU判定、元データグラムの短縮、欠落理由、実際に送ったバイト列を置く。受信側は観測地点と時刻、受け取ったバイト列を別欄に残す。認証欄は独立させ、外部の証拠がなければ「本草案ではなし」とする。

公開試験には合成名、設定ハッシュ、粗い宛先区分を使える。内部ホスト名やACL本文を公開する必要はない。開示を増やすための表ではなく、開示しなかった理由と送った結果を混同しないための表だ。

出典