要約

  • RFC 1146のAlternate Checksum RequestはKind 14で、両方向のSYNが同じアルゴリズム番号を示した場合だけ代替方式が成立した。欠落、不一致、旧実装による無視は、接続全体を標準チェックサムへ戻した。
  • 32ビットFletcherでは結果の後半をKind 15で通常セグメントに載せた一方、SYNとRSTは常に標準方式だった。RFC 4614は後に関心の乏しさを記録し、RFC 6247はRFC 1146をHistoric、両オプションをobsoleteとした。

長い結果は一度の合意では運べなかった

TCPヘッダーに用意されていたchecksum欄は16ビットである。RFC 1146のアルゴリズム1、8-bit Fletcherは16ビットの結果を出すため、この欄に収まった。アルゴリズム2、16-bit Fletcherの結果は32ビットだった。

そこで前半Aを既存欄に置き、後半BをAlternate Checksum Data、Kind 15に入れた。Kind 15は能力通知ではなく、合意済みの長い検査値を完成させるデータだった。

そのため、必要な通常セグメントごとにオプション空間を消費する。エンドポイントは接続状態を参照して既存欄の意味を変え、追加欄と合わせて計算しなければならない。パケット解析器も、握手を見ずに数値だけ検証することはできない。

不正なKind 15は軽く扱われなかった。長さが違う、または使うべきでない状況に現れた場合、セグメントを捨て、RSTを送り、接続を中止する。合意後の整合性表現に曖昧さを残せば、両端が同じデータについて別の判断をするからである。

その反復コストを誰が許可したか

Kind 15を使う前に、両端はKind 14で同じアルゴリズムを選ぶ必要があった。Kind 14は長さ3 octetで、標準方式の0、16ビット結果の1、32ビット結果の2を運んだ。

片方のSYNに2があるだけでは、後続セグメントへKind 15を入れる権限は生まれない。逆方向のSYNにも2が必要だった。相手が1を返した場合も、選択肢の中間を取らず、接続は標準方式を使った。

一方がオプションを付けない場合も同じである。以前の接続で合意した事実、ローカル設定、実装の能力表は今回の同意を代行しない。2本のSYNは、それぞれの送信者がこの接続について行った独立の意思表示だった。

反復するヘッダー費用を負うのは両端である。だから片方の希望だけで開始できない。フォーマット変更の費用と解釈責任を負う主体に、同じ番号を返す権利が置かれた。

最初の依頼は旧方式で読ませた

RFC 793は、TCPヘッダー、データ、疑似ヘッダーの16ビット語に対する1の補数和として標準checksumを定めた。現行のRFC 9293も、送信者が生成し、受信者が検査することを必須としている。

最初のSYNの時点では、代替方式について共有状態がない。提案を新方式で保護すると、受信者は検証方法を教える文を、方法を知る前に信じなければならない。

RFC 1146はKind 14入りSYNを標準checksumで保護した。受信者はまず既知の規則でセグメントを検査し、その後で将来の通常セグメントに関する提案を読む。

新方式は旧方式を一瞬で消したのではない。旧方式から、特定接続の限定された範囲について権限を借りた。変更の申請書には、変更前の印が必要だった。

SYNは合意前、RSTは状態外にいる

合意後もSYNとRSTは必ず標準checksumを使った。SYNは交渉そのものを運ぶため、結果を先取りできない。

RSTには別の理由がある。接続状態を持たないホストが、知らないセグメントに対してresetを返すことがある。そのホストに過去の代替アルゴリズムを再構成させることはできない。

つまり、標準方式は共通の入口だけでなく、状態を持たない出口でもあった。通常セグメントの検査規則を二者で変えても、TCP全体の拒否手段まで私有化しなかった。

キャプチャを読む際、標準方式のRSTは合意失敗の証拠ではない。SYNが標準方式なのも当然である。セグメント種別、方向、接続段階を抜きにchecksum欄を分類すると、正しい例外を故障にしてしまう。

知らない相手は安全に何もしなかった

