Hubbry Logo
ICMPv6ICMPv6Main
Open search
ICMPv6
Community hub
ICMPv6
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
ICMPv6
ICMPv6
ICMPv6
View on Wikipedia
from Wikipedia
Internet Control Message Protocol for IPv6
Communication protocol
General structure of ICMPv6 Messages
AbbreviationICMPv6
PurposeAuxiliary Protocol for IPv6
IntroductionDecember 1995; 29 years ago (1995-12)
OSI layerNetwork layer
RFC(s)4443
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

Internet Control Message Protocol version 6 (ICMPv6) is the implementation of the Internet Control Message Protocol (ICMP) for Internet Protocol version 6 (IPv6).[1] ICMPv6 is an integral part of IPv6 and performs error reporting and diagnostic functions.

ICMPv6 has a framework for extensions to implement new features. Several extensions have been published, defining new ICMPv6 message types as well as new options for existing ICMPv6 message types. For example, Neighbor Discovery Protocol (NDP) is a node discovery protocol based on ICMPv6 which replaces and enhances functions of ARP.[2] Secure Neighbor Discovery (SEND) is an extension of NDP with extra security. Multicast Listener Discovery (MLD) is used by IPv6 routers for discovering multicast listeners on a directly attached link, much like Internet Group Management Protocol (IGMP) is used in IPv4. Multicast Router Discovery (MRD) allows the discovery of multicast routers.

Message types and formats

[edit]

ICMPv6 messages may be classified as error messages and information messages. ICMPv6 messages are transported by IPv6 packets in which the IPv6 Next Header value for ICMPv6 is set to the value 58.

The ICMPv6 message consists of a header and the protocol payload. The header contains only three fields: Type (8 bits), Code (8 bits), and Checksum (16 bits).

ICMPv6 message
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Type Code Checksum
4 32 Message body
8 64
⋮ ⋮
Type: 8 bits
Specifies the type of the message. Values in the range from 0 to 127 (high-order bit is 0) indicate an error message, while values in the range from 128 to 255 (high-order bit is 1) indicate an information message.
Code: 8 bits
The Code field value depends on the message type and provides an additional level of message granularity.
Checksum: 16 bits
Provides a minimal level of integrity verification for the ICMP message. The checksum is calculated from the ICMP message (starting with the Type field), prepended with an IPv6 pseudo-header.[1] See below.
Message body: Variable
Contents depends on the message.

Types

[edit]

Control messages are identified by the value in the type field. The code field gives additional context information for the message. Some messages serve the same purpose as the correspondingly named ICMP message types.

Type Code
Value Meaning Value Meaning
ICMPv6 Error Messages
1 Destination unreachable 0 no route to destination
1 communication with destination administratively prohibited
2 beyond scope of source address
3 address unreachable
4 port unreachable
5 source address failed ingress/egress policy
6 reject route to destination
7 Error in Source Routing Header
2 Packet too big 0
3 Time exceeded 0 hop limit exceeded in transit
1 fragment reassembly time exceeded
4 Parameter problem 0 erroneous header field encountered
1 unrecognized Next Header type encountered
2 unrecognized IPv6 option encountered
100 Private experimentation
101 Private experimentation
127 Reserved for expansion of ICMPv6 error messages
ICMPv6 Informational Messages
128 Echo Request 0
129 Echo Reply 0
130 Multicast Listener Query (MLD) 0

There are two subtypes of Multicast Listener Query messages:

  • General Query, used to learn which multicast addresses have listeners on an attached link.
  • Multicast-Address-Specific Query, used to learn if a particular multicast address has any listeners on an attached link.

These two subtypes are differentiated by the contents of the Multicast Address field, as described in section 3.6 of RFC 2710

131 Multicast Listener Report (MLD) 0
132 Multicast Listener Done (MLD) 0
133 Router Solicitation (NDP) 0
134 Router Advertisement (NDP) 0
135 Neighbor Solicitation (NDP) 0
136 Neighbor Advertisement (NDP) 0
137 Redirect Message (NDP) 0
138 Router Renumbering[3] 0 Router Renumbering Command
1 Router Renumbering Result
255 Sequence Number Reset
139 ICMP Node Information Query 0 The Data field contains an IPv6 address which is the Subject of this Query.
1 The Data field contains a name which is the Subject of this Query, or is empty, as in the case of a NOOP.
2 The Data field contains an IPv4 address which is the Subject of this Query.
140 ICMP Node Information Response 0 A successful reply. The Reply Data field may or may not be empty.
1 The Responder refuses to supply the answer. The Reply Data field will be empty.
2 The Qtype of the Query is unknown to the Responder. The Reply Data field will be empty.
141 Inverse Neighbor Discovery Solicitation Message 0
142 Inverse Neighbor Discovery Advertisement Message 0
143 Multicast Listener Discovery (MLDv2) reports[4]
144 Home Agent Address Discovery Request Message 0
145 Home Agent Address Discovery Reply Message 0
146 Mobile Prefix Solicitation 0
147 Mobile Prefix Advertisement 0
148 Certification Path Solicitation (SEND)
149 Certification Path Advertisement (SEND)
151 Multicast Router Advertisement (MRD)
152 Multicast Router Solicitation (MRD)
153 Multicast Router Termination (MRD)
155 RPL Control Message
160 Extended Echo Request[5] 0 Request Extended Echo
161 Extended Echo Reply[5] 0 No Error
1 Malformed Query
2 No Such Interface
3 No Such Table Entry
4 Multiple Interfaces Satisfy Query
200 Private experimentation
201 Private experimentation
255 Reserved for expansion of ICMPv6 informational messages

