Introduction To The Internet Control Message Protocol

Introduction

The Internet Control Message Protocol, or ICMP as we will be calling it, is a very popular
protocol and actually part of an Internet Protocol (IP) implementation. Because IP wasn't
designed to be absolutely reliable, ICMP came into the scene to provide feedback on
problems which existed in the communication environment.

If I said the word 'Ping' most people who work with networks would recognise that a 'ping' is
part of ICMP and in case you didn't know that, now you do :)

ICMP is one of the most useful protocols provided to troubleshoot network problems like DNS
resolutions, routing, connectivity and a lot more. Personally, I use ICMP a lot, but you need
to keep its limits in mind beause you might end up spending half a day trying to figure out
why you're not getting a 'ping reply' ('echo reply' is the correct term) from, for example,
www.firewall.cx when, in fact, the site's webserver is configured NOT to reply to 'pings' for
security reasons !

Cool Note

A few years ago there was a program released, which still circulates around the Internet,
called Click ( I got my hands on version 1.4). Click was designed to run on a Windows
platform and work against Mirc users. The program would utilise the different messages
available within the ICMP protocol to send special error messages to Mirc users, making the
remote user's program think it had lost connectivity with the IRC server, thus disconnecting
them from the server ! The magic is not what the program can do, but how it does it ! This is
where a true networking guru will be able to identify and fix any network security weakness.

The Protocol

ICMP is defined in RFC (Request For Comments) 792. Looking at its position in the OSI
model we can see that it's sitting in the Network layer (layer 3) alongside IP. There are no
ports used with ICMP, this is because of where the protocol sits in the OSI model. Ports are
only used for protocols which work at the Session layer and above:

The ICMP protocol uses different

'messages' to identify the purpose
of an ICMP packet, for example, an
'echo' (ping) is one type of ICMP
message.

I am going to break down the

different message descriptions as
they have been defined by
theRFC792.

There is a lot of information to cover

in ICMP so I have broken it down to
multiple pages rather than sticking
everything into one huge page that
would bore you!
Also, I haven't included all the messages which ICMP supports, rather I selected a few of the
more common ones that you're likely to come across. You can always refer to the RFC792 to
get the details on all messages.

We will start with a visual example of where the ICMP header and information are put in a
packet, to help you understand better what we are dealing with :)

The structure is pretty simple, not a lot involved, but the contents of the ICMP header will
change depending on the message it contains. For example, the header information for an
'echo' (ping) message (this is the correct term) is different to that of a 'destination
unreachable' message, also a function of ICMP.

NOTE: If you were to run a packet sniffer on your LAN and catch a "ping" packet to see what
it looks like, you would get more than I am showing here. There will be an extra header, the
datalink header, which is not shown here because that header will change (or more likely be
removed) as the packet moves from your LAN to the Internet, but the 2 headers you see in
this picture will certainly remain the same until they reach their destination.

So, that now leaves us to analyse a few of the selected ICMP messages !

The table below shows all the ICMP messages the protocol supports. The messages that are
in the green colour are the ones covered. Please click on the ICMP message you wish to read
about:

ICMP - Echo / Echo Reply (Ping) Message

Introduction
As mentioned in the previous page, an Echo is simply what most people call a 'ping'. The
Echo Reply is the 'ping reply'. ICMP Echos are used mostly for troubleshooting. When there
are 2 hosts which have communication problems, a few simple ICMP Echo requests will show
if the 2 hosts have their TCP/IP stacks configured correctly and if there are any problems
with the routes packets are taking in order to get to the other side.

The 'ping' command is very well known, but the results of it are very often misunderstood
and for that reason I have chosen to explain all those other parameters next to the ping
reply, but we will have a look at that later on.

Let's have a look at what an ICMP-Echo or Echo Reply packet looks like:
If the above packet was an ICMP Echo (ping), then the Type field takes a value of 8. If it's an
ICMP Echo Reply (ping reply) then it would take a value of 1.

The picture below is a screen shot I took when doing a simple ping from my workstation:

Okay, now looking at the screen shot above, you can see I 'pinged' www.firewall.cx. The first
thing my workstation did was to resolve that URL to an IP address. This was done
using DNS. Once the DNS server returned the IP address of www.firewall.cx, the workstation
generated an ICMP packet with the Type field set to 8.

Here is the proof:

The picture above is a screenshot from my packet sniffer the same time this experement was
taking place. The packet displayed is one of the 4 packets which were sent from my
workstation to the webserver of firewall.cx

Notice the ICMP type = 8 Echo field right under the ICMP Header section. This clearly shows
that this packet is being sent from the workstation and not received. If it was received, it
would have been an 'Echo Reply' and have a value of 1.

The next weird thing, if anyone noticed, is the data field. Look at the screen shot from
command prompt above and notice the value there and the value the packet sniffer is
showing on the left. One says 32 Bytes, and the other 40 Bytes !

The reason for this is that the packet sniffer is taking into account the ICMP header files
(ICMP type, code, checksum and identifier), and I'll prove it to you right now.

