Decomposition of a ICMP Packet

The above is an example of an ICMP Header. ICMP is considered an unreliable protocol where no attempt is made to keep track of packets as to being in a sequence, order, or verify that they were received. (OVERSTRIKE BEGIN)Checks are made to see if the packet appears to be the same packet transmitted by evaluation of a checksum and comparison to the packets checksum. These packets are dropped if the destination calculations of the checksum differs from the packets claimed checksum.(OVERSTRIKE END) After being contacted by "Luzian Scherrer" <luzian@scherrer.ch>, I was asked if the above was true. Luzian asked, does a host need to drop an ICMP packet that has an invalid checksum? Luzian performed some tests to see if vendors provided support for droping ICMP packets with invalid checksum and found many vendors were inconsistent in their use of the ICMP checksum. At this time, I will alter the above text to read like this: Though there is no requirement in ICMP RFC (AFAIK) to drop ICMP packets that have invalid checksum, and there is no mention of this being a SHOULD for the protocol, the risk of not doing it is the remote host may choose to ignore an ICMP packet that has an invalid checksum. If you find information on where dropping is SUGGESTED or REQUIRED for the RFC on ICMP, please let me know.

ICMP is probably one of the more misunderstood of the common TCP/IP suite of protocols. The complexity of its conveyed content is minimal, but the actual meaning of the messages delivered and how it effects routes, sessions, and operations between hosts and nodes is more complicated. With exception to the math behind understanding all of the routing mechanisms in the various routing protocols that run over IP (RIP, OSPF, etc.) this is probably the one with the most complexity with all effects taken into consideration. (My opinion.)

Description of fields listed in above ICMP header starting from left to right, top to bottom.
• Type (8 bits): Is a kind of classification for grouping a "class" of communication types together.
• Code (8 bits): These are various types of messages that fit into the classification of the types listed above.
• ICMP Checksum (16 bits):This is a checksum that covers the header and data portion of an ICMP packet to allow the receiving host to verify the integrity of an incoming ICMP packet. The ICMP packet is loaded with a predefined number in the checksum field, and then when the checksum is computed, then the checksum is written over the previous value. (OVERSTRIKE BEGIN)When the packet arrives at the destination, the destination machine's OS looks to the 4 header field (bytes made from bits 16 through 31) and pulls them out of the packet, then re-calculates the checksum on the packet without anything in the checksum field. Then the OS compares the checksum calculated with thte one that was transmitted in the packet. If the checksum is the same, the data is fine, and it is allowed to pass on through, but if there is a difference, the ICMP packet, and data are dropped, and no attempt is made by the receiving machine to get a new copy, and the sending machine will not try to send that same packet. The packet is lost forever.(OVERSTRIKE END) As it turns out, there is no "REQUIRED" or "SUGGESTED" for this procedure in the RFC on ICMP (as of this date AFAIK). Though, it is a good idea to at least properly compute the checksum for packets you send out so that if the remote system does drop ICMP packets with invalid checksum, yours won't always be dropped. Thanks to "Luzian Scherrer" <luzian@scherrer.ch> for pointing this out to me! :-)
• Data (Variable bits): As you might expect, this is the payload, or data portion of an ICMP packet. The payload includes type and code values referring to control information.

Query: This specifies it is used to question, ask or convey non error information.

Error: This specifies it is used in error events.

Host: Message expected from a host.

Gateway: Message expected from a gateway.Gateway has an ambiguous meaning since microsoft decided to change the industry standard of its meaning. In this case I refer to a Network layer routing device like a router for a subnet or the glossary definition from RFC-950- "A node connected to two or more administratively distinct networks and/or subnets, to which hosts send datagrams to be forwarded."

**:From RFC950:may be received from a gateway, or a host acting in lieu of a gateway.

Also try ftp://ftp.isi.edu/in-notes/iana/assignments/icmp-parameters

Original ICMP Spec: RFC-792-

Internet Standard Subnetting Procedure: RFC-950-

General Review of and Internet Host: RFC-1122

Assigned Numbers: RFC-1700

This ends the brief preview of an ICMP packet.

Comments and/or suggestions for this?: Email me at: dugan@passwall.com

Attempts have been made to make the tables appear as they should for LYNX users by forcing a common field width for fields being used by padding them with other printable characters. This is meant to allow for LYNX users to see the tables much like the Netscape and other web browser worlds might show them. However, from personal experience, some versions of LYNX still manage to munge the tables, making them use up several pages. It seems to be a problem with how earlier versions of LYNX dealt with tables, but the problem has not been entirely isolated.

Some have asked why this collection of on-line documents is so lacking of graphic content. To them I answer: faster downloads. Many of these pages are smaller than some pictures on many commercial web sites. You do not come here to look at my pictures. You come here to read content. Also, LYNX users benefit from this, and by using ALL text, people with ADA issues are able to use speech recognition software on the text to hear the words.

Copyright (C) 1999, 2000, 2001, 2002 by Michael Egan: All rights reserved.

A Special License: No part of this document may be used for profit without the consent of the author Michael Egan in writing. Content may be duplicated for retransmission for non-profit purposes as long as the copyright and license remain included in their entirety. The content is provided "as-is" and I take no responsibility on the content's truthfulness or consistency. Errors may exist in these documents, but acting upon these errors is left up to the reader to verify by a third party that will take responsibility for fact verification. When notified of errors or inconsistencies, attempts will be made to rectify the errors.

In plan English this is meant to do many things: This copyright is meant to exist so that others may not profit from this work as published in paper form, or by duplicating the content to place advertisements over it and generate income. It is also meant to exist to prevent people from publishing this work as their own and receiving profit from this process on research they did not perform. It is not meant to stop a professor from running off copies to use in their classes for their students. It is also not meant to stop the student from printing up copies for their own education. How depressing it would be to find your work published in book form without your permission, or compensation. Another reason for this Copyright is to limit the effect of the mistakes I have made within this document before I was able to complete it. It would be even sadder to notice my mistakes in print and criticized before I could resolve them. Eventually, after I finish this work, I may retain copyright, but eliminate the license.