互聯網控制訊息協定

互聯網控制訊息協定（英語：Internet Control Message Protocol，縮寫：ICMP）是互聯網協定套組的核心協定之一。它用於網際網絡協定（IP）中傳送控制訊息，提供可能發生在通訊環境中的各種問題反饋。通過這些資訊，使管理者可以對所發生的問題作出診斷，然後採取適當的措施解決。

ICMP ^[1]依靠IP來完成它的任務，它是IP的主要部分。它與傳輸協定（如TCP和UDP）顯著不同：它一般不用於在兩點間傳輸數據。它通常不由網絡程式直接使用，除了 ping 和 traceroute 這兩個特別的例子。 IPv4中的ICMP被稱作ICMPv4，IPv6中的ICMP則被稱作ICMPv6。

技術細節

ICMP是在 RFC 792 中定義的互聯網協定套組之一。通常用於返回的錯誤資訊或是分析路由。ICMP錯誤訊息總是包括了源數據並返回給傳送者。 ICMP錯誤訊息的例子之一是TTL值過期。每個路由器在轉發數據報的時候都會把IP包頭中的TTL值減1。如果TTL值為0，「TTL在傳輸中過期」的訊息將會回報給源地址。每個ICMP訊息都是直接封裝在一個IP封包中的，因此，和UDP一樣，ICMP是不可靠的。

雖然ICMP是包含在IP封包中的，但是對ICMP訊息通常會特殊處理，會和一般IP封包的處理不同，而不是作為IP的一個子協定來處理。在很多時候，需要去檢視ICMP訊息的內容，然後傳送適當的錯誤訊息到那個原來產生IP封包的程式，即那個導致ICMP訊息被傳送的IP封包。

很多常用的工具是基於ICMP訊息的。traceroute 是通過傳送包含有特殊的TTL的包，然後接收ICMP超時訊息和目標不可達訊息來實現的。 ping 則是用ICMP的"Echo request"（類別代碼：8）和"Echo reply"（類別代碼：0）訊息來實現的。

ICMP封包結構

報頭

ICMP報頭從IP報頭的第160位元開始（IP首部20位元組）（除非使用了IP報頭的可選部分）。

Bits	160-167	168-175	176-183	184-191
160	Type	Code	校驗碼（checksum）
192	Rest of Header

Type - ICMP的類型,標識生成的錯誤封包；
Code - 進一步劃分ICMP的類型,該欄位用來尋找產生錯誤的原因.；例如，ICMP的目標不可達類型可以把這個位設為1至15等來表示不同的意思。
Checksum - Internet校驗和（RFC 1071），用於進行錯誤檢查，該校驗和是從ICMP頭和以該欄位替換為0的數據計算得出的。
Rest of Header - 報頭的其餘部分，四位元組欄位，內容根據ICMP類型和代碼而有所不同。

填充數據

填充的數據緊接在ICMP報頭的後面（以8位元為一組）：

Linux的"ping"工具填充的ICMP除了8個8位元組的報頭以外，預設情況下還另外填充數據使得總大小為64位元組。
Windows的"ping.exe"填充的ICMP除了8個8位元組的報頭以外，預設情況下還另外填充數據使得總大小為40位元組。

封包類型

