NerveCenter emits two types of traffic onto the networks it is attached to: SNMP and ICMP datagrams. Either of these traffic types can be replied to with an ICMP message. The reply message might be generated by the destination host or a gateway along the path taken by the datagram. NerveCenter, therefore, must be aware of ICMP messages and handle them appropriately.
This blog shows the ICMP Message types for IPv4 used within NerveCenter and how they are interpreted.
Table 1 shows the set of defined set of ICMP message types. Messages are encoded using Type and Code values as shown. While the Type field usually serves as the primary key for a particular group of ICMP messages, this has not always been the case. The Echo or Echo Reply group, for example, uses two Type values: one for the request and one for the reply.
While some message groups form a response/reply set, other do not. The Destination Unreachable group, for example, can be issued in response to any IP-based message on the network; there is no explicit ‘request’ message for this group. On the other hand the Echo group has a clearly defined ‘request’ and ‘reply’ message pair. The same is true of the Timestamp and Information groups.
The table’s Origin columns show which network nodes could generate such a message. Src Host is typically a management station, sending an ICMP or other IP-based request message to a specified Dest Host. An ICMP reply message is potentially generated either by the Dest Host or else by a gateway along the route taken by the request message.
Several of the groups can be considered Historic – meaning here that they are defined by their respective RFCs but are not known to have been implemented.i These are the groups Conversion Failed, Domain Name and Security Failures. For the sake of completeness, they are covered throughout this document; however, the likelihood of ever encountering them would be highly unlikely.
information request
| Message | Origin | Description | Reference | |||||
|---|---|---|---|---|---|---|---|---|
| Type | Code | src host |
gateway | dest host |
||||
| # | Label | # | Label | |||||
| 3 | Destination Unreachable | 0 | net unreachable | – | yes | no | The specified network is unreachable. | RFC792 |
| 1 | host unreachable | – | yes | no | The specified host is unreachable. | RFC792 | ||
| 2 | protocol unreachable | – | no | yes | The indicated protocol module is not active. | RFC792 | ||
| 3 | port unreachable | – | no | yes | The indicated process port is not active. | RFC792 | ||
| 4 | fragmentation needed and DF set | – | yes | no | The datagram must be fragmented in order to be forwarded; however, the Don’t Fragement flag is on. | RFC792 RFC1191 |
||
| 5 | source route failed | – | yes | no | Datagram cannot be route under current (transient) routing state | RFC792 | ||
| 6 | destination network unknown | – | yes | no | no route (include default route) is valid for this datagram’s target | RFC1122 | ||
| 7 | destination host unknown | – | yes | no | no known host matches this datagram’s target. | RFC1122 | ||
| 8 | source host isolated | – | no | yes | Source host isolated. | RFC1122 | ||
| 9 | communication with destination network is administratively prohibited | – | no | yes | (for use by end-to-end encryption devices used by U.S military agencies) | RFC1108 RFC1812 |
||
| 10 | communication with destination host is administratively prohibited | – | no | yes | (for use by end-to-end encryption devices used by U.S military agencies) | RFC1108 RFC1812 |
||
| 11 | destination network unreachable for Type of Service | – | yes | no | The TOS specified for a defined route is neither the default TOS nor the TOS of the datagram that the gateway is attempting to route. | RFC1122 | ||
| 12 | destination network unreachable for Type of Service | – | yes | no | The TOS specified for a directly connected host is neither the default TOS nor the TOS of the datagram that the gateway is attempting to route. | RFC1122 | ||
| 13 | communication administratively prohibited | – | yes | no | Administrative filtering prohibits gateway from forwarding datagram. | RFC1812 | ||
| 14 | host precedence violation | – | yes | no | The datagram’s requested precedence is not permitted for the combination of source/destination host or network, upper layer protocol, and source/destination port. | RFC1812 | ||
| 15 | precedence cutoff in effect | – | yes | no | The datagram’s requested precedence is below the administratively set required level for this operation. | RFC1812 | ||
| 11 | Time Exceeded | 0 | time to live exceeded in transit | – | yes | no | Datagram has time to live field set to 0 (zero) | RFC792 |
| 1 | fragment reassembly time exceeded | – | no | yes | A fragmented datagram cannot be reassembled with the host’s time limit. | RFC792 | ||
| 12 | Parameter Problem | 0 | pointer indicates the error | – | yes | yes | A problem exists with the datagram’s header parameters. | RFC792 |
| 1 | required option is missing | – | yes | yes | Datagram has no Basic Security Option option and this was required for receival on a given network port. | RFC1108 | ||
| 2 | bad length | – | yes | yes | bad length | IANA | ||
| 4 | Source Quench | 0 | pointer indicates the error | – | yes | yes | Datagram arrival is too fast for processing. | RFC792 |
| 5 | Redirect | 0 | redirect datagrams for the network | – | yes | no | Gateway advises the source host to send datagram instead to alternate gateway. | RFC792 |
| 1 | redirect datagrams for the host | – | yes | no | RFC792 | |||
| 2 | redirect datagrams for the Type of Service and Network | – | yes | no | RFC792 | |||
| 3 | redirect datagrams for the Type of Service and Host | – | yes | no | RFC792 | |||
| 8 | Echo or Echo Reply | 0 | echo | yes | – | – | echo | RFC792 |
| 0 | 0 | echo reply | – | yes | yes | echo reply | RFC792 | |
| 13 | Timestamp or Timestamp Reply | 0 | timestamp | – | – | – | timestamp | RFC792 |
| 14 | 0 | timestamp reply | – | yes | yes | timestamp reply | RFC792 | |
| 15 | Information Request or Information Reply | 0 | information request | yes | – | – | information request (Obsolete) | RFC792 |
| 16 | 0 | information reply | – | no | yes | information reply (Obsolete) | RFC792 | |
| 17 | Address Mask | 0 | address mask request | yes | yes | – | Request for net mask information. | RFC950 |
| 18 | 0 | address mask reply | – | yes | yes | Reply containing net mask information. | RFC950 | |
| 9 | Router Discovery | 0 | router advertisement | – | yes | no | Announcement of IP address(es) of a given interface. | RFC1256 |
| 16 | does not route common traffic | – | yes | no | Mobility agent does not route common traffic. | RFC2002 | ||
| 10 | 0 | router solicitation | yes | no | no | Solicitation for a router advertisement. | RFC1256 | |
| 30 | Traceroute | 0 | outbound packet successfully forwarded | – | yes | no | Request has been forwarded. | RFC1393 |
| 1 | no route for outbound packet; packet discarded | – | yes | no | Request cannot be forwarded. | RFC1393 | ||
| 31 | Conversion Failed (Historic) |
0 | unknown/unspecified error | – | yes | yes | These ICMP Messages are in support of RFC1475’s “TP/IX: The Next Internet” specification. This RFC, published in June 1993, proposed “IP version 7.” | RFC1475 |
| 1 | don’t convert option present | – | yes | yes | RFC1475 | |||
| 2 | unknown mandatory option present | – | yes | yes | RFC1475 | |||
| 3 | known unsupported option present | – | yes | yes | RFC1475 | |||
| 4 | unsupported transport protocol | – | yes | yes | RFC1475 | |||
| 5 | overall length exceeded | – | yes | yes | RFC1475 | |||
| 6 | IP header length exceeded | – | yes | yes | RFC1475 | |||
| 7 | transport protocol > 255 | – | yes | yes | RFC1475 | |||
| 8 | port conversion out of range | – | yes | yes | RFC1475 | |||
| 9 | transport header length exceeded | – | yes | yes | RFC1475 | |||
| 10 | 32 bit rollover missing and ACK set | – | yes | yes | RFC1475 | |||
| 11 | unknown mandatory transport option present | – | yes | yes | RFC1475 | |||
| 37 | Domain Name (Historic) |
0 | domain name request | yes | – | – | Domain Name request | RFC1788 |
| 38 | 0 | domain name reply | – | yes | yes | Domain Name reply | RFC1788 | |
| 40 | Security Failures (Historic) |
0 | bad SPI | – | yes | yes | RFC2521 | |
| 1 | authentication failed | – | yes | yes | RFC2521 | |||
| 2 | decompression failed | – | yes | yes | RFC2521 | |||
| 3 | decryption failed | – | yes | yes | RFC2521 | |||
| 4 | need authentication | – | yes | yes | RFC2521 | |||
| 5 | need authorization | – | yes | yes | RFC2521 | |||