Note that the table above is not comprehensive. The current complete list of assigned ICMPv6 types can be found at this link: IANA: ICMPv6 Parameters.

Checksum

[edit]

ICMPv6 provides a minimal level of message integrity verification by the inclusion of a 16-bit checksum in its header. The checksum is calculated starting with a pseudo-header of IPv6 header fields according to the IPv6 standard,[6] which consists of the source and destination addresses, the packet length and the next header field, the latter of which is set to the value 58. Following this pseudo header, the checksum is continued with the ICMPv6 message. The checksum computation is performed according to Internet protocol standards using 16-bit ones' complement summation, followed by a final ones' complement of the checksum itself and inserting it into the checksum field.[7] Note that this differs from the way it is calculated for IPv4 in ICMP, but is similar to the calculation done in TCP.

ICMPv6 pseudo-header
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Source Address
4 32
8 64
12 96
16 128 Destination Address
20 160
24 192
28 224
32 256 ICMPv6 Length
36 288 Zeroes Next Header (58)

Format

[edit]

The payload of an ICMPv6 message varies according to the type of message being sent. It begins at bit 32 immediately after the header described above. For some messages such as destination unreachable or time exceeded there is no defined message body.

Destination Unreachable
Bit offset 0–7 8–15 16–31
0 1 Code Checksum
32 Unused
64 Message body (Variable Size)
Time Exceeded
Bit offset 0–7 8–15 16–31
0 3 Code Checksum
32 Unused
64 Message body (Variable Size)

Others define a use only for the first four bytes of the body with no other defined content:

Packet Too Big
Bit offset 0–7 8–15 16–31
0 2 0 Checksum
32 MTU
64 Message body (Variable Size)
Parameter Problem
Bit offset 0–7 8–15 16–31
0 4 Code Checksum
32 Pointer
64 Message body (Variable Size)
Echo Request
Bit offset 0–7 8–15 16–31
0 128 0 Checksum
32 Identifier Sequence Number
64 Data (Variable Size)
Echo Reply
Bit offset 0–7 8–15 16–31
0 129 0 Checksum
32 Identifier Sequence Number
64 Data (Variable Size)

In the case of NDP messages the first four bytes are either reserved or used for flags/hoplimit. While the rest of the body has unspecified structured data:

Router Solicitation
Bit offset 0–7 8–15 16–31
0 133 0 Checksum
32 Reserved
64 Options (Variable Size)
Router Advertisement
Bit offset 0–7 8–15 16–31
0 134 0 Checksum
32 Cur Hop Limit Managed Address Flag Other Configuration Flag Reserved Router Lifetime
64 Reachable Time
96 Retrans Time
128 Options (Variable Size)
Neighbor Solicitation
Bit offset 0–7 8–15 16–31
0 135 0 Checksum
32 Reserved
64 Target Address (16 bytes)
192 Options (Variable Size)
Neighbor Advertisement
Bit offset 0–7 8–15 16–31
0 136 0 Checksum
32 From Router (R) Solicited Flag(S) Override(O) Reserved
64 Target Address (16 bytes)
192 Options (Variable Size)

For a redirect the first bytes of the message body are reserved but not used. This is followed by a Target and destination address. Unspecified options can be attached to the end:

ICMPv6 Redirect
Bit offset 0–7 8–15 16–31
0 137 0 Checksum
32 Reserved
64 Target Address (16 bytes)
192 Destination Address (16 bytes)
320 Options (Variable Size)

Message processing

[edit]

When an ICMPv6 node receives a packet, it must undertake actions that depend on the type of message. The ICMPv6 protocol must limit the number of error messages sent to the same destination to avoid network overloading. For example, if a node continues to forward erroneous packets, ICMP will signal the error to the first packet and then do so periodically, with a fixed minimum period or with a fixed network maximum load. An ICMP error message must never be sent in response to another ICMP error message.

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

ICMPv6

View on Grokipedia
from Grokipedia
ICMPv6, or version 6, is a supporting protocol within the specifically designed for use with version 6 (), enabling IPv6 nodes to report errors encountered during packet processing and to execute essential internet-layer functions such as diagnostics. Defined in RFC 4443, which obsoletes the earlier RFC 2463, ICMPv6 serves as the successor to ICMP for IPv4 but incorporates IPv6-specific adaptations. It supports integration with the (NDP) defined in RFC 4861 for tasks like address resolution and duplicate address detection. Unlike its IPv4 counterpart, ICMPv6 messages are transported directly after the IPv6 header and any extension headers, using Next Header value 58, and include a checksum computed over a pseudo-header that accounts for IPv6 addressing. ICMPv6 messages follow a standardized format consisting of an 8-bit Type field (0–255) to classify the message, an 8-bit field for further specification, a 16-bit for integrity verification, and a variable-length message body that carries additional data or the original invoking packet. Messages are categorized into two primary classes: error messages (Types 0–127), which inform the sender of delivery or processing issues without generating further errors from error messages themselves, and informational messages (Types 128–255), which facilitate diagnostics and other non-error communications. Key error message types include Destination Unreachable (Type 1), signaling failures like no route to destination (Code 0); Packet Too Big (Type 2), aiding by reporting limits; Time Exceeded (Type 3), indicating hop limit exhaustion (Code 0) or fragment reassembly timeouts (Code 1); and Parameter Problem (Type 4), highlighting unrecognized header fields or erroneous parameters. Among informational messages, the Echo Request (Type 128) and Echo Reply (Type 129) form the basis for the IPv6 ping utility, allowing network reachability testing by echoing back supplied data. Beyond basic error reporting and diagnostics, ICMPv6 plays a pivotal role in operations through its embedding in NDP (defined in RFC 4861), where specific message types support router discovery, neighbor solicitation, and redirect functions essential for autoconfiguration and efficient packet routing in IPv6 networks. This integration underscores ICMPv6's expanded scope compared to ICMPv4, making it indispensable for robust IPv6 deployment.

