Network Working Group           A. Conta (Digital Equipment Corporation)
INTERNET-DRAFT                        S. Deering (Xerox PARC)
                                            December 1994


            ICMP for the Internet Protocol Version 6 (IPv6)
                      draft-ietf-ipngwg-icmp-00.txt


Status of this Memo

   This document is an Internet  Draft.   Internet  Drafts  are  working
   documents  of  the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups  may  also  distribute
   working documents as Internet Drafts.

   Internet Drafts are draft  documents  valid  for  a  maximum  of  six
   months.  Internet  Drafts  may  be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to  use  Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   To learn the current status of any Internet-Draft, please  check  the
   ``1id-abstracts.txt''  listing  contained  in  the  Internet-  Drafts
   Shadow Directories on ds.internic.net (US East Coast),  nic.nordu.net
   (Europe),  ftp.isi.edu  (US  West  Coast),  or munnari.oz.au (Pacific
   Rim).

   Distribution of this memo is unlimited.

Abstract


   This document specifies a set of Internet  Control  Message  Protocol
   (ICMP)  messages  for  use  with  version  6 of the Internet Protocol
   (IPv6).  The  Internet  Group  Management  Protocol  (IGMP)  messages
   specified  in  RFC-1112 have been merged into ICMP, for IPv6, and are
   included in this document.













Conta & Deering       Expires in six months         [Page 1]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


Table of Contents



1. Introduction.......................................3
2. ICMP for IPv6......................................3
3. ICMP Error Messages................................7
      3.1 Destination Unreachable Message.............7
      3.2 Packet Too Big..............................9
      3.4 Time Exceeded Message.......................10
      3.5 Parameter Problem Message...................12
4. ICMP Non-Error Messages............................13
      4.1 Echo Message................................13
      4.2 Echo Reply Message..........................14
      4.3 Group Membership Message....................16
5. References.........................................18
6. Acknowledgements...................................19
7. Security Considerations............................19

































Conta & Deering       Expires in six months         [Page 2]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


1.   Introduction

   The Internet Protocol, version 6 (IPv6) is a new version of IP.  IPv6
   uses the Internet Control Message Protocol (ICMP) as defined for IPv4
   [RFC-792],  with  a  few  changes.   The  Internet  Group  Membership
   Protocol  (IGMP)  specified for IPv4 [RFC-1112] has also been revised
   and has been absorbed into ICMP for IPv6.

   This document describes the format of a set of control messages  used
   in  ICMP  for  IPv6.   This document does not describe the procedures
   that use these messages to achieve functions like Neighbor  Discovery
   and  Path  MTU Discovery; these procedures are described in companion
   documents ([IPv6-DISC],  and  respectively  [RFC-1191]).  Terminology
   defined  in  the  IPv6  specification [IPv6] and the IPv6 Routing and
   Addressing specification [IPv6-ADDR]  applies  to  this  document  as
   well.


2.   ICMP for IPv6

   IPv6 ICMP is used by IPv6  nodes  to  report  errors  encountered  in
   processing  packets,  and  to perform other internet-layer functions,
   such as diagnostics (ICMP "ping"), neighbor discovery, and  multicast
   membership reporting.  IPv6 ICMP is an integral part of IPv6 and MUST
   be implemented by every IPv6 node.

   ICMP messages are grouped into two classes.

        ICMP error messages, such as:

          Destination Unreachable
          Packet Too Big
          Time Exceeded
          Parameter Problem

        ICMP non-error messages, such as:

          Echo
          Echo Reply
          Group Membership Query
          Group Membership Report
          Group Membership Termination
          Advertisment
          Solicitation







