要約

  • RFC 9868 は UDP Length が宣言するユーザーデータの後ろにオプション領域を設ける。追加バイトは拡張用の封筒であり、アプリケーション本文ではない。
  • オプション検証が失敗した場合、既定ではオプション領域を捨て、検証済みのユーザーデータは渡す。より厳しい拒否はアプリケーションまたはライブラリが明示して初めて成立する。

UDP の長所は、約束を増やしすぎない点にある。ヘッダーはポート、誤り検出用チェックサム、長さを持つが、セッションも相手の身元もアプリケーション成功も作らない。既存の UDP を置き換えずに輸送層に近い機能を加えたいとき、その簡素さは制約にもなる。2025 年 10 月の RFC 9868 は、UDP Length が IP ペイロードの終端より前で終われるという既存の事実を使う。

UDP ユーザーデータの後ろ、IP データグラムの終端の前にある部分を、この RFC は surplus area と呼ぶ。そこにトランスポート・オプションを置く。配置は単なる形式ではない。オプションのバイト列はアプリケーションのメッセージへ混入せず、存在するだけでアプリケーションが新しい意味を承諾したことにもならない。UDP Length がユーザーデータの終端を指し、その後は別の解析・完全性規則に従う。

これは UDP を別の性格へ変える仕様ではない。RFC は soft control plane と表現する一方、UDP は依然として状態を持たず一方向であり、オプションは完成したプロトコルではなく枠組みだと明記する。オプションは能力を定義できるが、双方向の取り決め、継続する関係、共通の成功判定を単独では生まない。それらは別の仕様と採用するエンドポイントが定める。

互換性の扱いが重要である。SAFE オプションは、理解しない受信者が無視してもユーザーデータやその意味を変えないよう設計される。オプション対応受信者は未知または不正な SAFE オプションを静かに無視する。データの意味を変え得る UNSAFE オプションには制限があり、存在する場合、通常の UDP ユーザーデータは空でなければならず、輸送ペイロードは FRAG オプションに置かれる。

オプション・チェックサムはこの線を実務上の証拠にする。宣言済みデータを守る UDP チェックサムとは別に surplus area を保護する。検証に失敗した受信者は全オプションを無視し、その領域を静かに捨てる。UDP チェックサムが正しいユーザーデータは、オプションがなかった場合と同じように渡されなければならない。失敗が示すのは拡張封筒についてであり、アプリケーション・メッセージへの自動判定ではない。

既定が互換性を優先するのは意図的である。フラグメントを除けば、オプションのチェック、認証、復号に失敗しても受信パケットは通常ユーザーへ渡る。失敗で配送を止めたり変えたりしたいアプリケーションは、既定を明示的に上書きする必要がある。輸送層はオプションの異常を報告できるが、DNS リゾルバー、テレメトリー受信機、制御装置が他は妥当なデータを拒否すべきかまでは知りえない。

したがって「UDP パケットを受信した」だけでは証拠にならない。IP と UDP の長さ、オプションの種類と順序、解析結果、ある場合の OCS/APC/AUTH/UENC、受信者ポリシー、アプリケーション結果を分けて記録する。正しいチェックサムは送信者の身元や権限を証明しない。認証用オプションの存在も、特定の導入で有効だったことやアプリケーションが処理を受理したことの証明にはならない。

Touch への帰属にも限界がある。IETF の公開プロフィールは RFC とレビューの活動を示し、RFC 9868 は共同著者としての寄与を示す。それは全 UDP 実装や中間装置、アプリケーション方針を支配する権限ではない。この仕様の価値は、その権限を装わない点にある。封筒を観測可能にし、データ境界を残し、意味を知るエンドポイント・アプリケーションへ結果を委ねる。

出典