要約

  • TCPチェックサムはTCPヘッダーとデータに加え、IPの情報から作る概念上の擬似ヘッダーも対象にする。
  • 擬似ヘッダーはTCPデータとして送信されず、送信側と受信側がそれぞれ再構成する。
  • これは一部の誤りや誤配送を検出する仕組みであり、認証や経路の証明ではない。

TCPセグメントの見える部分はポート番号から始まるが、チェックサムの計算はそこから始まらない。送信側は送信元・宛先アドレス、プロトコル識別子、TCP長を概念的に計算へ加える。受信側は同じ情報を用いて入力を再現し、結果を確認する。

RFC 793のIPv4形式では、擬似ヘッダーは96ビットである。送信元アドレス、宛先アドレス、ゼロの1バイト、IPプロトコル番号、計算されたTCP長で構成される。これらはすでにIPの文脈に存在するため、TCPセグメントへ二重に書き込まれない。層の境界でTCPへ渡される情報なのである。

この方式には明確な目的があった。TCPのバイトだけを合計すると、包んでいるパケットのアドレスやプロトコル識別子が変わっても、同じ値になる場合がある。選ばれたIP情報を加えることで、TCPは単独のTCPバイトでは見つけにくい一部の破損や誤配送を検出できる。

計算は16ビット語の1の補数加算と、その結果の1の補数による。計算中、チェックサム欄はゼロとして扱う。対象のオクテット数が奇数なら、最後の語を埋めるためだけに右側へゼロを加えるが、そのゼロは送信されない。TCP長はTCPヘッダーとデータを数え、IPv4擬似ヘッダーの12バイトは数えない。

RFC 9293もこの設計を維持し、送信側はチェックサムを生成し、受信側は必ず検査しなければならないと定める。TCPの下位で働くプロトコルは、アドレス、プロトコル識別子、TCP長を知る手段を提供する必要がある。

IPv6では擬似ヘッダーは320ビットになる。IPv6の送信元・宛先アドレス、上位層パケット長、三つのゼロバイト、TCPを示すNext Header値を含む。拡張ヘッダーがある場合は、固定ヘッダー直後の値ではなく、拡張列の末尾でTCPを識別する値を使う。ソースルーティングでは、中継先ではなく本来の送信元と最終宛先を用いる。

一致する値が示すのは、対象となった語の再構成が整合したという限定的な事実である。送信者の身元、認可、通過経路は証明しない。攻撃者が通信を書き換えて再計算できる場合も防げない。擬似ヘッダーは、線上の追加ヘッダーではなく、層同士の合意なのである。

出典