Conta & Deering       Expires in six months         [Page 3]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


   This document defines the message formats for the following IPv6 ICMP
   messages:

          ICMP error messages:
          Destination Unreachable      (see section 3.1)
          Packet Too Big               (see section 3.2)
          Time Exceeded                (see section 3.3)
          Parameter Problem            (see section 3.4)
          ICMP non-error messages:
          Echo                         (see section 4.1)
          Echo Reply                   (see section 4.2)
          Group Membership             (see section 4.3)


   Other documents may define other ICMP messages.  For  example  [IPv6-
   DISC]  defines  in  detail  the  format  of  the  following IPv6 ICMP
   messages:

          Advertisment
          Redirect
          Solicitation

   Every IPv6 ICMP message is preceded by an IPv6  header  and  zero  or
   more IPv6 extension headers.  The ICMP header is identified by a Next
   Header value of 1 in the immediately preceding header.

   The IPv6 ICMP 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 is the 16-bit one's complement of the  one's  complement
   sum  of  the  IPv6  Source Address, the IPv6 Destination Address, the
   IPv6 Payload Length, the IPv6 Next Header Type, and the  entire  ICMP
   message  starting with the ICMP message type. (The rationale for this



Conta & Deering       Expires in six months         [Page 4]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


   checksum computation is described  in  [IPv6]).   For  computing  the
   checksum, the checksum field is set to zero.

Implementation Notes:

   An application that sends ICMP messages  has  to  fill  in  both  the
   Source  and  Destination  IPv6  Addresses  in  the IPv6 header before
   calculating the checksum.  If the node has multiple source addresses,
   it  is  necessary  to  make  an  appropriate  selection, based on the
   destination  address,  TClass,  and  flow  id.  This   requires   the
   implementation of a function:

   source_ipv6_address  = get_source_address (
                                      destination_ipv6_address,
                                      TClass,
                                      flow-id
                                             )

   The following rules are suggested for implementing this mapping:

  (a)  If the remote Internet address lies on one of  the  (sub)nets  to
       which  the  node  is  directly  connected, a corresponding source
       address may be chosen,  unless  the  corresponding  interface  is
       known to be down.


  (b)  The route cache may be consulted, to see if there  is  an  active
       route  to  the  specified destination network through any network
       interface; if so, a local  IPv6  address  corresponding  to  that
       interface may be chosen.

       If the route cache does  not  contain  information  about  static
       routes or default routers, then consult similarly:

  (c)  The table of static routes, and

  (d)  The  table  of  default  routers.  As  default  routers  may   be
       associated  with  a  preference,  chose  the  highest  preference
       router.


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

       (a)  If an IPv6 ICMP message of unknown type is received, it MUST
            be silently discarded.

       (b)  Every IPv6 ICMP error message (the first  four  messages  in



Conta & Deering       Expires in six months         [Page 5]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


            the  above  list)  includes  as  much  of the IPv6 offending
            (invoking) packet (the packet that causes the error) as will
            fit  without  making  the  error  message  packet exceed 576
            octets.

            In case the ICMP packet that would result exceeds  the  size
            of  576  octets,  then truncate the ICMP packet to a size of
            576 octets.  If the ICMP packet contains a pointer to a  bad
            parameter  and  the  ICMP  message  had to be truncated, the
            pointer may point beyond the end of the ICMP message if  the
            bad  parameter  was in the part of the ICMP message that had
            to be truncated.

       (c)  In those cases where the Internet layer is required to  pass
            a  IPv6  ICMP error message to the transport layer, the IPv6
            Transport Protocol  MUST  be  extracted  from  the  original
            header  (contained  in  the  body  of  the  IPv6  ICMP error
            message)  and  used  to  select  the  appropriate  transport
            protocol entity to handle the error.

       (d)  An IPv6 ICMP error message MUST NOT be sent as a  result  of
            receiving:


          (d.1.)an IPv6 ICMP error message, or

          (d.2.)a packet destined  to  an  IPv6  multicast  address  (an
               exception  to  this  rule is the Packet Too Big Message -
               Section 3.2 - to allow Path MTU  discovery  to  work  for
               IPv6 multicast), or

          (d.3.)a packet sent as a link-layer multicast, or

          (d.4.)a packet sent as a link-layer broadcast, or

          (d.5.)a packet whose source address does not uniquely identify
               a  single  node -- e.g., the IPv6 Unspecified Address, or
               an IPv6 multicast address.


       (e)  Finally, to each sender of an erroneous data packet, an IPv6
            node  MUST  limit  the rate of ICMP error messages sent. One
            could limit the rate based on not sending more than  N  ICMP
            error messages per second to a certain destination. For such
            an implementation a value of <TBD> for N is recommended.

   The following sections describe the message  formats  for  the  above
   IPv6 ICMP messages.



