Internet Control Message Protocol (ICMP)

Presented by

Dr.Apichan Kanjanavapastit

Why ICMP is needed?• The IP protocol is a best-effort delivery service that delivers a

datagram from its original source to its final destination• However, it has two deficiencies: lack of error control and lack of

assistance mechanisms• What happens if something goes wrong? What happens if a router

must discard a datagram because it cannot find a router to the final destination, or because the time-to-live field has a zero value?

• The Internet Control Message Protocol (ICMP) has been designed to compensate for the two deficiencies

ICMP Encapsulation

• ICMP itself is a network layer protocol. However, its messages are not passed directly to the data link layer as would be expected

• Instead, the messages are first encapsulated inside IP datagrams before going to the lower layer

• The value of the protocol field in the IP datagram is 1 to indicate that the IP data is an ICMP message

Types of ICMP Messages

• ICMP message are divided into two broad categories: error-reporting messages and query messages

• The error-reporting messages report problems that a router or a host (destination) may encounter when it processes an IP packet

• The query messages help a host or a network manager get specific information from a router or another host

Types of ICMP Messages (cont.)

Message Format• An ICMP message has an 8-byte header and a variable-size data

section• The general format of the header is different for each message type,

but the first 4 bytes are common to all• The first field, ICMP type defines the type of the message and the

Code field specifies the reason for the particular message type• The rest of the header is specific for each message type• The data section in error messages carries information for finding

the original packet that had the error• In query messages, the data section carries extra information based

on the type of the query

Figure 9.3 General format of ICMP messages

Error Reporting

• IP is not concerned with error checking and error control• ICMP was designed to compensate for this shortcoming.

ICMP does not correct errors, it simply reports them• Error correction is left to the higher layer protocols• Five types of errors are handled: destination

unreachable, source quench, time exceeded, parameter problems, and redirection

Error Reporting (cont.)

• All error messages contain a data section that includes the IP header of the original datagram plus the first 8 bytes of data in that datagram

• The original datagram header is added to give the original source information about the datagram itself

• The 8 bytes of data are included because they provide information about port number and sequence number

• This information is needed so the source can inform the protocols (TCP or UDP) about the error

The following are important points about ICMP error messages:

❏ No ICMP error message will be generated in response to a datagram carrying an ICMP error message.❏ No ICMP error message will be generated for a fragmented datagram that is not the first fragment.❏ No ICMP error message will be generated for a datagram having a multicast address.❏ No ICMP error message will be generated for a datagram having a special address such as 127.0.0.0 or 0.0.0.0.

Note:Note:

Contents of data field for the error messages

Destination Unreachable

• When a router cannot route a datagram or a host cannot deliver a datagram, the datagram is discarded and the router or the host sends a destination-unreachable message back to the source host that initiated the datagram

Destination-unreachable messages with codes 2 or 3 can be created only

by the destination host.

Other destination-unreachable messages can be created only by

routers.

Note:Note:

Source Quench• The source-quench message in ICMP was designed to add a kind

of flow control to the IP• When a router or host discards a datagram due to congestion, it

sends a source-quench message to the sender of the datagram• This messages has two purposes: First, it informs the source that

the datagram has been discarded, Second, it warns the source that there is congestion somewhere in the path and that the source should slow down (quench) the sending process

More explanations for source quench

• One source-quench message is sent for each datagram that is discarded due to congestion

• There is no mechanism to tell the source that the congestion has been relieved and the source can resume sending datagrams at its previous rate

• The congestion can be created either by a one-to-one or many-to-one communication

Time Exceeded

• The time-exceeded message is generated in 2 cases:– When a datagram is discarded due to the value of time to live

field is zero– When all fragments that make up a message do not arrive at the

destination host within a certain time limit

In a time-exceeded message, code 0 is used only by routers to show that the value of the time-to-live field is zero. Code 1 is used only by the destination

host to show that not all of the fragments have arrived within a set time.

Parameter Problem

• An ambiguity in the header part of a datagram can create serious problems as the datagram travels through the Internet

• If a router or the destination host discovers an ambiguous or missing value in any field of the datagram, it discards the datagram and sends a parameter-problem message back to the source

Redirection• Normally, hosts do not take part in the routing update process

because there are many more hosts in an internet than routers• The hosts usually use static routing and their routing table has a

limited number of entries• They usually know the IP address of a router, the default router• Fore this reason, the hosts may send a datagram, which is destined

