Connected: An Internet Encyclopedia
RFC 1122 - 3.2.2 Internet Control Message Protocol -- ICMP

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1122
Up: 3. INTERNET LAYER PROTOCOLS
Up: 3.2 PROTOCOL WALK-THROUGH
Prev: 3.2.1.8 Options: RFC-791 Section 3.2
Next: 3.2.2.1 Destination Unreachable: RFC-792

### 3.2.2 Internet Control Message Protocol -- ICMP

ICMP messages are grouped into two classes.

- ICMP error messages:

  Destination Unreachable (see Section 3.2.2.1)
  Redirect (see Section 3.2.2.2)
  Source Quench (see Section 3.2.2.3)
  Time Exceeded (see Section 3.2.2.4)
  Parameter Problem (see Section 3.2.2.5)

- ICMP query messages:

  Echo (see Section 3.2.2.6)
  Information (see Section 3.2.2.7)
  Timestamp (see Section 3.2.2.8)
  Address Mask (see Section 3.2.2.9)

If an ICMP message of unknown type is received, it MUST be silently discarded.

Every ICMP error message includes the Internet header and at least the first 8 data octets of the datagram that triggered the error; more than 8 octets MAY be sent; this header and data MUST be unchanged from the received datagram.

In those cases where the Internet layer is required to pass an ICMP error message to the transport layer, the IP protocol number MUST be extracted from the original header and used to select the appropriate transport protocol entity to handle the error.

An ICMP error message SHOULD be sent with normal (i.e., zero) TOS bits. An ICMP error message MUST NOT be sent as the result of receiving:

- an ICMP error message, or

- a datagram destined to an IP broadcast or IP multicast address, or

- a datagram sent as a link-layer broadcast, or

- a non-initial fragment, or

- a datagram whose source address does not define a single host -- e.g., a zero address, a loopback address, a broadcast address, a multicast address, or a Class E address.

NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES.

DISCUSSION:

  These rules will prevent the "broadcast storms" that have resulted from hosts returning ICMP error messages in response to broadcast datagrams. For example, a broadcast UDP segment to a non-existent port could trigger a flood of ICMP Destination Unreachable datagrams from all machines that do not have a client for that destination port. On a large Ethernet, the resulting collisions can render the network useless for a second or more.

  Every datagram that is broadcast on the connected network should have a valid IP broadcast address as its IP destination (see Section 3.3.6). However, some hosts violate this rule. To be certain to detect broadcast datagrams, therefore, hosts are required to check for a link-layer broadcast as well as an IP-layer broadcast address.

IMPLEMENTATION:

  This requires that the link layer inform the IP layer when a link-layer broadcast datagram has been received; see Section 2.4.

3.2.2.1 Destination Unreachable: RFC-792
3.2.2.2 Redirect: RFC-792
3.2.2.3 Source Quench: RFC-792
3.2.2.4 Time Exceeded: RFC-792
3.2.2.5 Parameter Problem: RFC-792
3.2.2.6 Echo Request/Reply: RFC-792
3.2.2.7 Information Request/Reply: RFC-792
3.2.2.8 Timestamp and Timestamp Reply: RFC-792
3.2.2.9 Address Mask Request/Reply: RFC-950

Next: 3.2.2.1 Destination Unreachable: RFC-792

Connected: An Internet Encyclopedia
RFC 1122 - 3.2.2 Internet Control Message Protocol -- ICMP