(Translated by https://www.hiragana.jp/)
互联网控制消息协议 - 维基百科，自由的百科全书
维基百科

互联网控制せい消息しょうそく协议

互联网协议族的てき核心かくしん协议之の一いち。主要しゅよう用よう于IPv4网络，以指示しじ网络操作そうさ中ちゅう的てき错误消息しょうそく

互联网控制せい消息しょうそく协议（英語えいご：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 超ちょう时 ●
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 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
类型（Type） = 4 代だい码（Code） = 0 检验和わ（Checksum）
未み使用しよう
IP数すう据すえ报头部ぶ和わ源げん数すう据すえ报数据すえ的てき前まえ8个字节

其中:

类型（Type） 必须设置为4
代だい码（Code） 必须设置为0
IP数すう据すえ报头部ぶ 和かず其附加ふか的てき数すう据すえ用よう于发送端はし根ね据すえ回かい应报文ぶん匹ひき配はい对应的てき请求报文

重定しげさだ向むかい

编辑
 
关于ICMPv4 重定しげさだ向こう报文如何いか工作こうさく的てき示しめせ例れい图

重定しげさだ向むかい 报文是ぜ网关发出的てき，用よう于要求ようきゅう主ぬし机つくえ或ある路みち由よし器き改あらため变数据すえ报的传输路ろ径みち的てきICMP报文。ICMP 重定しげさだ向むかい是ただし路みち由よし器き将しょう路ろ由よし信しん息いき传达给主机つくえ的てき机つくえ制せい。这种类型的てき报文通知つうち主ぬし机つくえ更新こうしん它的路ろ由よし信しん息いき（请求主ぬし机つくえ改あらため变其路ろ由ゆかり）。如果一个主机在通信时将数据报发送给了路みち由よし器きR1，而R1将しょう这个数すう据すえ报转发给了りょう另一个路由よし器きR2，且主机つくえ到いた路みち由よし器きR2之これ间有一条直连的路径（也就是ぜ说，此主机つくえ和わ路ろ由よし器きR2处于同どう一以太网段上），那な么路由よし器きR1会かい发送一条重定向报文给主机，来らい通知つうち它到路ろ由よし器きR2可用かよう路ろ径みち里さと有ゆう一いち条じょう更さら短たん、更さら优化的てき路ろ径みち。这个主ぬし机つくえ在ざい接收せっしゅう到いた这个重定しげさだ向こう报文之の后きさき应该改あらため变其路ろ由よし至いたり这个优化版本はんぽん的てき路ろ由よし信しん息いき，来らい将しょう抵达这个目的もくてき地ち的てき数すう据すえ报直接ちょくせつ发送到いた路みち由よし器きR2，并且路ろ由よし器き仍将原始げんし数すう据すえ报发送おく到いた预期目的もくてき地ち。[2]但ただし是ぜ，如果一个数据报携带有路由信息，那な么即使し有ゆう更さら加か优化的てき路ろ径みち，路みち由よし器き也不会かい发送重定しげさだ向こう报文。并且，RFC 1122 指出さしで，重定しげさだ向こう报文应该只ただ由よし网关发送，而不应该由よし互联网主机つくえ发送。[3]

重定しげさだ向こう报文[1]:11
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
类型（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 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
类型（Type） = 11 代だい码（Code） 校こう验和（Checksum）
路みち由よし器き的てきIP 地ち址し
激げき发超时报文ぶん的てき数すう据すえ报IP首部しゅぶ及其数すう据すえ的てき前まえ8字じ节

其中:

类型（Type） 必须设置为 11
代だい码（Code） 指定してい重おも超ちょう时的原因げんいん，见下表ひょう
Code Description
0 存そん活かつ時間じかん计数超ちょう时
1 分ぶん片かた重じゅう装そう超ちょう时
激げき发超时报文ぶん的てき数すう据すえ报IP首部しゅぶ及其数すう据すえ的てき前まえ8字じ节 这些信しん息いき用よう于源站根据すえ收おさむ到いた的てき超ちょう时报文ぶん来らい确定具体ぐたい哪个数すう据すえ报已被ひ丢弃。对于高だか层协议，比ひ如用よう户数据すえ报协议 和わ 传输控ひかえ制せい协议而言，额外的てき8字じ节数据すえ指ゆび明あきら了りょう已やめ被ひ丢弃的てき数すう据すえ报中的てき源げん端はし口こう与あずか目的もくてき端はし口こう。

时间戳请求もとむ

编辑

时间戳请求もとむ 报文主要しゅよう用よう于互联网机つくえ器き（包括ほうかつ路ろ由よし器き和わ主ぬし机つくえ）之の间同步ふ时钟。起おこり始はじめ时间戳是发送端はし最さい后きさき一次改动该数据报的时间戳(为世界せかい标准时午うま夜よる开始计算的てき毫秒数すう)。在ざい该类型がた的てき报文中ちゅう，接收せっしゅう时间戳和传输时间戳未被ひ使用しよう。

时间戳请求もとめ报文[1]:15
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
类型（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 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
类型（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 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
类型（Type） = 17 代だい码（Code） = 0 检验和わ（Checksum）
标识符ふ（Identifier） 序じょ号ごう（Sequence number）
地ち址し掩码（Address mask）

其中:

类型（Type） 必须设置为 17
代だい码（Code） 必须设置为 0
地ち址し掩码（Address mask） 可か以为0

由よし于ICMP 地ち址し掩码请求可能かのう会かい被ひ用よう于嗅探攻おさむ击来らい收集しゅうしゅう特定とくてい网络的てき信しん息いき，因いん此该报文默だま认情况下被ひCisco IOS禁きん用よう。[4]

地ち址し掩码回答かいとう

编辑

地ち址し掩码回答かいとう 报文携带有ゆう地ち址し掩码信しん息いき，用よう于回答かいとう地ち址し掩码请求报文。

地ち址し掩码回答かいとう报文
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
类型（Type） = 18 代だい码（Code） = 0 校こう验和（Checksum）
标识符ふ（Identifier） 序じょ号ごう（Sequence number）
地ち址し掩码（Address mask）

其中:

类型（Type） 必须设置为 18
代だい码（Code） 必须设置为 0
地ち址し掩码（Address mask） 为待回答かいとう的てき地ち址し掩码

源みなもと站不可ふか达

编辑

源みなもと站不可ふか达 报文是ぜ由ゆかり主しゅ机つくえ或ある入にゅう站网关用于通知つうち客きゃく户端出で于目的もくてき站无法ほう连接的てき报文。这些原因げんいん可能かのう包括ほうかつ：物理ぶつり连接失效しっこう（也即网络距离无限大だい），或ある指定してい的てき地ち址し或ある端はし口こう处于非ひ激げき活かつ状じょう态，或ある者もの数すう据すえ报长度ど过长而导致必须分片へん但ただし是ぜIP首部しゅぶ指定してい了りょう“不ふ分ぶん片へん”选项导致无法分ぶん片へん。如果是ぜTCP端はし口こう不可ふか达，则会返かえし回かいTCP RST，而不会かい返かえし回かい此报文ぶん。如果是ぜIP多た播的情じょう况，也不会かい返かえし回かい此报文ぶん。

源みなもと站不可ふか达报文ぶん[1]:3
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
类型（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. ^ 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）. 

外部がいぶ連結れんけつ

编辑
检索自じ“https://zh.wikipedia.org/w/index.php?title=互联网控制せい消息しょうそく协议&oldid=77689961”