要約

  • URGと緊急ポインタは第二のデータ経路を作らない。緊急情報は通常のTCPシーケンス空間にとどまる。
  • RFC 793には境界に関する二つの矛盾した規則があった。RFC 1122は「最後の緊急オクテット」を選び、その後RFC 6093が広く実装されていた「緊急データの次のオクテット」に規格を合わせた。
  • RFC 9293は現行規則と実装義務を維持するが、優先レーンを設けるものではなく、新規アプリケーションの依存も推奨しない。

URGが設定されると、16ビットの緊急ポインタはセグメントのシーケンス番号からの正のオフセットとして解釈される。したがって通常データと同じシーケンス空間に属する。示された点がRCV.NXTより先にある間、受信側は緊急モードにあり、受信がその点に追いつくと通常モードへ戻る。バイト自体はストリーム内に残る。ソケットAPIが既定で1バイトを「帯域外」として見せても、それはAPI上の慣行であって第二のトランスポートサービスではない。

当初の矛盾は一位置の差だったが、結果は大きかった。RFC 793のヘッダ説明はポインタを緊急データの次のオクテットに置く一方、SEND処理はSND.UPをSND.NXT-1とし、最後の緊急オクテットを示した。RFC 1122は後者を選び、任意長の緊急シーケンスとアプリケーションへの非同期通知を要求した。しかしRFC 6093が調査した広く普及した実装は、次のオクテットという解釈に従っていた。そのためRFC 793、RFC 1011、RFC 1122を更新して実装慣行を規格化した。RFC 9293はこれを現行の必須規則として引き継ぐ。

受信側がすでに緊急モードにある間のポインタ更新は、新たなアプリケーション通知を生まないことがある。送信側の緊急呼び出し数と受信側の通知数は一対一とは限らない。RFC 6093はURGを消去しポインタをゼロにする一部のミドルボックスも記録したが、すべてがそうするとは述べていない。資料は現在の利用率、OSの既定値、攻撃頻度を示さない。

参照資料