Introduction

Definition and Purpose

ICMPv6, or version 6, is a core supporting protocol within the suite, assigned the Next Header value of 58 in the IPv6 header. It serves primarily to report errors encountered during the processing of IPv6 datagrams and to facilitate diagnostic functions essential for network operation. Unlike transport protocols, ICMPv6 operates at the network layer to convey control messages that help maintain the reliability and efficiency of IPv6 communications. The protocol's key purposes include delivering error messages, such as those indicating destination unreachable, packet too big, time exceeded, or parameter problems, which inform senders of issues in datagram transmission. It also supports informational and query messages, exemplified by echo request and echo reply, enabling network diagnostics like reachability testing. Furthermore, ICMPv6 underpins higher-level protocols by providing mechanisms for path (MTU) discovery through packet too big messages and neighbor discovery via specialized message types in the (NDP). ICMPv6 plays a vital role in network management, enabling troubleshooting of connectivity issues, notification of congestion, and support for IPv6-specific features such as stateless autoconfiguration. These functions ensure robust error handling and adaptive routing in modern networks. Defined primarily in RFC 4443 (2006), ICMPv6 messages are encapsulated directly within IPv6 packets, without an intervening , allowing seamless integration into the .

Historical Development and Standards

ICMPv6 originated as an integral component of the protocol suite, developed in the mid-1990s by the (IETF) through its IP Next Generation (IPng) working group to provide error reporting and diagnostic functions tailored to IPv6, succeeding the ICMP protocol for IPv4. The IPng effort, formalized in recommendations published in early 1995, addressed the limitations of IPv4, including address exhaustion, by designing a new protocol family that included ICMPv6 from the outset. The initial specification for ICMPv6 appeared in RFC 1885, published in December 1995, as part of the core protocol documents. Key milestones in ICMPv6's standardization followed the evolution of itself. Refinements to the protocol were incorporated in RFC 2463, released in December 1998, which updated the specification and provided a more mature definition of ICMPv6 messages. This was superseded by RFC 4443 in March 2006, establishing the current baseline standard for ICMPv6 by clarifying message formats, processing rules, and integration requirements while obsoleting RFC 2463. Subsequent updates addressed specific enhancements, such as mechanisms relying on ICMPv6's Packet Too Big message, initially detailed in RFC 1981 from August 1996 and further integrated with neighbor discovery in RFC 4861 from September 2007; extended echo request and reply options for advanced diagnostics were added in RFC 8335 in March 2018. More recent advancements have extended ICMPv6's role in modern deployments. In November 2024, RFC 9685 introduced listener subscription options for IPv6 , enabling efficient and address handling via ICMPv6 extensions. Complementing this, RFC 9673, published in October 2024, refined IPv6 hop-by-hop options processing procedures, ensuring ICMPv6 compatibility with emerging network behaviors. The (IANA) maintains the official registry for ICMPv6 parameters, assigning message types in the range 0-255, with types 0-127 designated for error messages and 128-255 for informational and query messages. Unlike its predecessor ICMPv4, ICMPv6 was engineered from the ground up to support 's 128-bit address architecture and to remove reliance on broadcast mechanisms, instead leveraging for functions like neighbor discovery.

Protocol Fundamentals

Integration with IPv6

ICMPv6 messages are encapsulated directly within IPv6 packets, serving as the following the header and any preceding extension headers, with the Next Header field set to the protocol number 58 to identify the ICMPv6 protocol. Unlike some upper-layer protocols, the ICMPv6 computation incorporates a pseudo-header derived from header fields—such as source and destination addresses, payload length, and the value 58 in the Upper Layer Packet Length field—but does not include the full IPv6 header itself. As an integral component of the IPv6 protocol suite, ICMPv6 is utilized by all IPv6 nodes, including hosts and routers, to perform essential error reporting and diagnostic functions, ensuring reliable network operation. Every IPv6 implementation is required to fully support ICMPv6; this mandatory inclusion is necessary for basic IPv6 connectivity and functionality. ICMPv6 interacts closely with IPv6 header mechanisms, including extension headers, fragmentation, and routing processes, to report errors such as reassembly timeouts via Time Exceeded messages or routing failures through Destination Unreachable messages. It also enables critical features like Path MTU Discovery (PMTUD) by conveying Packet Too Big messages that inform senders of the maximum transmittable unit along a path, allowing dynamic adjustment of packet sizes to avoid fragmentation. In processing IPv6 hop-by-hop options, routers may optionally generate ICMPv6 Parameter Problem messages (Code 2) when encountering unrecognized options in the Hop-by-Hop Options header, facilitating error reporting as defined in updated IPv6 procedures. ICMPv6 leverages IPv6's Traffic Class field for prioritization of diagnostic messages and the Flow Label for identifying packet flows during transmission, ensuring these control messages receive appropriate handling within the network stack.

Comparison to ICMPv4

