ietf-corpus

rfc-792

Internet Control Message Protocol

J. Postel
date1981-09 streamLegacy statusINTERNET STANDARD pages21 canonicalhttps://www.rfc-editor.org/rfc/rfc792 doi10.17487/RFC0792 errataview

obsoletes

updated by

also

Extracted elements (26)

design-rationale §Introduction

IP is not designed to be absolutely reliable. ICMP provides feedback about problems in the communication environment but does not make IP reliable; there are still no guarantees that a datagram will be delivered or a control message returned.

ip

interoperability-note §Destination Unreachable Message

Destination Unreachable codes 0, 1, 4, and 5 may only be received from a gateway, while codes 2 and 3 may only be received from a host. Time Exceeded code 0 comes from a gateway; code 1 comes from a host.

ip

normative-requirement §Redirect Message MUST NOT

A redirect message is not sent for datagrams with the IP source route option even if a better route exists; the gateway simply forwards using the next address in the source route.

ip, routing

normative-requirement §Message Formats MUST

Any field labeled 'unused' in an ICMP message must be zero when sent, but receivers should not use these fields except to include them in the checksum.

ip

normative-requirement §Introduction MUST

ICMP is an integral part of IP and must be implemented by every IP module. It uses IP's basic support as if it were a higher-level protocol.

ip, security

normative-requirement §Time Exceeded Message MUST

If a gateway finds the TTL field is zero it must discard the datagram and may notify the source host via the Time Exceeded message (code 0). If a host cannot complete fragment reassembly within its time limit, it discards the datagram and may send Time Exceeded (code 1); if fragment zero is not available, no Time Exceeded need be sent.

ip

normative-requirement §Parameter Problem Message MUST

If a gateway or host processing a datagram finds a header parameter problem that prevents completing processing, it must discard the datagram. It may notify the source via the Parameter Problem message, but only if the error caused the datagram to be discarded.

ip

normative-requirement §Introduction MUST NOT

No ICMP messages are sent about ICMP messages, to avoid infinite regress. Additionally, ICMP messages are only sent about errors in handling fragment zero of fragmented datagrams.

ip

normative-requirement §Source Quench Message SHOULD

On receipt of a Source Quench message, the source host should cut back the rate at which it is sending traffic to the specified destination until it no longer receives Source Quench messages, then may gradually increase the rate again.

ip, congestion

normative-requirement §Echo or Echo Reply Message MUST

The data received in an Echo message must be returned in the Echo Reply message. The Identifier and Sequence Number fields aid in matching replies with requests.

ip

normative-requirement §Destination Unreachable Message MUST

When a datagram must be fragmented to be forwarded by a gateway but the Don't Fragment (DF) flag is set, the gateway must discard the datagram and may return a Destination Unreachable message (code 4) to the source.

ip

protocol-element §Destination Unreachable Message

All ICMP error messages include the Internet Header plus the first 64 bits of the original datagram's data, enabling the receiving host to match the error to the appropriate process. If a higher-level protocol uses port numbers, they are assumed to be in the first 64 data bits.

ip

protocol-element §Message Formats

ICMP checksum is the 16-bit one's complement of the one's complement sum of the ICMP message starting with the ICMP Type field. The checksum field is set to zero during computation. For Echo messages with odd total length, the data is padded with one zero octet for checksum computation.

ip, crypto

protocol-element §Summary of Message Types

Summary of ICMP message type numbers: 0=Echo Reply, 3=Destination Unreachable, 4=Source Quench, 5=Redirect, 8=Echo, 11=Time Exceeded, 12=Parameter Problem, 13=Timestamp, 14=Timestamp Reply, 15=Information Request, 16=Information Reply.

ip, registry

protocol-element §Timestamp or Timestamp Reply Message

The Originate Timestamp is the time the sender last touched the message before sending it; the Receive Timestamp is the time the echoer first touched it on receipt; the Transmit Timestamp is the time the echoer last touched it on sending.

ip, ntp

protocol-element §Timestamp or Timestamp Reply Message

Timestamps are 32 bits of milliseconds since midnight UT. If a non-standard time is inserted (not milliseconds since midnight UT), the high-order bit of the timestamp must be set to indicate this non-standard value.

ip, ntp

security-consideration §Redirect Message

ICMP Redirect messages advise hosts to change their routing tables based on gateway instructions; a malicious or misconfigured gateway could redirect traffic inappropriately. RFC 792 does not include authentication for ICMP messages, leaving implementations vulnerable to spoofed redirects and other ICMP-based attacks.

ip, security

wire-format §Message Formats

All ICMP messages are carried in IP datagrams with Protocol=1. The first octet of the IP data portion is the ICMP Type field; its value determines the format of the remaining data. The IP header uses Version=4, ToS=0, and a 16-bit one's complement Header Checksum.

ip

wire-format §Destination Unreachable Message

Destination Unreachable message: Type=3, 8-bit Code (0=net unreachable, 1=host unreachable, 2=protocol unreachable, 3=port unreachable, 4=fragmentation needed and DF set, 5=source route failed), 16-bit Checksum, 32-bit unused, followed by the Internet Header plus the first 64 bits of the original datagram's data.

ip

wire-format §Echo or Echo Reply Message

Echo (Type=8) and Echo Reply (Type=0) messages: 16-bit Checksum, 16-bit Identifier, 16-bit Sequence Number, followed by variable-length Data. To form a reply, source and destination addresses are reversed, type code changed to 0, and checksum recomputed.

ip

wire-format §Information Request or Information Reply Message

Information Request (Type=15) and Information Reply (Type=16) messages: 16-bit Checksum, 16-bit Identifier, 16-bit Sequence Number. A host may send with source and destination IP address fields set to zero ('this' network); the reply must return fully specified addresses.

ip

wire-format §Parameter Problem Message

Parameter Problem message: Type=12, Code=0 (pointer indicates the error), 16-bit Checksum, 8-bit Pointer identifying the octet where the error was detected, 24-bit unused, followed by the Internet Header plus first 64 bits of the original datagram.

ip

wire-format §Redirect Message

Redirect message: Type=5, Code (0=redirect for Network, 1=redirect for Host, 2=redirect for ToS and Network, 3=redirect for ToS and Host), 16-bit Checksum, 32-bit Gateway Internet Address (address to which traffic should be redirected), followed by Internet Header plus first 64 bits of original datagram.

ip, routing

wire-format §Source Quench Message

Source Quench message: Type=4, Code=0, 16-bit Checksum, 32-bit unused, followed by the Internet Header plus first 64 bits of the original datagram. Sent by a gateway or destination host to request the source reduce its sending rate.

ip, congestion

wire-format §Time Exceeded Message

Time Exceeded message: Type=11, Code 0=time to live exceeded in transit (from gateway), Code 1=fragment reassembly time exceeded (from host), 16-bit Checksum, 32-bit unused, followed by the Internet Header plus the first 64 bits of the original datagram's data.

ip

wire-format §Timestamp or Timestamp Reply Message

Timestamp (Type=13) and Timestamp Reply (Type=14) messages: 16-bit Checksum, 16-bit Identifier, 16-bit Sequence Number, three 32-bit timestamp fields (Originate Timestamp, Receive Timestamp, Transmit Timestamp), each representing milliseconds since midnight UT.

ip, ntp