ICMPv6

{{Short description|Internet protocol used for error messages in network operations}}

{{Infobox networking protocol

| title = Internet Control Message Protocol for IPv6

| logo =

| logo alt =

| image = ICMP header - General-en.svg

| image alt =

| caption = General structure of ICMPv6 Messages

| is stack =

| abbreviation = ICMPv6

| purpose = Auxiliary Protocol for IPv6

| developer =

| date = {{Start date and age|1995|12| }}

| based on =

| influenced =

| osilayer = Network layer

| ports =

| rfcs = RFC 4443

| hardware =

}}

{{IPstack}}

Internet Control Message Protocol version 6 (ICMPv6) is the implementation of the Internet Control Message Protocol (ICMP) for Internet Protocol version 6 (IPv6).{{Ref RFC|4443}} 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.{{Ref RFC|8415|section=3}} 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

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 {{Mono|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).

{{APHD|start|title=ICMPv6 message}}

{{APHD|0|bits1=8|field1=Type|bits2=8|field2=Code|bits3=16|field3=Checksum}}

{{APHD|4|bits1=0|field1=Message body|background1=mistyrose}}

{{APHD|end}}

;{{APHD|def|name=Type|length=8 bits|text=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.}}

;{{APHD|def|name=Code|length=8 bits|text=The Code field value depends on the message type and provides an additional level of message granularity.}}

;{{APHD|def|name=Checksum|length=16 bits|text=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.{{Ref RFC|4443}} See below.}}

;{{APHD|def|name=Message body|length=Variable|text=Contents depends on the message.}}

=Types=

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.

class="wikitable"

! colspan="2" align="center"| Type

! colspan="2" align="center"| Code

ValueMeaningValueMeaning
colspan="4" align="center"| ICMPv6 Error Messages
rowspan=8| 1

|rowspan=8| 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

2Packet too big0
rowspan=2| 3

|rowspan=2| Time exceeded

| 0

| hop limit exceeded in transit

1

| fragment reassembly time exceeded

rowspan=3| 4

|rowspan=3| Parameter problem

| 0

| erroneous header field encountered

1

| unrecognized Next Header type encountered

2

| unrecognized IPv6 option encountered

100Private experimentation
101Private experimentation
127Reserved for expansion of ICMPv6 error messages
colspan="4" align="center"| ICMPv6 Informational Messages
128Echo Request0
129Echo Reply0
130Multicast Listener Query (MLD)0There 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

131Multicast Listener Report (MLD)0
132Multicast Listener Done (MLD)0
133Router Solicitation (NDP)0
134Router Advertisement (NDP)0
135Neighbor Solicitation (NDP)0
136Neighbor Advertisement (NDP)0
137Redirect Message (NDP)0
rowspan=3| 138

|rowspan=3| Router Renumbering{{Ref RFC|2894}}

| 0

| Router Renumbering Command

1

| Router Renumbering Result

255

| Sequence Number Reset

rowspan=3| 139

|rowspan=3| 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.

rowspan=3| 140

|rowspan=3| 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.

141Inverse Neighbor Discovery Solicitation Message0
142Inverse Neighbor Discovery Advertisement Message0
143Multicast Listener Discovery (MLDv2) reports{{Ref RFC|3810}}
144Home Agent Address Discovery Request Message0
145Home Agent Address Discovery Reply Message0
146Mobile Prefix Solicitation0
147Mobile Prefix Advertisement0
148Certification Path Solicitation (SEND)
149Certification Path Advertisement (SEND)
151Multicast Router Advertisement (MRD)
152Multicast Router Solicitation (MRD)
153Multicast Router Termination (MRD)
155RPL Control Message
160Extended Echo Request{{Ref RFC|8335}}

| 0

Request Extended Echo
rowspan=5| 161rowspan=5| Extended Echo Reply{{Ref RFC|8335}}

| 0

No Error
1Malformed Query
2No Such Interface
3No Such Table Entry
4Multiple Interfaces Satisfy Query
200Private experimentation
201Private experimentation
255Reserved 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: [https://www.iana.org/assignments/icmpv6-parameters IANA: ICMPv6 Parameters].

=Checksum=

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,{{Ref RFC|8200|section=8.1}} 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 {{Mono|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.{{Ref RFC|1071}} Note that this differs from the way it is calculated for IPv4 in ICMP, but is similar to the calculation done in TCP.

{{APHD|start|title=ICMPv6 pseudo-header}}

{{APHD|0|bits1=128|field1=Source Address}}

{{APHD|16|bits1=128|field1=Destination Address}}

{{APHD|32|bits1=32|field1=ICMPv6 Length}}

{{APHD|36|bits1=24|field1=Zeroes|bits2=8|field2=Next Header|value2=58}}

{{APHD|end}}

= Format =

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.

class="wikitable" style="text-align:center"

|+Destination Unreachable

Bit offsetcolspan="8" width="22%" | 0–7colspan="8" width="22%" | 8–15colspan="16" width="44%" | 16–31
0colspan="8" | 1colspan="8" | Codecolspan="16" | Checksum
32colspan="32" | Unused
64colspan="32" | Message body (Variable Size)

class="wikitable" style="text-align:center"

|+

Time Exceeded

Bit offsetcolspan="8" width="22%" | 0–7colspan="8" width="22%" | 8–15colspan="16" width="44%"| 16–31
0colspan="8"| 3colspan="8" | Codecolspan="16"| Checksum
32colspan="32"| Unused
64colspan="32"| Message body (Variable Size)

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

class="wikitable" style="text-align:center"

|+Packet Too Big

Bit offsetcolspan="8" width="22%" | 0–7colspan="8" width="22%" | 8–15colspan="16" width="44%"| 16–31
0colspan="8"| 2colspan="8" | 0colspan="16" | Checksum
32colspan="32"| MTU
64colspan="32"| Message body (Variable Size)

class="wikitable" style="text-align:center"

|+

Parameter Problem

Bit offsetcolspan="8" width="22%" | 0–7colspan="8" width="22%" | 8–15colspan="16" width="44%"| 16–31
0colspan="8"| 4colspan="8" | Codecolspan="16"| Checksum
32colspan="32" | Pointer
64colspan="32" | Message body (Variable Size)

class="wikitable" style="text-align:center"

|+

Echo Request

Bit offsetcolspan="8" width="22%" | 0–7colspan="8" width="22%" | 8–15colspan="16" width="44%"| 16–31
0colspan="8"| 128colspan="8" | 0colspan="16" | Checksum
32colspan="16"| Identifiercolspan="16 | Sequence Number
64colspan="32"| Data (Variable Size)

class="wikitable" style="text-align:center"

|+

Echo Reply

Bit offsetcolspan="8" width="22%" | 0–7colspan="8" width="22%" | 8–15colspan="16" width="44%"| 16–31
0colspan="8"| 129colspan="8"| 0colspan="16"| Checksum
32colspan="16"| Identifiercolspan="16" | Sequence Number
64colspan="32"| 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:

class="wikitable" style="text-align:center"

|+

Router Solicitation

Bit offsetcolspan="8" width="22%" | 0–7colspan="8" width="22%" | 8–15colspan="16" width="44%"| 16–31
0colspan="8"| 133colspan="8"| 0colspan="16"| Checksum
32colspan="32"| Reserved
64colspan="32"| Options (Variable Size)

class="wikitable" style="text-align:center"

|+

Router Advertisement

Bit offsetcolspan="8" width="22%" | 0–7colspan="8" width="22%" | 8–15colspan="16" width="44%"| 16–31
0colspan="8"| 134colspan="8"| 0colspan="16"| Checksum
32colspan="8"| Cur Hop Limitcolspan="1" | Managed Address Flagcolspan= "1"| Other Configuration Flagcolspan="6" | Reservedcolspan="16" | Router Lifetime
64colspan="32" | Reachable Time
96colspan="32" | Retrans Time
128colspan="32"| Options (Variable Size)

class="wikitable" style="text-align:center"

|+

Neighbor Solicitation

Bit offsetcolspan="8" width="22%" | 0–7colspan="8" width="22%" | 8–15colspan="16" width="44%"| 16–31
0colspan="8"| 135colspan="8"| 0colspan="16"| Checksum
32colspan="32" | Reserved
64colspan="32"| Target Address (16 bytes)
192colspan="32"| Options (Variable Size)

class="wikitable" style="text-align:center"

|+

Neighbor Advertisement

Bit offsetcolspan="8" width="22%" | 0–7colspan="8" width="22%" | 8–15colspan="16" width="44%"| 16–31
0colspan="8"| 136colspan="8"| 0colspan="16" | Checksum
32colspan="1" | From Router (R)colspan="1"| Solicited Flag(S)Override(O)colspan="30" | Reserved
64colspan="32" | Target Address (16 bytes)
192colspan="32" | 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:

class="wikitable" style="text-align:center"

|+

ICMPv6 Redirect

Bit offsetcolspan="8" width="22%" | 0–7colspan="8" width="22%" | 8–15colspan="16" width="44%"| 16–31
0colspan="8"| 137colspan="8"| 0colspan="16" | Checksum
32colspan="32" | Reserved
64colspan="32"| Target Address (16 bytes)
192colspan="32"| Destination Address (16 bytes)
320colspan="32"| Options (Variable Size)

Message processing

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

{{Reflist}}