ICMP の役割：エラー通知とネットワーク診断の内部

ICMP は「IP の付帯メッセージ」である

ICMP（Internet Control Message Protocol）は、しばしば「pingのためのプロトコル」と誤解されますが、本質は IP 自身のための制御・エラー通知の仕組み です。IP はベストエフォートで、パケットを配送できなくても黙って捨てるだけです。そこで「なぜ届かなかったか」を送信元に知らせる役割を ICMP が担います。

ICMP メッセージは IP パケットのペイロードとして運ばれますが、TCP/UDP のような上位アプリケーション向けプロトコルではなく、IP と同じ層に属する制御専用のプロトコル（IPv4 ではプロトコル番号 1、IPv6 では ICMPv6 が番号 58）です。各メッセージは type と code の2フィールドで種別を表し、多くのエラーメッセージは 問題を起こした元パケットの IP ヘッダと先頭8バイト を引用して含みます。この8バイトに TCP/UDP のポート番号が入るため、送信元は「どの通信が失敗したか」を特定できます。

代表的なメッセージの意味

実務で頻出する3つを正確に押さえます。type と code の組み合わせが診断の手がかりです。

Destination Unreachable（type 3） は最も情報量が多いメッセージです。とくに code 3（Port Unreachable） は、UDP パケットを受け取ったホストにそのポートで待つプロセスがいないときに返すもので、tracerouteの終端判定に使われます。code 4（Fragmentation Needed and DF Set） は後述する Path MTU Discovery の中核で、ここが届かないと通信が静かに壊れます。

Time Exceeded（type 11, code 0） は、IP ヘッダの TTL（IPv6 では Hop Limit） が中継のたびに1ずつ減り、0になったルータがパケットを破棄して送信元に返すものです。これはループ防止のための寿命管理であり、tracerouteはこの挙動を逆手に取ります。

Redirect（type 5） は、同一セグメント内に送信元が知らないより適切なゲートウェイがあるとき、ルータが「次からはあちらへ」と教えるメッセージです。便利な反面、偽のRedirectで経路を乗っ取られる危険があるため、現在の多くのホストは受信時のRedirectを無視または制限する設定が既定です。

ping の仕組み：Echo の往復

ping は Echo Request（type 8） を宛先に送り、宛先が Echo Reply（type 0） を返す、という単純な往復です。送信時刻を記録し、Replyが戻った時刻との差を RTT（往復遅延） として表示します。Requestには識別子とシーケンス番号が入り、複数のpingやプロセスの応答を取り違えないようになっています。

重要なのは、ping が通らないこと自体は故障の証明にならない 点です。多くのファイアウォールやホストが Echo Request を遮断するため、サービス自体は正常でも ping だけ無応答ということが普通に起こります。到達性は ping 単独でなく、実際のアプリ層（curl など）と併せて判断します。詳しくは ネットワークの切り分け の手順が役立ちます。

traceroute の仕組み：TTL を1ずつ増やす

tracerouteは ICMP の Time Exceeded を意図的に誘発して経路を可視化します。手順は次の通りです。

1. TTL=1 のパケットを宛先へ送る。最初のルータでTTLが0になり、そのルータが Time Exceeded を返す。送信元アドレスから1ホップ目が判明する。
2. TTL=2 で送る。2番目のルータがTime Exceededを返し、2ホップ目が判明する。
3. これをTTLを増やしながら繰り返し、最終的に宛先まで届いたら終了する。

終端の検出方法は実装で異なります。古典的な UNIX 系 traceroute は 高ポート番号宛てのUDP を送り、宛先に届くと前述の Port Unreachable（type 3 code 3） が返ることで「到達した」と判断します。Windows の tracert は ICMP Echo を使い、宛先からの Echo Reply で終端を判断します。

# Linux/macOS: 既定はUDP、-I でICMP Echo方式に切替
traceroute example.com
traceroute -I example.com

# Windows: 既定でICMP Echoを使用
tracert example.com

途中ホップのRTTが一見「逆転」して見えることもあります。各ホップのRTTはそのルータからの往復であり、ルータがICMP応答を低優先で処理するため、転送そのものより遅く見えるからです。中間ホップのRTTは経路品質の直接指標ではない と理解しておきます。

レート制限とフィルタが招く障害

ICMP の生成・応答には負荷がかかるため、ルータやホストは ICMPレート制限（単位時間あたりの生成数の上限）を設けます。これ自体は正当な保護ですが、診断結果を歪めます。tracerouteで中間が欠ける、pingで断続的にロスして見える、といった現象の一因がこのレート制限です。装置のCPUを守るために優先度を下げているだけで、データ転送は影響を受けていないことが多いのです。

より深刻なのが 過剰なICMPフィルタ です。「ICMPはセキュリティ上危険だから全部落とす」という運用は、必要なメッセージまで遮断して通信を壊します。最大の落とし穴が Path MTU Discovery（PMTUD）の破綻 です。

PMTUD ブラックホールが厄介なのは、症状が部分的で再現条件が分かりにくい ことです。ping（小さいパケット）は通り、TCPの接続確立も成功するのに、本文が大きいHTTPレスポンスやファイル転送だけが止まります。背景の仕組みは MTU とフラグメンテーション と合わせて理解すると腑に落ちます。回避策としてTCPでは MSS Clamping（経路上でMSSを書き換えMTUに収める）が使われますが、根本はICMP type 3 code 4 を通すことです。

NAT 環境も注意が必要です。ICMPエラーは元パケットのヘッダを引用するため、NATはエラー内部のアドレス/ポートも正しく書き戻さないと、送信元がエラーを自分の通信と紐づけられません。実装が不十分なNATでは、これがPMTUDやtraceroute不全の原因になります。

IPv6 における ICMPv6 の位置づけ

IPv6 では ICMP の役割がさらに拡大し、ICMPv6 は近隣探索（NDP）やマルチキャスト管理まで担う必須の中核プロトコルになりました。詳細は IPv6 のアドレス体系と近隣探索（NDP） に譲りますが、ここで決定的なのは IPv6 では ICMPv6 を一律ブロックすると通信が成立しない ことです。

IPv4 では「ICMPを落としても基本通信は動く（PMTUDなどが壊れるだけ）」という乱暴な運用が一応成り立ちましたが、IPv6 では NDP（NS/NA/RS/RA）が ICMPv6 そのものなので、遮断するとアドレス解決もルータ発見もできません。さらにIPv6では中継ルータが分割を行わないため、PMTUDが必須であり、Packet Too Big（ICMPv6 type 2）の疎通はIPv4以上に重要です。「ICMPは危険だから全部落とす」という発想がIPv6時代に通用しないことは、明確に押さえておくべきです。

つまずきポイント

• ping不通＝障害ではない：Echoが遮断されているだけのことが多い。アプリ層でも確認する。
• traceの * を断線と誤読しない：レート制限や応答抑制が原因で、経路自体は生きていることがある。
• 中間ホップのRTTを品質指標にしない：ルータのICMP低優先処理で実際の転送より遅く見える。
• ICMPを一律ブロックしない：とくにtype 3 code 4 を落とすとPMTUDブラックホールで「大きい通信だけ詰まる」障害になる。
• IPv6でICMPv6を止めない：NDPごと機能停止し、そもそも通信が始まらない。

ICMP は「おまけの診断ツール」ではなく、IP が正しく動くための 制御チャネル です。pingやtracerouteの結果を正しく解釈し、フィルタ設計でtype単位の判断ができれば、見えにくい障害の多くは未然に防げます。