4.1. General Message Format There are two classes of ICMP messages: ICMP error messages Error messages have a 0 in the high-order bit of their message Type field. ICMP error message types are, therefore, in the range from 0 to 127. ICMP informational messages Informational messages have a 1 in the high-order bit of their message Type field. ICMP informational message types are, therefore, in the range from 128 to 255. An IPv6 header and zero or more Extension headers precede every ICMPv6 message. The header just preceding the ICMP header has a next header value of 58. This value is different from the value for ICMPv4 (which has the value 1). | The values for the Next Header field are discussed in Chapter 2. |
|
The following message types are described in RFC 4443: | For the most current list of ICMPv6 message types, refer to the Internet Assigned Number Authority (IANA) at http://www.iana.org/assignments/icmpv6-parameters. All IPv4 ICMP parameters can be found at http://www.iana.org/assignments/icmp-parameters. |
|
All ICMPv6 messages have the same general header structure, as shown in Figure 4-1. Notice that the first three fields for type, code, and checksum have not changed from ICMPv4. Figure 4-1. General ICMPv6 header format 4.1.1. Type (1 Byte) This field specifies the type of message, which determines the format of the remainder of the message. Tables 4-1 and 4-2 list ICMPv6 message types and numbers. 4.1.2. Code (1 Byte) The Code field depends on the message type and allows for more granular information in certain cases. Refer to Tables 4-1 and 4-2 for a detailed list. 4.1.3. Checksum (2 Bytes) The Checksum field is used to detect data corruption in the ICMPv6 header and in parts of the IPv6 header. In order to calculate the checksum, a node must determine the Source and Destination address in the IPv6 header. If the node has more than one unicast address, there are rules for choosing the address (refer to RFC 4443 for details). There is also a pseudoheader included in the checksum calculation, which is new with ICMPv6. 4.1.4. Message Body (Variable Size) Depending on the type and code, the message body will hold different data. In the case of an error message, it will contain as much as possible of the packet that invoked the message to assist in troubleshooting. The total size of the ICMPv6 packet should not exceed the minimum IPv6 MTU, which is 1,280 bytes. Tables 4-1 and 4-2 provide an overview of the different message types, along with the additional code information, which depends on the message type. Table 4-1. ICMPv6 error messages and code typeMessage number | Message type | Code field |
|---|
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 | 2 | Packet Too Big | Code field set to 0 by the sender and ignored by the receiver | 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 The pointer field identifies the octet offset within the invoking packet where the error was detected. The pointer points beyond the end of the ICMPv6 packet if the field in error is beyond what can fit in the maximum size of an ICMPv6 error message. | 100 and 101 | Private experimentation | RFC 4443 | 127 | Reserved for expansion of ICMPv6 error messages | RFC 4443 |
Note that the message numbers and types have substantially changed compared to ICMPv4. ICMP for IPv6 is a different protocol, and the two versions of ICMP are not compatible. Your analyzer should properly decode all this information, so you do not have to worry about memorizing it. Table 4-2. ICMPv6 informational messagesMessage number | Message type | Description |
|---|
128 | Echo Request | RFC 4443. Used for the ping command. | 129 | Echo Reply | | 130 | Multicast Listener Query | RFC 2710. Used for multicast goup management. | 131 | Multicast Listener Report | | 132 | Multicast Listener Done | | 133 | Router Solicitation | RFC 2461. Used for neighbor discovery and autoconfiguration. | 134 | Router Advertisement | | 135 | Neighbor Solicitation | | 136 | Neighbor Advertisement | | 137 | Redirect Message | | 138 | Router Renumbering | RFC 2894 Codes: 0 = Router renumbering command 1 = Router renumbering result 255 = Sequence number reset | 139 | ICMP Node Information Query | draft-ietf-ipngwg-icmp-name-lookups-15.txt | 140 | ICMP Node Information Response | | 141 | Inverse ND Solicitation | RFC 3122 | 142 | Inverse ND Adv Message | RFC 3122 | 143 | Version 2 Multicast Listener Report | RFC 3810 | 144 | ICMP Home Agent Address Discovery Request Message | RFC 3775 ICMPv6 Messages for Mobile IPv6 | 145 | ICMP Home Agent Address Discovery Reply Message | | 146 | ICMP Mobile Prefix Solicitation Message | | 147 | ICMP Mobile Prefix Advertisement Message | | 148 | Certification Path Solicitation Message | RFC 3971 ICMPv6 Messages for SEcure Neighbor Discovery | 149 | Certification Path Advertisement Message | | 151 | Multicast Router Advertisement | RFC 4286 | 152 | Multicast Router Solicitation | | 153 | Multicast Router Termination | | 200 201 | Private experimentation | RFC 4443 | 255 | Reserved for expansion of ICMPv6 informational messages | RFC 4443 |
With the exception of the router renumbering message (138), the ICMPv6 informational messages do not use the Code field. It is, therefore, set to zero. |