IPv6デュアルスタック化後に大きいレスポンスだけが停止する
中堅製造業の本社（従業員1,200名）で、基幹WebシステムのIPv6デュアルスタック化を進めている。サーバセグメントはIPv6対応済みで、クライアントPC（Windows 11）はIPv6を優先して名前解決する。しかし社内からIPv6でHTTPS接続すると、TCPの3ウェイハンドシェイクとTLSネゴシエーションまでは成功するものの、その後のアプリケーションデータの受信が途中で止まり、ブラウザがタイムアウトする。IPv4で接続すれば問題なく表示される。小さいHTMLページはIPv6でも表示できるが、画像を多く含む大きなレスポンスでは必ず失敗する。境界ファイアウォールはIPv6ポリシーを「最小限」で運用しており、ICMPv6は既定で全遮断、必要なものだけ個別に許可する方針である。サーバセグメントのMTUは1,500バイト、クライアントセグメントはIPv6 over IPv4トンネルを経由するためMTUは1,400バイトである。経路はOSPFv3で広告され、トンネルは端点のルータで終端されている。監視担当からは「IPv6はまだ不安定なのでIPv4に戻してほしい」という声が出ている。
1. この障害の原因として最も疑わしいものを特定し、症状の現れ方（ハンドシェイク成功／大きなレスポンスのみ失敗／IPv4では正常）と結びつけて論理的に説明せよ。あわせて、原因を確定させるための切り分け手順を3つ以上示せ。
Read the worked answer
結論：PMTUD（Path MTU Discovery）のブラックホールである。
根拠を症状ごとに整理する。
- TLSハンドシェイクまで成功：TCPの確立や証明書交換は数百〜数KBの小さなパケットで完結するため、MTUに触れずに通過する。つまり「通信できない」のではなく「大きいパケットだけ通らない」状態である。
- 大きなレスポンスだけ失敗：経路上のMTUがサーバ側1,500、クライアント側1,400で食い違っている。1,400バイトを超えるセグメントはトンネル端点で転送できなくなる。
- IPv6特有の挙動：IPv6では経路途中のルータはフラグメントせず、送信元にICMPv6 Type 2（Packet Too Big）を返してMTUを通知する。ところがファイアウォールがICMPv6を全遮断しているため通知が届かず、送信側は同じサイズで再送を繰り返す。これがPMTUDブラックホールである。
- IPv4では正常：IPv4は経路途中のルータがフラグメントできるため、同じポリシーでも通信が成立する。この差分が「IPv6だけ不安定」に見える理由である。
切り分け手順
- サイズを変えたping6（1,200／1,380／1,450バイトなど）を実行し、失敗し始める境界を探す。境界が1,400付近ならMTU起因とほぼ確定できる。
- クライアントとサーバで同時にパケットキャプチャし、ICMPv6 Type 2が返っているか、同一セグメントの再送が繰り返されているか、TCPウィンドウが更新されないまま止まっていないかを見る。
- ファイアウォールのログとカウンタで、ICMPv6の遮断件数が増えていないか確認する。遮断が増えていれば裏付けになる。
- traceroute6で経路ごとのMTUを確認し、MTUが1,400に落ちるホップ（トンネル端点）を特定する。
「IPv6が不安定」という表現は現象の言い換えにすぎない。レイヤ3のMTUとICMPの扱いに分解して捉えることが重要である。
2. 恒久対策を設計せよ。ICMPv6を最小限しか許可しないというセキュリティ方針との整合をとりながら、複数の対策を階層的に組み合わせ、それぞれの副作用も述べること。
Read the worked answer
対策は「通知経路を開ける」「そもそも大きなセグメントを送らせない」「経路設計を是正する」の3層で考える。
1. ICMPv6 Type 2の限定的許可（通知経路の回復）
- ステートフルファイアウォールであれば、確立済みセッションに関連するICMPv6 Type 2 Code 0のみを通過させる。全許可ではなく、関連付けで絞るのが要点である。
- レート制限（例：100pps）を併せて設定し、増幅攻撃や偵察への悪用余地を抑える。
- 副作用：ICMPを一切通さない現行方針からの逸脱になるため、セキュリティ部門との合意と、許可ルールのレビュー体制が必要になる。
2. TCP MSSクランプ（保険としての制御）
- トンネル端点およびクライアント側L3スイッチでMSSを明示的に下げる。目安はMTU 1,400からIPv6ヘッダ40バイトとTCPヘッダ20バイトを引いた1,340バイトである。
- サーバ側OSのTCP MSS上限設定も併用すると、経路変更時の影響を抑えられる。
- 副作用：全TCP通信に一律で適用されるため、MTUが十分な経路ではスループットをわずかに損なう。適用範囲をトンネル配下のセグメントに限定するなどの設計が必要である。
3. 経路設計の是正（根本対策）
- トンネル経由をやめ、サイト間をMTU 1,500で統一できる伝送方式に変更する。中長期的にはこれが最も保守性が高い。
- 全セグメントのMTUを一覧化し、設計書に明記する。機器更改時にMTUが変わることを防ぐためである。
4. 監視と再発防止
- ICMPv6 Type 2の受信数、ファイアウォールの遮断ログ、TCP再送率を継続監視する。再送率のしきい値超過でアラートを上げれば、同種の障害を早期に検知できる。
「IPv4に戻す」は症状を隠すだけで、デュアルスタック化の目的（IPv6前提の外部サービス接続、将来のIPv4アドレス枯渇対応）を放棄することになる。切り分けが済んだ以上、採るべき選択肢ではない。