ICMPv6

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Juanpdp (talk | contribs) at 01:08, 28 December 2007 (→‎See also: add RFC names and indicate obsolecense.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Internet Control Message Protocol Version 6 (ICMPv6) or ICMP for IPv6 is a new version of ICMP and is an integral part of the IPv6 architecture that must be completely supported by all IPv6 implementations and nodes. ICMPv6 combines functions previously subdivided among different protocols, such as ICMP, IGMP (Internet Group Membership Protocol version 3), and ARP (Address Resolution Protocol) and it introduces some simplifications by eliminating obsolete types of messages no longer in use.

Summary

As IPv6 is a new version of IPv4, it uses ICMP as defined for IPv4 RFC 792 (which will be referred to as ICMPv4) with a number of changes. IGMP has also been absorbed into ICMPv6. The IPv6 Next Header value for ICMPv6 is 58.

This article describes the format of a set of control messages used in ICMPv6, but it does not describe the procedures for using these messages to achieve functions like Path MTU discovery. Additional ICMPv6 message types, such as Neighbor Discovery messages (IPv6-DISC) may be detailed in additional RFCs.

ICMPv6 is a multipurpose protocol and it is used for reporting errors encountered in processing packets, performing diagnostics, performing Neighbor Discovery and reporting IPv6 multicast memberships. For this reason, ICMPv6 messages are subdivided into two classes: error messages and information messages. ICMPv6 messages are transported within an IPv6 packet in which IPv6 extension headers can also be present.

ICMPv6 (ICMP for IPv6)

ICMPv6 is used by IPv6 nodes to report errors encountered in processing packets, and to perform other internet-layer functions, such as diagnostics (ICMPv6 ping).

Packets Format

ICMPv6 packets have the format Type, Code & Checksum. The 8-bit Type field indicates the type of the message. If the high-order bit has value zero (values in the range from 0 to 127), it is an error message; if the high-order bit has value 1 (values in the range from 128 to 255), it is an information message. The 8-bit Code field content depends on the message type, and it is used to create an additional level of message granularity. The Checksum field is used to detect errors in the ICMP message and in part of the IPv6 message.

Error Messages

ICMPv6 error messages are similar to ICMPv4 error messages. They belong to four categories: Destination Unreachable, Packet Too Big, Time Exceeded, and Parameter Problems.

            1    Destination Unreachable      
            2    Packet Too Big               
            3    Time Exceeded                
            4    Parameter Problem            

Informational Messages

A second type of ICMP message is the informational message. These messages are subdivided into three groups: diagnostic messages, messages for the management of multicast groups, and Neighbor Discovery messages.

            128  Echo Request                 
            129  Echo Reply                   

Every ICMPv6 message is preceded by an IPv6 header and zero or more IPv6 extension headers. The ICMPv6 header is identified by a NextHeader value of 58 in the immediately preceding header. (NOTE: this is different than the value used to identify ICMP for IPv4.)

The ICMPv6 messages have the following general format

      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      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                         Message Body                          +
     |                                                               |
     +---------------------------------------------------------------+

The type field indicates the type of the message. Its value determines the format of the remaining data. The code field depends on the message type. It is used to create an additional level of message granularity. The checksum field is used to detect data corruption in the ICMPv6message and parts of the IPv6 header.

Message Source Address Determination

A node that sends an ICMPv6 message has to determine both the Source and Destination IPv6 Addresses in the IPv6 header before calculating the checksum. If the node has more than one unicast address, it must choose the Source Address of the message as follows:

(a) If the message is a response to a message sent to one of the node's unicast addresses, the Source Address of the reply MUST be that same address.

(b) If the message is a response to a message sent to any other address, such as

  • a multicast group address,
  • an anycast address implemented by the node, or
  • a unicast address that does not belong to the node

the Source Address of the ICMPv6 packet MUST be a unicast address belonging to the node. The address SHOULD be chosen according to the rules that would be used to select the source address for any other packet originated by the node, given the destination address of the packet. However, it MAY be selected in an alternative way if this would lead to a more informative choice of address reachable from the destination of the ICMPv6 packet.

Message Checksum Calculation

The checksum is the 16-bit one's complement of the one's complementsum of the entire ICMPv6 message starting with the ICMPv6 messagetype field, prepended with a "pseudo-header" of IPv6 header fields, as specified in IPv6. The Next Header value used in the pseudo-header is 58. (NOTE: the inclusion of a pseudo-header in the ICMPv6 checksum is a change from IPv4; see IPv6 for the rationale for this change.) For computing the checksum, the checksum field is set to zero.

ICMPv6 Message Transmission

A node that forwards an ICMP message has to determine both the source and the destination IPv6 addresses for the ICMPv6 message. Particular care must be put into the choice of the source address. If a node has more than one unicast address, it must choose the source address of the message as follows:

  • If the message is a response to a message sent to one of the node unicast addresses, the Source Address of the reply must be that same address.
  • If the message is a response to a message sent to a multicast or anycast group to which the node belongs, the Source Address of the reply must be a unicast address belonging to the interface on which the multicast or anycast packet was received.
  • If the message is a response to a message sent to an address that does not belong to the node, the Source Address should be the unichecking the error (for example, the unicast address belonging to the interface on which the packet forwarding failed).
  • In other cases, the node routing tables must be examined to determine which interface will be used to transmit the message to its destination, and the unicast address belonging to that interface must be used as the Source Address of the message.

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.

Types of ICMP messages

Type Meaning
1 Destination Unreachable
2 Packet Too Big
3 Time Exceeded
4 Parameter Problem
128 Echo Request
129 Echo Reply
130 Group Membership Query
131 Group Membership Report
132 Group Membership Reduction
133 Router Solicitation
134 Router Advertisement
135 Neighbor Solicitation
136 Neighbor Advertisement
137 Redirect
138 Router Renumbering

See also

  • RFC 2894 Router Renumbering for IPv6
  • RFC 4443 ICMPv6 for IPv6 Specification (Obsoleted RFC 2463 and RFC 1885)

External links

  • go6.net - IPv6 Knowledge Center, IPv6 Services and Applications, IPv6 News and Events, IPv6 Discussion Forums