要約

  • IPv6ジャンボグラムでは、基本ヘッダーのPayload Lengthゼロが、直後のHop-by-Hop OptionsヘッダーにあるJumbo Payloadオプションへ長さの判断を引き渡す。
  • オプションの32ビット値は65,535オクテットを超えなければならず、ゼロだけでは空であることも、形式が正しいことも示せない。
  • ヘッダーが整合していても経路上の全装置が運べるとは限らず、ICMPv6エラーが見えないことも配送成功の証拠にはならない。

長さではなく、次を読むための符号

IPv6基本ヘッダーは40オクテットで、Payload Lengthは16ビットである。通常は基本ヘッダーより後ろの全体、つまり拡張ヘッダーと上位層データを数える。表現できる上限は65,535だ。RFC 2675は、まれな巨大ペイロードのためにすべての基本ヘッダーを広げず、ゼロを番兵値として使い、実長を別のオプションへ移した。

ただし、ゼロを見れば無条件にジャンボグラムになるわけではない。基本長がゼロで、Next HeaderがHop-by-Hop Optionsを示し、基本ヘッダーの後にバイトが存在する場合、ノードはその拡張ヘッダーを処理する。そこに置かれたJumbo Payload Lengthは符号なし32ビットで、基本ヘッダーを除く拡張ヘッダーと上位層データを数え、65,535より大きい必要がある。

したがって、基本フィールドだけを抜き出したログは、照会命令を残して回答を捨てている。調査にはNext Header、オプションの有無と位置、その値、実際に採取されたバイト数が必要だ。スナップ長で切られたパケットキャプチャなら、ファイルの欠落をネットワーク上の形式不良と取り違えてはならない。

正しさは二つの値の関係にある

RFC 2675は矛盾を具体的に列挙する。基本長ゼロでHop-by-HopヘッダーがあるのにJumboオプションがなければ誤り。基本長が非ゼロなのにオプションがあっても誤り。Jumbo値が65,536未満なら、この形式を使う理由がなく無効である。JumboオプションとFragmentヘッダーの併用も認められない。

証拠は一つのセルではなく組み合わせに宿る。基本ヘッダーが権限を渡し、オプションが長さで応答し、ヘッダー列が正しい引き渡しかを証明する。ゼロをすべて「空」と表示する装置は正当なジャンボグラムを見失う。一方、ゼロを見ただけで受け入れる装置は、標準が破棄させる矛盾を通してしまう。

不正な組み合わせにはICMPv6 Parameter Problemが関係する。RFC 4443のType 4 Code 0は誤ったヘッダーフィールドを示し、対象パケットは破棄され、規定の制約下で応答が送られる。しかし応答がないことは受理の証明ではない。フィルター、レート制限、非対称経路、戻り経路の断絶のいずれでもエラーは観測点から消える。

UDPにもゼロがあるが、役割は別

UDPデータグラムがジャンボグラムに載り、実際のUDP長が65,535を超えると、UDP Lengthもゼロにできる。受信側はJumbo Payload LengthからUDPより前の拡張ヘッダー分を差し引いて実長を求める。チェックサムにはゼロではなく、その実長を用いる。

二つのゼロは協調するが、同一の証拠ではない。IPv6側はJumboオプションを参照させ、UDP側はUDP固有の例外を起動する。一方を見て他方を推測することはできない。TCPには同種のパケット長フィールドがなく、この文脈ではMSS 65,535を無限大として扱い、現実のセグメント寸法は経路MTU探索に制約される。

仕様上の有効性と通過可能性

ジャンボグラムは、MTUが65,575オクテットを超えるリンクで初めて意味を持つ。40オクテットの基本ヘッダーと65,535を超えるペイロードの合計だ。そのようなリンクに接続しない実装には対応義務がない。RFC 8201によればPath MTUは経路上で最小のリンクMTUであり、収まらないパケットは破棄され、Packet Too Bigが返る場合がある。

つまり、構文の合格は帯域やバッファーの予約券ではない。両端と最初のリンクが対応しても、途中のトンネルや装置が運べないことはある。逆に、Jumboオプションがあるという理由だけで一律に破棄すれば、標準上有効なパケットまで失う。RFC 9288が拡張ヘッダーの過剰なフィルタリングで区別を求めるのはこのためだ。

記録すべき主張は三つに分かれる。送信者が宣言した内容、ヘッダー列の整合性、そして経路上で実際に起きたことだ。最初の二つは完全なキャプチャと検証で判断できる。最後は到着確認、装置カウンター、Packet Too Big、既知の両端からの試験など別の裏付けを要する。

著者情報も単純化できない。RFC 2675の著者はDavid Borman、Steve Deering、Robert M. Hindenであり、RFC 8200はSteve DeeringとBob Hindenを掲げる。IETFのプロフィールはHindenをIPv6共同発明者の一人と説明する。単独の発明や、各ネットワークの実装判断まで本人に帰する根拠ではない。

出典