ICMPv6 represents a significant evolution from ICMPv4, designed to address the architectural changes in IPv6 while maintaining the core purpose of error reporting and diagnostics. Like ICMPv4, which is required for all IPv4 implementations per RFC 1122, ICMPv6 is mandatory for all IPv6 nodes, ensuring consistent support for essential network functions across the protocol stack. This integration stems from IPv6's streamlined design, where ICMPv6 messages are encapsulated directly within IPv6 packets using Next Header value 58, without the need for separate IP-layer checksums over the ICMP header, as IPv6 headers already include their own checksum for integrity. A key design improvement in ICMPv6 is the checksum calculation, which incorporates an IPv6 pseudo-header including the source and destination addresses, upper-layer packet length, and zero fields, providing enhanced protection against misdelivery compared to ICMPv4's checksum that covers only the ICMP message itself. This change eliminates vulnerabilities associated with excluding IP header fields and better suits IPv6's 128-bit addressing, allowing error messages to include full address information without truncation or fragmentation issues that could arise in ICMPv4 due to 32-bit limits. Additionally, ICMPv6 replaces IPv4's reliance on broadcast addresses for certain operations with multicast addressing, reducing network overhead and enabling more efficient group communications in IPv6 environments. Functionally, ICMPv6 expands beyond ICMPv4 by subsuming roles previously handled by separate protocols: Multicast Listener Discovery (MLD), which manages multicast group memberships, uses ICMPv6 message types 130–132, effectively replacing the standalone (IGMP) of IPv4. Similarly, the (NDP) for address resolution and router discovery employs ICMPv6 types 133–137, supplanting the (ARP) and introducing capabilities like router advertisements that have no direct ICMPv4 equivalent. These expansions make ICMPv6 a more comprehensive control protocol, integral to 's autoconfiguration and mobility features. ICMPv6 message types are not backward-compatible with ICMPv4, requiring distinct handling in dual-stack environments where IPv4 and traffic coexist. For instance, ICMPv4's Type 3 (Destination Unreachable) message is mapped to ICMPv6 Type 1 with various codes (e.g., no route to destination as Code 0) or even Type 2 (Packet Too Big) for fragmentation-related issues, reflecting 's end-to-end fragmentation model where routers do not fragment packets. Time Exceeded messages follow a similar pattern, with ICMPv4 Type 11 translating to ICMPv6 Type 3, but -specific codes address extended features like header extensions. In translation scenarios, such as stateless IP/ICMP conversion, these mappings ensure but highlight the protocols' structural divergences, necessitating protocol-specific processing to avoid errors.

Message Structure

General Header Format

All ICMPv6 messages share a common fixed header format consisting of four octets, followed by a variable-length message body. This 4-byte header includes an 8-bit Type field, an 8-bit field, and a 16-bit field. The Type field determines the primary category and function of the message, with values ranging from 0 to 255; specifically, values 0 through 127 are for error messages, which must not trigger the generation of additional messages to prevent error loops, while values 128 through 255 are designated for informational or query messages, which may be nested within other messages. The field provides further specificity within a given Type, also spanning 0 to 255, allowing for subtypes or additional parameters relevant to the message's purpose. The field serves as the primary mechanism, covering the entire ICMPv6 message (header and body) along with a pseudo-header derived from the enclosing . The body follows the header and varies in length from 0 to 65,535 bytes, depending on the type and requirements. For messages, the body typically includes as much of the original invoking packet as possible—starting with the header of the erroneous packet followed by subsequent bytes—to provide context for the condition, though truncated if necessary to fit within the packet's constraints. Informational messages may include arbitrary data or additional fields specific to their function, such as identifiers or sequence numbers. Unlike the header, the body lacks a dedicated length indicator; its size is instead inferred from the Payload Length field in the enclosing header, which encompasses the entire ICMPv6 . The overall ICMPv6 , including header and body, is limited by the path's minimum MTU of 1280 octets, ensuring compatibility across networks. To illustrate the header structure:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | [Code](/page/Code) | [Checksum](/page/Checksum) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Body (variable)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | [Code](/page/Code) | [Checksum](/page/Checksum) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Body (variable)

This layout ensures a compact, extensible where the fixed header provides essential and categorization information, while the body accommodates type-specific content.

Checksum Calculation

The ICMPv6 checksum is a 16-bit one's complement value computed over the entire ICMPv6 message, including its header and body, prepended by a pseudo-header derived from the header fields. This mechanism ensures the integrity of the message during transmission and verifies that it is destined for the correct recipient, incorporating addresses to mitigate off-path attacks that could otherwise forge messages. Unlike the ICMPv4 checksum, which does not include IP addresses, the ICMPv6 approach integrates these elements directly into the computation for enhanced . The pseudo-header used in the checksum calculation is 40 bytes long and consists of the following fields, as defined for upper-layer protocols in :
FieldSize (bits)Description
Source Address128IPv6 source address from the packet.
Destination Address128IPv6 destination address from the packet.
Upper-Layer Packet Length32Length of the ICMPv6 message (header plus body), equivalent to the IPv6 Payload Length minus any extension headers.
Zero24Set to zero.
Next Header8Set to 58, indicating ICMPv6.
During computation, the ICMPv6 checksum field itself is set to zero, and the pseudo-header is logically prepended to the ICMPv6 message without being transmitted. If the total length of the pseudo-header plus ICMPv6 message is odd, a padding byte of zero is appended virtually for the calculation only. The is generated using the standard one's complement : the 16-bit words of the prepended are summed, with any carry from the most significant bit added back to the least significant bit, and the result is then bitwise complemented (one's complement). For verification at the receiver, the process is repeated including the received checksum value; a correct checksum yields a result of zero. This can be expressed as: Checksum=∼(∑i=1nwi)\text{Checksum} = \sim \left( \sum_{i=1}^{n} w_i \right) where wiw_i are the 16-bit words from the pseudo-header and ICMPv6 message (with checksum field zeroed), the sum includes wrap-around of carries, nn is the number of words (after padding if necessary), and ∼\sim denotes bitwise NOT.

