要約

  • RFC 5320 は外側 IPv4 の断片化を制御ループの入力にする。出口が報告し、入口が SEAL_ID の送信窓と照合し、次の世代の S_MSS を変える。
  • 証跡では、プローブの意図、32 ビットまたは 16 ビットの識別方式、観測、更新、IPv4 再構成、SEAL 再構成、上位層への受け渡し、Experimental 文書としての限界を分離する必要がある。

狭い場所に当たったことと、経路が分かったことは違う

仮想トポロジーの中では、物理リンクごとに MTU が異なり得る。SEAL は外側 IPv4 を通常 DF=0 で送り、途中のルータに断片化を許す。出口がその事実を入口へ返し、入口は断片化が収まるまで後続の SEAL セグメントを小さくする。

この発想の価値は、故障として捨てられがちな現象を測定に変える点にある。しかし、測定の意味まで変わるわけではない。最初の断片は、あるパケットがどこかで小さい境界に遭遇したと示すだけだ。リンク名、恒久的な経路 MTU、残りの断片の到着、アプリケーションの受領は示さない。

「断片化報告を受理した」を「経路を検証した」と表示すれば、局所的な事実に過大な権限を与える。前者は次のサイズ変更を許す。後者には別の観測が要る。

NAT の前後で識別子の契約が変わる

通常モードの SEAL_ID は 32 ビットである。上位 16 ビットは SEAL ヘッダの ID Extension、下位 16 ビットは外側 IPv4 Identification に置かれる。入口は出口ごとのソフトステートを乱数で初期化し、パケットごとに 2^32 を法として増分する。

IPv4 NAT を通る場合、変換器が外側 Identification を書き換え得る。そのため NAT モードでは ID Extension の 16 ビットだけを追跡し、2^16 を法として増分する。外側 Identification には乱数を入れる。

証跡がモードを残さなければ、NAT 後の二つの値を連結して、誰も維持していない 32 ビットの同一性を作ってしまう。それでも正しい一致が証明するのは、報告が最近の送信状態に対応することまでだ。内容の正しさ、配送、経路の暗号学的な認証ではない。

S_MRU と S_MSS は同じ MTU の別名ではない

入口は出口ごとに二つのソフトステート値を持つ。S_MRU は最大 2 KB で初期化され、出口に要求する再構成能力を制限する。S_MSS は SEAL セグメントの大きさを制限し、下位 IPv4 インターフェースの MTU から外側のオーバーヘッドを引き、S_MRU/8 に関係する下限も用いて決める。

これらを一つの「トンネル MTU」にすると、責任の違いが消える。S_MRU は再構成の義務、S_MSS は送信単位である。報告が S_MSS を変えても、内側パケットの同一性や送信元から見えるインターフェース MTU が自動的に変わるわけではない。

大きすぎる内側の非断片化パケットは捨てられ、元の送信元へ PTB が返る場合がある。したがって、台帳にはインターフェース MTU、各層のオーバーヘッド、S_MRU、S_MSS の値と世代、内側長、断片化可否、選択した動作を別々に残す。

三種類の切断には三種類の責任がある

SEAL は中間層パケットを最大八つの重ならないセグメントに分けられる。最終以外は同じ長さで、最終はそれより大きくない。More Segments ビットと三ビットの番号が列を記述し、出口は上位層へ渡す前に元の中間層パケットを戻す。

これは内側 IPv4 の断片化ではなく、途中のルータが外側 IPv4 を断片化する行為でもない。三者は実行者、識別情報、再構成地点、回復動作が異なる。単一の fragments カウンタでは、どの契約が使われたか説明できない。

外側 IPv4 の再構成に成功した後で、SEAL の再構成が失敗することもある。SEAL の再構成後に上位層が拒否することもある。前段の成功を後段の成功として埋めてはならない。

R と A は別の問いを投げる

入口がゼロ番セグメントに R=1 を設定すると、外側 IPv4 が断片化された場合の報告を要求する。A=1 は応答要求である。明示的なプローブはデータでも、No Next Header を持つ NULL パケットでもよく、その SEAL_ID は未完了送信の窓に置かれる。

R と A が同時に設定されて断片化が起きても、出口が返す Fragmentation Needed は一つである。二つの独立した確認が生まれるわけではない。同じ応答が複数の意図を満たすため、送信理由を保存しなければ意味を復元できない。

応答がないことも一意ではない。出口が非確認型の報告をレート制限したかもしれず、プローブか応答が失われたかもしれず、本当に断片化しなかったかもしれない。沈黙は原因を選択しない。

短すぎる最初の断片は限界値ではない

カプセル化されていない ICMP は、偽造や引用不足があるため弱い助言として扱う。現在の窓に一致する SEAL 内の報告は、対応関係を強くする。それでも制約リンクの MTU を直接示すとは限らない。

ルータは極端に短い先頭断片を作ることがある。runt fragmentation の長さをそのまま MTU と見なせば誤学習になる。RFC 5320 は反復的に縮小し、新しい世代で送って再び観測する。

同じ世代で最初に適用できる報告だけが S_MSS を変更すべきである。後続の古い報告は、新しい現実を表す命令ではない。新しい値で試した後にのみ、次の変更を判断できる。

nonce は相関の範囲を狭めるが、経路に署名しない

nonce、識別子、最近の送信窓は、任意の ICMP に従う危険を減らす。だが IPsec がなければ SEAL ヘッダは平文になり得るし、レイヤー2の完全性は局所的な隣接しか守らない。仕組み全体を合わせても、エンドツーエンド経路の証明にはならない。

正確な表現は「生きている送信記録に関連付けられたフィードバック」である。NAT モード、ソフトステートの epoch、窓、サイズ世代、プローブ種別も必要だ。「認証済み経路」と短縮すると、時間的な相関を安全保証へすり替える。

有効な報告の後でも再構成は失敗できる

出口は再構成の高水位、重複、欠落、順序の乱れ、メモリ圧力を扱う。待機は 15 秒で期限切れになる。不完全な集合は、入口へ有効なフィードバックが返った後でも破棄され得る。

証拠は、カプセル受信、外側 IPv4 再構成、SEAL セグメント再構成、上位プロトコルへの受け渡し、最終結果の観測という別々の欄に置く。調整ループの成功をアプリケーション配送の成功として扱わない。

Experimental は制度上の制限である

RFC 5320 は 2010 年 2 月の Independent Submission Stream による Experimental 文書である。IESG の注記は通常の IETF 合意形成を経ていないことを明示する。SEAL_PROTO、SEAL_PORT、SEAL_OPTION は実験用で、出荷製品や通常配備で使ってはならない。

後年の IPv4 Identification、断片化、PMTUD、DPLPMTUD に関する文書は評価の背景を与えるが、SEAL を遡って標準に変えない。RFC 番号は文書の身元であって、運用許可証ではない。

最小の決定証跡

時刻、入口と出口、32/16 ビットモード、ソフトステート epoch、SEAL_ID、R、A、NULL またはデータ、送信サイズ、活動中の窓、S_MRU、S_MSS の値と世代、観測断片、報告経路、許可された調整、二段階の再構成と上位層移送の個別結果を残す。

適応は、自分を教えた症状を減らす。最後の数値だけを残せば、静かになったネットワークほど理由を説明できなくなる。狭い事実を狭いまま保存することが、制御ループを運用可能にする。

出典