IPv4 は途中で分割するが、IPv6 は代わりに「パケットが大きすぎる」を送る

IPv6 の障害は、原因となったパケットサイズよりもプロトコルのせいにされることがはるかに多い。二つのファミリは大きすぎるパケットを実際に異なる方法で扱い、その違いを重要にするのはトンネルである。IPv4 のルータは規則が許せばパケットを分割できるが、IPv6 のルータは途中で分割してはならない。IPv6 は代わりに送信者に伝え、送信者が反応することが期待される。その後に起きるあらゆる不具合は、そのメッセージが届くかどうかから生じる。

各ファミリがすること

表は四行で仕組みを示しており、一行が混乱の大半を説明する。

IPv6 には途中分割も、消すべき DF フラグもないため、パケットが大きすぎるときに頼るものがない。送信者に伝える必要があり、送信者はそれを信じなければならない。

トンネルは経路を静かに狭める

VPN はパケットがホストを離れる前に外側のヘッダを追加し、暗号化の場合は完全性データも加える。内側のパケットは見えているインターフェース MTU に収まっても、外側のパケットは次のリンクの上限を超えるため、これがまずトンネルで表面化する。トンネルインターフェースの MTU を意図的に下げるか、経路上で TCP MSS を絞り、選んだ数値とその理由を書き留めよ。

ESP のオーバーヘッドはモードとアルゴリズムに依存するため、正しいトンネル MTU は慣習ではなく計算である。何を選んでも、すべての IPv6 リンクがそれだけを運ぶ義務があるため、1280 バイトの完全な内側 IPv6 パケットの余地を残さねばならない。1280 バイトの IPv6 を運べないトンネルは調整の問題ではなく、そのファミリにとって壊れた経路である。IPv4 専用の配備から MTU 値をコピーすると消えるのは、まさにこの制約だ。

症状がハングに見える理由

障害はきれいなエラーではないため、誤診される。TCP ハンドシェイクが完了し、小さな応答が届き、大きな応答や一括アップロードが始まった途端に接続が止まるのは、それらが捨てられるほど大きい最初のパケットだからだ。SSH は接続後に最初の大きな出力で止まり、ページはヘッダが読み込まれても本文が最後まで終わらない。

ICMPv6 のパケットが大きすぎるというメッセージがフィルタされると、送信者はそれを知らないまま同じサイズを再試行し続ける。これは遅い経路ではなくブラックホールであり、その兆候はランダムな損失ではなく再現性のあるサイズ境界である。関連する制御トラフィックを通しておくことは、IPv6 配備を機能させる一部であり、礼儀ではない。

自分の経路が依存するメッセージを無効にしてから、その結果を IPv6 の障害と呼んではならない。同じ論法は IPv4 の Fragmentation Needed メッセージにも当てはまり、これもファイアウォールの作者に等しく不人気で、等しく必要である。

境界を測り、次に層を直す

推測せずに確かめるには、IPv4 では don't-fragment フラグを、IPv6 では固定のペイロードサイズを使い、応答が止まる場所を記録することだ。ping -M do -s 1472とping -6 -s 1400で問題の形を把握するのに十分であり、tracepathは途中で発見した経路 MTU を報告する。

次に、その数値を所有する層、つまりトンネルインターフェースの MTU、TCP の MSS クランプ、あるいは経路そのものを直す。IPv6 の規則の参照は RFC 8200 であり、それが防ぐインシデントより短く読める。

デュアルスタックの名前は一方のファミリでは応答し他方では応答しないことがあり、ネットワーク変更後にアプリケーションが切り替わることもあるため、アプリケーションが実際に使うファミリを試すこと。A レコードに対する結果は AAAA レコードについて何も語らないため、試したアドレスを記録せよ。

サイズ境界を証拠として扱う

再現性のあるサイズ境界は、同じバイト数で、同じ送信元から、毎回正確に再現する数少ないネットワーク障害の一つである。それは謎ではなく贈り物であり、修正を期待するのではなく検証できることも意味する。

発見した MTU、設定したトンネル MTU、そして違いを証明した試験をチケットに書く。次の人は別のリンクで同じ算術に出会う。