Look at the top of this page where we analysed the ICMP headers (the 3d picture), you will
notice that the lengths (in Bits) of the various fields are as follows: 8, 8, 16, 16, 16. These
add up to a total of 64 Bits. Now 8 Bits = 1 Byte, therefore 64 Bits = 8 Bytes. Take the 32
Bytes of data the workstation's command prompt is showing and add 8 Bytes .... and you
have 40 Bytes in total.

If you want to view the full screen shot of the packet sniffer, please click here.

And that just about does it for these two ICMP messages !
ICMP - Destination Unreachable Message

Introduction

This ICMP message is quite interesting, because it doesn't actually contain one message, but
six! This means that the ICMP Destination unreachable futher breaks down into 6 different
messages.

We will be looking at them all and analysing a few of them to help you get the idea.

To make sure you don't get confused, keep one thing in mind: The ICMP
Destinationunreachable is a generic ICMP message, the different code
values or messages which are part of it are there to clarify the type of "Destination
unreachable" message was received. It goes something like this: ICMP Destination <Code
value or message> unreachable.

The ICMP - Destination net unreachable message is one which a user would usually get from

the gateway when it doesn't know how to get to a particular network.

The ICMP - Destination host unreachable message is one which a user would usually get

from the remote gateway when the destination host is unreachable.

If, in the destination host, the IP module cannot deliver the packet because the indicated
protocol module or process port is not active, the destination host may send an ICMP
destination protocol / port unreachable message to the source host.

In another case, when a packet received must be fragmented to be forwarded by a gateway

but the "Don't Fragment" flag (DF) is on, the gateway must discard the packet and send
anICMP destination fragmentation needed and DF set unreachable message to the source
host.

These ICMP messages are most useful when trying to troubleshoot a network. You can check
to see if all routers and gateways are configured properly and have their routing tables
updated and synchronised.

Let's look at the packet structure of an ICMP destination unreachable packet:

Please read on as the following example will help you understand all the above.

The Analysis

When you open a DOS command prompt and type "ping 200.200.200.200", assuming that
your workstation is NOT part of that network, then it would forward the ICMP Echo request
to the gateway that's configured in your TCP/IP properties. At that point, the gateway should
be able to figure out where to forward the ICMP Echo request.

The gateway usually has a "default route" entry, this entry is used when the gateway doesn't
know where the network is. Now, if the gateway has no "default route" you would get an
"ICMP Destination net unreachable" message when you try to get to a network which the
gateway doesn't know about. When you're connected to the Internet via a modem, then your
default gateway is the modem.
In order for me to demonstrate this, I set up my network in a way that should make it easy
for you to see how everything works. I have provided a lot of pictures hoping to make it as
easy as possible to understand.

I will analyse why and how you get an "ICMP - Destination net unreachable" message.

In the example above, I've setup my workstation to use the Linux server as a default
gateway, which has an IP of 192.168.0.5. The Linux server also has a default gateway entry
and this is IP: 192.168.0.1 (the Windows 2000 Server).

When my workstation attempts to ping (send an ICMP Echo request) to IP 200.200.200.200,
it realises it's on a different network, so it sends it to the Linux server, which in turn forwards
it to its default gateway (the Win2k server) so it can then be forwarded to the Internet and
eventually I should get a ping reply (ICMP Echo reply) if the host exists and has no firewall
blocking ICMP echo requests.

Here is the packet which I captured:

When looking at the decoded section (picture above) you can see in the ICMP header section
that the ICMP Type is equal to 8, so this confirms that it's an ICMP Echo (ping). As
mentioned earlier, we would expect to receive an ICMP echo reply.

Check out though what happens when I remove the default gateway entry from the Linux
server:

Now what I did was to remove the default gateway entry from the Linux server. So when it
gets a packet from my workstation, it wouldn't know what to do with it. This is how you get
the gateway to generate an "ICMP Destination net unreachable" message and send it back to
the source host (my workstation).

Here is a screen shot from the command prompt:

As you can see, the Linux server has returned an "ICMP Destination net unreachable". This is
one of the six possible 'ICMP Destination Unreachable' messages as listed at the beginning of
this page. The Linux server doesn't know what to do with the packet since it has no way of
getting to that 200.200.200.0 network, so it sends the "ICMP
Destination net unreachable"message to my workstation, notifiying it that it doesnt know
how to get to that network.

Let's now take a look what the packet sniffer caught :

The decoder on the left shows that the Linux

server (192.168.0.5) sent back to my
workstation (192.168.0.100) an ICMP
Destination unreachable message (look at
theICMP type field, right under the ICMP
header) but if you also check out the ICMP
Code (highlighted field), it's equal to 0, which
means "net unreachable". Scrolling right at the
top of this page, the first table clearly shows
that when the code field has a value of 0, this
is indeed a "net unreachable" message.

It is also worth noticing the "Returned IP

