I ICMP (AGAIN...?)
OK.. We know that IP has a simple, elegant design. Under
normal conditions, IP makes very efficient use of memory and
transmission resources. But what happens when things go
wrong? After a router has chrashed and disrupted the
network, what notice is given that datagrams are wondering
around until their Time-to-Live (TTLs) expire? What warning
is provided so that the applications don't persists in
sending information to an unreachable destination? The
Internet Control Message Protocol (ICMP) offers remedies for
this ills. ICMP also plays the role of network helper,
assisting hosts with their IP routing and enabling network
managers to discover the status of network nodes. ICMP's
functions are an essential part of IP. All hosts and routers
must be able to generate ICMP message and process the ICMP
messages that they receive. Properly used, ICMP messages can
contribute to smoother network operation. ICMP messages are
carried in IP datagrams with ordinary IP Headers (see fig 1)
with the protocol field is set to one.
+----------------+
| IP HEADER |
| Protocol = 1 |
+----------------+
| ICMP Message |
| |
+----------------+
Fig 1, Packaging for an ICMP messages
There are a number if situations that cause IP datagrams
to be discarded. Fo example, a destination may be
unreachable because a link is down. The Time-to-Live hop
count may have expired. It may be impossible for a router to
forward a large datagram because fragmentation is not
enabled. When a datagram has been discarded, ICMP messages
are used to report the problem to the address that sent the
datagrams. Fig 2, ICMP Messages being distributed to a
datagram source:
+----+ ____ ____
| | | | | |
+--------+ ICMP| | ICMP | | link is
| HOST |<--- | |<-----| | down
+--------+_____|____|______|____|____//___
Router Router //
Fig 2, message directed to traffic source
There are also disadvantages. For example, if a
destination is not reached, messages will be propagated to
sources all over the network, rather to a network management
station. In fact, ICMP has no facilities for reporting
errors to a designated neetwork operations center. This is
left to up to the SNMP (Simple Network Management Protocol).
II. TYPES OF ERROR MESSAGES:
- Destination Unreachable
A datagram cannot reach it's destination host, utility or
application.
- Time Exceeded
Time-to-live value has expired or the Fragment Reassembly
Time has expired at destination hosts
- Parameter Problem
There is a bad parameter at the IP header.
- Source Quench
A router or destination is congested (It is recommended
that the system shouldn't send Quench Messages).
- Redirect
A host has routed a datagram to a wrong local router.
OBLIGATION TO SEND ICMP MESSSAGES
The ICMP protocol specifies that an ICMP messages _should_
or _may_ be sent each instance. It doesn't require every
error _must_ result an ICMP message. This make a very good
sense, the first priority of a router on a network is to
forward datagrams. And congested recipient host should give
more attention to delivering datagrams to it's application
than to remote error notifications. It won't hurt, if
occationally, some discards are not reported.
INCOMING ICMP MESSAGES
What happens when a host receive an ICMP messages? Let's
look at an example. We'll try to connect to an address at
one of reserved -- and therefore unreachable network:
> telnet 10.13.2.1
Trying 10.13.2.1 .....
telnet: connect: Host is unreachable...
Now we have been told exaclty what happened.
To find out which router sent the ICMP message(s) we can
use a handy tool call traceroute.
> traceroute 10.13.2.1
traceroute to 10.13.2.1, 30 hps max, 40 bytes packets
1 nomad-gateway (128.121.50.40) 2ms 2ms 2ms
2 liberty-gateway (120.194.40.250) 91ms 11 ms 78 ms
3 border2-hssi2-0.newyork.mci.net (207.70.45.9) !H!H!H
The new york router has destination unreachable mesages,
which are reported on the screen as the !H responses.
The traceroute function based on ICMP time Expired
Messages. The procedure is:
- A short UDP Messages is constructed. It''s given an IP
Header whose Tome-to-live field is equal to 1.
- The datagram is transmitted three times..
- The first router (nomad-gateway in the eexample above),
decrements TTL value to zero, discard the datagram, and
sends an ICMP time expired message back to the souce.
- The traceroute function (in sender) idenntifies the router
that sent the messages and print the three round trip
times.
- The TTL is sent to two, and the messagess is sent
again.
- The process is repeated, increasing the TTL at each
step.
- If the destination can be reached, eventtually, the
full route will be displayed.
III. WHEN NOT TO SEND ICMP MESSAGES
We can expect ICMP to send error messages when a
network is under stress. It's important to assure that the
ICMP traffic does not flood the network making the situation
much worse. Some obvious limits have been imposed on the
protocol. ICMP _must_not_ report problems caused by:
- Routing or delivering ICMP Messages.
- Broadcast or multicast datagrams.
- Datagram fragments other than the first..
- Messages whose source address does not iidentifies the
unique (such as 127.0.0.1 or 0.0.0.0)
IV. ICMP MESSAGE FORMAT
Recall that an ICMP message is carried in the data part of
an IP datagrams, Each ICMP message start with the same
three fields: a Type Field, a Code Field, that sometimes
specifies the specific description of the error, and a
Checksum field. The format of the resst of the message is
determined by the type.
ICMP error messages enclose the IP header and first 8
octets of datagram caused the error. This information can be
the basis of the problem since it includes data such as the
intended destination and the target layer 4 protocol. When
study TCP and UDP, we will discover that from these protocol
the extra 8 octets include information that identifies the
communicating application entities.
The ICMP checksum is applied to the ICMP messages
(starting from it's Type Field).
Destination Ureachable Message
There are many stages at which delivery of a datagram can
fail. Because of a broken link, a router may physically
unable to reach a destination subnet or to execute the next
hop in a source route. A destination host may be unavailable
because it's down for maintenance.
As we know, modern routers have the powerful security
features. A router could be configured to screen traffic
entering the network. Thus, datagrams may be undelivered
because communication with destination has administratively
prohibited.
Destination unreachable error code:
==========================================
CODE Meaning
==========================================
0 Network is unreachable
1 Host is unreachable
2 Requested protocol is not suported
at destination
3 Port is unreachable (Remote
application may not be available).
4 Fragmentation is needed but the
Don't fragment is set
5 Source Route has failed
6 Destination network is unknown.
7 Destination host is unknown.
8 Source host is isolated
9 Communication with destination net
work is administratively forbidden
10 Communication with destination
host is administratively forbidden
11 Network unreachable for specified
Type of service
12 Host is unreachable for specified
Type of service
|<8bit>|<8bit>|<-16bit-->|
+------+------+----------+
|Type=3|Code | Checksum |
+------+------+----------+
| Unused |
+------------------------+
| Internet header + |
| 8 OCTET OF Original |
| Datagram |
+------------------------+
Fig 3, Format of dest unreachable ICMP message
Time Exceeded Messages
A datagram may time out because the TTL reached zero while
the datagram was in transit. Another kind of time-out
occures when the destination host's reassembly timer expires
before all the pieces have arrived. In either case the ICMP
time exceeded messages is sent to the datagram source. The
format of time exceeded messages is shown below:
|<8bit> |<8bit>|<-16bit-->|
+-------+------+----------+
|Type=11|Code | Checksum |
+-------+------+----------+
| Unused |
+-------------------------+
| Internet header + |
| 8 OCTET OF Original |
| Datagram |
+-------------------------+
CODE MEANING
========================================
0 Time-to-live exceeded
1 Fragmet reassembly time exceeded
Parameter problem message
The ICMP Parameter problem message is used to report
problems not covered by any of the other error messages. For
example, tere may be some inconsistent information in an
options field that makes it impossible to process the
datagram correctly, so the datageam must be discarded. Most
often, parameter problems arise because of implentation
errors at the system that wrote the parameters ontp the IP
Header.
The pointer field in the ICMP Parameter Problem
message identifies the octet at which the error was
detected. Below, the parameter problem codes value table:
|<8bit> |<8bit>|<-16bit-->|
+-------+------+----------+
|Type=12|Code | Checksum |
+-------+------+----------+
| Unused |
+-------------------------+
| Internet header + |
| 8 OCTET OF Original |
| Datagram |
+-------------------------+
CODE MEANING
========================================
0 The Value in the pointer field
Identifies the octet where an
error occur.
1 A required option is missing
(used in the military community
to indicate missing security
options.
2 Bad length.
------------------------------------ this part is new
Congestion problem
The IP protocol is very simple, a host or route process a
datagram and sends it on as quickly as possible. However,
delivery doesn't always proceed smoothly. A number of thing
can go wrong.
One or more hosts sending traffic to slow a server may
flood server with UDP traffic. This may cause the server to
discard the overflow trafic.A router may run out of a
buffer space. This will cause the server to discard the
overflow traffic.
A router may run out of buffer space and be forced to
discard some datagrams. A slow wide area connection, such as
56 kbps link between two 10-megabit per second LANs, can
create a bottleneck. Congestion causes datagras to be
discarded, resulting retransmission and produce even more
traffic.
Source Quench
The Source Quench message shown in figure below was
intended to relieve the problem but did not succeed. The
details of exactly how the congested system should execute a
source quench were left out to the implementer, leaving open
question:
When - and to whom - should a router or host send a Source
Quench message?
Format of Source Quench ICMP message
|<8bit> |<8bit>|<-16bit-->|
+-------+------+----------+
|Type=4 |Code=0| Checksum |
+-------+------+----------+
| Unused |
+-------------------------+
| Internet header + |
| 8 OCTET OF Original |
| Datagram |
+-------------------------+
Usually, ICMP error messages tell a source host why one of
its datagram gas been discarded. However, in a congestion
situation, it is possible that the datagrams that happen to
be discarded do not come from the hosts that are generating
very heavy traffic. Moreover, exactly how a host should
handle an incoming source quench message was left equally
fuzzy.
The current router requirement document (RFC 1812)
stipulates that in fact, Source Quench messages should not
be sent. Work proceeding on more effective congestion
control mechanism.
Redirect
More than one router might be attached to LAN. If a local
host sends a datagram to the wrong router, the router
forwards the datagram but sends a Redirect Message. The
host should switch subsequent traffic to the shorter route.
+----+
| | ___
+--------+ | |
| HOST | | |
+--------+ | | improper router
|..Datagram..>|___| .....
| <---ICMP--- | :
|_______________|_____ Datagram is
| : forwarded
| v to
_|__ the
| | proper router
| | (or shorter
| | route)
|____|
Redirect messages can be used to cut down on manual
network administration. A host can be configured with a
single default router and can dynamically learn to route
that pass to other routers.
Some routing protocols can choose a delivery path based on
datagram's type of service (TOS) field. Code 2 and 3 provide
advice that reflects these considerations.
The format of redirect message:
|<8bit> |<8bit>|<-16bit-->|
+-------+------+----------+
|Type=5 |Code | Checksum |
+-------+------+----------+
|Address of better router |
+-------------------------+
| Internet header + |
| 8 OCTET OF Original |
| Datagram |
+-------------------------+
Redirect Code
CODE MEANING
==========================================
0 Redirect datagrams for the network
1 Redirect datagrams for the host
2 Redirect datagrams for the TOS
& Network
3 Redirect datagrams for the TOS
TOS & Host
IV. PATH MTU DISCOVERY
When performing a function (such as a file transfer) which
carries bulk data from one host to another, the size of
datagrams that are used can have a big impact on
performance. IP and TCP headers use up to at east 40 bytes
of overhead.
- If data is sent 80-byte datagrams, overhead is 50%
- If data is sent 400-byte datagrams, overhead is 10%
- If data is sent 4000-byte datagrams, overhead is 1%
To minimize overhead, we would like to send the bigest
datagrams that we can. But recall that there are limits on
the biggest datagram size (MTU = Maximum Transmission unit)
for each medium. If datagrams are too large, they will be
fragmented, and fragmentation slows performance.
For many years, hosts would avoid fragmentation by
setting the "effective MTU for sending" to 576 for traffic
to any local destination. This often crippled performance
unnecessarily.
Clearly, it would be very useful to know the biggest
datagrams size that can be sent along a path and delivered
intact. There is a very simple mechanism called Path MTU
discovery that determine the size.
The way that it works is:
- Don't fragment the flag in IP headers iss equal to 1.
- The Path MTU size starts out at the MTU for local
interface.
- If the datagram is too large for some roouter to forward,
the router will send back an ICMP destination unreachable
message code = 4.
- The sending host reduces the datagram siize and tries
again.
What size should the host try? If the router has up-to-
date software, it's destination unreachable message will
include MTU size (see below).
|<8bit>|<8bit>|<---16bit--->|
+------+------+-------------+
|Type=3|Code | Checksum |
+------+------+-------------+
| unused | next-hop MTU|
+-------------+-------------+
| Internet header + |
| 8 OCTET OF Original |
| Datagram |
+---------------------------+
Destination unreachable reporting MTU size.
Because path can change dynamically, the don't fragment
can be left on troughout the telecommunication. Routers will
send corection as needed.
If old router software is used, the router will not
provide next-hop MTU size. A host can make a reasonable
guest by picking the next lower level on the list of
standard MTU sizes. The risizing procedure continues until a
feasible value has been found and destination is reached.
V. ICMP QUERY MESSAGES
Not all ICMP messages signal errors. Some are used to
probe the network for useful information. Is host X up? Is
router Y running ? How long does it take to Z and Back? what
is my address mask?
Specifically, the ICMP query message include:
- Echo request and reply messages that can be exchanged
with host and routers.
- Adress mask request and reply messages that enable a
system to discover the address mask that should be
assigned to an interface.
- Timestap request and reply messages that retrive the
clock settings at a target system. (The respomse was
also intended to give some id of how long that system
takes to process a datagram).
The ping program which sends "Are you alive?" ehco
messages is used on daily basis by network managers. Address
mask queries are used occasionally, while timestamp messages
are rarely seen.
+----+ ____
| | | | Are you alive? (PING)
+--------+ ---> | | What is my address mask?
| HOST | <--- | | Timestamp
+--------+ |____|
Router
+----+ +----+
| | | | Are you alive? (PING)
+--------+ ---> +--------+ What is my address mask?
| HOST | <--- | HOST | Timestamp
+--------+ +--------+
Echo Request and Reply
The Echo request and echo reply messages are used to check
wheter the systems are active. Type = 8 and type = 0 are
used for echo and reply. The number of octets in the
datafield is variable and can be selected by the sender.
The responder must send back the same data that it
receives. The identifier field is used to match a teply with
its original request . A sequence of echo messages can be
sent to test whether the network is dropping messages and
ti estimate the average round trip time. To do this, the
identifier is held fixed while the sequence number (which
starts at zero) is incremented for each message.
|<-8bit---->|<8bit>|<---16bit--->|
+-----------+------+-------------+
|Type=8 or 0| Code | Checksum |
+-----------+------+-------------+
| unused | Seq. number |
+------------------+-------------+
| Internet header + 8 OCTET |
| OF Original Datagram |
+--------------------------------+
Format of echo request / reply ICMP messages
The famous ping command, available on just every TCP-IP
system, is built on the TCP-IP echo request and and reply
messages.In the dialog below, we send it a sequence of 6
messages; each contains 64 octec of data. Note that messages
0,1,2 were dropped. Round-trip time are displayed at the
right.
[ganda@linux ~]$ ping wisnu.cisco.com
PING 2000 (192.168.0.2) from 192.168.0.5 : 56(84) bytes of data.
64 bytes from 2000 (192.168.0.2): icmp_seq=0 ttl=128 time=0.7 ms
64 bytes from 2000 (192.168.0.2): icmp_seq=1 ttl=128 time=0.4 ms
64 bytes from 2000 (192.168.0.2): icmp_seq=2 ttl=128 time=0.4 ms
64 bytes from 2000 (192.168.0.2): icmp_seq=3 ttl=128 time=0.4 ms
64 bytes from 2000 (192.168.0.2): icmp_seq=4 ttl=128 time=0.4 ms
64 bytes from 2000 (192.168.0.2): icmp_seq=5 ttl=128 time=0.3 ms
--- 2000 ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.4/0.7 ms
Address Mask
Recall that an organization may choose to break up its
local address field into a subnet part and a host part. When
a system comes up, it may not have been configured to know
how many bits is assigen to the subnet address field. To
find out, the system address can broadcast an Address Mask
Request.
The Response should be sent by address mask server.
Normally, we would expect that server to be a router. But a
host may occasionally be used. The reply will put 1s by the
network and subnet fields of 32 bit address mask field.
An address mask server caan be configured so that if it
has been off-line for a while, it will broadcast an address
mask reply as soon as it becomes active. This is done for
the benefit of the system that started up while the server
was unavailable.
The format of the Address Mask Request and Reply as soon
as it becomes active is shown below:
|<---8bit---->|<8bit>|<---16bit--->|
+-------------+------+-------------+
|Type=17 or 18| Code | Checksum |
+-------------+------+-------------+
| unused | Seq. number |
+--------------------+-------------+
| Internet header + 8 OCTET |
| OF Original Datagram |
+----------------------------------+
Format for Address Mask message.
Type 17 for request and type 18 for reply. Generally the
identifier and sequence number can be ignored.
Actually, the preferred method of determining the address
mask is to use a boot protocol, such as Dynamic Host
Donfoguration Protocol or DHCP, or BOOTP this process are
more efficient because they provide a full set of
configuration parameters. They also often are more accurate,
for example a unix workstation can be misconfigured and
respond incorrectly to Adrress Mask Request messages. A
resultm your system may result a several answers and some of
them could be wrong.
Timestamp and Timestamp Reply
Timestamp messages respond the time at a system and were
intended to give a sense of how long the remote system
spends buffering and processing datagram. Note the fields:
- Originate time stamp: Time that the sennder last
touched the message.
- Receive time stamp : Time the echoer ffirst touch it.
- Transmit time stamp : Time the echoer llast touch it.
If possible, the time that is returned should be measured
in milliseconds since GMT. Most implementations actually
return the same time in the receive time-stamp and transmit
timestap fields.
Type 13=is used for Timestamp Query, ad 14 is used for
the Timestamp Reply.
|<---8bit---->|<8bit>|<---16bit--->|
+-------------+------+-------------+
|Type=13 or 14| Code | Checksum |
+-------------+------+-------------+
| unused | Seq. number |
+--------------------+-------------+
| - Originate Timestamp |
+----------------------------------+
| - Receive Timestamp |
+----------------------------------+
| - Transmit Timestamp |
+----------------------------------+
Format of timestamp Request or Reply messages.
This protocol could provide a very simple way for one
system to synchronize it's clock with another. Of coures,
the sychronization could be the rough one because of the
possible network delay. There is a far more capable Network
Time Protocol that has been defined for internet time
sychronization.
VI. Viewing ICMP Activities
Below we show the ICMP part of a netstat report on
protocol statistics. This report shows ICMP activity since
the last initialization:
[ganda@linux ~]$ netstat -s
Ip:
.....
.....
.....
Icmp:
176 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
destination unreachable: 3
echo requests: 81
echo replies: 92
84 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 3
echo replies: 81
Tcp:
.....
.....
.....
Udp:
.....
.....
.....
TcpExt:
So we summarized that:
- ICMP messages received 176 = 81+92+3
- ICMP messages sent 84 = 81+3
- No ICMP messages failed.
Or from Windows 2000:
C:\>netstat -s
IP Statistics
.......
.......
.......
ICMP Statistics
Received Sent
Messages 41 45
Errors 0 0
Destination Unreachable 1 1
Time Exceeded 0 0
Parameter Problems 0 0
Source Quenches 0 0
Redirects 0 0
Echos 28 16
Echo Replies 12 28
Timestamps 0 0
Timestamp Replies 0 0
Address Masks 0 0
Address Mask Replies 0 0
TCP Statistics
.......
.......
.......
UDP Statistics
.......
.......
.......
We can see that this host received 41=28+12+1 messages and
sent 45=16+28+1.
(
geocities.com/gandautama)