Comments Welcome
Chapter 2. Internetworking and Transport Layer Protocols
2.2 Internet Control Message Protocol (ICMP)
2.2.1 ICMP Messages
ICMP messages are described in RFC 792 and RFC 950, belong to STD 5 and are mandatory.
ICMP messages are sent in IP datagrams. The IP header will always have a Protocol number of 1, indicating ICMP and a type of service of zero (routine). The IP data field will contain the actual ICMP message in the format shown in
Figure 30.
type code checksum
3376\3376F2A1 ICMP data (depending on the type of message)
...
0 8 16 31
Figure 30. ICMP - Message Format Where:
Type Specifies the type of the message:
0 Echo reply
3 Destination unreachable 4 Source quench
5 Redirect 8 Echo
9 Router advertisement 10 Router solicitation 11 Time exceeded 12 Parameter problem 13 Time Stamp request 14 Time Stamp reply
15 Information request (obsolete) 16 Information reply (obsolete) 17 Address mask request 18 Address mask reply 30 Traceroute
31 Datagram conversion error 32 Mobile host redirect 33 IPv6 Where-Are-You 34 IPv6 I-Am-Here
35 Mobile registration request 36 Mobile registration reply 37 Domain name request 38 Domain name reply 39 SKIP
40 Photuris
Code Contains the error code for the datagram reported on by this ICMP message. The interpretation is dependent upon the message type.
Checksum Contains the 16-bit one's complement of the one's complement sum of the ICMP message starting with the ICMP Type field. For
computing this checksum, the checksum field is assumed to be zero.
This algorithm is the same as that used by IP for the IP header.
Compare this with the algorithm used by UDP and TCP (see 2.7,
“User Datagram Protocol (UDP)” on page 75 and 2.8, “Transmission Control Protocol (TCP)” on page 78), which also include a pseudo-IP header in the checksum.
Data Contains information for this ICMP message. Typically it will contain a part of the original IP message for which this ICMP message was generated. The length of the data can be determined from the length of the IP datagram that contains the message less the IP header length.
Each of the messages is explained below.
2.2.1.1 Echo (8) and Echo Reply (0)
identifier
3376\3376F2A6 data
...
0 8 16 31 sequence number
Figure 31. ICMP - Echo and Echo Reply
Echo is used to detect if another host is active on the network. The sender initializes the identifier and sequence number (which is used if multiple echo requests are sent), adds some data to the data field and sends the ICMP echo to the destination host. The ICMP header code field is zero. The recipient changes the type to Echo Reply and returns the datagram to the sender. This mechanism is used by the Ping command to determine if a destination host is reachable (see 2.2.2.1, “Ping” on page 66).
2.2.1.2 Destination Unreachable (3)
unused (zero)
3376\3376F2A2 IP header + 64 bits of original data of the datagram
0 8 16 31
Figure 32. ICMP - Destination Unreachable
If this message is received from an intermediate router, it means that the router regards the destination IP address as unreachable.
If this message is received from the destination host, it means that the protocol specified in the protocol number field of the original datagram is not active, or that
protocol is not active on this host or the specified port is inactive. (See 2.7, “User Datagram Protocol (UDP)” on page 75 for an introduction to the port concept.) The ICMP header code field will have one of the following values:
0 Network unreachable 1 Host unreachable 2 Protocol unreachable 3 Port unreachable
4 Fragmentation needed but the Do Not Fragment bit was set 5 Source route failed
6 Destination network unknown 7 Destination host unknown 8 Source host isolated (obsolete)
9 Destination network administratively prohibited 10 Destination host administratively prohibited 11 Network unreachable for this type of service 12 Host unreachable for this type of service
13 Communication administratively prohibited by filtering 14 Host precedence violation
15 Precedence cutoff in effect
If a router implements the Path MTU Discovery protocol, the format of the
destination unreachable message is changed for code 4 to include the MTU of the link that could not accept the datagram.
unused (zero)
3376\3376F2A3 IP header + 64 bits of original data of the datagram
0 8 16 31 link MTU
Figure 33. ICMP - Fragmentation Required with Link MTU
2.2.1.3 Source Quench (4)
unused (zero)
3376\3376F2A4 IP header + 64 bits of original data of the datagram
0 8 16 31
Figure 34. ICMP - Source Quench
If this message is received from an intermediate router, it means that the router does not have the buffer space needed to queue the datagrams for output to the next network.
If this message is received from the destination host, it means that the incoming datagrams are arriving too quickly to be processed.
The ICMP header code field is always zero.
2.2.1.4 Redirect (5)
router IP address
3376\3376F2A5 IP header + 64 bits of original data of the datagram
0 8 16 31
Figure 35. ICMP - Redirect
If this message is received from an intermediate router, it means that the host should send future datagrams for the network to the router whose IP address is given in the ICMP message. This preferred router will always be on the same subnet as the host that sent the datagram and the router that returned the IP datagram. The router will forward the datagram to its next hop destination. If the router IP address matches the source IP address in the original datagram header it indicates a routing loop. This ICMP message will not be sent if the IP datagram contains a source route.
The ICMP header code field will have one of the following values:
0 Network redirect 1 Host redirect
2 Network redirect for this type of service 3 Host redirect for this type of service
2.2.1.5 Router Advertisement (9) and Router Solicitation (10)
ICMP messages 9 and 10 are optional. They are described in RFC 1256 which is elective.
number
3376\3376F2A7 0 8 16 31
TTL entry length
router address 1 preference level 1
/ / / /
router address n preference level n
Figure 36. ICMP - Router Advertisement
unused (zero)
3376\3376F2A8 0 8 16 31
Figure 37. ICMP - Router Solicitation Where:
number
The number of entries in the message.
entry length
The length of an entry in 32-bit units. This is 2 (32 bits for the IP address and 32 bits for the preference value).
TTL The number of seconds that an entry will be considered valid.
router address
One of the sender's IP addresses.
preference level
A signed 32-bit level indicating the preference to be assigned to this address when selecting a default router for a subnet. Each router on a subnet is responsible for advertising its own preference level. Larger values imply higher preference; smaller values imply lower. The default is zero, which is in the middle of the possible range. A value of X'80000000' -231 indicates that the router should never be used as a default router.
The ICMP header code field is zero for both of these messages.
These two messages are used if a host or a router supports the router discovery protocol. The use of multicasting is recommended, but broadcasting may be used if multicasting is not supported on an interface. Routers periodically advertise their IP addresses on those subnets where they are configured to do so.
Advertisements are made on the all-systems multicast address (224.0.0.1) or the limited broadcast address (255.255.255.255). The default behavior is to send advertisements every 10 minutes with a TTL value of 1800 (30 minutes). Routers also reply to solicitation messages they receive. They may reply directly to the soliciting host, or they may wait a short random interval and reply with a multicast.
Hosts can send solicitation messages when they start until they receive a response.
Solicitation messages are sent to the all-routers multicast address (224.0.0.2) or the limited broadcast address (255.255.255.255). Typically, three solicitation messages are sent at 3-second intervals. Alternatively a host may wait for periodic
advertisements. Each time a host receives an advertisement, it updates its default router if the new advertisement has one with a higher preference value and sets the TTL timer for the entry to match the value in the advertisement. When the host receives a new advertisement for its current default router, it resets the TTL value to that in the new advertisement. This also provides a mechanism for routers to declare themselves unavailable. They send an advertisement with a TTL value of zero.
2.2.1.6 Time Exceeded (11)
unused (zero)
3376\3376F2A9 IP header + 64 bits of original data of the datagram
0 8 16 31
Figure 38. ICMP - Time Exceeded
If this message is received from an intermediate router, it means that the time-to-live field of an IP datagram has expired.
If this message is received from the destination host, it means that the IP fragment reassembly time-to-live timer has expired while the host is waiting for a fragment of the datagram. The ICMP header code field may have the one of the following values:
0 transit TTL exceeded 1 reassembly TTL exceeded
2.2.1.7 Parameter Problem (12)
pointer
3376\3376F2AA IP header + 64 bits of original data of the datagram
0 8 16 31 unused (zero)
Figure 39. ICMP - Parameter Problem
Indicates that a problem was encountered during processing of the IP header parameters. The pointer field points to the byte in the original IP datagram where the problem was encountered. The ICMP header code field may have the one of the following values:
0 unspecified error 1 required option missing
2.2.1.8 Time Stamp Request (13) and Time Stamp Reply (14)
identifier
3376\3376F2AB originate timestamp
0 8 16 31 sequence number
receive timestamp transmit timestamp
Figure 40. ICMP - Time Stamp Request and Time Stamp Reply
These two messages are for performance measurements and for debugging. They are not used for clock synchronization.
The sender initializes the identifier and sequence number (which is used if multiple time stamp requests are sent), sets the originate time stamp and sends it to the recipient. The receiving host fills in the receive and transmit time stamps, changes the type to time stamp reply and returns it to the recipient. The receiver has two time stamps in case there is a perceptible time difference between the receipt and transmit times, but in practice, most implementations will perform the two (receipt and reply) in one operation and will set the two time stamps to the same value.
Time Stamps are the number of milliseconds elapsed since midnight UT (GMT).
2.2.1.9 Information Request (15) and Information Reply (16)
identifier
0 8 16 31 sequence number
3376\3376F2AC Figure 41. ICMP - Information Request and Information Reply
An information request is issued by a host to obtain an IP address for an attached network. The sender fills in the request with the destination IP address in the IP header set to zero (meaning this network) and waits for a reply from a server authorized to assign IP addresses to other hosts. The ICMP header code field is zero. The reply will contain IP network addresses in both the source and
destination fields of the IP header. This mechanism is now obsolete (see also 2.5,
“Reverse Address Resolution Protocol (RARP)” on page 72).
2.2.1.10 Address Mask Request (17) and Address Mask Reply
(18)
identifier
3376\3376F2AD subnet address mask
0 8 16 31 sequence number
Figure 42. ICMP - Address Mask Request and Reply
An address mask request is used by a host to determine the subnet mask in use on an attached network. Most hosts will be configured with their subnet mask(s), but some, such as diskless workstations, must obtain this information from a server.
A host uses RARP (see 2.5, “Reverse Address Resolution Protocol (RARP)” on page 72) to obtain its IP address. To obtain a subnet mask, the host broadcasts an address mask request. Any host on the network that has been configured to send address mask replies will fill in the subnet mask, convert the packet to an address mask reply and return it to the sender. The ICMP header code field is zero.