Message Types

Error Messages

ICMPv6 error messages, identified by types in the range 0 through 127, are used to report problems encountered in the forwarding process, local delivery, or processing of IPv6 packets. These messages inform the sender of issues such as unreachable destinations or invalid headers, enabling corrective actions like rerouting or retransmission. Unlike informational messages, error messages carry as much of the original (invoking) packet as possible to aid diagnosis, typically up to 1280 bytes or the full packet if smaller, while adhering to IPv6 minimum MTU requirements. The Destination Unreachable message (Type 1) indicates that a packet cannot be delivered to its destination for reasons other than congestion. As of November 2025, IANA has assigned the following codes: 0 (no route to destination), 1 (communication administratively prohibited), 2 (beyond scope of source address), 3 (address unreachable), 4 ( unreachable), 5 (source address failed ingress/egress policy), 6 (reject route to destination), 7 (error in Header), and 8 (headers too long). Additional codes may be assigned in the future. Although Code 4 (port unreachable) is intended for transport protocols like UDP/TCP with closed ports, it is commonly returned by IPv6 firewalls (e.g., ip6tables, UFW) when rejecting ICMPv6 Echo Request packets (ping6) using a default deny action with --reject-with icmp6-port-unreachable, even though ICMPv6 has no ports. This results in the "Destination unreachable: Port unreachable" message and is frequent in strict IPv6 firewall policies, VPNs/tunnels (e.g., 6in4, Mullvad), or misconfigured routers blocking ICMPv6 traffic. This message is generated by routers or hosts when forwarding or delivery fails, excluding cases involving or broadcast-like addresses. The Packet Too Big message (Type 2, Code 0) notifies the sender that a packet exceeds the MTU of the next link in the path. It includes the MTU value of that link in its data field, which is essential for (PMTUD) in , where end hosts must adjust packet sizes to avoid fragmentation—unlike IPv4, where fragmentation is handled by routers and PMTUD is optional. This message is sent by routers upon encountering an oversized packet and includes the invoking packet for context. An extended variant exists as Type 101 (RFC 6946). Time Exceeded (Type 3) reports when the processing time for a packet expires. Code 0 signifies that the Hop Limit field reached zero during transit, preventing loops, while Code 1 indicates a fragment reassembly timeout at the destination. Routers decrement the Hop Limit and generate this message if it hits zero; hosts do the same for reassembly failures. The message embeds the original packet to show the point of failure. Parameter Problem (Type 4) alerts the sender to errors in the packet's header fields or options that prevent proper processing. Codes include 0 (erroneous header field, with a pointer to the octet causing the issue), 1 (unrecognized Next Header type), and 2 (unrecognized IPv6 option encountered). Generated by nodes unable to parse the packet due to these issues, it includes the invoking packet and a 32-bit pointer to the problematic location. Additional error message types include Type 100 (Extended Destination Unreachable, providing more detailed error information) and Type 101 (Extended Packet Too Big, for advanced PMTUD scenarios), defined in RFC 6946. Type 127 is reserved. ICMPv6 error messages are generated only in response to unicast packets (with limited exceptions for certain multicast scenarios defined elsewhere in the protocol) and must not be sent for multicast packets, broadcast addresses, or in reply to other ICMPv6 error messages to avoid infinite loops or amplification. The message integrity is ensured via a checksum covering the ICMPv6 header and data. These mechanisms are vital for robust IPv6 operation, particularly PMTUD, which relies on error feedback for efficient transmission.

Informational and Query Messages

Informational and query messages in ICMPv6 are distinguished by type values ranging from 128 to 255, serving purposes such as diagnostics, confirmation, and protocol-specific queries without indicating errors. These messages support essential functions like path discovery and group management, and they may indirectly elicit error messages (e.g., Time Exceeded, type 3) when used with varying hop limits, facilitating tools like for route tracing. Unlike error messages (types 0-127), informational messages are not generated in response to malformed packets but are initiated for proactive operations. The Echo Request message (type 128, code 0) is a fundamental diagnostic tool analogous to the IPv4 ping, sent to test reachability and measure round-trip times. Its format includes the standard ICMPv6 header followed by an identifier (16 bits) and sequence number (16 bits) in the body, with optional data that is echoed back unchanged. Upon receipt, the target node must respond with an Echo Reply unless rate-limited. The Echo Reply message (type 129, code 0) directly mirrors the Echo Request to confirm successful delivery and provide timing data. It replicates the request's identifier, sequence number, and data fields exactly, enabling the sender to verify connectivity and calculate latency. In practice, if firewalls or hosts block ICMPv6 Echo Requests without an explicit allow rule for Types 128 and 129, the sender may receive a Destination Unreachable (Type 1, Code 4 - Port Unreachable) response instead of an Echo Reply or no response, leading to the common "Destination unreachable: Port unreachable" error in ping6 diagnostics. This occurs frequently in configurations using netfilter/ip6tables where the REJECT target defaults to --reject-with icmp6-port-unreachable, reusing the port unreachable code (intended for UDP/TCP closed ports) for blocked ICMPv6 packets. The Group Membership Query message (type 130) is employed in Multicast Listener Discovery (MLD) to poll hosts for their multicast group memberships. With code 0 for a general query (querying all groups), it includes fields such as Maximum Response Code (for timing responses), a multicast address (all zeros for general queries), and optional source addresses for specific queries; the sender sets the IPv6 Hop Limit to 1 and includes a Router Alert option. Neighbor Discovery Protocol (NDP) utilizes several informational message types for address resolution and router discovery on IPv6 links. Router Solicitation (type 133, code 0) prompts routers to send advertisements and includes options like the source link-layer address if the IPv6 source is specified. Router Advertisement (type 134, code 0) conveys network parameters such as prefixes and lifetimes, with options for MTU and link-layer addresses. Neighbor Solicitation (type 135, code 0) resolves a target's link-layer address or confirms reachability, featuring a Target Address field and options like the source link-layer address. Neighbor Advertisement (type 136, code 0) responds to solicitations or announces changes, including the Target Address and flags (e.g., Router, Solicited), plus a target link-layer address option. Redirect (type 137, code 0) informs a host of a better next-hop router, specifying Target and Destination Addresses with a Redirected Header option. Among other informational types, the Multicast Router Advertisement (type 151, code 0) enables hosts to discover routers on a link without relying on NDP. Its format follows the ICMPv6 header with an Advertisement Interval field and a single octet for robustness, sent periodically from routers. Types 200 and 201 are reserved for private experimentation, while others in 202-254 may be assigned for future use by the IETF; type 255 is reserved.

