要約

  • IETFのPROBE草案第05版は導入経験を追加し、pingとの比較がパケット形式の誤解を誘い、さらに成功に見えるクライアント表示を生んだ可能性を記録した。
  • 草案は説明を改善したが、運用側では結果コード、元の状態ビット、画面の表示名、その対応を証明する受入試験を一つの記録に結ぶ必要がある。

次の一行は、最後まで読む前に安心感を与える。

64 bytes from 192.0.2.2: icmp_seq=1 ttl=63 active=1 ipv4=0 ipv6=0

アドレスから応答があり、シーケンス番号とTTLが並ぶ。障害対応でpingを見慣れた人には、成功応答の形に見える。しかし末尾の二つのゼロは、確認したかったIPv4またはIPv6の状態が存在しない可能性を示す。

この危うさを明記したのがPROBE草案第05版の新しい付録である。人はパターン認識に長けているため、各項目を吟味せず成功と判断しやすい、と本文は説明する。これは表示上の小さな問題ではない。ネットワークが返した結果と、運用者が下す判断は別々の対象である。見慣れた外形が、明示的な権限もないまま両者に同じ意味を与えてしまう。

PROBEは別の問いを立てる

通常のpingは、送信元と宛先インターフェースの双方向到達性を調べる。PROBEはICMP Extended Echo Requestをプロキシ・インターフェースへ送り、別の対象インターフェースの状態を問い合わせる。対象はプロキシと同じノードにあっても、直接接続された隣接ノードにあってもよい。必要な双方向通信は送信元とプロキシの間であり、送信元と対象の間とは限らない。

したがって応答は単純な「到達した」ではない。ローカル対象では、Aビットがインターフェースの稼働を示し、別の二つのビットがIPv4とIPv6の稼働を示す。草案の表にある 1/0/0 は、インターフェース自体は稼働中だがIPv4もIPv6も動いていない状態である。別の結果コードは、不正な問い合わせ、対象インターフェースなし、表の項目なし、複数一致を区別する。

プロキシから応答が届いたことは、問い合わせが処理された証拠である。望む状態が存在する証拠ではない。通信の成功を運用上の成功へ置き換えれば、測定が勝手に判定へ変わる。

比喩はパケット形式にも届いた

新付録は実装の経緯も振り返る。2018年のRFC 8335はPROBEをpingに似たものとして紹介した。第05版によれば、その説明が実装者にパケット形式まで似ていると思わせたようだ。草案は、初期実装がRFC 4884の通常の拡張配置に反したと記す。

bis草案は導入済み動作との互換性を守るため、ICMP Extension StructureにInterface Identification Objectを一つだけ置き、任意データをその外側に続ける形を文書化する。同時に、他のICMP拡張用途はこの形を模倣すべきではないとする。既知のRFC 8335実装はすべて互換で、線上の動作変更や移行は不要だとも述べる。

ここから「すべての実装者が同じ誤りを犯した」とは言えない。一つの比喩だけで全経緯を説明することもできない。確認できるのは、親しみやすい説明が近道を促したように見え、その互換性コストが後継文書にも残ったという、より限定された事実である。

経験の記録は普及調査ではない

Datatrackerの履歴は第05版の公開を2026年9月6日UTCとし、文書の表紙は9月7日付である。サブステートはRevised I-D NeededからAD Followupへ移った。Proposed Standardを目指すInternet-Draftのままであり、RFCでもIESG承認でもない。

第04版との差分は、導入経験の付録が新設されたことを示す。担当Area Directorは5月、公共インターネットやミドルボックスを通過できたかを含む経験の追記を求めていた。新付録は、Extended Echoが初期状態で無効であり、厳しく管理されるべきだとする。多くの導入は、経路上のファイアウォールなどを同じ組織が管理する領域内になると見込む。公共インターネットの一部を越えた個別実験はあるが、広範な実験結果はない。

この限定が重要である。個別経験は導入率ではない。第05版はさらに、アドレスをユニキャストに限定し、AFI 1ならARP表、AFI 2ならIPv6 Neighbor Cacheを参照し、それ以外ならNo Such Table Entryとする。Flow Labelは規定しない。状態モデルは明確になったが、全ネットワークの動作が検証されたわけではない。

問う権限と表示の正しさは別である

草案には妥当な防御策がある。Extended Echoは初期状態で無効にし、診断アクセスが必要なノードだけで有効化する。送信元プレフィックスを認可済み管理ネットワークに制限し、要求をレート制限する。ネットワーク・インスタンス間の情報漏えいも禁止する。

これらは、誰が質問できるか、量はどこまでか、情報が越えてはならない境界はどこかを統治する。しかし、クライアントが答えを正確に表示したことは証明しない。正しく認可された問い合わせでも、急いでいる人には誤読されうる。

付録A.1はすでに、ゼロ以外の結果コードを完全なエラー文として表示し、A/IPv4/IPv6の組合せを明示的な文章にするよう示す。運用者はその先に、結果と表示の受入記録を置ける。対象識別子とローカル・隣接の別、結果コードと三つの生ビット、表示した文言と重大度、クライアントとサーバーの版、否定・曖昧・複数一致の試験ベクトル、表示対応を承認した人と日付を一緒に保存する。

この記録はDaniel Kadeの分析であり、IETFの要求ではない。成功したパケット交換が、存在しないサービス成功へ変換されていないことを後から証明するためのものだ。

比喩そのものを禁じる必要はない。状態モデルが分かれる地点で比喩を止めればよい。「pingのようだ」と書くなら、どこが違うかを試験で列挙する。pingの見た目を借りるなら、否定的状態を行末に隠さず、最初に目へ入る形にする。

情報源

  1. IETFの最近のInternet-Draft
  2. PROBE Datatracker
  3. 改訂履歴
  4. 第05版
  5. 第04版
  6. 公式04–05差分
  7. RFC 8335
  8. RFC 4884
  9. RFC 5706
  10. RFC 2151
  11. RFC 8343
  12. PROBEソース・リポジトリ
  13. 担当Area Directorによる第04版レビュー
  14. Lu Heng — Minimum Initial Specification, Localized Future Decision
  15. Lu Heng — Running Code Primary