RFC 1122は、長さを持つ未知のTCPオプションをエラーなしで無視するよう求めた。RFC 1146以前の実装はKind 14を理解せずとも、オプションを飛ばして通常のSYN応答を返せた。

新実装は、応答に同じKind 14がないことを「暗黙の賛成」と解釈しない。二者条件が成立しなかったので、接続全体を標準checksumにする。

この組み合わせは半分だけ切り替わる事故を防いだ。古い側は旧方式を送り、新しい側も旧方式を期待する。知らないことが、明確なフォールバックへ変換された。

ただし利用者には接続成功しか見えない。片側だけ更新しても障害が起きないため、代替方式が一度も有効にならなかった事実は、専用の計測がなければ隠れる。

フォールバックは導入摩擦の裏面だった

安全な後方互換性は実験に必要だった。未対応相手との接続を壊すなら、広いネットワークでコードを試す危険が大きすぎる。

一方、利益が出る条件は厳しい。両端が実装し、同じ番号を選び、後続セグメントを合意どおり計算する必要がある。片側導入の費用は発生しても、機能価値はゼロのままになりうる。

標準TCPへの復帰が滑らかであるほど、第二端を更新する圧力は弱い。接続可用性だけをKPIにすれば、フォールバックの成功と新機能の成功を区別できない。

この設計は互換性に失敗したのではない。互換性に成功したことで、採用の不足を静かにした。新しい選択肢には、接続数とは別に提案、合致、実使用を数える仕組みが必要だった。

実験という地位を越えて読まない

RFC 1146は1990年3月にExperimentalとして公開され、production systemsには推奨しないと明記した。これは試せる状態機械の定義であり、インターネットへの移行命令ではなかった。

RFC 1071はInternet checksumの性質と実装技法を整理している。背景理解には有用だが、その計算例はAlternate Checksumの導入実績を示さない。一部の実装例にはheld errataもあり、コード例と規範的な採用史を分ける必要がある。

2006年のRFC 4614は、Alternate Checksumが関心を集めなかったと記した。これは「実装が一つもなかった」や「Fletcherが数学的に破綻した」という主張ではない。文書が支えるのは関心の乏しさである。

2011年のRFC 6247は、広く展開されなかったとしてRFC 1146をHistoricへ移し、IANAにKind 14と15をobsoleteと記すよう求めた。同文書のspoofingに関する具体的な安全議論はT/TCPについてであり、Alternate Checksumの原因として借用できない。

実験は、広い採用に至らず、現行標準への候補という地位を閉じた。資料は残り、因果関係は資料が言う範囲に留まる。

obsoleteの番号は消えた番号ではない

IANAのTCP Parameters登録簿は、Kind 14と15をobsoleteとして今も掲げる。Alternate Checksum Algorithmsの表も、0から3までの意味を保存する。

登録が残るのは、現役利用を保証するためではない。古いキャプチャやソースコードを読めるようにし、同じ番号へ別の意味を重ねないためである。

IANAの行は割当、意味、現在の登録状態を証明する。実装数、トラフィック量、経路互換性は証明しない。obsoleteは履歴を消す命令でも、新規利用の許可でもない。

したがって証拠は分けて扱う。Kind 14の一方向は提案、二方向の一致は合意、後続の正しいKind 15は使用、登録簿は地位である。一つの番号に四つの物語を語らせてはならない。

追加欄が残した設計上の勘定書

長い検査値の利点を評価するには、計算だけでなく、握手の二者性、通常セグメントの追加バイト、状態依存の解析、エラー時のRST、旧相手へのフォールバックまで数える必要がある。

RFC 1146はそれらを隠さず仕様にした。だから採用しなかった歴史も、単純な「強いchecksumが負けた」という話にはならない。共有されるフォーマットを変える費用が、アルゴリズム名の外側に広がっていた。

新しい検査値への変更を旧方式で頼んだのは、旧方式だけが最初から双方に読めたからである。そして32ビットを選んだ後は、選択の結果を毎回運ぶ必要があった。入口の安全と運用の反復コストは、同じ設計の別々の面だった。

出典