要約

  • IPヘッダーの一部が変わったとき、RFC 1141は保存済みの検査和を直接直す式を示した。TTLを一つ減らす処理が代表例だった。
  • RFC 1624は、その式がゼロの境界で0xFFFFを出す一方、ヘッダー全体の再計算では0x0000になる例を示し、式を改めた。

「ゼロを選んでください」と言われて、二枚の札が出てくる。一枚のビットはすべてゼロ。もう一枚はすべて一。どちらも一の補数演算ではゼロの名で呼ばれるが、IPパケットに書き込めば別の模様になる。1994年の検査和の修正は、こうした算術の癖が実装を試す現場へ出てきた話だ。

1988年9月のRFC 1071は、インターネット検査和の計算を詳しくまとめた。バイトを16ビットの語に組み、一の補数として足し合わせ、その和を反転して検査和欄に置く。受け取った側は検査和欄を含めて足し、結果がすべて一なら通す方法を採れる。文書は計算を軽くする工夫にも熱心だった。語の並べ方、並列加算、繰り上がりの遅延処理、メモリーコピーとの組み合わせまで扱っている。

IPを転送するルーターがTTLを減らす場面は、もっと分かりやすい節約先だった。変わるのはヘッダーの一部分だけである。RFC 1071は差分から検査和を更新する考えを示した。1990年1月のRFC 1141は、それをパケットに実際に保存されている検査和へ直接適用する式にした。TTLが16ビット語の上位バイトにある通常の例では、TTLを一つ減らすと検査和に0x100を加える形になる。毎回ヘッダー全体を読み直さずに済む。

ところが、その式の変形には境界条件があった。一の補数には0x0000という正のゼロと、0xFFFFという負のゼロがある。1994年5月のRFC 1624は、RFC 1141の式がゼロで成り立たない分配法則を使っていたと説明した。計算の近道は、正しいゼロのつもりで違うビット列を選び得た。

RFC 1624の実例は数字が揃っている。ヘッダー内の16ビット値0x5555が0x3285へ変わり、ほかの語の和は0xCD7A。元の検査和は0xDD2Fである。新しいヘッダーを最初から計算すると、保存すべき検査和は0x0000。RFC 1141の近道では0xFFFFになる。改訂式HC' = ~(~HC + ~m + m')なら0x0000を得る。このヘッダーにはゼロでない欄があり、全体を正しく計算して保存欄が0xFFFFになることはない。

では、間違った札のパケットは必ず捨てられたのか。受信側の計算方法が分かれ目だった。検査和欄も含めたヘッダー全体を足して、すべて一になるかを見る方式では、この例の0x0000と0xFFFFのどちらも通る。一方、検査和欄を再計算して保存値と照合する方式は、0xFFFFを拒否し得る。送る側の式だけ見ても、通信の結果は決まらない。

RFC 1624は発見の経路も記した。RFC 1141のアルゴリズムを実装した製品の試験で失敗条件が見つかり、改訂式はシミュレーションでも確認された。製品名や普及率の話は出てこない。重要なのは、具体的な試験結果がきれいな式の例外を示し、数値例と修正式に結び付いたことだ。追加の命令が気になる実装には、借りを使った減算の別表現も挙げられた。

差分更新そのものは便利なままだった。必要なのは、最終的にワイヤーへ載る16ビットを正しく選ぶこと。黒板のゼロには双子がいても、受信側の比較処理はその顔を見分ける。