INTERNET CONTROL MESSAGE PROTOCOL V4

→ The Internet Protocol (IP) is the key network layer protocol that implements
the TCP/IP protocol suite. Since IP is the protocol that provides the mechanism
for delivering datagrams between devices, it is designed to be relatively basic,
and to function with few “bells and whistles”. One of the provisions it lacks is
some way to allow errors to be reported back to a transmitting device, and for
tests and special tasks to be accomplished. However, these capabilities are
necessary for the operation of an internetwork, so TCP/IP defines an adjunct
protocol for IP that provides them: the Internet Control Message Protocol
(ICMP).

⚫ ICMP MESSAGE CLASSES, TYPES AND CODES

1. ERROR MESSAGES : These messages are used to provide feedback to a

source device about an error that has occurred. They are usually generated
specifically in response to some sort of action, usually the transmission of a
datagram.

2. INFORMATIONAL (OR QUERY) MESSAGES : These are messages that

are used to let devices exchange information, implement certain IP-related
features, and perform testing. They do not indicate errors and are typically not
sent in response to a regular datagram transmission. They are generated either
when directed by an application, or on a regular basis to provide information to
other devices. An informational ICMP message may also be sent in reply to
another informational ICMP message, since they often occur in request/reply
or solicitation/advertisement functional pairs.

→ ICMP messages are divided into two general categories: error messages that
are used to report problem conditions, and informational messages that are
used for diagnostics, testing and other purposes.

→ Each individual kind of message in ICMP is given its own unique Type value,
which is put into the field of that name in the ICMP common message format.
This field is 8 bits wide, so a theoretical maximum of 256 message types can
be defined.

→ The message type indicates the general purpose of each kind of ICMP
message. ICMP also provides an additional level of detail within each message
type in the form of a Code field, which is also 8 bits. You can consider this
field as a message “subtype”. Thus, each message type can have up to 256
subtypes that are more detailed subdivisions of the message's overall
functionality.

ICMP Page 1
INTERNET CONTROL MESSAGE PROTOCOL V4

ICMP Page 2
INTERNET CONTROL MESSAGE PROTOCOL V4
⚫ ICMP COMMON MESSAGE FORMAT

→ The structure of an ICMP message can be generally thought of as having a

