要約

  • IPv4のチェックサムは、ルーターが読み書きするヘッダーだけを対象にした。各処理点は受信ヘッダーを検査し、TTLなどを正当に変更した後、新しい状態に対する値を作る。ペイロードの完全性まで主張しない。
  • TCPとUDPは、トランスポートのヘッダーとデータに加え、IPアドレス、プロトコル、長さからなる擬似ヘッダーを計算対象にした。誤配送を検知しやすくするが、送信者の認証や経路の正当性を証明するものではない。
  • 1の補数演算には正のゼロと負のゼロがある。RFC 1141の増分更新は境界条件で完全再計算と異なる値を作り得たため、RFC 1624が修正した。IPv6は基本ヘッダーのチェックサムをなくし、依存する上位層へ責任を移した。

ルーターが書き換えるヘッダー

IPv4ヘッダーは、差出人が封印したまま目的地へ届く文書ではない。Time to Liveは処理されるたびに少なくとも一つ減る。フラグメント化が起きれば全長、フラグ、オフセットが変わる。許されたオプション処理もヘッダーを変え得る。

RFC 791 のHeader Checksumは、この可変性を前提にする。ヘッダーを16ビット語に分け、1の補数加算で合計し、その1の補数を格納する。計算中のチェックサム欄はゼロとして扱い、対象はヘッダーだけである。

ルーターは到着時のヘッダーを検査し、失敗すればデータグラムを捨てる。転送するならTTLなどを変更し、変更後のヘッダーに合う値を出す。つまりチェックサムは送信元の不変署名ではなく、一つの処理境界から次の境界まで有効な局所的な整合性表明である。

同じRFCは、IPがデータの誤り制御、確認応答、再送、フロー制御を提供しないと明記する。IPv4ヘッダーが合格しても、ペイロードについては何も証明されない。ネットワーク層が処理に必要な情報と、アプリケーションが受け取る内容は別の責任領域だった。

一枚のパケットに重なる有限の主張

同じ1の補数演算が使われるため、すべてを一つのチェックと見なしやすい。しかし範囲は異なる。

IPv4は自分のヘッダーだけを検査する。RFC 768 のUDPはUDPヘッダー、データ、擬似ヘッダーを対象にする。RFC 793 のTCPはTCPヘッダーと本文、96ビットの擬似ヘッダーを対象にする。

この分離により、TTLが一跳ごとに変わってもTCPやUDPの端点間計算をルーターが更新する必要はない。ルーターはIPv4ヘッダーだけを更新し、トランスポートの結果は端点が所有する。リンク層の誤り検出もあり得るが、それは一つの隣接区間だけで寿命を終える。

複数の検査に通ることは、一つの万能証明に通ることではない。各値は自分が覆うビットと、その値を作る役割の範囲だけを語る。

送信されない擬似ヘッダー

擬似ヘッダーはワイヤ上の独立した構造ではない。UDPではIPの送信元、宛先、プロトコル番号、UDP長を概念的に前置きして合計する。TCPも送信元、宛先、プロトコル番号、TCP長を含む96ビットを使う。受信側は実際のIP情報から同じ材料を再構成する。

RFC 768とRFC 793は、これが誤配送への保護になると説明する。TCP部分が無傷でも、異なる宛先や異なる上位プロトコルとして届けられたなら、同じ結果で受理されにくくなる。トランスポートが依存するネットワーク層の事実を計算へ取り込む設計である。

ただし、これは暗号学的な結合ではない。パケットを作れる者はチェックサムも作れる。対象バイトを意図的に変えた装置は値を計算し直せる。アドレスの保有者、組織の身元、ルーティング方針、経路上の傍受を証明する能力はない。

擬似ヘッダーが優れているのは、層を越えて必要な証拠だけを借りながら、権限まで混ぜなかった点にある。TCPはIPアドレスを検査材料にしても、そのアドレスの所有を裁定しない。

UDPが区別した二つのゼロ

1の補数では、0x0000が正のゼロ、0xFFFFが負のゼロを表す。算術上の等価性が、プロトコル上の同義性を意味するわけではない。

RFC 768は、UDPチェックサムの計算結果がゼロなら全ビット1を送ると定めた。全ビット0の欄は、送信者がチェックサムを生成しなかったことを示す。したがって0xFFFFは有効な計算結果を、0x0000はIPv4時代の省略を表し得る。

この区別がなければ、受信者は「検査した結果ゼロ」と「検査していない」を分けられない。内部表現を簡略化した実装が両方を同じに扱えば、ワイヤ契約の意味を消してしまう。

RFC 8200 のIPv6では、UDPチェックサムが原則必須となる。結果がゼロなら0xFFFFを格納し、全ゼロを受けたノードは破棄する。特定のUDPトンネル用途には追加条件付きの限定例外があるが、一般的な省略許可ではない。