Conta & Deering       Expires in six months         [Page 6]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


3.   ICMP Error Messages

3.1. Destination Unreachable Message


       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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             unused                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    As much of invoking packet                 |
      |                   as will fit without ICMP packet             |
      |                       exceeding 576 octets                    |
      |                                                               |



IPv6 Fields:

   Source Address
                  The IPv6 address of the node that composes
                  (sends) the ICMP message.

   Destination Address
                  The IPv6 address of the node to which the
                  ICMP message is sent.

IPv6 ICMP Fields:

   Type           3

   Code           0 - intermediate router unreachable
                  1 - destination address unreachable (last hop)
                  2 - unused
                  3 - port unreachable
                  4 - unused
                  5 - unused
                  6 - destination router or prefix unkown
                  7 - destination address unknown  (last hop)
                  8 - source node isolated
                  9 - communication with intermediate router
                            administratively prohibited
                  10 - communication with destination node
                            administratively prohibited (last hop)

   Unused         This field is unused for all code values.



Conta & Deering       Expires in six months         [Page 7]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


                  It must be initialized to zero by the sender
                  and ignored by the receiver.


Description

   A Destination Unreachable SHOULD be sent by a router in response to a
   packet  which  it  cannot  forward  either  because  the  next router
   destination address is unreachable (code  0),  the  node  destination
   address  is unreachable (code 1), the next router destination address
   is unknown (code 6), the node destination address  is  unknown  (code
   7),  or  if the router is administratively prohibited from forwarding
   packets to the destination of the IPv6  packet  either  to  a  router
   (code 11), or to the final destination which is a node (code 12).

   A host SHOULD generate a Destination Unreachable message in  response
   to  a packet when the transport protocol indicated by the Next Header
   Type field (such as UDP) is unable to demultiplex the packet (code 3)
   but has no protocol mechanisms to inform the sender.

   NOTE:

   The distinction between node or router for messages with code  <0, or
   1>,  <6, or 7>, <9, or 10> is made by the ICMP packet generator based
   on whether the packet is being forwarded to  an  intermediate  router
   (the packet is en route) or to its final destination node (last hop).

   Also the distinction between messages with code <0, or 1>, and <6, or
   7>is made by the ICMP packet generator based on whether the packet is
   unreachable  because  of  a  link-level  problem,  or   because   the
   destination is not in the route cache.

Upper layer notification

   A node receiving the ICMP Destination Unreachable message MUST notify
   the upper layer.















Conta & Deering       Expires in six months         [Page 8]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


3.2. Packet Too Big Message

       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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             MTU                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    As much of invoking packet                 |
      |                   as will fit without ICMP packet             |
      |                       exceeding 576 octets                    |
      |                                                               |



IPv6 Fields:

   Source Address
                  The IPv6 address of the node that composes
                  (sends) the ICMP message.

   Destination Address
                  The IPv6 address of the node to which the
                  ICMP message is sent.

IPv6 ICMP Fields:

   Type           TBD

   Code           0

   MTU            The 32-bits of this field contain the next hop's link
                  Maximum Transmission Unit.

Description

   A Packet Too Big MUST be sent by a router in  response  to  a  packet
   which  it cannot forward because the packet is larger than the MTU of
   the outgoing link.

   A node sending packets that cannot be forwarded by a  router  due  to
   the  packets exceeding the MTU of the next-hop link will receive from
   that router the ICMP Packet Too Big message,  reporting  the  MTU  of
   that next-hop link.

   The node SHOULD store that PMTU information and use it for subsequent
   packets  sent  to  the same destination. Using this mechanism, if the