for another network, to the wrong router• In this case, the router that receives the datagram will forward the

datagram to the correct router• To update the routing table of the host, it sends a redirect message

to the hostIP packet 1

RM2

IP packet

3

IP packet

4

Redirection Message Format

• Default gateways only send ICMP redirect/change request messages if the following conditions are met: – The interface on which the packet comes into the router is the same

interface on which the packet gets routed out.

– The subnet/network of the source IP address is the same subnet/network of the next-hop IP address of the routed packet.

– The datagram is not source-routed.

– The route for the redirect is not another ICMP redirect or a default route.

– The router is configured to send redirects. (By default, Cisco routers send ICMP redirects. The interface subcommand no ip redirects will disable ICMP redirects.)

ICMP Redirect Example• Host H sends a packet to Host 10.1.1.1 on network 10.0.0.0/8. • Since Host H is not directly connected to the same network, it forwards the packet to its default

gateway, Router R1 at 172.16.1.100. • Router R1 finds the correct route to network 10.0.0.0/8 by looking in its route table. • It determines that the path to the network is back out the same interface the request to forward

the packet came from to Router R2 at 172.16.1.200. • R1 forwards the packet to R2 and sends an ICMP redirect/change request to Host H telling

it to use Router R2 at 172.16.1.100 as the gateway to forward all future requests to network 10.0.0.0/8.

Query

• ICMP can also diagnose some network problems through the query messages, a group of four different pairs of messages

• In this type of ICMP message, a node sends a message that is answered in a specific format by the destination node.

Echo Request and Reply• The echo-request and echo-reply messages are designed for

diagnostic purposes• The combination of echo-request and echo-reply messages

determines whether two systems (hosts or routers) can communication with each other at the IP level

• Echo-request and echo-reply can determine whether or not a node is functioning properly. The node to be tested is sent an echo-request message. The optional data field contains a message that must be repeated exactly by the responding node in its echo-request message

Timestamp Request and Reply

• Two machines (hosts or routers) can use the timestamp-request and timestamp-reply messages to determine the round-trip time needed for an IP datagram to travel between them

• It can also used to synchronize the clocks in two machines

Timestamp Computations

Computation Example

We use the ping program to test the server fhda.edu. The result is shown below:

Example 1

We use the traceroute program to find the route from the computer voyager.deanza.edu to the server fhda.edu. The following shows the result:

Example 2

See Next Slide

$ traceroute fhda.edutraceroute to fhda.edu (153.18.8.1), 30 hops max, 38 byte packets1 Dcore.fhda.edu (153.18.31.254) 0.995 ms 0.899 ms 0.878 ms2 Dbackup.fhda.edu (153.18.251.4) 1.039 ms 1.064 ms 1.083 ms3 tiptoe.fhda.edu (153.18.8.1) 1.797 ms 1.642 ms 1.757 ms

The un-numbered line after the command shows that the destination is 153.18.8.1. The TTL value is 30 hops. The packet contains 38 bytes: 20 bytes of IP header, 8 bytes of UDP header, and 10 bytes of application data. The application data is used by traceroute to keep track of the packets.

Example 2 (Continued)

The first line shows the first router visited. The router is named Dcore.fhda.edu with IP address 153.18.31.254. The first round trip time was 0.995 milliseconds, the second was 0.899 milliseconds, and the third was 0.878 milliseconds.

The second line shows the second router visited. The router is named Dbackup.fhda.edu with IP address 153.18.251.4. The three round trip times are also shown.

The third line shows the destination host. We know that this is the destination host because there are no more lines. The destination host is the server fhda.edu, but it is named tiptoe. fhda.edu with the IP address 153.18.8.1. The three round trip times are also shown.

Finally, we use the traceroute program to find the route between fhda.edu and mhhe.com (McGraw-Hill server). We notice that we cannot find the whole route. When traceroute does not receive a response within 5 seconds, it prints an asterisk to signify a problem, and then tries the next hop..

Example 3

$ traceroute mhhe.comtraceroute to mhhe.com (198.45.24.104), 30 hops max, 38 byte packets1 Dcore.fhda.edu (153.18.31.254) 1.025 ms 0.892 ms 0.880 ms2 Ddmz.fhda.edu (153.18.251.40) 2.141 ms 2.159 ms 2.103 ms3 Cinic.fhda.edu (153.18.253.126) 2.159 ms 2.050 ms 1.992 ms ...16 * * *17 * * *...............