ICMPv6 - Internet Control Message Protocol for IPv6

ICMPv6 is a "helper" protocol for IPv6. It is not part of IPv6 itself, but is used to control certain aspects of IPv6 traffic, and to provide diagnostic mechanisms and error messages related to IPv6. It was defined at the same time as IPv6, in RFC 1885, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", December 1995.

RFC 1885 was replaced by RFC 2463, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", December 1998. RFC 2463 was replaced by RFC 4443, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", April 2006, which is the current version. RFC 4443 was updated, but not replaced, by RFC 4884, "Extended ICMP to Support Multi-Part Messages", April 2007.

ICMPv6 has the same basic purpose as ICMPv4, but is a completely different protocol. ICMPv6 is more integral to IPv6 than ICMPv4 is to IPv4. You can block all ICMPv4 messages and IPv4 will still work fairly well. If you block all ICMPv6 messages, IPv6 cannot work. If you want to block pings, you should block just the Echo Request and Echo Reply messages, not all ICMPv6 messages. Unlike ICMPv4, there are a number of additional message types that are considered to be two other protocols (Neighbor Discovery protocol and Multicast Listener Discovery protocol), even though they use the same protocol number (58) and the same syntax as the basic ICMPv6 messages. In the Wireshark application, you must specify the protocol name "ICMPv6" to refer to all three protocols. The complete set of messages for protocol number 58 is split into three groups only to simplify discussions of IPv6. In reality those are all ICMPv6 messages.

Neighbor Discovery is currently specified in RFC 4861, "Neighbor Discovery for IPv6 Version 6 (IPv6)", September 2007. Multicast Listener Discovery is specified in RFC 2710, "Multicast Listener Discovery (MLD) for IPv6", October 1999 and RFC 3810, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", June 2004.

An ICMPv6 packet consists of an IPv6 Packet Header, optionally followed by one or more IPv6 Extension Headers, then an ICMPv6 message, which might include data in some cases. With ICMPv6 packets there is no Transport Layer header (UDP, TCP or SCTP). The Next Header field of the IPv6 Packet Header (or any Extension Header) contains the value 58 for an ICMPv6 message (versus 6 for TCP, 17 for UDP and 132 for SCTP).

There are a total of 6 ICMPv6 messages defined in RFC 4443 (compared to 11 for ICMPv4). An ICMPv6 message contains the Message Type in the first 8 bits of the message. The next 8 bits contains a Code, the meaning of which depends on the message type. A 16-bit checksum follows these two values. The basic messages defined in RFC 4443 (and their Message Types) are:

The first four are "error messages", and are sent in response to some error condition, such as being unable to deliver a packet onward. The last two are "informative messages" and are used for diagnostic purposes. In comparison to ICMPv4, Echo Request, Echo Reply, Time Exceeded, Parameter Problem and Destination Unreachable are still there in ICMPv6. Timestamp Request, Timestamp Reply, Information Request and Information Reply were dropped (they were rarely used in IPv4). Redirect is now part of Neighbor Discovery. Flow control (Source Quench) is done in a very different way in IPv6.

The ICMPv6 error messages return as much of the failed packet as will fit in the IPv6 minimum MTU (1280 bytes). This includes the IPv6 Packet Header, any Extension Packet Headers, any ICMPv6 or transport header, and as much of the data as will fit. In comparison, ICMPv4 error messages return only the IPv4 Packet Header and the following 64 bits (8 bytes).

ICMPv6 messages are sent only regarding the first (or only) fragment of IPv6 packets. No ICMPv6 message is sent in response to problems with another ICMPv6 message, which might otherwise lead to infinite regression.

 

ICMPv6 Checksums

The Checksum field contains a 16 bit value which is the ones' complement of the ones' complement sum of all 16-bit words in the ICMPv6 message (padded with a zero byte if needed to make an even number of bytes). If you do the ones' complement sum of all the 16 bit words in a received packet, you should get the result 0xffff (ones' complement "negative zero"). Any other result indicates one of more bits have been changed in route (due to noise or malicious attack). It is possible for certain error bit patterns to cancel out. An 8 bit checksum would detect about 99.6% of all random bit errors. The 16 bit checksum used will detect about 99.9985% of all random bit errors. However, anyone can calculate a new valid checksum from modified data, so it will not detect any malicious modifications to a packet. For ICMPv6 messages, unlike ICMPv4, the checksum calculation includes some fields from the IPv6 Packet Header in the calculation (this is called a "pseudo header").

 

Destination Unreachable error message 

When a router is unable to forward a packet for any reason, it returns a Packet Unreachable message to the source address in the failed packet (which should be the original sender). The reason for the failure is returned in the Code field. The syntax of the Destination Unreachable message is as follows:

icmpv6 destunreachable syntax

The Type field contains the value 1 for Destination Unreachable

The Code field contains one of the following values as to why the destination was unreachable:

 0 - No route to destination (e.g. no default route on node)
 1 - Forwarding administratively prohibited (e.g. firewall rule blocked packet)
 2 - Beyond the scope of the source address (link-local source, offlink dest.)
 3 - Address unreachable (catchall reason, if no other applies) 
 4 - Port unreachable (no socket awaiting data to that port)
 5 - Source address failed ingress/egress policy (filtering by source address)
 6 - Reject route to destination (router rejects all traffic for that prefix)
  
