ietf-corpus

rfc-1885

Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)

A. Conta, S. Deering
date1995-12 streamIETF areaint wgipngwg statusPROPOSED STANDARD pages20 canonicalhttps://www.rfc-editor.org/rfc/rfc1885 doi10.17487/RFC1885
This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]

obsoleted by

Extracted elements (30)

design-rationale §2.1

ICMPv6 uses Next Header value 58, distinct from the value used for ICMPv4, because the two protocols differ substantially; using the same value would have implied backward compatibility that does not exist.

ip

design-rationale §1

IPv4's IGMP was merged into ICMPv6 rather than kept as a separate protocol, simplifying the IPv6 protocol stack by reducing the number of required internet-layer protocols from two to one.

ip, multicast

design-rationale §2.3

The ICMPv6 checksum includes a pseudo-header of IPv6 fields, unlike IPv4 ICMP. The rationale for this change is given in the IPv6 specification (RFC 1883, section 8.1), providing stronger integrity coverage across the IP and ICMP headers together.

ip, crypto

design-rationale §3.2

The Packet Too Big message is explicitly exempted from the rule prohibiting ICMPv6 errors in response to multicast packets, so that Path MTU Discovery (RFC 1191) can function correctly for IPv6 multicast traffic.

ip, multicast

interoperability-note §2.1

ICMPv6 has IPv6 Next Header value 58, which is different from the protocol number used for ICMPv4. Implementations must not conflate the two protocols when demultiplexing.

ip

normative-requirement §3.1 MUST

A node receiving an ICMPv6 Destination Unreachable message MUST notify the upper-layer protocol. A Destination Unreachable message MUST NOT be generated due to congestion.

ip

normative-requirement §3.2 MUST

A Packet Too Big message MUST be sent by a router when it cannot forward a packet because the packet exceeds the MTU of the outgoing link. This message is an exception to the no-error-for-multicast rule and MUST be sent even for multicast-destined packets.

ip

normative-requirement §2.4 MUST NOT

An ICMPv6 error message MUST NOT be sent in response to: another ICMPv6 error message; a packet destined to an IPv6 multicast address (with two exceptions: Packet Too Big and Parameter Problem Code 2); a link-layer multicast or broadcast packet; or a packet whose source address does not uniquely identify a single node (e.g., unspecified address, multicast address, anycast address).

ip, security

normative-requirement §3.2 MUST

An incoming Packet Too Big message MUST be passed to the upper-layer protocol to support Path MTU Discovery.

ip

normative-requirement §2.4 MUST

Every ICMPv6 error message (Type < 128) MUST include as much of the offending packet as will fit without making the error message exceed 576 octets.

ip

normative-requirement §4.1 MUST

Every node MUST implement an ICMPv6 Echo responder that receives Echo Requests and sends Echo Replies. A node SHOULD also implement an application-layer interface for sending Echo Requests and receiving Echo Replies for diagnostic purposes.

ip

normative-requirement §2 MUST

ICMPv6 is an integral part of IPv6 and MUST be fully implemented by every IPv6 node.

ip, security

normative-requirement §3.3 MUST

If a router receives a packet with Hop Limit of zero, or decrements Hop Limit to zero, it MUST discard the packet and send a Time Exceeded message (Code 0) to the source.

ip

normative-requirement §2.4 MUST

If an ICMPv6 error message of unknown type is received, it MUST be passed to the upper-layer protocol. If an ICMPv6 informational message of unknown type is received, it MUST be silently discarded.

ip

normative-requirement §3.4 MUST

If an IPv6 node finds a problem with a field in the IPv6 header or extension headers such that it cannot complete processing, it MUST discard the packet and SHOULD send a Parameter Problem message indicating the type and location of the problem via the Pointer field.

ip

normative-requirement §4.2 MUST

The data received in an Echo Request MUST be returned entirely and unmodified in the Echo Reply, unless the reply would exceed the path MTU, in which case the data is truncated to fit.

ip

normative-requirement §2.3 MUST

The ICMPv6 checksum is computed over the entire ICMPv6 message prepended with an IPv6 pseudo-header (as specified in the IPv6 spec, section 8.1), using Next Header value 58. This differs from IPv4 ICMP which does not include a pseudo-header.

ip, crypto

normative-requirement §4.2 MUST

The source address of an Echo Reply sent in response to a unicast Echo Request MUST be the same as the destination address of that Echo Request. For multicast Echo Requests, the source MUST be a unicast address on the receiving interface.

ip

normative-requirement §2.4 MUST

To prevent bandwidth exhaustion, an IPv6 node MUST rate-limit ICMPv6 error messages sent to each source of erroneous packets. Rate-limiting parameters (e.g., T=1 second per source or F=2% of link bandwidth) MUST be configurable with conservative defaults.

ip, security

normative-requirement §2.2 MUST

When sending an ICMPv6 message in response to a unicast packet sent to one of the node's addresses, the source address of the reply MUST be that same address. For responses to multicast or anycast packets, the source address MUST be a unicast address on the interface that received the packet.

ip

protocol-element §2.1

ICMPv6 is identified by IPv6 Next Header value 58, which is distinct from the value used for ICMPv4. This document defines error messages (types 1–4) and informational messages (types 128–132).

ip

protocol-element §4.3

Three Group Membership message types are defined: Query (130) sent by routers to discover group membership, Report (131) sent by nodes to report membership, and Reduction (132) sent by nodes leaving a group. These replace IGMP for IPv6.

ip, multicast

security-consideration §7

Security issues are explicitly not discussed in this memo. However, the specification includes implicit mitigations: rate-limiting of error messages (section 2.4(f)) to prevent ICMPv6-based bandwidth amplification, and prohibition on sending errors in response to packets with non-unicast or unspecified source addresses to prevent reflection attacks.

ip, security

wire-format §3.1

Destination Unreachable (Type 1): 32-bit unused field (zeroed), followed by as much of the invoking packet as fits within the 576-octet limit. Code values: 0=no route, 1=administratively prohibited, 2=not a neighbor (strict routing), 3=address unreachable, 4=port unreachable.

ip

wire-format §4.1

Echo Request (Type 128, Code 0): 16-bit Identifier, 16-bit Sequence Number, followed by zero or more octets of arbitrary data. Echo Reply (Type 129) mirrors the same format with data copied from the request.

ip

wire-format §2.1

Every ICMPv6 message begins with a fixed 32-bit header: Type (8 bits), Code (8 bits), and Checksum (16 bits), followed by a variable-length message body. Error messages have Type values 0–127; informational messages have Type values 128–255.

ip

wire-format §4.3

Group Membership Messages (Types 130/131/132): 16-bit Maximum Response Delay (ms, meaningful only in Query), 16-bit Unused (zeroed), followed by the 128-bit Multicast Address. Hop Limit is set to 1. A zero Multicast Address in a Query implies a query for all groups.

ip, multicast

wire-format §3.2

Packet Too Big (Type 2, Code 0): contains a 32-bit MTU field reporting the maximum transmission unit of the next-hop link, followed by as much of the invoking packet as fits within 576 octets.

ip

wire-format §3.4

Parameter Problem (Type 4): 32-bit Pointer field identifying the octet offset within the invoking packet where the error was detected, followed by as much of the invoking packet as fits within 576 octets. Code 0 = erroneous header field; Code 1 = unrecognized Next Header; Code 2 = unrecognized IPv6 option.

ip

wire-format §3.3

Time Exceeded (Type 3): 32-bit unused field (zeroed), followed by as much of the invoking packet as fits within 576 octets. Code 0 = hop limit exceeded in transit; Code 1 = fragment reassembly time exceeded.

ip