TCP/IP Protocols (6) --ICMP: Internet Control Message Protocol

Introduction

ICMP is often considered part of the IP layer. It communicates error messages and other conditions that require attention. ICMP messages are usually acted on by either the IP layer or the higher layer protocol (TCP or UDP). Some ICMP messages cause errors to be returned to user processes.

IP Header	ICMP message
20 bytes

The format of ICMP is as below

1	7	8	15	16	31
8-bit type		8-bit code		16-bit checksum
contents depends on type and code

The first 4 bytes have the same format for all messages, but the remainder differs from one message to the next.

There are 15 different values for the type field, which identify the particular ICMP message. Some types of ICMP messages then use different values of the code field to further specify the condition.

The checksum field covers the entire ICMP message.

ICMP Message Types

ICMP message types:

type	code	Description	Query	Error
0	0	echo reply (Ping reply)	*
3	0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	destination unreachable: network unreachable host unreachable protocol unreachable port unreachable fragmentation needed but don't-fragment bit set source route failed destination network unknown destination host unknown source host isolated (obsolete) destination network administratively prohibited destination host administratively prohibited network unreachable for TOS host unreachable for TOS communication administratively prohibited by filtering host precedence violation precedence cutoff in effect		* * * * * * * * * * * * * * * *
4	0	source quench (elementary flow control)		*
5	0 1 2 3	redirect: redirect for network redirect for host redirect for type-of-service and network redirect for type-of-service and host
8	0	echo request (Ping request. )	*
9 10	0 0	router advertisement router solicitation	* *
11	0 1	time exceeded: time-to-live equals 0 during transit (Traceroute) time-to-live equals 0 during reassembly		* *
12	0 1	parameter problem: IP header bad (catchall error) required option missing		* *
13 14	0 0	timestamp request timestamp reply	* *
15 16	0 0	information request (obsolete) information reply (obsolete)	* *
17 18	0 0	address mask request address mask reply	* *

The final two columns in this figure specify whether the ICMP message is a query message or an error message. We need to make this distinction because ICMP error messages are sometimes handled specially. For example, an ICMP error message is never generated in response to an ICMP error message. (If this were not the rule, we could end up with scenarios where an error generates an error, which generates an error, and so on, indefinitely)

When an ICMP error message is sent, the message always contains the IP header and the first 8 bytes of the IP datagram that caused the ICMP error to be generated. This lets the receiving ICMP module associate the message with one particular protocol (TCP or UDP from the protocol field in the IP header) and one particular user process (from the TCP or UDP port numbers that are in the TCP or UDP header contained in the first 8 bytes of the IP datagram).

An ICMP error message is never generated in response to

1. An ICMP error message. (An ICMP error message may, however, be generated in response to an ICMP query message.)

2. A datagram destined to an IP broadcast address or an IP multicast address (a class D address).

3. A datagram sent as a link-layer broadcast.

4. A fragment other than the first.

5. A datagram whose source address does not define a single host. This means the source address cannot be a zero address, a loopback address, a broadcast address, or a multicast address.

These rules are meant to prevent the broadcast storms that have occurred in the past when ICMP errors were sent in response to broadcast packets.

ICMP Address Mask Request and Reply

The ICMP address mask request is intended for a diskless system to obtain its subnet mask at bootstrap time. The requesting system broadcasts its ICMP request. (This is similar to a diskless system using RARP to obtain its IP address at bootstrap time.) An alternative method for a diskless system to obtain its subnet mask is the BOOTP protocol.

The format of the ICMP address mask request and reply messages:

1	7	8	15	16	31
8-bit type		8-bit code		16-bit checksum
identifier				sequence number
32-bit subnet mask

The identifier and sequence number fields in the ICMP message can be set to anything the sender chooses, and these values are returned in the reply This allows the sender to match replies with requests.

ICMP Timestamp Request and Reply

The ICMP timestamp request allows a system to query another for the current time. The recommended value to be returned is the number of milliseconds since midnight,  Coordinated Universal Time (UTC). (Older manuals refer to UTC as Greenwich Mean Time.) The nice feature of this ICMP message is that it provides millisecond resolution, whereas some other methods for obtaining the time from another host (such as the rdate command provided by some Unix systems) provide a resolution of seconds. The  drawback is that only the time since midnight is returned-the caller must know the date from some other means.

The format of the ICMP timestamp request and reply messages:

1	7	8	15	16	31
Type = 13		Code = 0		16-bit checksum
identifier				sequence number
Originate Timestamp
Receive Timestamp
Transmit Timestamp

The requestor fills in the originate timestamp and sends the request. The replying system fills in the receive timestamp when it receives the request, and the transmit time-stamp when it sends the reply. In actuality, however, most implementations set the latter two fields to the same value. (The reason for providing the three fields is to let the sender compute the time for the request to be sent, and separately compute the time for the reply to be sent.)

Round-trip time (rtt) is the time the reply is received minus the time the request was sent.

Alternatives

There are other ways to obtain the time and date.

1. The daytime service and time service: e.g. telnet host daytime.

2. Serious timekeepers use the Network Time Protocol (NTP) described in RFC 1305 [Mills 1992]. This protocol uses sophisticated techniques to maintain the clocks for a  group of systems on a LAN or WAN to within millisecond accuracy.

3. The Open Software Foundation's (OSF) Distributed Computing Environment (DCE) defines a Distributed Time Service (DTS) that also provides clock synchronization between computers.

4. Berkeley Unix systems provide the daemon timed(8) to synchronize the clocks of systems on a local area network. Unlike NTP and DTS, timed does not work across wide area networks.

ICMP Port Unreachable Error

One rule of UDP is that if it receives a UDP datagram and the destination port does not correspond to a port that some process has in use, UDP responds with an ICMP port unreachable. We can force a port unreachable using the TFTP client.

The well-known UDP port for the TFTP server to be reading from is 69. But most TFTP client programs allow us to specify a different port using the connect command.

One rule of ICMP is that the ICMP error messages must include the IP header (including any options) of the datagram that generated the error along with at least the first 8 bytes that followed this IP header.

ICMP unreachable message:

1	7	8	15	16	31
Type = 3		Code = 0-15		16-bit checksum
identifier				sequence number
Unset (must be 0)
IP header (including option) + first 8 bytes of original IP datagram data

Since ICMP covers such a wide range of conditions, from fatal errors to informational messages, each ICMP
message is handled differently, even within a given implementation.