要約

  • IPv4オプション型の最上位一ビットは、オプションをゼロ・オフセット断片だけに置くか、全断片へコピーするかを断片化処理に指示した。
  • 断片化後のヘッダーは複製品ではない。オプション集合、IHL、Total Length、Fragment Offset、MF、チェックサムが断片ごとに意図的に異なり得る。
  • Copy 1は処理責任を引き継がせるだけで、配達、優先、認証、完全性、到着時の同一バイト列を保証しない。完全な非コピー状態はゼロ・オフセット断片に依存する。

先に見えたものが全体とは限らない

ネットワーク観測では、「最初のパケット」という言葉が二つの意味を持つ。捕捉装置に最初に到着したものと、元データの先頭を含むものだ。IPv4の断片化は、この二つを区別しなければならない代表例である。

RFC 815は、ゼロ・オフセット断片が来るまで、受信側が最終的なヘッダー長を知らない場合があると説明する。先に来た後続断片は壊れているから短いのではない。Copy 0のオプションを合法的に持たないため短いのである。

この保留は実装上の弱さではない。部分的な証拠から確定できない事項を確定しない、という境界である。後続断片からは、その断片を扱うのに必要な情報を読める。しかし、元データグラムに存在した全オプションの不存在までは証明できない。

一つの型オクテットに三つの判断材料が入った

RFC 791は、IPv4オプションの型オクテットをCopy一ビット、Class二ビット、Number五ビットに分ける。Copyが0なら、そのオプションは最初の断片だけにコピーされる。1なら全断片へコピーされる。

ここで「最初」とは時刻ではなく構造である。Fragment Offsetがゼロの断片が、元ヘッダーの全オプションを受け持つ。ほかの断片には、個別に転送される際にも意味を保つ必要があるCopy 1のオプションだけが残る。

たとえばLoose Source and Record Routeは型131で、二進表現の最上位ビットが1である。Record Routeは型7で、最上位ビットが0である。両方を持つ一つのデータグラムが分割されると、ゼロ・オフセット断片は両方を持ち、後続断片は前者だけを持つ。Strict Source and Record Routeの型137やStream Identifierの型136もCopy 1、Timestampの型68はCopy 0である。

この一ビットは、中央の判断主体に「このオプションは重要ですか」と問い合わせる仕組みではない。型を理解する実装がローカルに適用できる決定規則だ。小さな共通規則が、分散した断片化処理に同じ責任境界を与えた。

断片化はデータだけを切る処理ではなかった

元データグラムを三つに分け、ヘッダーを三回コピーするだけなら、後続断片にも全オプションが残る。しかしRFC 791が定めた処理は選択的である。最初の断片は元ヘッダーを基礎にし、次の断片はコピー対象のオプションだけを含むようヘッダーを構築する。

非コピーオプションを外せばIHLが変わる。各片が担うデータ量に応じてTotal Lengthが変わる。元データ内の位置に応じてFragment Offsetが変わり、続きがあるかどうかでMore Fragmentsも変わる。これらを変更すればHeader Checksumも計算し直す必要がある。

したがって、同一データグラムに属するフラグメントのヘッダーは、同じであるべきコピーではなく、同じ規則から作られた異なる派生物である。IHLの不一致だけを異常検知条件にすると、仕様通りのパケットを攻撃と誤認する。逆にチェックサムが正しいだけで、必要なCopy 1オプションまで保存されたとは証明できない。

この区別は、識別と内容を分離する。各フラグメントが同じ再構成単位に属するために、全オプションが同じである必要はない。再構成に必要な識別情報と、断片ごとに必要な処理情報は、同じものではない。

規則はRFC 791より前から存在した

1980年1月のRFC 760は、すでに全断片へ複写すべきオプションと最初の断片にだけ残すオプションを区別していた。また、次の断片を作るときにInternet Headerを選択的にコピーし、新しいヘッダーの値を調整する手順を記している。

RFC 791はこの発想を明確な型ビットとして固定した。歴史的に重要なのは、断片化を単なるMTU対策としてではなく、意味のあるメタデータを分配する変換として扱った点だ。中間ルータはアプリケーション内容を理解しないが、少なくともどのネットワーク層オプションを次の断片にも渡すかは決定できなければならなかった。

この設計は、共通層を必要以上に厚くしない。すべてのオプションを全断片へ持たせるのではなく、独立転送に必要な状態だけを共通化する。一方、観測履歴や時刻のような非コピー状態はゼロ・オフセット断片に集約される。

Copy 0は「価値がない」という印ではない

Record RouteやTimestampがCopy 0だからといって、それらが捨ててよいという意味ではない。元ヘッダーの完全な選択はゼロ・オフセット断片に残る。Copyは価値の序列ではなく、分割後の配置規則である。

同様にCopy 1は安全ラベルではない。以前のBasic Security Optionは型130でCopy 1だったが、ビットそのものが機密性や認証を与えたわけではない。Loose Source RouteがCopy 1なのも、経路指示を暗号化するためではなく、独立して進む各断片がその指示を必要とするためである。