共通の答えに至る別々の速さ

毎パケットの計算は、遅ければ設計上の負担になる。RFC 1071 は、互換性を失わず高速化できる性質を整理した。

偶数・奇数バイトの対応を保てば、1の補数和は交換・結合できる。バッファを分割して部分和を最後に合わせてもよい。どちらのバイト順でも計算でき、必要な位置で結果を入れ替えられる。広い累算器で桁上がりの折り返しを遅らせ、ループ展開や並列処理を利用することもできる。奇数長なら計算上だけ末尾にゼロを補う。

規格が決めたのは一つの機械語ループではなく、入力範囲と最終ビット列である。実装は各CPUに合わせて自由に工夫できた。その自由は、バイト位置、桁上がり、奇数末尾、ゼロ表現を正確に保つ限りで成立する。

走るコードが優先されるのは、共通結果を再現できるからであって、近似が許されるからではない。

小さな変更を小さな計算で処理する

TTLを一つ減らすだけなら、どの16ビット語が変わったかは分かっている。ヘッダー全体を再走査せず、古い語の寄与を除き、新しい語を足せる。

RFC 1141 は増分更新を実用的な式で示した。TTLを一つ減らす場合、バイト位置に応じて格納済み値へ1または256を1の補数加算する。RFC 1624 はTTL、フラグメント化、ソースルート変更を用途として挙げる。

コストを変更量に合わせる合理的な方法だった。しかし増分式の正しさは、新しいヘッダーを最初から計算した結果との完全一致でしか測れない。通常ケースで一致するだけでは足りない。

負のゼロへ滑った式

RFC 1624が記録した失敗は、まさにゼロで現れた。RFC 1141の式は、1の補数算術で結果がゼロになると成立しない分配的な変形を暗黙に使っていた。

例では、16ビット欄が0x5555から0x3285へ変わり、ほかのヘッダー部分の和が0xCD7Aである。全面再計算は0x0000を格納値として出すが、旧増分法は0xFFFFを出す。

IPv4ヘッダーには少なくとも一つ非ゼロ欄がある。非ゼロ入力の1の補数加算は負のゼロを作れても正のゼロを作れず、最後に補数を取るヘッダーチェックサムでは0x0000は現れ得るが0xFFFFは正規結果にならない。旧式は参照計算が生まない表現へ移ってしまった。

修正式はHC' = ~(~HC + ~m + m')である。すべてを1の補数加算として扱い、不正な分配を避ける。

受信実装の差が発見を難しくした。受信値自身も合計して負のゼロと比べるRFC 1071型の検査は、この例で両方を受け入れ得る。再計算した値を欄と直接比較する実装は拒否し得る。製品試験が条件を見つけ、分析とシミュレーションが修正を確かめた。

受信側の寛容さは、生成側の非正規出力を正当化しない。相互運用性は、相手が善意に読み替えてくれることではなく、同じ参照結果を送ることに依存する。

IPv6が移した検査点

RFC 8200のIPv6基本ヘッダーにはインターネット層チェックサムがない。バージョン、Traffic Class、Flow Label、Payload Length、Next Header、Hop Limit、128ビットアドレスを持つが、IPv4の16ビット欄は消えた。

上位層の責任は残る。IPv6のTCPとUDPは、128ビットの送信元と最終宛先、上位層長、Next Headerを擬似ヘッダーへ入れる。ICMPv6も同じ考えを使う。RFC 8200は、その理由をIPv6の依存欄がIPv4のようなインターネット層チェックサムで覆われないためと説明する。

IPv4では、リンク層やトランスポート層に隣接する検査があっても、全ルーターが基本ヘッダーを検査し更新した。IPv6はその反復をなくし、実際に特定フィールドへ依存する上位層へ検査を残した。

これはチェックサムの全廃ではなく、責任範囲の再配置である。互換性を要する端点計算は維持し、毎跳の基本ヘッダー計算を除き、UDPの省略を原則として閉じた。

史料と分からないこと

RFC 768はUDPの範囲とゼロ表現、RFC 791はIPv4、RFC 793はTCP、RFC 1071は計算技法、RFC 1141は増分化、RFC 1624は境界修正、RFC 8200はIPv6の分担を示す。

これらから単独発明者、現在の全実装、ハードウェア・オフロードの普及率、未検出誤りの特定確率は断定できない。合格は意図的な再計算を排除せず、不合格は変更を起こした装置や人物を一意に示さない。

確認できるのは限定された設計史である。対象バイト、更新者、有効期限を明示することで、インターネットは多くの偶発的な不一致を安価に見つけられるようにした。