ICMP Internet Control Message Protocol

didesain u/ mengontrol pesan antar router dan antar host.

Sebuah ICMP header mengikuti IP header pada Paket IP, tapi bukan dianggap sbg header layer 4 seperti TCP dan UDP tapi ICMP dianggap sebagai satu kesatuan dari IP.

Here is a picture of the fields an ICMP header adds to an IP
packet:
8 16 32 bits
Type Code Checksum
Identifier Sequence number
Data

You'll note that an ICMP header is composed of six fields. Interestingly, the Data field does not contain the actual ICMP "message." Instead, the Type and the Code fields contain numeric values, and each numeric value represents a specific ICMP message. Every ICMP packet must have a Type value, but only some ICMP types have an associated non-zero Code value.

RFC 1700 contains the possible values for each ICMP type and code; I've summarized these into the following table:
Type Name Code(s)
0 Echo reply 0 - none
1 Unassigned
2 Unassigned
3 Destination unreachable 0 - Net unreachable
1 - Host unreachable
2 - Protocol unreachable
3 - Port unreachable
4 - Fragmentation needed and DF bit set
5 - Source route failed
6 - Destination network unknown
7 - Destination host unknown
8 - Source host isolated
9 - Communication with destination network is administratively prohibited
10 - Communication with destination host is administratively prohibited
11 - Destination network unreachable for TOS
12 - Destination host unreachable for TOS
4 Source quench 0 - none
5 Redirect 0 - Redirect datagram for the network
1 - Redirect datagram for the host
2 - Redirect datagram for the TOS and network
3 - Redirect datagram for the TOS and host
6 Alternate host address 0 - Alternate address for host
7 Unassigned
8 Echo 0 - None
9 Router advertisement 0 - None
10 Router selection 0 - None
11 Time Exceeded 0 - Time to live exceeded in transit
1 - Fragment reassembly time exceeded
12 Parameter problem 0 - Pointer indicates the error
1 - Missing a required option
2 - Bad length
13 Timestamp 0 - None
14 Timestamp reply 0 - None
15 Information request 0 - None
16 Information reply 0 - None
17 Address mask request 0 - None
18 Address mask reply 0 - None
19 Reserved (for security)
20-29 Reserved (for robustness experiment)
30 Traceroute
31 Datagram conversion error
32 Mobile host redirect
33 IPv6 where-are-you
34 IPv6 I-am-here
35 Mobile registration request
36 Mobile registration reply
37-255 Reserved

You'll note that the ICMP types that do have associated codes use the Code field to further explain the message value in the Type field. For example, ICMP Type 3 represents "destination unreachable." There can be many reasons why a destination is unreachable; accordingly, every ICMP Type 3 packet will also use one of the codes to explain why the destination was unreachable.

In our dump file, packets 4-9 contained ICMP information. These packets were created right after ARP had determined the destination MAC address and just before the TCP 3-way handshake. Let's take a look at packets 4 and 5:

tcpshow < dump


-------------------------------------------------
Packet 4
TIME: 10:25:28.608640 (0.000355)
LINK: 00:00:B4:3C:56:40 -> 00:50:BA:DE:36:33 type=IP
IP: 10.0.0.2 -> 10.0.0.1 hlen=20 TOS=00 dgramlen=84 id=0010
MF/DF=0/0 frag=0 TTL=255 proto=ICMP cksum=A796
ICMP: echo-request cksum=169F
DATA: ....:_.:6....
..................... !"#$%&'()*+,-./01234567
-------------------------------------------------
Packet 5
TIME: 10:25:28.608722 (0.000082)
LINK: 00:50:BA:DE:36:33 -> 00:00:B4:3C:56:40 type=IP
IP: 10.0.0.1 -> 10.0.0.2 hlen=20 TOS=00 dgramlen=84 id=9551
MF/DF=0/0 frag=0 TTL=255 proto=ICMP cksum=1255
ICMP: echo-reply cksum=1E9F
DATA: ....:_.:6....
..................... !"#$%&'()*+,-./01234567

Notice that these are normal IP packets with the expected IP header fields. Immediately following the IP header is the ICMP header which is followed by some strange-looking data. The tcpshow utility did not show all of the ICMP fields, but you can see that Packet No. 4 was an echo-request and Packet No. 5 was an echo-reply. If we look up these names in the chart, we'll see that Packet 4 contains an ICMP Type 8 Code 0 message, and Packet 5 contains an ICMP Type 0 Code 0 message.

Let's look at these same packets using Ethereal. Because Ethereal is so verbose, I'll just show the frame number and the ICMP header:

Also in FreeBSD Basics:

Fun with Xorg

Sharing Internet Connections

Building a Desktop Firewall

Using DesktopBSD