The Checksum field contains a standard IP 16 bit checksum. 
 
Bytes 4-7 are unused and must be set to zero.
 
As much of the failed packet as will fit in the minimum MTU (1280 bytes) is included starting at offset 8.
 

Packet Too Big error message 

This error message is sent by a router when a packet to be forwarded is larger than the MTU of the ongoing path. In IPv4, any node in the path can fragment a packet. In IPv6, only the originating node can fragment packets, as if every packet had the DF flag set. If the router cannot forward a packet because it is too big, it drops the packet and returns a Packet Too Big error message to the source address in the failed packet, which should be the original sender.
 
In IPv4, the Packet Too Big error message (actually a destination unreachable message code) does not inform the sender of the MTU of the ongoing path, so the sender has to try smaller values until the packet goes through. In IPv6, the MTU of the ongoing path is returned to the original sender, so the sender can immediately go to the maximum MTU (for that ongoing path).
 
The IPv6 Path MTU Discovery process sends a test packet to a destination node, decreasing the packet size until the packet is accepted by all intervening routers (i.e. is within the overall path MTU).
 
The Packet Too Big message syntax is as follows:
mtu msg

The Type field contains the value 2 for Packet Too Big.

The Code field must be set to zero.

The Checksum field contains a standard IP 16 bit checksum.
 
The MTU field contains the Maximum Transmission Unit of the next-hop link (no packets larger than this value can be forwarded down the ongoing path).
 
As much of the failed packet as will fit in the minimum MTU (1280 bytes) is included starting at offset 8.
 

Time Exceeded error message 

If a router receives a packet with a Hop Limit of zero, or if the Hop Limit is decremented to zero by the router, the router must discard the packet and return a Time Exceeded error message to the source address of the failed packet (which should be the original sender), with Code = 0.
 
If any node cannot reassemble a fragmented packet within a certain time limit (due to one or more missing fragments), it must discard what it has, and return a Time Exceeded error message to the source address of the failed packet (which should be the original sender), with Code = 1. In IPv6, usually only the final destination node reassembles fragmented packets.
 
The Time Exceeded error message syntax is as follows:
icmpv6 error syntax

The Type field contains the value 3 for Time Exceeded

The Code field contains one of the following values as to why the destination was unreachable:

 0 - Hop Limit exceeded in transit (only returned by routers)
 1 - Packet reassembly time limit reached (can be returned by any node)
 
The Checksum field contains a standard IP 16 bit checksum. 
 
Bytes 4-7 are unused and must be set to zero.
 
As much of the failed packet as will fit in the minimum MTU (1280 bytes) is included starting at offset 8.
 

Parameter Problem error message 

If any IPv6 node finds a problem with any field in the IPv6 basic header or any extension header, such that it can't process the packet, it must discard the packet and return a Parameter Problem error message to the source address in the failed packet (which should be the original sender).
 
If you get a Parameter Problem error message, either your OS vendor made a mistake in your TCP/IP stack, or someone may be hacking you. Either case is bad news.
 
The Parameter Problem error message syntax is as follows:
param prob msg

The Type field contains the value 4 for Parameter Problem.

The Code field must be set to zero.

The Checksum field contains a standard IP 16 bit checksum.
 
The Pointer field contains the offset within the failed packet at which the first parameter problem was detected. It is possible that this may be beyond the end of what is returned in the data following the Pointer (the sender may need to look in the original packet they sent).
 
As much of the failed packet as will fit in the minimum MTU (1280 bytes) is included starting at offset 8.
 

Echo Request diagnostic message 

Any node can test connectivity to any other node over IPv6 by sending an Echo Request message to that node. The receiving node should respond with an Echo Reply diagnostic message. A request can be sent to a unicast or multicast destination address. These messages can be used in any address scope. This message has exactly the same functionality as the ICMPv4 Echo Request message.
 
The Echo Request diagnostic message syntax is as follows:
icmpv6 echo syntax

The Type field contains the value 128 for Echo Request.

The Code field must be set to zero.

The Checksum field contains a standard IP 16 bit checksum.
 
The Identifier field can contain any 16 bit value, but the same value should be used for all messages in a series. This is used to help both ends identify which messages belong to a given series. Any other series should use a different Identifier.
 
The Sequence Number field of the first message in a series must contain the value zero. Every succeeding message should increment this value by one. This is used to help both ends identify missing messages.
 
The Data field can contain any arbitrary data, up to the MTU limit for the path used. Typically, something like a lower case alphabet is used.
 

Echo Reply diagnostic message 

Any node that receives an Echo Request diagnostic message should reply to the node that sent the request. The source address of the reply packet should be an address that belongs to the receiving node, that is compatible with the source address from the Echo Request diagnostic message. The destination address should be the source address from the request packet. This message has exactly the same functionality as the ICMPv4 Echo Reply message.
 
The Echo Reply diagnostic message syntax is as follows:
icmpv6 echo syntax

The Type field contains the value 129 for Echo Reply.

The Code field must be set to zero.

The Checksum field contains a standard IP 16 bit checksum.
 
The Identifier field must contain the Identifier value from the received Echo Request diagnostic message.
 
The Sequence Number must contain the Sequence Number value from the received Echo Request diagnostic message.
 
The Data field must contain the data from the received Echo Request diagnostic message.