要約

  • IETF Internet Area作業部会のICMPノード識別草案は、2026年9月28日に第06版へ更新された。現在はIESGで審査中のInternet-Draftであり、承認済みRFCではない。
  • 新しい規定は受信側のAFI判定を扱う。AFI 1なら32ビットのIPv4、2なら128ビットのIPv6として長さを求められる。それ以外では長さを決められず、ノード識別オブジェクトの処理を止め、そのオブジェクトがないものとして扱う。
  • 停止範囲はパケット全体ではない。RFC 4884の外側の長さ情報を使えば、後ろにある別のICMP拡張を処理し得ると草案は明記する。

読めない境界を推測しない

IPv4の経路検査にIPv6-onlyのノードが関わる場合など、ICMP応答の送信元アドレスだけではどのノードが答えたか判然としないことがある。Node Identification草案は一部のエラー応答にIPアドレスや名前を添える仕組みを提案する。ただし、それは運用上の手掛かりであって、送信者の暗号学的な認証ではない。

第06版が追加したのは、未知のAFIを受けたときの受信側の境界である。アドレス欄は可変長で、長さをAFIから求める。番号を知らなければ次の名前欄の開始位置も分からない。既知の長さを当てはめて読むのは、パケットが示していない識別情報を作り出すことになる。そこで草案は、Node IDオブジェクトの解釈を中止するよう求める。

一方、RFC 4884の拡張構造には外側の長さがある。内側を読み切れなくてもその領域を飛ばし、後続の拡張へ進む余地が残る。RFC 5837のAFIに関する将来の変更もこの草案に及ぶと書かれているが、任意の未対応番号を今すぐ解釈してよいという意味ではない。

第05版の記事とは別の判断

第05版には、この未知AFIの処理文はなかった。セキュリティ部門のレビューは、アドレスの長さが分からない場合に残りをどう扱うのかと問い、第06版の変更履歴は運輸・安全のレビューへの対応と記す。これは仕様上の問いへの回答であり、実際の攻撃や製品障害を確認した記録ではない。

以前のDaniel Kade記事は、識別情報をデフォルトで送るか、条件付きの送信義務をどう読むかを扱った。今回は送信可否ではなく、受信側がどこまで意味を認められるかが争点だ。

出典