Protocol Processing

Transmission and Reception Rules

ICMPv6 transmission rules specify that error messages must only be generated in response to non-ICMPv6 packets received by an node, ensuring that ICMPv6 messages themselves do not trigger further errors to avoid infinite loops. To further prevent such loops, nodes are required to rate-limit error message transmissions using a algorithm. Additionally, when sending an , the node includes as much of the invoking packet as possible—up to 1280 bytes, which corresponds to the minimum IPv6 MTU—to provide sufficient context for the recipient. On the reception side, all nodes are obligated to process incoming ICMPv6 messages, validating the and discarding any message that fails this check to maintain . For error messages, hosts typically forward the information to the relevant upper-layer protocols or applications; for instance, upon receiving a Packet Too Big message, the sender adjusts its path MTU estimate to avoid future fragmentation issues. Node-specific behaviors differentiate processing between hosts and routers: routers are responsible for generating certain error types, such as Time Exceeded messages during packet forwarding, while hosts must suppress error messages in response to packets sent to multicast or broadcast addresses, except in defined cases. Per the ICMPv6 specification, error messages are not generated for fragmented packets except for the first fragment, as subsequent fragments lack the upper-layer information needed for accurate error reporting. Redirect messages, which inform a host of a better next-hop router, are only sent by routers on the same link as the receiving host. Upon reception, nodes handle specific ICMPv6 messages accordingly: for Redirect messages, the receiving host updates its to reflect the suggested better route, improving local traffic efficiency.

Rate Limiting and Congestion Control

ICMPv6 implementations must incorporate to prevent network overload from excessive error messages, which could otherwise lead to amplification attacks or unnecessary bandwidth consumption. According to RFC 4443, nodes are required to limit the rate at which they originate ICMPv6 error messages, with a recommended algorithm using parameters such as a bucket size of 10 tokens and a replenishment rate of 10 tokens per second for small- to medium-sized devices; these parameters should be configurable to suit network conditions. These limits help ensure that repeated errors do not overwhelm the network, while global limits apply to query messages like Echo Requests to curb potential floods. For congestion avoidance, ICMPv6 error messages must not be generated in response to packets dropped due to , as this prevents further exacerbating the issue; instead, upper-layer protocols like TCP handle congestion control. IPv6's Traffic Class field in the packet header can be used to deprioritize ICMPv6 messages during periods of high congestion, allowing routers to drop or delay them preferentially over critical traffic, though specific prioritization values are implementation-dependent. Since ICMPv6 does not support source quench messages, error suppression is mandatory in such scenarios to maintain stability. Rate limiting mechanisms extend to both error and informational/query messages, with algorithms like token buckets accommodating short bursts while enforcing sustained limits; excessive rates should be logged for monitoring and potential anomaly detection. RFC 9099 provides updated guidance for IPv6 operational security, emphasizing ICMPv6 throttling through control plane policers and rate limiters based on traffic baselines to preserve router resources and mitigate denial-of-service risks. For Neighbor Discovery Protocol (NDP) messages, which rely on ICMPv6, additional limits include random delays of up to 1 second for Router Solicitations to avoid synchronization, retransmission timers defaulting to 1 second, and restrictions on multicast Router Advertisements to no more than one every 3 seconds. These NDP-specific controls complement general ICMPv6 rate limiting, applying exponential backoff implicitly through adjustable timers for repeated probes.

Applications

Neighbor Discovery Protocol (NDP)