common part and a unique part. The common part consists of three fields that
have the same size and same meaning in all ICMP messages (though the values
in the fields aren't the same for each ICMP message type, of course). The
unique part contains fields that are specific to each type of message.

→ The message body typically contains one or several fields that carry
information of relevance to each specific type of ICMP message. For error
messages, we see here one more area of commonality in ICMP messages: all
ICMP error messages include a portion of the original IP datagram that led to
the ICMP error message. This aids in diagnosing the problem that caused the
ICMP message to be generated, by allowing the error to be communicated to
higher layers.

ICMP Page 3
INTERNET CONTROL MESSAGE PROTOCOL V4
→ Each error message includes the full IP header and the first 8 bytes of the
payload. Since the beginning of the payload will contain the encapsulated
higher-layer header, this means the ICMP message also carries either the full
UDP header, or the first 8 bytes of the TCP header. In both cases, the source
and destination port numbers are part of what is included.
If the original header was a standard IP header with no options, the Message
Body will therefore have a length of 28 bytes; if options are present, it will be
larger.

→ After an ICMP message is formatted, it is encapsulated in an IP datagram like

any other IP message. This is why some people believe ICMP is architecturally
a higher layer than IP, though as we discussed earlier it is really more of a
special case. You can also see then, that when an ICMP error message is
generated, we end up with the original IP header and part or all of the payload,
encapsulated in the ICMP message, in turn encapsulated within a new IP
header to be sent back as an error report usually to the device that sent the
original IP message.

⚫ ICMP ERROR MESSAGE TYPES AND FORMATS

1. ICMP DESTINATION UNREACHABLE MESSAGES

→ Since the Internet Protocol is an unreliable protocol, there are no guarantees

that a datagram sent by one device to another will ever actually get there. The
internetwork of hosts and routers will make a “best effort” to deliver the
datagram but it may not get where it needs to for any number of reasons. Of
course, devices on an IP network understand that and are designed accordingly.
IP software never assumes its datagrams will always be received, and higher
layer protocols like TCP take care of providing reliability and
acknowledgements of received data for applications that need these features.

→ This setup, with higher layers handling failed deliveries, is sufficient in some
cases. For example, suppose device A tries to send to device B, but a router
near B is overloaded, so it drops the datagram. In this case the problem is likely
intermittent, so A can retransmit and eventually reach B. But what about a
situation where a device is trying to send to an IP address that doesn't exist, or
a problem with routing that isn't easily corrected? Having the source just
continually retry while it remains “in the dark” about the problem would be
inefficient, to say the least.

ICMP Page 4
INTERNET CONTROL MESSAGE PROTOCOL V4
→ So in general, while IP is designed to allow IP datagram deliveries to fail, we
should take any such failures seriously. What we really need is a feedback
mechanism that can tell a source device that something improper is happening,
and why. In IPv4, this service is provided through the transmission of
Destination Unreachable ICMP messages. When a source node receives one of
these messages it knows there was a problem sending a datagram, and can then
decide what action, if any, it wants to take. Like all ICMP error messages,
Destination Unreachable messages include a portion of the datagram that could
not be delivered, which helps the recipient of the error figure out what the
problem is.

→ There are many different reasons why it may not be possible for a datagram to
reach its destination. Some of these may be due to erroneous parameters (like
the invalid IP address example mentioned above.) A router might have a
problem reaching a particular network for whatever reason. There can also be
other more “esoteric” reasons as well why a datagram cannot be delivered.

ICMP Page 5
INTERNET CONTROL MESSAGE PROTOCOL V4

ICMP Page 6
INTERNET CONTROL MESSAGE PROTOCOL V4
⚫ ICMPV4 TIME EXCEEDED MESSAGE

→ Large IP internetworks can have thousands of interconnected routers that pass

datagrams between devices on various networks. In large internetworks, the
topology of connections between routes can become complex, which makes
routing more difficult.

→ In the worst case of inefficient routing, a router loop may occur. An example of
this situation is where Router A thinks datagrams intended for network X
should next go to Router B; Router B thinks they should go to Router C; and
Router C thinks they need to go to Router A. If a loop like this occurred,
datagrams for network X entering this part of the internet would circle forever,
chewing up bandwidth and eventually leading to the network being unusable.

→ As insurance against this occurrence, each IP datagram includes in its header a

Time To Live (TTL) field. This field was originally intended to limit the
maximum time (in seconds) that a datagram could be on the internetwork, but
now limits the life of a datagram by limiting the number of times the datagram
can be passed from one device to the next.

→ The TTL is set to a value by the source that represents the maximum number of
hops it wants for the datagram. Each router decrements the value; if it ever
reaches zero the datagram is said to have expired and is discarded.

→ When a datagram is dropped due to expiration of the TTL field, the device that
dropped the datagram will inform the source of this occurrence by sending it an
ICMPv4 Time Exceeded message, as shown in Figure below. Receipt of this
message indicates to the original sending device that there is either a routing
problem when sending to that particular destination, or that it set the TTL field
value too low in the first place. As with all ICMP messages, the device
receiving it must decide whether and how to respond to receipt of the message.
For example, it may first try to re-send the datagram with a higher TTL value.

→ There is another “time expiration” situation where ICMP Time Exceeded

messages are used. When an IP message is broken into fragments, the
destination device is charged with reassembling them into the original message.
One or more fragments may not make it to the destination, so to prevent the
device from waiting forever, it sets a timer when the first fragment arrives. If
this timer expires before the others are received, the device gives up on this
message. The fragments are discarded, and a Time Exceeded message
generated.

ICMP Page 7
INTERNET CONTROL MESSAGE PROTOCOL V4

→ The TCP/IP traceroute (or tracert) utility is used to show the sequence of
devices over which a datagram is passed on a particular route between a source
and destination, as well as the amount of time it takes for a datagram to reach
each hop in that route. This utility was originally implemented using Time
Exceeded messages by sending datagrams with successively higher TTL
values. First, a “dummy” datagram is sent with a TTL value of 1, causing the
first hop in the route to discard the datagram and send back an ICMP Time
Exceeded; the time elapsed for this could be measured. Then, a second
datagram is sent with a TTL value of 2, causing the second device in the route
to report back a Time Exceeded, and so on. By continuing to increase the TTL
value we can get reports back from each hop in the route.

⚫ ICMP ECHO REQUEST AND ECHO REPLY MESSAGE

→ One of the main purposes of ICMP informational messages is to enable testing

and diagnostics, to help identify and correct problems on an internetwork. The
most basic test that can be conducted between two devices is simply checking
if they are capable of sending datagrams to each other. The usual way that this
is done is to have one device send a test message to a second device, which
receives the message and replies back to tell the first device it received the
message.

→ ICMPv4 includes a pair of messages specifically for connection testing.

Suppose Device A wants to see if it can reach Device B. Device A begins the
test process by sending an ICMPv4 Echo message to B. Device B, when it
receives the Echo, responds back to Device A with an Echo Reply message.
When Device A receives this message, it knows that it is able to communicate
(both send and receive) successfully with Device B.

ICMP Page 8
INTERNET CONTROL MESSAGE PROTOCOL V4

→ Two special fields are used within the format of these messages to allow Echo
and Echo Reply messages to be matched together, and to allow a sequence of
messages to be exchanged. The Identifier field was envisioned as being used as
a higher-level label, like a session identifier, while the Sequence Number was
seen as something to identify individual test messages within a series.
However, the use of these fields is up to the particular implementation. In some
cases, the Identifier field is filled in with the process number of the application
that is using the Echo or Echo Reply message, to allow several users to use
utilities like ping without interference.

ICMP Page 9