類型	代碼	狀態	描述	查詢	差錯
0 - 響應回顯	0		Echo響應 (被程式ping使用）	●
1 and 2		未分配	保留		●
3 - 目的不可達	0		目標網絡不可達		●
	1		目標主機不可達		●
	2		目標協定不可達		●
	3		目標埠不可達		●
	4		要求分段並設置DF flag標誌		●
	5		源路由失敗		●
	6		未知的目標網絡		●
	7		未知的目標主機		●
	8		源主機隔離（作廢不用）		●
	9		禁止訪問的網絡		●
	10		禁止訪問的主機		●
	11		對特定的TOS 網絡不可達		●
	12		對特定的TOS 主機不可達		●
	13		由於過濾網絡流量被禁止		●
	14		主機越權		●
	15		優先權終止生效		●
4 - 源端關閉	0	棄用	源端關閉（擁塞控制）		●
5 - 重新導向	0		重新導向網絡		●
	1		重新導向主機		●
	2		基於TOS 的網絡重新導向		●
	3		基於TOS 的主機重新導向		●
6		棄用	備用主機地址
7		未分配	保留
8 - 請求回顯	0		Echo請求	●
9 - 路由器通告	0		路由通告	●
10 - 路由器請求	0		路由器的發現/選擇/請求	●
11 - ICMP 逾時	0		TTL 逾時		●
11 - ICMP 逾時	1		分片重組逾時		●
12 - 參數問題：錯誤IP頭部	0		IP 報首部參數錯誤		●
	1		遺失必要選項		●
	2		不支援的長度
13 - 時間戳請求	0		時間戳請求	●
14 - 時間戳應答	0		時間戳應答	●
15 - 資訊請求	0	棄用	資訊請求	●
16 - 資訊應答	0	棄用	資訊應答	●
17 - 地址遮罩請求	0	棄用	地址遮罩請求	●
18 - 地址遮罩應答	0	棄用	地址遮罩應答	●
19		保留	因安全原因保留
20 至 29		保留	Reserved for robustness experiment
30 - Traceroute	0	棄用	資訊請求
31		棄用	數據報轉換出錯
32		棄用	手機網絡重新導向
33		棄用	Where-Are-You（originally meant for IPv6）
34		棄用	Here-I-Am（originally meant for IPv6）
35		棄用	Mobile Registration Request
36		棄用	Mobile Registration Reply
37		棄用	Domain Name Request
38		棄用	Domain Name Reply
39		棄用	SKIP Algorithm Discovery Protocol, Simple Key-Management for Internet Protocol
40			Photuris, Security failures
41		實驗性的	ICMP for experimental mobility protocols such as Seamoby [RFC4065]
42 到 255		保留	保留
235		實驗性的	RFC3692（ RFC 4727）
254		實驗性的	RFC3692（ RFC 4727）
255		保留	保留

源站抑制

源站抑制封包旨在請求傳送方降低發往路由器或主機的封包傳送速率。在接收的過程中，當接收方沒有足夠的接收緩衝區來處理接收到的封包，或者接收這個封包會導致臨近其本身的緩衝區限制時，就會觸發源站抑制封包。

數據被從一個或一群主機高速地發往網絡上的一個路由器，雖然路由器有緩衝機制，但是路由器的緩衝區大小通常（由於實體記憶體有限的原因）被限制。因此，如果路由器的通訊量過大，路由器最終會（由於主記憶體耗盡，導致必須丟棄掉接收到的數據報）無法繼續處理超過輸入緩衝區限制的部分數據，直到路由器緩衝佇列有空餘空間可以存放新的數據報。但是由於網絡層（Network Layer）缺乏確認訊息（ACK）機制，因此客戶端無法獲知數據是否成功抵達接收方。所以研究者提出了源站抑制這一補救措施來解決這一問題：當路由器發現流入數據速率遠遠高於流出數據速率時，會傳送ICMP源站抑制封包給源站，通知源站應該降低其數據傳輸速度或等待一定時間後再嘗試傳送更多數據。當源站接收到ICMP源站抑制封包時會減慢數據傳送的速度，或者在再次嘗試傳送數據前等待一定的時間，使得路由器能夠（在處理完當前接收到的數據之後）清空輸入緩衝佇列。

但是因為有研究表明「源站抑制是一種無效的（不公平的）補救措施「，所以路由的源站抑制封包已在1995年被RFC 1812 （頁面存檔備份，存於互聯網檔案館）棄用。此外，（路由）轉發和回應任何形式的源站抑制封包已在2012年被RFC 6633 （頁面存檔備份，存於互聯網檔案館）棄用

源站抑制封包^[1]
00	08	16
類型（Type） = 4	代碼（Code） = 0	核對和（Checksum）
未使用
IP數據報頭部和源數據報數據的前8個位元組

其中:

類型（Type） 必須設置為4

代碼（Code） 必須設置為0

IP數據報頭部 和其附加的數據用於傳送端根據回應封包匹配對應的請求封包

重新導向

重新導向 封包是閘道器發出的，用於要求主機或路由器改變數據報的傳輸路徑的ICMP封包。ICMP 重新導向是路由器將路由資訊傳達給主機的機制。這種類型的封包通知主機更新它的路由資訊（請求主機改變其路由）。如果一個主機在通訊時將數據報傳送給了路由器R1，而R1將這個數據報轉發給了另一個路由器R2，且主機到路由器R2之間有一條直連的路徑（也就是說，此主機和路由器R2處於同一乙太網路段上），那麼路由器R1會傳送一條重新導向封包給主機，來通知它到路由器R2可用路徑里有一條更短、更最佳化的路徑。這個主機在接收到這個重新導向封包之後應該改變其路由至這個最佳化版本的路由資訊，來將抵達這個目的地的數據報直接傳送到路由器R2，並且路由器仍將原始數據報傳送到預期目的地。^[2]但是，如果一個數據報攜帶有路由資訊，那麼即使有更加最佳化的路徑，路由器也不會傳送重新導向封包。並且，RFC 1122 指出，重新導向封包應該只由閘道器傳送，而不應該由互聯網主機傳送。^[3]

重新導向封包^[1]^:11
00	08	16
類型（Type） = 5	代碼（Code）	核對和（Checksum）
路由器的IP 地址
激發重新導向封包的數據報IP首部及其數據的前8位元組

其中:

類型（Type） 必須設置為 5.

代碼（Code） 指定重新導向的原因，見下表

代碼（Code）	描述
0	針對網絡的重新導向封包
1	針對主機的重新導向封包
2	針對網絡和服務類型的重新導向封包
3	針對主機和服務類型的重新導向封包

路由器的IP 地址（IP address） 是一個32位元的閘道器IP位址，該地址指明了該數據報應該被重新導向到的路由器地址。

激發重新導向封包的數據報IP首部及其數據的前8位元組（IP header） 用於收到重新導向封包的主機根據回應封包匹配對應的請求封包，來確定該數據報的目的站地址。

逾時

逾時封包是閘道器產生並行送給源站的ICMP封包，用於通知源站有數據報因為存活時間遞減至0而被此閘道器丟棄。當主機等待數據報分片的過程中逾時而無法重新組裝數據報分片時也會產生該封包。

逾時封包也用於traceroute工具來辨識兩個主機之間的路徑上的閘道器。

逾時封包^[1]^:5
00	08	16
類型（Type） = 11	代碼（Code）	校驗和（Checksum）
路由器的IP 地址
激發逾時封包的數據報IP首部及其數據的前8位元組

其中:

類型（Type） 必須設置為 11

代碼（Code） 指定重逾時的原因，見下表

Code	Description
0	存活時間計數逾時
1	分片重新安裝逾時

激發逾時封包的數據報IP首部及其數據的前8位元組 這些資訊用於源站根據收到的逾時封包來確定具體哪個數據報已被丟棄。對於高層協定，比如用戶數據報協定和傳輸控制協定而言，額外的8位元組數據指明了已被丟棄的數據報中的源埠與目的埠。

時間戳請求

時間戳請求 封包主要用於互聯網機器（包括路由器和主機）之間同步時鐘。起始時間戳是傳送端最後一次改動該數據報的時間戳(為世界標準時午夜開始計算的毫秒數)。在該類型的封包中，接收時間戳和傳輸時間戳未被使用。

時間戳請求封包^[1]^:15
00	08	16
類型（Type） = 13	代碼（Code） = 0	核對和（Checksum）
識別碼（Identifier）		序號（Sequence number）
起始時間戳（Originate timestamp）
接收時間戳（Receive timestamp）
傳輸時間戳（Transmit timestamp）

其中:

類型（Type） 必須設置為 13

代碼（Code） 必須設置為 0

識別碼（Identifier） and 序號（Sequence） 用於在時間戳請求封包和時間戳回答封包之間建立關聯

起始時間戳（Originate timestamp） 為世界標準時午夜開始計算的毫秒數。如果沒有可用的世界標準時參考，則可以將最高有效位設置為1以指示這是一個非標準時間值。

時間戳回答

時間戳回答 封包是對時間戳請求封包的回答封包。時間戳回答封包由接收到的時間戳請求封包其中的起始時間戳和接收時間戳（回應端主機接收到請求封包並建立時間戳回應封包的時間，單位為毫秒）、傳輸時間戳（時間戳回答封包被傳送出去的時間，單位為毫秒）組成。

時間戳回答封包^[1]^:15
00	08	16
類型（Type） = 14	代碼（Code） = 0	核對和（Checksum）
識別碼（Identifier）		序號（Sequence number）
起始時間戳（Originate timestamp）
接收時間戳（Receive timestamp）
傳輸時間戳（Transmit timestamp）

其中:

類型（Type） 必須設置為 14

代碼（Code） 必須設置為 0

識別碼（Identifier） 和 序號（Sequence number） 用於在時間戳請求封包和時間戳回答封包之間建立關聯。

起始時間戳（Originate timestamp） 是傳送端最後一次改動該數據報的時間戳。

接收時間戳（Receive timestamp） 是回應端主機接收到請求封包並建立時間戳回應封包的時間，單位為毫秒。

傳輸時間戳（Transmit timestamp） 是最後一次修改回應封包並將其傳送出去的時間，單位為毫秒。

所有的時間戳都是世界標準時午夜起始的毫秒數。如果這個時間不能表示為毫秒或者沒有可用的世界標準時參考值，則可以使用任何格式的時間值並將最高有效位設置為1以指示這是一個非標準時間值。

地址遮罩請求

地址遮罩請求 封包是主機為了得到一個合適的子網絡遮罩而傳送到路由器的ICMP請求封包。

接收到此請求封包的機器應當傳送一個地址遮罩回答封包給源站。

地址遮罩請求封包
00	08	16
類型（Type） = 17	代碼（Code） = 0	核對和（Checksum）
識別碼（Identifier）		序號（Sequence number）
地址遮罩（Address mask）

其中:

類型（Type） 必須設置為 17

代碼（Code） 必須設置為 0

地址遮罩（Address mask） 可以為0

由於ICMP 地址遮罩請求可能會被用於嗅探攻擊來收集特定網絡的資訊，因此該封包預設情況下被Cisco IOS禁用。^[4]

地址遮罩回答

地址遮罩回答 封包攜帶有地址遮罩資訊，用於回答地址遮罩請求封包。

地址遮罩回答封包
00	08	16
類型（Type） = 18	代碼（Code） = 0	校驗和（Checksum）
識別碼（Identifier）		序號（Sequence number）
地址遮罩（Address mask）

其中:

類型（Type） 必須設置為 18

代碼（Code） 必須設置為 0

地址遮罩（Address mask） 為待回答的地址遮罩

源站不可達

源站不可達 封包是由主機或入站閘道器用於通知客戶端出於目的站無法連接的封包。這些原因可能包括：物理連接失效（也即網絡距離無限大），或指定的地址或埠處於非啟用狀態，或者數據報長度過長而導致必須分片但是IP首部指定了「不分片」選項導致無法分片。如果是TCP埠不可達，則會返回TCP RST，而不會返回此封包。如果是IP多播的情況，也不會返回此封包。

源站不可達封包^[1]^:3
00	08	16
類型（Type） = 3	代碼（Code）	核對和（Checksum）
未使用		下一跳的MTU值
激發ICMP地址不可達封包的數據報IP首部及其數據的前8位元組

其中:

類型（Type） 必須設置為 3

代碼（Code） 欄位用於指示具體導致源站不可達的原因。見下表。

代碼（Code）	解釋（Description）
0	網絡不可達
1	主機不可達
2	協定不可達
3	埠不可達
4	需要分片但是DF(Do not Fragment)置位
5	源路由失敗
6	目的網絡未知
7	目的主機未知
8	源主機被隔離
9	與受到管理禁控的目的網絡通訊
10	與受到管理禁控的目的主機通訊
11	對於指明的服務類型，網絡不可達
12	對於指明的服務類型，主機不可達
13	出於管理目的禁止通訊
14	主機越權.
15	優先權剝奪生效

Next-hop MTU 當需要分片但是DF(Do not Fragment)置位的錯誤發生時，包含了下一跳網絡的MTU的值。

IP header 用於源站根據收到的源站不可達封包來確定具體哪個數據報引起了源站不可達錯誤。

參考

^ ^1.0 ^1.1 ^1.2 ^1.3 ^1.4 ^1.5 ^1.6 RFC 792 INTERNET CONTROL MESSAGE PROTOCOL; DARPA INTERNET PROGRAM; PROTOCOL SPECIFICATION; Introduction. J. Postel (Internet RFC/STD/FYI/BCP Archives). 1981-09-01 [2008-05-16]. （原始內容存檔於2009-03-16）.
^ When Are ICMP Redirects Sent?. Cisco Systems. 2008-06-28 [2013-08-15]. （原始內容存檔於2014-01-12）.
^ Requirements for Internet Hosts -- Communication Layers. RFC. [2021-01-12]. （原始內容存檔於2011-05-23）.
^ Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and Services, Release 12.3 - IP Addressing and Services Commands: ip mask-reply through ip web-cache. Cisco Systems. [2013-01-07]. （原始內容存檔於2013-01-02）.

外部連結

RFC 792, Internet Control Message Protocol
ICMP Sequence Diagram（頁面存檔備份，存於互聯網檔案館）
RFC 1122, Requirements for Internet Hosts -- Communication Layers
RFC 1716, Towards Requirements for IP Router
RFC 1812, Requirements for IP Version 4 Routers
RFC 6633, Deprecation of ICMP Source Quench Messages
Filtering ICMP on firewalls
IANA（頁面存檔備份，存於互聯網檔案館）

[rfc792-1] 1.0 ^1.1 ^1.2 ^1.3 ^1.4 ^1.5 ^1.6 RFC 792 INTERNET CONTROL MESSAGE PROTOCOL; DARPA INTERNET PROGRAM; PROTOCOL SPECIFICATION; Introduction. J. Postel (Internet RFC/STD/FYI/BCP Archives). 1981-09-01 [2008-05-16]. （原始內容存檔於2009-03-16）.

[2] When Are ICMP Redirects Sent?. Cisco Systems. 2008-06-28 [2013-08-15]. （原始內容存檔於2014-01-12）.

[3] Requirements for Internet Hosts -- Communication Layers. RFC. [2021-01-12]. （原始內容存檔於2011-05-23）.

[4] Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and Services, Release 12.3 - IP Addressing and Services Commands: ip mask-reply through ip web-cache. Cisco Systems. [2013-01-07]. （原始內容存檔於2013-01-02）.

[1]

[2]

[3]

[4]