Download Internet Control Message Protocol (ICMP)

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: errorreporting 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
Note:
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.
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
Note:
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.
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 host
IP packet
1
RM
2
4
3
IP packet
IP packet
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 echorequest 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
Example 1
We use the ping program to test the server fhda.edu. The result
is shown below:
Example 2
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:
$ traceroute fhda.edu
traceroute to fhda.edu (153.18.8.1), 30 hops max, 38 byte packets
1 Dcore.fhda.edu (153.18.31.254) 0.995 ms 0.899 ms 0.878 ms
2 Dbackup.fhda.edu (153.18.251.4) 1.039 ms 1.064 ms 1.083 ms
3 tiptoe.fhda.edu (153.18.8.1) 1.797 ms 1.642 ms 1.757 ms
See Next Slide
Example 2
(Continued)
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.
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.
Example 3
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..
$ traceroute mhhe.com
traceroute to mhhe.com (198.45.24.104), 30 hops max, 38 byte packets
1 Dcore.fhda.edu (153.18.31.254) 1.025 ms 0.892 ms 0.880 ms
2 Ddmz.fhda.edu (153.18.251.40) 2.141 ms 2.159 ms 2.103 ms
3 Cinic.fhda.edu (153.18.253.126) 2.159 ms 2.050 ms 1.992 ms
...
16 * * *
17 * * *
...............