マシンのネットワーク設定を行い、外部のネットワークやサーバとつながるかどうかを確認する際には、実際にネットワークアプリケーションを使う前に、「ping」「traceroute(tracert)」などのコマンドを用いる方法が有効だ。
マシンのネットワーク設定を行い、外部のネットワークやサーバとつながるかどうかを確認する際には、実際にネットワークアプリケーションを使う前に、「ping」「traceroute(tracert)」などのコマンドを用いる方法が有効だ。
「ping」は簡単な接続の可否をOK/NGで確認できるコマンドであり、「traceroute」は目的のホストまでの経路を順に表示する詳細な調査向けのコマンドである。エラーメッセージや経路表示から、ネットワーク接続が正常でない場合に、どこに問題がありそうか、ある程度の切り分けが可能になる。
こうしたネットワークの疎通確認に用いるコマンド/ツールは、ICMPの性質をうまく利用している。
pingやtracerouteでは一般に、ICMP(Internet Control Message Protocol : RFC 792/ RFC 1812)と呼ばれる特別なプロトコルを用いてネットワークの疎通を確認している。
もともとICMPは、ネットワークに障害があり正常な通信が行えない場合に、経路に位置するルーターやホストが送信元ホストへその障害を知らせるためのプロトコルである。そのため、エラー報告プロトコルとも呼ばれる。
IP自体は到達信頼性の低いプロトコルだが、仮に途中でパケットが破棄されたとしても、再送などによりエラーをハンドリングすることは可能だ。しかし永続的な障害などの場合には、非常に効率が悪い結果となる。そこで、ICMPによってエラーを通知することで、復旧やエラーハンドリングの効率を上げる目的を持っている。ICMPはIP上で動作するプロトコルであり、TCPやUDPと同一階層と考えてよい。IPヘッダにおけるProtocolフィールドは1が設定される。こうした障害時通知など特殊な目的のためには、通常のTCPやUDPに比べ、より詳細な情報が通知できるように設計されている。
Type | 説明 | 意味 | 種類 |
---|---|---|---|
0 | Echo Reply | Echo要求への返答 | Query |
3 | Destination Unreachable | 宛先到達不能 | Error |
4 | Source Quench | 軋轢(あつれき)発生による転送抑制指示 | Error |
5 | Redirect | より最適な経路への変更指示 | Error |
8 | Echo Request | Echo要求 | Query |
9 | Router Advertisment | ルーター通知 | Query |
10 | Router Solicitation | ルーター要求 | Query |
11 | Time Exceeded | TTLの超過によるパケットの破棄報告 | Error |
12 | Paramter Problem | パケットパラメータにおけるエラー | Error |
13 | Timestamp Request | タイムスタンプ保持要求 | Query |
14 | Timestamp Reply | タイムスタンプ保持要求への返答。 | Query |
15 | Information Request(未使用) | ― | Query |
16 | Information Reply(未使用) | ― | Query |
17 | AddressMask Request | アドレスマスク要求。サブネット内のサブネットマスク値を要求する | Query |
18 | AddressMask Reply | アドレスマスク要求への返答 | Query |
表1 Type一覧 |
ICMPの種類(目的)は、Typeフィールドの性質によって「Queryメッセージ」と「Errorメッセージ」に大きく分けられる。
「Queryメッセージ」は、pingやtracerouteなどの調査コマンドに対して返答されるメッセージだ。pingやtracerouteでは、Echo Request(Type=8)と呼ばれるTypeがリクエストとして送られる。これに対して調査対象ホストは、Echo Reply(Type=0)レスポンスを返答し、正常に稼働していることを示す。Echo Typeの組み合わせは俗に「Are you Alive」機能とも呼ばれ、「存在確認」機能を提供する。その他、Queryメッセージでは、レスポンスタイムを計測するために到達時刻を返答するTimestamp Request(Type=14)/Timestamp Reply(Type=14)などもよく用いられる。
一方、「Errorメッセージ」は障害を通知するためのメッセージだ。通常のIP通信において何らかの問題が発生した場合には、経路途中のルーターやホストが単独でメッセージを送信元ホストへ返答する。Destination Unreachable(Type=3)エラーの場合、Codeフィールドには以下のような障害時の詳細情報が格納されることになっている。
Code | 説明 |
---|---|
0 | Network Unreachable |
1 | Host Unreachable |
2 | Protocol Unreachable |
3 | Port Unreachable |
4 | Fragmentation Needed and DF set |
5 | Source Route Failed |
6 | Destinantion Network Unknown |
7 | Destinantion Host Unknown |
8 | Source Host Isolated |
9 | Network Administartively Prohibited |
10 | Destinantion Host Administartively Prohibited |
11 | Network Unreachable For TOS |
12 | Host Unreachable For TOS |
13 | Communication Administratively Prohibited |
14 | Host Precedence Violation |
15 | Precedence Cutoff in Effect |
表2 Code一覧 |
Dataフィールドには、Echo Requestの場合は任意の文字列が埋められるが、Errorメッセージの場合ではどのパケットに対するエラーかを示すために、対応するパケットのIPヘッダが格納される。
図の送信元ホストAでは、パケット送信時に目的のホストが存在しているのかどうかまでは分からない(送信元ホストが把握しているルーティングは、せいぜいネットワークのサブネット単位までのため)。それを把握できるのはルーターのみである。パケットがルーターに到着すると、ルーターはルーティングテーブルから経路を探すが、目的のホストは存在していないため、ルーターがDestination Unreachable/Host Unreachable(Type=3 Code=1)を返答し、エラーを報告する。ホストYへのEcho Requestへの場合には、ホストY自身がEcho Reply(Type=0)を報告することになる。
ICMPはこのようにインターネットの「健康的な運用」のために不可欠な仕組みだが、IPv6ではIPv4以上にさまざまな役割を定義されている。これはIPv4におけるARPやIGMP、DHCPにおけるIPアドレス決定などの機能が、IPv6ではICMPを用いて定義し直されたからである。そのためIPv4におけるICMPとは仕様が大きく変わっており、ICMPv6と呼ばれる。主にRFC 4443で定義されている。
Type | 名前 | RFC |
---|---|---|
0 | Reserved | - |
1 | Destination Unreachable | RFC 4443 |
2 | Packet Too Big | RFC 4443 |
3 | Time Exceeded | RFC 4443 |
4 | Parameter Problem | RFC 4443 |
100 | Private experimentation | RFC 4443 |
101 | Private experimentation | RFC 4443 |
102-126 | Unassigned | - |
127 | Reserved for expansion of ICMPv6 error messages | RFC 4443 |
128 | Echo Request | RFC 4443 |
129 | Echo Reply | RFC 4443 |
130 | Multicast Listener Query | RFC 2710 |
131 | Multicast Listener Report | RFC 2710 |
132 | Multicast Listener Done | RFC 2710 |
133 | Router Solicitation | RFC 4861 |
134 | Router Advertisement | RFC 4861 |
135 | Neighbor Solicitation | RFC 4861 |
136 | Neighbor Advertisement | RFC 4861 |
137 | Redirect Message | RFC 4861 |
138 | Router Renumbering | Matt_Crawford |
139 | ICMP Node Information Query | RFC 4620 |
140 | ICMP Node Information Response | RFC 4620 |
141 | Inverse Neighbor Discovery Solicitation Message | RFC 3122 |
142 | Inverse Neighbor Discovery Advertisement Message | RFC 3122 |
143 | Version 2 Multicast Listener Report | RFC 3810 |
144 | Home Agent Address Discovery Request Message | RFC 6275 |
145 | Home Agent Address Discovery Reply Message | RFC 6275 |
146 | Mobile Prefix Solicitation | RFC 6275 |
147 | Mobile Prefix Advertisement | RFC 6275 |
148 | Certification Path Solicitation Message | RFC 3971 |
149 | Certification Path Advertisement Message | RFC 3971 |
150 | ICMP messages utilized by experimental mobility protocols such as Seamoby | RFC 4065 |
151 | Multicast Router Advertisement | RFC 4286 |
152 | Multicast Router Solicitation | RFC 4286 |
153 | Multicast Router Termination | RFC 4286 |
154 | FMIPv6 Messages | RFC 5568 |
155 | RPL Control Message | RFC 6550 |
156 | ILNPv6 Locator Update Message | RFC 6743 |
157 | Duplicate Address Request | RFC 6775 |
158 | Duplicate Address Confirmation | RFC 6775 |
159-199 | Unassigned | - |
200 | Private experimentation | RFC 4443 |
201 | Private experimentation | RFC 4443 |
255 | Reserved for expansion of ICMPv6 informational messages | RFC 4443 |
表3 ICMPv6 Type一覧 |
ICMPとしての基本的な役割やプロトコルフォーマットはICMPv4から変更はないが、Typeフィールドの種類が増え、値も整理され、それに応じた新たな機能が定義されている。Typeフィールドは0〜127がエラー報告関連、128〜255が一般的な機能関連(インフォメーション)と分類された(つまり先頭1ビットで区別している)。
エラー報告関連はv4に比べるとかなり少なくなった。簡単にまとめると、「ルーティング不能」「TTL超過」「MTU超過」「パケットパラメータエラー」のみとなった。これは実際には使われていなかった機能が削除されたからである。逆に言うと、ICMPv6でもこれらICMPv4でもおなじみの機能はそのまま利用される。Type番号こそ変わったものの、基本的な動作はICMPv4と全く同じである。
一方で大きく変わったのが一般的な機能関連で、IPv4では別のプロトコルや機能として定義されていたものが、IPv6ではICMPv6の機能として整理された。IPv6では基本的にこうした「ノード間の情報交換や調整機能」はICMPv6で吸収する思想なので、RFC 4443以外の仕様でもTypeと機能が増えており、今後もそうした傾向になるだろう。
ICMPv4と比べて増えた機能などの詳細については、ICMPを利用した「ping」と「traceroute(tracert)」の解説記事(下記)の中で紹介しよう。
【2017/01/30】最新の状況に合わせて内容を精査の上、更新しました
【2001/08/30】初版公開
Copyright © ITmedia, Inc. All Rights Reserved.