Using PC-BSD

more etherdump

more etherdump


Frame 4 (98 on wire, 98 captured)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x169f (correct)
Identifier: 0xdd00
Sequence number: 00:00
Data (56 bytes)

0 3a5f a23a 36c3 0600 0809 0a0b 0c0d 0e0f :_.:6...........
10 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f ................
20 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f !"#$%&'()*+,-./
30 3031 3233 3435 3637 01234567

Frame 5 (98 on wire, 98 captured)
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0x1e9f (correct)
Identifier: 0xdd00
Sequence number: 00:00
Data (56 bytes)

0 3a5f a23a 36c3 0600 0809 0a0b 0c0d 0e0f :_.:6...........
10 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f ................
20 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f !"#$%&'()*+,-./
30 3031 3233 3435 3637 01234567

Notice that Ethereal interprets all of the ICMP fields, including the Type and Code numbers. It also indicates the name of the utility that issued these ICMP packets -- before TCP initiated its 3-way handshake, three "ping" packets were sent out to verify connectivity between my telnet client and the telnet server. The first ping packet contained the echo-request and it was followed by the desired echo-reply.

Packets 6 and 7 contained the next echo-request/echo-reply pair. These packets were identical, except they both contained a sequence number of 01:00, instead of the sequence number of 00:00 you saw in Packets 4 and 5. Packets 8 and 9 contained the last echo-request/echo-reply pair and both shared a sequence number of 02:00. However, all six packets contained the same Identifier value of 0xdd00; this means that they were all issued from the same ping command.

To summarize, whenever you run the ping utility, you will send out ICMP Type 8 Code 0 packets. Each packet will have the same identifier, but every packet's sequence number will be increased by 1. If you have connectivity to the other host, you should receive back ICMP Type 0 Code 0 packets with the same identifier. If you don't receive all the packets back in sequence, you don't have a very reliable connection.

You've probably used the ping utility yourself to test the connection between two hosts running TCP/IP; you may have not known that ping uses ICMP. Here is an interesting article on ping by the author of the utility.

The traceroute utility is another utility that uses ICMP messages, but its usage is different from that of the ping utility. When you type traceroute hostname, three UDP packets are sent out with a TTL (time to live) value of 1. These three packets will arrive at the router closest to you which will decrease the TTL by one, meaning the TTL will now be 0. When routers notice a TTL of 0, they respond by sending an ICMP packet of Type 11 Code 0, or "time exceeded" as "time to live exceeded in transit." The traceroute utility will make note of the IP address of the router that sent back the three ICMP packets, calculate the time it took to receive each of the packets, then send out three more UDP packets, this time with a TTL of 2.

Because these packets have a TTL of 2, ICMP packets should be returned by the router that is two hops away from you. Once these packets are received and noted, traceroute sends out three more packets with a TTL of 3. The traceroute utility will continue this pattern until you either reach your final destination or you've gone through the default maximum of 30 routers. The results will be sent to your screen like so:

traceroute www.freebsd.org

traceroute to freefall.freebsd.org (216.136.204.21), 30 hops max, 40 byte packets
1 10.69.4.1 (10.69.4.1) 33.137 ms 110.654 ms 52.307 ms
2 d226-12-1.home.cgocable.net (24.226.12.1) 15.413 ms 36.285 ms 12.538 ms
3 cgowave-0-158.cgocable.net (24.226.0.158) 13.857 ms 14.130 ms 16.433 ms
4 cgowave-busy-core.cgocable.net (24.226.1.1) 15.304 ms 15.470 ms 14.940 ms
5 cgowave-0-202.cgocable.net (24.226.0.202) 16.681 ms 14.324 ms 16.357 ms
6 10.0.185.33 (10.0.185.33) 16.066 ms 15.919 ms 17.318 ms
7 c1-pos8-0.bflony1.home.net (24.7.74.29) 18.234 ms 18.063 ms 19.266 ms
8 c1-pos1-0.hrfrct1.home.net (24.7.65.253) 27.590 ms 25.213 ms 48.447 ms
9 c1-pos3-0.nycmny1.home.net (24.7.69.2) 32.722 ms 29.405 ms 29.724 ms
10 ibr02-p1-0.jrcy01.exodus.net (24.7.70.122) 31.728 ms 48.891 ms 29.017 ms
11 bbr02-g4-0.jrcy01.exodus.net (216.32.223.114) 37.117 ms 37.070 ms 62.180 ms
12 bbr01-p2-0.okbr01.exodus.net (216.32.132.109) 59.707 ms 40.090 ms 39.422 ms
13 bbr02-p3-0.sttl01.exodus.net (216.32.132.89) 142.048 ms 101.184 ms 86.259 ms
14 bbr01-g5-0.sttl01.exodus.net (216.32.29.19) 83.362 ms 83.433 ms 83.103 ms
15 bbr01-p1-0.tkwl01.exodus.net (209.185.9.66) 85.309 ms 123.174 ms 83.753 ms
16 bbr01-p4-0.sntc05.exodus.net (216.32.173.229) 88.995 ms 90.207 ms 88.723 ms
17 dcr01-g2-0.sntc05.exodus.net (64.56.192.3) 109.213 ms 90.418 ms 90.458 ms
18 g2-1.bas1-m.sc5.yahoo.com (64.56.207.146) 170.210 ms 164.354 ms 281.053 ms
19 freefall.freebsd.org (216.136.204.21) 91.146 ms 88.509 ms 91.049 ms

