ietf-corpus

rfc-2463

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

A. Conta, S. Deering
date1998-12 streamIETF areaint wgipngwg statusDRAFT STANDARD pages18 canonicalhttps://www.rfc-editor.org/rfc/rfc2463 doi10.17487/RFC2463
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

obsoletes

Extracted elements (25)

design-rationale §2.3

ICMPv6 includes the IPv6 pseudo-header in its checksum calculation, unlike ICMPv4. This change was made to provide additional protection against corrupted source/destination addresses in the IPv6 header.

ip, security

interoperability-note §3.4

Parameter Problem Code 2 (unrecognized IPv6 option with highest-order two bits set to 10) is an exception to the rule against sending ICMPv6 errors in response to multicast/broadcast-destined packets.

ip

interoperability-note §3.2

The Packet Too Big message is an explicit exception to the rule prohibiting ICMPv6 errors in response to multicast/broadcast packets; it MUST be sent even for multicast-destined packets to enable Path MTU Discovery to function for IPv6 multicast.

ip, multicast

normative-requirement §3.1 MUST

A node receiving the ICMPv6 Destination Unreachable message MUST notify the upper-layer process.

ip

normative-requirement §3.2 MUST

A Packet Too Big MUST be sent by a router when it cannot forward a packet because the packet exceeds the MTU of the outgoing link. An incoming Packet Too Big message MUST be passed to the upper-layer process.

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 a multicast, link-layer multicast, or link-layer broadcast address (with two specific exceptions); or a packet whose source address does not uniquely identify a single node (e.g., unspecified, multicast, or anycast).

ip

normative-requirement §2.4 MUST

An ICMPv6 error message of unknown type MUST be passed to the upper layer; an ICMPv6 informational message of unknown type MUST be silently discarded.

ip

normative-requirement §2.4 MUST

An IPv6 node MUST limit the rate of ICMPv6 error messages it sends, using either timer-based (e.g., at most once per T milliseconds) or bandwidth-based (e.g., fraction F of link bandwidth) mechanisms. Rate-limit parameters MUST be configurable with conservative defaults (e.g., T=1s, F=2%).

ip, security

normative-requirement §2.4 MUST

Every ICMPv6 error message (Type < 128) MUST include as much of the IPv6 offending packet as will fit without the resulting error message packet exceeding the minimum IPv6 MTU.

ip

normative-requirement §4.1 MUST

Every IPv6 node MUST implement an ICMPv6 Echo responder that receives Echo Requests and sends corresponding Echo Replies. Echo Reply data MUST be returned entirely and unmodified.

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 an ICMPv6 Time Exceeded message (Code 0) to the source.

ip

normative-requirement §3.4 MUST

If an IPv6 node finds a problem with a field in the IPv6 header or extension headers, it MUST discard the packet and SHOULD send a Parameter Problem message indicating the type and byte offset of the problem.

ip

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 reply source MUST be a unicast address belonging to the receiving interface.

ip

normative-requirement §2.2 MUST

When a node sends an ICMPv6 message in response to a packet sent to one of its own unicast addresses, the Source Address of the reply MUST be that same address. For multicast/anycast responses, a unicast address on the receiving interface MUST be used.

ip

protocol-element §2.1

ICMPv6 messages are classified by the high-order bit of the Type field: error messages have Types 0–127 (high-order bit = 0); informational messages have Types 128–255 (high-order bit = 1). This document defines Types 1–4 (errors) and 128–129 (Echo Request/Reply).

ip

protocol-element §2.3

The ICMPv6 checksum is the 16-bit one's complement of the one's complement sum of the entire ICMPv6 message prepended with an IPv6 pseudo-header (as per RFC 2460 section 8.1), using Next Header value 58. The checksum field is set to zero during computation.

ip

security-consideration §5.1

A node SHOULD include an IP Authentication Header when sending ICMPv6 messages if a security association exists for the destination. Received Authentication Headers in ICMP packets MUST be verified, and packets with incorrect authentication MUST be discarded. Administrators SHOULD be able to configure nodes to ignore unauthenticated ICMPv6 messages, but this SHOULD default to allowing unauthenticated messages.

security, ipsec, ip

security-consideration §5.2

ICMPv6 messages are subject to spoofing (mitigated by AH), redirection attacks (mitigated by checksum plus AH/ESP), payload modification (mitigated by AH/ESP), and denial-of-service via back-to-back error-inducing packets (mitigated by the rate-limiting requirement in section 2.4).

security, ip

wire-format §3.1

Destination Unreachable (Type=1): 4-byte header (Type, Code, Checksum) followed by a 4-byte Unused field (initialized to zero), then as much of the invoking packet as fits within the minimum IPv6 MTU. Code values: 0=no route, 1=admin prohibited, 3=address unreachable, 4=port unreachable.

ip

wire-format §4.1

Echo Request (Type=128) and Echo Reply (Type=129): 4-byte header followed by a 2-byte Identifier, a 2-byte Sequence Number (both may be zero), and zero or more octets of arbitrary Data. Echo Reply copies Identifier, Sequence Number, and Data verbatim from the request.

ip

wire-format §2.1

Every ICMPv6 message begins with a fixed 4-byte header: Type (8 bits), Code (8 bits), and Checksum (16 bits), followed by a variable-length message body. The ICMPv6 Next Header value is 58.

ip

wire-format §3.2

Packet Too Big (Type=2): 4-byte header (Type, Code, Checksum) followed by a 4-byte MTU field carrying the Maximum Transmission Unit of the next-hop link, then as much of the invoking packet as fits within the minimum IPv6 MTU. Code is always 0.

ip

wire-format §3.4

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

ip

wire-format §3.3

Time Exceeded (Type=3): 4-byte header (Type, Code, Checksum) followed by a 4-byte Unused field (zero), then as much of the invoking packet as fits. Code 0 = hop limit exceeded in transit; Code 1 = fragment reassembly time exceeded.

ip