Conta & Deering       Expires in six months         [Page 9]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


   packets  are  traversing  several  networks  (forwarded  by   several
   routers),  a  node  may  receive several ICMP Packet Too Big messages
   until the PMTU to the final destination is learned.  It is up to  the
   transport  or  application  protocol  to  make sure that packets lost
   because of inadequate PMTU are retransmitted.

   The minimum legal value of the next-hop MTU field in  a  "packet  too
   big"  message  (code 4) received by an IPv6 node is 68 octets.  While
   IPv6 requires all links in the Internet to have an MTU of 576  octets
   or greater, the smaller minimum legal value is required to allow Path
   MTU discovery  to  work  correctly  when  IPv6  packets  are  undergo
   translation to IPv4 packets (see Section 5 in [IPv6-SIT]).


Upper layer notification

   An incoming Packet Too Big message MUST be passed  to  the  transport
   layer.


3.3. Time Exceeded Message

       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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             unused                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    As much of invoking packet                 |
      |                   as will fit without ICMP packet             |
      |                       exceeding 576 octets                    |
      |                                                               |



IPv6 Fields:

   Source Address
                  The IPv6 address of the node that composes
                  (sends) the ICMP message.

   Destination Address
                  The IPv6 address of the node to which the
                  ICMP message is sent.

IPv6 ICMP Fields:




Conta & Deering       Expires in six months        [Page 10]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


   Type           11

   Code           0 - hop limit exceeded in transit

                  1 - fragment reassembly time exceeded


   Unused         It must be initialized to zero by the sender
                  and igmored by the receiver.


Description

   If a router receives a packet with a Hop Limit of zero, or  a  router
   decrements  a  packet's Hop Limit to zero, it discards the packet and
   sends an IPv6 ICMP Time Exceeded message with code 0. This  indicates
   either a routing loop or too small an initial Hop Limit value.

   IPv6 systems are expected to avoid fragmentation by implementing Path
   MTU  discovery.   However,  IPv6  defines an end-to-end fragmentation
   function for backwards compatibility with existing higher-layer  pro-
   tocols and IPv4-to-IPv6 translation.

   From [RFC-1122], the IPv6 layer  within  IPv6  hosts  MUST  implement
   reassembly  of  IPv6  fragments.  There MUST be a reassembly timeout.
   The reassembly timeout SHOULD be a fixed value.   It  is  recommended
   that  this  value  lie  between  60  and 120 seconds.  If the timeout
   expires, the partially-reassembled datagram MUST be discarded. If the
   fragment  with  offset zero was received, the destination host SHOULD
   also send an IPv6 ICMP Time Exceeded message with code 1.

Upper layer notification

   An incoming Time Exceeded message MUST be  passed  to  the  transport
   layer.
















Conta & Deering       Expires in six months        [Page 11]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


2.5. Parameter Problem Message

       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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Pointer                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    As much of invoking packet                 |
      |                   as will fit without ICMP packet             |
      |                       exceeding 576 octets                    |
      |                                                               |


IPv6 Fields:

   Source Address
                  The IPv6 address of the node that composes
                  (sends) the ICMP message.

   Destination Address
                  The IPv6 address of the node to which the
                  ICMP message should be sent.

IPv6 ICMP Fields:

   Type           12

   Code           0 means Pointer field indicates incorrect parameter.

                  1 means unrecognized Next Header type

                  2 means unrecognized IPv6 option

   Pointer        identifies the octet offset within the
                  invoking packet where an error was detected.

                  The pointer will point beyond the end of the ICMP packet,
                  if the parameter in error is beyond what can fit in the
                  576-byte limit of an ICMP error message.


Description

   If an IPv6 node processing a packet finds a problem with the  parame-
   ters in the IPv6 header or extension headers such that it cannot com-
   plete processing the packet, it MUST discard the  packet  and  SHOULD



