|     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 ICMPv6
   message and parts of the IPv6 header.


2.2 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:




 
RFC 1885                 ICMPv6 (ICMP for IPv6)            December 1995


    (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 a multicast or
        anycast group in which the node is a member, the Source Address
        of the reply must be a unicast address belonging to the
        interface on which the multicast or anycast packet was received.

    (c) 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
        that unicast address belonging to the node that will be most
        helpful in diagnosing the error. For example, if the message is
        a response to a packet forwarding action that cannot complete
        successfully, the Source Address should be a unicast address
        belonging to the interface on which the packet forwarding
        failed.

    (d) Otherwise, the node's routing table must be examined to
        determine which interface will be used to transmit the message
        to its destination, and a unicast address belonging to that
        interface must be used as the Source Address of the message.


2.3 Message Checksum Calculation

   The checksum is the 16-bit one's complement of the one's complement
   sum of the entire ICMPv6 message starting with the ICMPv6 message
   type field, prepended with a "pseudo-header" of IPv6 header fields,
   as specified in [IPv6, section 8.1].  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.


2.4 Message Processing Rules

   Implementations MUST observe the following rules when processing
   ICMPv6 messages (from [RFC-1122]):

    (a) If an ICMPv6 error message of unknown type is received, it MUST
        be passed to the upper layer.

    (b) If an ICMPv6 informational message of unknown type is received,
        it MUST be silently discarded.





 
RFC 1885                 ICMPv6 (ICMP for IPv6)            December 1995


    (c) Every ICMPv6 error message (type < 128) includes as much of the
        IPv6 offending (invoking) packet (the packet that caused the
        error) as will fit without making the error message packet
        exceed 576 octets.

    (d) In those cases where the internet-layer protocol is required to
        pass an ICMPv6 error message to the upper-layer protocol, the
        upper-layer protocol type is extracted from the original packet
        (contained in the body of the ICMPv6 error message) and used to
        select the appropriate upper-layer protocol entity to handle the
        error.

        If the original packet had an unusually large amount of
        extension headers, it is possible that the upper-layer protocol