The Neighbor Discovery Protocol (NDP) is a core component of IPv6 that facilitates address resolution, router discovery, and other link-local communication functions, utilizing ICMPv6 message types 133 through 137 to perform these operations over the local network segment. It replaces the Address Resolution Protocol (ARP) used in IPv4 for mapping IPv6 addresses to link-layer addresses and extends router discovery beyond IPv4's limited capabilities by providing hosts with prefix information, default router details, and other network parameters. These ICMPv6 informational messages enable hosts and routers to dynamically discover and maintain neighbor relationships without relying on broadcast mechanisms, promoting efficiency in modern networks. Key NDP messages include Router Solicitation (type 133), sent by hosts to promptly request router information from neighboring routers, and Router Advertisement (type 134), which routers transmit periodically or in response to solicitations to announce their presence, supply on-link prefixes, and indicate default router preferences. Neighbor Solicitation (type 135) and Neighbor Advertisement (type 136) handle address resolution and confirmation; for instance, a solicitation is sent to the derived from the target's to resolve its link-layer address, with the advertisement providing the response. Additionally, Redirect (type 137) allows routers to inform hosts of a more optimal next-hop address for a specific destination, improving efficiency. NDP messages carry optional Type-Length-Value (TLV) options to convey additional details, such as the Source Link-Layer Address (type 1) and Target Link-Layer Address (type 2) for direct hardware address inclusion, the MTU option (type 5) to specify the link's (commonly 1500 bytes on Ethernet links), and Prefix Information (type 3) to detail prefixes for on-link determination and autoconfiguration. The protocol is defined in RFC 4861, published in September 2007 and obsoleting RFC 2461, with updates in RFC 9685 (November 2024) to support listener subscriptions for and addresses via extended registration options, enhancing applicability in low-power networks. Stateless address autoconfiguration, as specified in RFC 4862, allows hosts to derive global addresses by combining prefixes from Router Advertisements with the interface identifier (e.g., EUI-64 format), enabling plug-and-play configuration without DHCP. A critical process in NDP is Duplicate Address Detection (DAD), where a host sends a Neighbor Solicitation to its own tentative IPv6 address (using the unspecified address as source) to verify uniqueness before assignment, preventing conflicts on the link. If no Neighbor Advertisement is received within the retransmission timer (default 1 second), the address is considered unique and installed. For security, NDP is vulnerable to spoofing and denial-of-service attacks, but SEcure Neighbor Discovery (SEND), outlined in RFC 3971, mitigates these by incorporating cryptographic methods like Cryptographically Generated Addresses (CGAs) and digital signatures to authenticate messages and options.

Multicast Listener Discovery (MLD)

Multicast Listener Discovery (MLD) is a protocol used in networks to manage group memberships, enabling hosts to inform neighboring routers about their interest in receiving traffic for specific addresses. It serves as the equivalent of the (IGMP) used in IPv4, and it operates by embedding its messages within ICMPv6 packets to facilitate efficient group join, leave, and query operations. MLD relies on the informational message types of ICMPv6 for its queries and reports, ensuring seamless integration with the overall ICMPv6 framework. The protocol has two primary versions: MLDv1, specified in RFC 2710 published in 1999, which provides basic any-source support, and MLDv2, defined in RFC 3810 from 2004, which introduces advanced features like source-specific filtering to allow hosts to specify interest in traffic from particular sources within a group. Both versions utilize specific ICMPv6 message types: type 130 for Multicast Listener Queries, type 131 for MLDv1 Listener Reports, type 132 for MLDv1 Listener Done messages, and type 143 for MLDv2 Listener Reports. These types enable routers to discover which addresses are of interest to attached hosts and to maintain up-to-date group membership information. In operation, hosts send unsolicited Listener Reports to join a multicast group, indicating their desire to receive traffic for one or more addresses, while routers periodically transmit general Multicast Listener Queries to all hosts on a link to verify ongoing memberships. Specific Queries can target individual groups or sources in MLDv2, allowing for more precise filtering and reducing unnecessary traffic. When a host leaves a group in MLDv1, it sends a Done to prompt the router for a query, whereas MLDv2 handles leaves more efficiently through included state change records in reports. The querier router on a link is elected based on the lowest among potential queriers, and listener reports are multicast to the all-MLDv2-routers address (ff02::16) to ensure reliable delivery to relevant routers. MLD integrates with multicast routing protocols such as Protocol Independent Multicast (PIM) to propagate group information across the network, enabling efficient multicast tree construction. MLDv2 extends functionality beyond MLDv1 by supporting (SSM), where hosts can filter traffic to include or exclude packets from designated sources, enhancing and bandwidth efficiency in scenarios like video streaming or collaborative applications. For interoperability in dual-stack environments with IPv4 and , RFC 4604 defines mappings between MLDv2 and IGMPv3, allowing shared infrastructure without protocol conflicts.

Security Considerations

Common Vulnerabilities and Attacks

ICMPv6's integration with IPv6 protocols exposes it to several vulnerabilities, particularly in (NDP) messages, where the lack of built-in authentication allows attackers to forge packets. Neighbor spoofing occurs when an attacker sends forged Neighbor Solicitation (NS) or Neighbor Advertisement (NA) messages to impersonate a legitimate host, enabling traffic interception or denial of service by associating the attacker's link-layer address with a victim's . Router Advertisement (RA) floods involve overwhelming a network with spoofed RA messages to advertise a rogue router, redirecting traffic to the attacker and disrupting legitimate routing. Duplicate Address Detection (DAD) can be bypassed through attacks where a malicious node responds to DAD probes with forged NA messages, allowing address theft and subsequent . Error messages in ICMPv6 are susceptible to abuse for denial-of-service (DoS) attacks, as they lack inherent in some implementations. Floods of ICMPv6 Packet Too Big messages can exhaust resources through excessive processing. Parameter Problem messages, sent when a node encounters unrecognized options or headers, can be weaponized to trigger excessive processing of malformed extension headers, leading to resource exhaustion on vulnerable devices. Query messages provide avenues for reconnaissance and disruption, leveraging ICMPv6's diagnostic functions. Echo Request messages enable by eliciting responses that reveal active hosts, often used in to identify infrastructure. Smurf-like attacks adapt IPv4 techniques to IPv6 by sending spoofed Echo Requests to multicast addresses like FF02::1, prompting multiple responses that flood the spoofed victim. Redirect messages can be forged to enable man-in-the-middle (MITM) attacks or DoS by altering host . RFC 9099 outlines IPv6-specific risks amplified in ICMPv6, such as vulnerabilities in extension header parsing that enable targeted DoS through malformed error generation. Additional threats include man-in-the-middle (MITM) attacks via forged Redirect messages, which trick hosts into sending traffic through the attacker for or modification. on unencrypted ICMPv6 diagnostics, such as Replies or error messages, allows passive attackers on the same link to gather and host information without active intervention.