Conta & Deering       Expires in six months        [Page 12]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


   send an ICMP Parameter Problem message.

Upper layer notification

   A node receiving this ICMP message MUST notify the upper layer.


4.   ICMP Non-Error Messages

4.1. Echo Message

       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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Identifier          |        Sequence Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Data ...
      +-+-+-+-+-


IPv6 Fields:

   Source Address
                  The IPv6 address of the node that composes
                  (sends) the ICMP message.

   Destination Address
                  The IPv6 address of the node to which the
                  ICMP message should be sent.

IPv6 ICMP Fields:

   Type           8 - Echo Message

   Code           0

   Identifier     If code = 0, some identifier to match echo messages
                  with echo replies.  May be zero.

   Sequence Number If code = 0, a sequence number to aid in matching
                  echo messages with echo replies.  May be zero.


Description

   Every node MUST implement an ICMP Echo server function that  receives



Conta & Deering       Expires in six months        [Page 13]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


   Echo  Requests  and  sends corresponding Echo Replies.  A node SHOULD
   also implement an application-layer interface  for  sending  an  Echo
   Request and receiving an Echo Reply, for diagnostic purposes.

   An Echo Reply SHOULD be sent in response to an Echo message  sent  to
   an IPv6 multicast address.  The source address of the reply MUST be a
   unicast address belonging to the interface  on  which  the  multicast
   Echo message was received.

   The source address of an Echo Reply sent in  response  to  a  unicast
   Echo message MUST be the same as the destination address of that Echo
   message.


Upper layer notification

   A node receiving this ICMP message MUST notify the upper layer.

Implementation Note:

   An application that sends ICMP Echo messages has to fill in both  the
   Source  and  Destination  IPv6  Addresses  in  the ICMP header before
   calculating the checksum.  Please  see  the  Implementation  Note  in
   Section 2.


4.2. Echo Reply Message

       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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Identifier          |        Sequence Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Data ...
      +-+-+-+-+-


IPv6 Fields:

   Source Address
                  The IPv6 address of the node that composes
                  (sends) the ICMP message.

   Destination Address
                  The IPv6 address of the node to which the
                  ICMP message should be sent.



Conta & Deering       Expires in six months        [Page 14]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


IPv6 ICMP Fields:

   Type           0 - Echo Reply Message

   Code           0

   Identifier     If code = 0, some identifier to match echo messages
                  with echo replies.  May be zero.

   Sequence Number If code = 0, a sequence number to aid in matching
                  echo messages with echo replies.  May be zero.


Description

   Every node MUST implement an ICMP Echo server function that  receives
   Echo  Requests  and  sends corresponding Echo Replies.  A node SHOULD
   also implement an application-layer interface  for  sending  an  Echo
   Request and receiving an Echo Reply, for diagnostic purposes.

   An Echo Reply SHOULD be sent in response to an Echo message  sent  to
   an IPv6 multicast address.  The source address of the reply MUST be a
   unicast address belonging to the interface  on  which  the  multicast
   Echo message was received.

   The source address of an Echo Reply sent in  response  to  a  unicast
   Echo message MUST be the same as the destination address of that Echo
   message.

   The data received in the ICMP Echo message MUST be returned  entirely
   and  unmodified  in the ICMP Echo Reply message. However, if the Echo
   Reply would exceed the  path  MTU  of  the  path  back  to  the  Echo
   requestor,  then the Echo Reply message MUST be truncated to the path
   MTU size and sent.


Upper layer notification

   Echo Reply messages MUST be passed to the ICMP user interface, unless
   the corresponding Echo Request originated in the IP layer.

Implementation Note:

   An application that sends ICMP ECHO messages has to fill in the  ICMP
   header   both  the  Source  and  Destination  IPv6  Addresses  before
   calculating the checksum.  See the Implementation Note in Section 2.





Conta & Deering       Expires in six months        [Page 15]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


4.3. Group Membership Messages

   The ICMP Group Membership Messages have the following 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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Unused                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                          Multicast                            |
      +                                                               +
      |                           Address                             |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