Note that the traceroute utility numbered each hop, gave the name and IP address of the associated router, and recorded the time it took to receive an ICMP response to each of the three UDP packets that were sent to each router.

The ping and traceroute utilities are the most common utilities used by users that involve the ICMP protocol. However, there is another ICMP type that you should be aware of as it can affect network performance if there are routers between you and your final destination.

When I captured the packets involved in the telnet session, both the telnet client and the telnet server were cabled onto the same LAN and none of the packets had to pass through a router. During the TCP 3-way handshake, each host indicated the maximum segment size (MSS) it was capable of receiving. The tcpshow utility did not interpret this data, but it can be seen using Ethereal:

more etherdump



Frame 10 (60 on wire, 60 captured)
Internet Protocol
Source: biko (10.0.0.2)
Destination: genisis (10.0.0.1)
Transmission Control Protocol, Src Port: blackjack (1025), Dst Port: telnet (23), Seq: 3205630181, Ack: 0
Source port: blackjack (1025)
Destination port: telnet (23)
Sequence number: 3205630181
Header length: 24 bytes
Flags: 0x0002 (SYN)
Window size: 16384
Checksum: 0x7814
Options: (4 bytes)
Maximum segment size: 1460 bytes

Frame 11 (58 on wire, 58 captured)
Internet Protocol
Source: genisis (10.0.0.1)
Destination: biko (10.0.0.2)
Transmission Control Protocol, Src Port: telnet (23), Dst Port: blackjack (1025), Seq: 1746119590, Ack: 3205630182
Source port: telnet (23)
Destination port: blackjack (1025)
Sequence number: 1746119590
Acknowledgement number: 3205630182
Header length: 24 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 17520
Checksum: 0x5fd9
Options: (4 bytes)
Maximum segment size: 1460 bytes

Because both computers were cabled onto the same LAN, they both understood and agreed upon a MSS of 1,460 bytes. Note that this is a maximum "segment" size, meaning a segment of data without including the extra bytes needed for the headers and frame. In this example, both hosts agreed that they wouldn't send a segment of data that was bigger than a 1,460-byte chunk.

What would happen if these two same hosts were not on the same LAN and their packets had to pass through a network that could only accept frames with a maximum transmission unit (MTU) size of 576 bytes? Because the two end hosts had already agreed upon a segment size of 1,460 bytes, they would be creating their IP packets accordingly. When these IP packets arrive at the router, which is cabled to the network with the smaller MTU, it will have to re-package every packet into smaller segments that will fit into the smaller size frames of that network. The destination host will then have to reassemble all of the fragmented packets back into the original agreed-upon sized segment. This creates more work and definitely slows things down.

To help prevent this, TCP uses something called Path-MTU Discovery. TCP will send out IP packets using the agreed MSS size, but will set the DF (don't fragment) bit to 1. If this packet is received by a router that needs to fragment the packet so that it will fit over a network that uses smaller-sized frames, the router will respond with an ICMP Type 3 Code 4 packet which translates to "destination unreachable as fragmentation needed" and "DF bit set." When the host receives this ICMP packet, it knows that it needs to start sending smaller packets.

You can read more about Path-MTU Discovery here.

The last ICMP type I'd like to cover is Source Quench, or ICMP Type 4 Code 0. This message is sent whenever a router is being overwhelmed by packets. It basically tells the host to slow down the rate it is sending packets so it can have a chance to deal with the packets it has already received. This is an important message -- if the host does not slow down its transmission rate, the router will run out of buffer space to store packets and will have to start throwing packets away. Every packet that is thrown away will have to be re-transmitted which will make the original situation worse.

The ICMP types we've covered do have implications when you start creating packet filter rules on your FreeBSD system. Next week, we will start looking at creating these rules, I'd like to summarize the ICMP types and codes that we'll need to be mindful of:
ICMP Type Code Used By
0 0 Ping
3 4 Path-MTU Discovery
4 0 Source Quench
8 0 Ping
11 0 traceroute

Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.