Section 4.1. General Message Format


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:

  • ICMPv6 error messages

    • Destination Unreachable (message type 1)

    • Packet Too Big (message type 2)

    • Time Exceeded (message type 3)

    • Parameter Problem (message type 4)

  • ICMPv6 informational messages

    • Echo Request (message type 128)

    • Echo Reply (message type 129)

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 type

Message 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 messages

Message 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.



IPv6 Essentials
IPv6 Essentials
ISBN: 0596100582
EAN: 2147483647
Year: 2004
Pages: 156
Authors: Silvia Hagen

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net