IPv6 Fields:

   Source Address
                  The IPv6 address of the node that composes (sends) the
                  ICMP message.

   Destination Address
                  The IPv6 address of the node to which the ICMP message
                  is sent.

IPv6 ICMP Fields:

   Type           TBD - Group Membership Query
                  TBD - Group Membership Report
                  TBD - Group Membership Termination

   Code           In Query messages, the Code field specifies the
                  maximum time that responding Reports may be delayed.

                  In Report and Termination messages, the Code field
                  is initialized to zero by the sender and ignored by
                  receivers.

   Unused         Initialized to zero by the sender; ignored by receivers.




Conta & Deering       Expires in six months        [Page 16]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


   Multicast Address
                  The address if the multicast group about which the
                  message is being sent.  In Query messages, the Multicast
                  Address field may be zero, implying a query for all
                  groups.



Description

   The ICMP Group Membership messages are to  convey  information  about
   multicast  group  membership from nodes to their neighboring routers.
   The details of their usage is given in [RFC-1112].


4.4. Solicitation and Advertisment

       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                          |
      +                                                               +
      |                                                               |


      Type       33 - solicitation
                 34 - advertisment

[IPv6-DISC] defines in detail this ICMP message header format.



5.   References



     [IPv6]R.  Hinden,  "Internet  Protocol  Version  6  Specification",
          Internet Draft, <DRAFT-HINDEN-IPNG-IPV6-SPEC-00.TXT>.  October
          1994


     [IPv6-ADDR]
          R.  Hinden.  IP  Next  Generation   Addressing   Architecture.
          Internet Draft <DRAFT-HINDEN-IPNG-ADDR-00.TXT>.  October 1994.





Conta & Deering       Expires in six months        [Page 17]


INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


     [IPv6-DISC]
          W. A. Simpson "Neighbor Discovery",  Internet  Draft,  <DRAFT-
          SIMPSON-IPV6-DISCOV-FORMATS-01.TXT>, November 1994


     [IPv6-SIT]
          R.Gilligan,   E.   Nordmark,   "Simple   Internet   Transition
          Overview",  Internet Draft, <DRAFT-GILLIGAN-IPV6-SIT-OVERVIEW-
          01.TXT>, November 1994


     [RFC-792]
          J. Postel, "Internet Control Message Protocol", RFC 792.


     [RFC-1112]
          S. Deering, "Host Extensions for IP Multicasting", RFC 1112.


     [RFC-1122]
          R. Braden, "Requirements for Internet  Hosts  -  Communication
          Layers", RFC 1122.


     [RFC-1191]
          J. Mogul and S. Deering, "Path MTU Discovery", RFC 1191.


     [RFC-1256]
          S. Deering, "ICMP Router Discovery", RFC 1256.


     [TRANS-MECH]
          R. Gilligan, E. Nordmark. IPv6 Transition Mechanisms for Hosts
          and   Routers.    Internet  Draft  <draft-gilligan-ipv6-trans-
          mechanisms-00.txt>. November 1994.





6.   Acknowledgements

   The document is derived from the "ICMP and IGMP  for  SIPP"  document
   published  as  a  draft by Ramesh Govindan and Steve Deering in March
   1994.

   Extensive review information and feedback was provided by Robert Elz,



Conta & Deering       Expires in six months        [Page 18]

INTERNET-DRAFT               ICMP for IPv6              December 3, 1994


   Jim Bound, and others.


7.   Security Considerations

   Security considerations are not discussed in this memo.


Authors' Addresses:

   Alex Conta                               Stephen Deering
   Digital Equipment Corporation            Xerox Palo Alto Research Center
   110 Spitbrook Rd                         3333 Coyote Hill Road
   Nashua, NH 03062                         Palo Alto, CA 94304
   +1-603-881-0744                          +1-415-812-4839

   email: conta@zk3.dec.com                 email: deering@parc.xerox.com