要約

  • RFC 3542 は、ソケットに保持されるIPv6の既定オプションと、一つのメッセージに付随する補助データを分けた。補助データが上書きするのは同名の既定オプションだけで、他の設定は有効なまま残る。
  • この仕組みには境界がある。長さゼロの補助データは一つのデータグラムで一項目を無効にできる一方、すでに受信キューに入ったパケットには新たに要求したメタデータがない場合があり、TCPの送信呼び出しは個々の転送セグメントと一対一には対応しない。

診断トラフィックを送る長寿命のUDPソケットを考えてみよう。アプリケーションは出力インターフェースを選び、各データグラムに適用するIPv6オプションを設定している。そのうち一つのメッセージだけ別の経路を通したい。ここでメッセージ用の補助データを「既定値一式の置換」と解釈すると、望んだ経路に乗る代わりに、変更するつもりのなかった設定まで失われかねない。

2003年5月に Advanced Sockets Application Program Interface (API) for IPv6 として発行されたRFC 3542は、この範囲を明文化した。これはInformationalなメモであり、ネットワーク上のパケット形式を定める標準ではない。対象はアプリケーションとカーネルの間にあるインターフェースだ。プログラムが何を要求できるかを定めても、ネットワークが実際に何を送ったかまでは保証しない。

置き換えられたRFC 2292との比較が、変更の理由を示す。旧APIでは永続的なオプションが一つの集合として設定され、メッセージに添える補助データがその集合全体を置き換えることがあった。RFC 3542はオプションを分離し、それぞれを個別に指定できるようにした。状態を個別に扱えるようになれば、上書きも個別の範囲に限るべきである。同じ種類のオプションだけを置き換えるのが新しい規則になった。

これは単なる実装上の作法ではない。例外がどこまで効いてよいかという境界の定義だ。出力インターフェース、トラフィッククラス、拡張ヘッダーの扱いをソケットが保持しているとき、経路変更用の補助データが他の設定まで消す権限を持つわけではない。カーネルは永続状態と狭い例外を組み合わせてデータグラムを構築する。その構築処理が成功したことと、実際に送信されたパケットを観測したことは別の証拠である。

この規則は、特定の項目だけを一時的に無くす要求にも対応する。アプリケーションが IPV6_HOPOPTS を既定値として設定し、一つのメッセージに同種で長さゼロの補助データを付ければ、そのデータグラムではHop-by-Hop Optionsヘッダーを省ける。ゼロは「すべての既定値を忘れる」という意味ではない。名前の付いた一項目を一度だけ無効にする指定だ。別の変更がなければ、次のデータグラムは保存済みの既定値に戻る。

受信では時間が問題になる。アプリケーションが IPV6_RECVxxx オプションを有効にすると、recvmsg() は得られた情報を補助データとして返す。期待した項目がなければ、パケットにその情報がなかった可能性はある。しかしRFC 3542は、受信オプションを有効にする前からキューにあったデータグラムには、新しいメタデータが付かない場合もあると注意している。情報の欠落はワイヤ上の内容だけでなく、観測を始めた時点にも由来しうる。

TCPはデータグラムとの類推に限界を設ける。アプリケーションの一回の送信呼び出しと、ネットワーク上の一つのTCPセグメントは対応しないため、RFC 3542はTCPについて同じ「送信ごとの補助制御」を定義しない。再送セグメントが新旧どちらのソケット設定を使うかは確定しない。TCPではメッセージ単位に観測できない境界を仕様が作り出すことはできない。また、TCP受信時の一部の任意情報も未定義であり、アクセス制御の根拠にしてはならないと警告している。

歴史的な例には時代の注記も必要だ。RFC 3542にはRFC 2460時代のRouting Header Type 0の例がある。現在のIPv6基本仕様はRFC 8200であり、旧文書の例は当時のAPI表現を示す資料であって、現在の経路制御の推奨ではない。

RFC 3542の歴史的な意味は、例外の範囲を小さくしたことにある。RFC 2292での集合全体の置換から、同名オプションだけの置換へ移った。動作を検証するには、呼び出し前のソケット設定、メッセージに付けた補助データ、観測されたデータグラム、下流の結果を別々に記録しなくてはならない。sendmsg() が成功しても、それはAPIが意図を受け取った証拠であり、データグラムが想定した経路を通った証明ではない。

出典