header" which exists within the ICMP header.
This is the IP header of the packet my
workstation sent to the Linux server when it
attempted to ping 200.200.200.200, and
following that is 64 bits (8 bytes) of the
ICMP - Source Quench Message

Introduction

The ICMP - Source quench message is one that can be generated by either a gateway or host. You won't
see any such message pop up on your workstation screen unless you're working on a gateway which will
output to the screen all ICMP messages it gets. In short, anICMP - Source quench is generated by a
gateway or the destination host and tells the sending end to ease up because it cannot keep up with the
speed at which it's receiving the data.

Analysis

Now let's get a bit more technical: A gateway may discard internet datagrams (or packets) if it does not
have the buffer space needed to queue the datagrams for output to the next network on the route to the
destination network. If a gateway discards a datagram, it may send an ICMP - Source quench message to
the internet source host of the datagram.

Let's have a look at the packet structure of the ICMP - Source quench message:
A destination host may also send an ICMP - Source quench message if datagrams arrive too fast to be
processed. The ICMP - Source quench message is a request to the host to cut back the rate at which it is
sending traffic to the internet destination. The gateway may send an ICMP - Source quench for every
message that it discards. On receipt of an ICMP - Source quench message, the source host should cut
back the rate at which it is sending traffic to the specified destination until it no longer receives ICMP -
Source quench messages from the gateway. The source host can then gradually increase the rate at which
it sends traffic to the destination until it again receives ICMP - Source quench messages.

The gateway or host may also send the ICMP - Source quench message when it approaches its capacity
limit rather than waiting until the capacity is exceeded. This means that the data datagram which
triggered the ICMP - Source quench message may be delivered.

That pretty much does it for this ICMP message.

ICMP - Redirect Message

Introduction

The ICMP - Redirect message is always sent from a gateway to the host and the example below will
illustrate when this is used.

Putting it simply (before we have a look at the example) the ICMP - Redirect message occurs when a host
sends a datagram (or packet) to its gateway (destination of this datagram is a different network), which in
turn forwards the same datagram to the next gateway (next hop) and this second gateway is on the same
network as the host. The second gateway will generate this ICMP message and send it to the host from
which the datagram originated.

There are 4 different ICMP - Redirect message types and these are:

The format of this ICMP message is as follows: ICMP - Redirect (0, 1, 2, 3 or 4) message.

Our example:

The gateway (Win2k Server) sends a redirect message (arrow No. 3) to the host in the following situation:

Gateway 1 (the linux server), receives an Internet datagram (arrow No. 1) from a host on the same
network. The gateway checks its routing table and obtains the address of the next gateway (hop) on the
route to the datagram's Internet destination network and sends the datagram to it (arrow No. 2).

Now, gateway 2 receives the datagram and, if the host identified by the Internet source address of the
datagram (in other words, it checks the source IP of the datagram, which will still be 192.168.0.100), is
on the same network, a redirect message (arrow No. 3) is sent to the host. The redirect message advises
the host to send its traffic for the Internet networkdirectly to gateway 2 as this is a shorter path to the
destination. The gateway then forwards the original datagram's data (arrow No. 1) to its Internet
destination (arrow No.4).

For datagrams (or packets) with the IP source options and the gateway address in the destination address
field, a redirect message is not sent even if there is a better route to the ultimate destination than the
next address in the source route.

Analysis

Let's have a look at the structure of an ICMP - Redirect message:

That's all about ICMP - Redirect messages !

ICMP - Time Exceeded Message

Introduction

The ICMP - Time exceeded message is one which is usually created by gateways or routers. In order to
fully understand this ICMP message, you must be familiar with the IP header within a packet. If you like
you can go to the Download - Documents section and grab a copy of theTCP/IP in a Ethernet II Frame file
which breaks down the IP header nicely.

When looking at an IP header, you will see the TTL and Fragment Flag fields which play a big part in how
this ICMP message works. Please make sure you check them out before attempting to continue !

The ICMP - Time exceeded message is generated when the gateway processing the datagram (or packet,
depending on how you look at it) finds the Time To Live field (this field is in the IP header of all packets) is
equal to zero and therefore must be discarded. The same gateway may also notify the source host via the
time exceeded message.

The term 'fragment' means to 'cut to pieces'. When the data is too large to fit into one packet, it is cut into
smaller pieces and sent to the destination. On the other end, the destination host will receive the
fragmented pieces and put them back together to create the original large data packet which
was fragmented at the source.

Analysis

Let's have a look at the structure of an ICMP - Time exceeded message:

If a host reassembling a fragmented datagram (or packet) cannot complete the reassembly due to missing
fragments within its time limit it discards the datagram and it may send anICMP - time
exceeded message.

If fragment zero is not available then no ICMP - time exceeded message is needed to be sent at all. Code
0 may be received from a gateway and Code 1 from a host.

So, summing it up, an ICMP - Time exceeded message can be generated because the Time to live field in
the IP header has reached a value of zero (0) or because a host reassembling a fragmented datagram
cannot complete the reassembly within its time limit because there are missing fragments (Fragment
reassembly time exceeded the allocated time).