Mitigation Techniques

To mitigate vulnerabilities in ICMPv6, network administrators should implement strict filtering rules at firewalls and border routers, allowing only essential message types such as Destination Unreachable (type 1), Packet Too Big (type 2), Time Exceeded (type 3), Parameter Problem (type 4), Echo Request (type 128), Echo Reply (type 129), and Neighbor Discovery messages (types 133-137), while blocking unnecessary ones like redirects from untrusted sources. This approach ensures that critical functions like (PMTUD) remain operational without exposing the network to exploitation. RFC 9099 provides guidance on least-privilege filtering policies that balance security with the need to support PMTUD and other legitimate ICMPv6 uses. Note that authentication for ICMPv6 is optional in implementations, often requiring manual key configuration for NDP protection as per RFC 6434. Cryptographic protections enhance the authenticity and integrity of ICMPv6 messages, particularly for (NDP) components. The Secure Neighbor Discovery (SEND) protocol, defined in RFC 3971, uses Cryptographically Generated Addresses (CGA) and digital signatures to prevent spoofing of Router Advertisements and Neighbor Advertisements. Additionally, can be employed to authenticate ICMPv6 payloads, providing end-to-end protection against tampering or impersonation in scenarios where SEND is not feasible. Effective monitoring and are crucial for identifying and responding to potential ICMPv6-based threats. Tools like NDPMon can be deployed to monitor NDP traffic for irregularities, such as unexpected Router Advertisement floods, while RA Guard (RFC 7113) filters invalid Router Advertisements at the network edge to mitigate spoofing attempts. Rate-limiting ingress ICMPv6 messages helps prevent denial-of-service floods by capping the volume of incoming packets per source. IPv6-aware Intrusion Detection Systems (IDS) further support this by analyzing traffic patterns for deviations from normal ICMPv6 behavior. Broader best practices include disabling unnecessary ICMPv6 responses on hosts and routers to reduce the , such as turning off responses to Echo Requests from external sources unless required. Strict validation of ICMPv6 checksums during processing ensures that malformed packets are discarded early. RFC 4890 outlines updated security requirements for nodes, emphasizing these configurations to harden ICMPv6 implementations against common threats.

References

  1. https://datatracker.ietf.org/doc/html/rfc4443
  2. https://datatracker.ietf.org/doc/html/rfc4861
  3. https://www.iana.org/assignments/icmpv6-parameters
  4. https://datatracker.ietf.org/doc/html/rfc4443#section-2.1
  5. https://datatracker.ietf.org/doc/html/rfc4443#section-2.3
  6. https://datatracker.ietf.org/doc/html/rfc4443#section-2
  7. https://datatracker.ietf.org/doc/html/rfc4443#section-3.1
  8. https://datatracker.ietf.org/doc/html/rfc4443#section-3.2
  9. https://www.rfc-editor.org/rfc/rfc9673.html#section-5.2
  10. https://datatracker.ietf.org/doc/html/rfc1122
  11. https://www.rfc-editor.org/rfc/rfc4443
  12. https://linux.die.net/man/8/ip6tables
  13. https://datatracker.ietf.org/doc/html/rfc6554
  14. https://datatracker.ietf.org/doc/html/rfc8883
  15. https://datatracker.ietf.org/doc/html/rfc1981
  16. https://datatracker.ietf.org/doc/html/rfc6946
  17. https://datatracker.ietf.org/doc/html/rfc4443#section-3.3
  18. https://datatracker.ietf.org/doc/html/rfc4443#section-3.4
  19. https://datatracker.ietf.org/doc/html/rfc4443#section-2.4
  20. https://datatracker.ietf.org/doc/html/rfc4443#section-4.1
  21. https://datatracker.ietf.org/doc/html/rfc4443#section-4.2
  22. https://man7.org/linux/man-pages/man8/iptables-extensions.8.html
  23. https://datatracker.ietf.org/doc/html/rfc3810#section-5.1
  24. https://datatracker.ietf.org/doc/html/rfc3810#section-5.1.1
  25. https://datatracker.ietf.org/doc/html/rfc4861#section-4
  26. https://datatracker.ietf.org/doc/html/rfc4861#section-4.1
  27. https://datatracker.ietf.org/doc/html/rfc4861#section-4.2
  28. https://datatracker.ietf.org/doc/html/rfc4861#section-4.3
  29. https://datatracker.ietf.org/doc/html/rfc4861#section-4.4
  30. https://datatracker.ietf.org/doc/html/rfc4861#section-4.5
  31. https://datatracker.ietf.org/doc/html/rfc4286#section-5.1
  32. https://datatracker.ietf.org/doc/html/rfc4286#section-5.1.1
  33. https://datatracker.ietf.org/doc/html/rfc4443#section-3
  34. https://datatracker.ietf.org/doc/html/rfc2460
  35. https://datatracker.ietf.org/doc/html/rfc9099
  36. https://datatracker.ietf.org/doc/html/rfc9685
  37. https://datatracker.ietf.org/doc/html/rfc4862
  38. https://datatracker.ietf.org/doc/html/rfc3971
  39. https://datatracker.ietf.org/doc/rfc9099/
  40. https://datatracker.ietf.org/doc/rfc7707/
  41. https://core.ac.uk/download/pdf/78390261.pdf
  42. https://www.usenix.org/conference/usenixsecurity22/presentation/feng
Add your contribution
Related Hubs
User Avatar
No comments yet.