要約

  • IPv4 の 16 ビット・チェックサムはヘッダーだけを対象にし、データグラムの処理に必要な情報を確認します。
  • ヘッダーは転送中に変化するため、処理点ごとに検証と再計算が必要です。

転送判断を守る

RFC 791 は、ヘッダー内の 16 ビット語を一の補数で加算し、その補数を格納する方式を定義しています。計算中はチェックサム欄をゼロとして扱います。

宛先、長さ、フラグメント情報、生存時間、プロトコル番号は、データグラムの扱いを決めます。RFC 791 は、このチェックサムが処理情報の正しさを確認するものだと説明し、データ自体には誤りが残り得ることも認めています。検証に失敗したデータグラムは、検出したエンティティが直ちに破棄します。

したがって、これはエンドツーエンドのデータ整合性機能ではありません。ペイロードを保護する仕組みが存在するかどうかも、IPv4 のチェックサムからは分かりません。

途中で変わるチェックサム

ルーターは TTL を減らします。フラグメント化やアドレス、オプションの変更もヘッダーを変えます。そのため RFC 791 は、ヘッダーを処理するすべての地点で検証と再計算を求めます。

全体を再計算する代わりに増分更新もできますが、RFC 1624 は完全計算と厳密に同じ結果になることを条件にしています。

ゼロが二つある

一の補数には正のゼロと負のゼロという二つの表現があります。RFC 1141 の式は、狭い条件で完全計算と異なる表現を生成する可能性がありました。RFC 1624 は式を修正しましたが、フィールド幅やヘッダーだけという範囲は変えていません。

出典