IANA IPv4 Parametersレジストリは、割り当てられた各オプションについてCopy、Class、Number、値、名称、参照文書を掲載する。そこから型の正式な構造は確認できる。しかし現在のトラフィック量、製品の実装品質、経路上での受理率までは読み取れない。

仕様上の割当、送信、途中処理、到着、再構成は別々の証拠である。レジストリの一行を最後の段階まで拡大してはならない。

コピーされた記録も同じ経路を語るとは限らない

RFC 815はさらに厄介なケースを扱う。フラグメントは別々の経路を通り得る。Source and Record Route系のオプションが全断片へコピーされても、各経路のルータが異なる記録を追加すれば、到着時のオプション内容は一致しない。

このため、Copy 1を「到着時にも全片で同一」と説明するのは誤りである。コピーは分割時点の初期状態を配る。のちに正当に可変なフィールドが更新される可能性まで凍結しない。

再構成時にどの記録を採るかについて、RFC 815は最初の断片に記録された復路を使い、ほかの断片の異なる版を無視する。これは多数決ではない。ゼロ・オフセット断片に権威を割り当てる決定規則である。

観測装置が重複オプションを一つに正規化してしまうと、経路分岐という証拠を失う。反対に、すべてを独立した矛盾と扱えば、仕様が許した変化を攻撃と誤る。元フラグメント、更新履歴、再構成で採用した版を分けて残す必要がある。

完全な検査はゼロ・オフセットを待つことがある

RFC 6274は、再構成後の上位層ヘッダーが本当に収まるかを点検する際、最初の断片のIHLが必要になることを示す。Copy 0オプションがあると、後続断片の短いIHLを使った計算では最終条件を確定できない。

ゼロ・オフセット断片がまだなければ、実装は暫定的な検査を行える。しかし完全な情報が来たときに、厳密な検査を再適用しなければならない。これが重要なのは、保留状態を失敗として扱わず、成功としても固定しないからだ。

セキュリティ装置が高速化のため最初に届いた片だけで判定を固定すると、合法な長いヘッダーを見落とすか、逆に正常な後続片を不正と分類する。速度のために暫定結果を出すことと、その結果を取り消せなくすることは別の設計判断である。

オプション領域には境界を閉じる文法もある

End of Option ListとNo Operationは、通常の可変長オプションと同じ物語に押し込められない。オプション領域を終了し、32ビット境界へ揃えるための制御要素である。非コピーオプションを除いた後続ヘッダーでは、終了やパディングを整え直す必要が生じる。

つまり、断片化処理は「Copy 0と書かれたバイトを消す」だけではない。オプション長を理解し、途中で切らず、ヘッダーを閉じ、整列させ、IHLとチェックサムを一致させる。最小の共通規則にも、構造を検証するだけの厳密さが要る。

解析器が未知オプションを扱うときも同じである。意味を知らなくても、型、長さ、コピー規則を壊さず次へ進めなければならない。未知であることは、自由に削除したり全断片へ複写したりする権限ではない。

「断片化は脆い」は「常に失敗する」ではない

RFC 8900は、全IPv4オプションが最初の断片にあり、後続断片にはCopy 1のものだけが現れると明記したうえで、現実のネットワークにおける断片化の脆さを整理している。中間装置が後続片を落とす、上位層ヘッダーを見られない、再構成資源が不足する、といった問題である。

ただし、これは全フローの失敗率を示す統計ではない。RFCの分析は障害機構を説明する。ある製品、経路、時代でどの程度起きたかを主張するには別の測定が要る。

IPv6ではRFC 8200が、断片化を送信元に限定し、各片に必要な部分と最初の片に置く部分を別の構造で表した。これは設計比較として有用だが、IPv4のCopyビットを後知恵で無意味にするものではない。IPv4は途中のルータも断片化できる世界で、意味を失わずに派生ヘッダーを作る必要があった。

分割する主体の権限は限定されていた

IPv4の断片化主体は送信元の場合も、途中ルータの場合もある。冒頭のルータは典型例にすぎない。DF、リンクMTU、転送条件によって結果は変わる。

だが誰が分割しても、権限の範囲は同じく限定的である。負荷を適切な単位に分け、再構成フィールドを設定し、Copyビットに従ってオプションを派生させる。Copy 0の情報を無価値と宣言したり、Copy 1の内容が真実だと保証したりする権限はない。

この限定は、運用の自律性と相互運用の両方を守る。各実装はローカルに規則を検証して実行できる。すべての将来の選択を中央へ集める必要はない一方、共有すべき不変条件は曖昧にしない。

出典と証拠の境界

本稿はRFC 760、RFC 791、RFC 815、RFC 1122、RFC 1812、RFC 6274、RFC 8900、RFC 8200、IANAレジストリを用いた。これらは仕様と限定された運用上の帰結を示すが、現在の利用率、全実装の適合性、特定攻撃の発生、各経路の到達率を証明しない。