要約

  • RFC 768では計算結果のゼロを全ビット1で送り、全ビット0は計算自体を行わなかった印とした。
  • 局所的な性能節約は未検出エラーを他者へ移した。IPv6は下位のIPヘッダー・チェックサムも持たないため、UDP検査を既定義務にした。
  • RFC 6935/6936の例外はポートとトンネル端点に限定され、代替完全性、経路確認、状態保護を要求する。

フィールドは証言を拒めた

UDPチェックサムはデータとUDPヘッダーに加え、送信元・宛先アドレス、プロトコル番号、長さからなるIP疑似ヘッダーも計算する。RFC 768はこれに破損だけでなく誤配送を見つける役割を与えた。

1の補数演算では正当な結果がゼロになる。その場合は全ビット1を送る。全ビット0だけが「チェックサム未生成」を表す。つまりゼロは正常の証明でなく、判断材料を提供しないという宣言だった。

私的な節約が共有の盲点を作った

RFC 1122はアプリによる制御を残したが、生成と検証の実装を必須とし、既定を有効にした。LAN専用アプリが効率のため無効化し、未検出エラーが多数報告されたことも記録している。

計算を省く利益は送信側に集中する。破損や誤配送を拒む手掛かりの喪失は受信側に広がる。省略できる機能があることは、未知の相手に代わって証拠不要と決める権限ではない。

IPv6は最低限の共通判定を戻した

IPv4は少なくとも自分のヘッダーを検査した。IPv6はインターネット層のヘッダー・チェックサムを廃した。RFC 2460はそこでUDPチェックサムを必須にし、ゼロのパケットを受信側が破棄するよう定めた。

RFC 8200も通常動作を維持する。送信時に計算し、結果がゼロならFFFFを置き、真のゼロは破棄して記録することが推奨される。16ビットの値は認証ではない。共有経路の最低限の配送証拠を、一方の都合だけで消さないための規則である。

UDP-Liteは露出範囲を申告した

音声や映像には、全廃棄より一部破損の受信を望む場合がある。RFC 3828のUDP-Liteは部分被覆を許すが、疑似ヘッダーとUDP-Liteヘッダーは常に保護し、送信チェックサムの全ゼロを禁止する。

送信側は保護境界を表明し、受信アプリは最低被覆を選ぶ。危険を消したふりをせず、関係当事者が見える形で引き受ける設計だった。

トンネル例外は責任者を名指した

高速トンネルでは、内側パケットが既に保護され、外側全体を読み直す費用が大きい場合がある。RFC 6935はIPv6 UDPのゼロを制約付きで認め、RFC 6936が条件を定めた。

既定は無効のままである。送受信ポートを指定し、ゼロを受けるポートは計算済みチェックサムも受ける。制御情報と状態を守り、断片化、誤配送、中間装置、経路検証、注入や過負荷を扱う必要がある。通常UDPとUDP-Liteを先に検討する。

例外は公共網の全送信者に属さず、設定・監視・撤回できる特定トンネルの両端に属する。

情報源と限界

根拠は RFC 768、RFC 1122、RFC 2460、RFC 3828、RFC 6935、RFC 6936、RFC 8085、RFC 8200 である。規範と記録された懸念を示すが、全実装の同一動作や世界的エラー率は示さない。チェックサムは暗号学的認証ではない。