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

            ICMP for the Internet Protocol Version 6 (IPv6)
                      draft-ietf-ipngwg-icmp-00.txt
                     draft-ietf-ipngwg-icmp-01.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.

Table of Contents

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

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  number  of  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  It does  not  describe  the  procedures
   that use  for  using  these  |
   messages  to  achieve  functions like Neighbor  Discovery
   and Path MTU Discovery; these discovery or multicast  |
   group membership maintenance; such procedures are described in companion  other  |
   documents ([IPv6-DISC],  and  respectively  [RFC-1191]).  (e.g.,  [RFC-1112,  RFC-1191]).   Other documents may also  |
   introduce additional ICMP message types, such as  Neighbor  Discovery  |
   messages  [IPv6-DISC], subject to the general rules for ICMP messages  |
   given in section 2 of this document.                                   |

   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, "ping") 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  classes:  error messages, such as:

          Destination Unreachable
          Packet Too Big
          Time Exceeded
          Parameter Problem

        ICMP non-error messages,  messages  and  |
   informational  messages.   Error  messages  are identified as such as:

          Echo
          Echo Reply
          Group Membership Query
          Group Membership Report
          Group Membership Termination
          Advertisment
          Solicitation by  |
   having a zero in the high-order bit of  their  message  Type  values.  |
   Thus,  error messages have message Types from 0 to 127; informational  |
   messages have message Types from 128 to 255.                           |

   This document defines the message formats for the following IPv6 ICMP  |
   messages:                                                              |
        ICMP error messages:                                              |
            1  Destination Unreachable      (see section 3.1)             |
            2  Packet Too Big               (see section 3.2)             |
            3  Time Exceeded                (see section 3.3)             |
            4  Parameter Problem            (see section 3.4)             |
        ICMP non-error informational messages:                                      |
          128  Echo Request                 (see section 4.1)             |
          129  Echo Reply                   (see section 4.2)             |
          130  Group Membership Qeury       (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             |
          131  Group Membership Report      (see section 4.3)             |
          132  Group Membership Termination (see section 4.3)             |

   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  <TBD> in the immediately preceding header.  (NOTE:  |
   this is different than the value used to identify ICMP for IPv4.)      |

   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,
   Address (the final destination, if a Routing Header is  being  used),  |
   the  IPv6  Payload  Length, the IPv6 Next Header Type, type that identifies IPv6  |
   ICMP(<TBD>), and the entire  ICMP  message  starting  with  the  ICMP  |
   message type. (The rationale for this
   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
   (NOTE: the
   Source  and  Destination  IPv6  Addresses  in inclusion of the IPv6 header before fields in the  ICMP  checksum  |
   is a change from IPv4; see [IPv6] for the rationale for this change.)  |
   Implementation Notes:                                                  |

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

      If the message is  necessary a response to  make  an  appropriate  selection, based on a  message  sent  to  one  of  the
   destination  |
      node's  unicast  address,  TClass,  and  flow  id.  This   requires  the
   implementation Source Address 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 reply must be  |
      that same address.                                                  |

      If the  (sub)nets message is a response to a  message  sent  to  a  multicast  |
      group  in  which  the  node is  directly  connected, a corresponding source
       address may member, the Source Address of the  |
      reply must be chosen,  unless a unicast address  belonging  to  the  corresponding  interface  is
       known to be down.

  (b)  The route cache may  on  |
      which the multicast packet was received.                            |

      Otherwise, the node's routing table must be consulted, examined to see if there  is  an  active
       route  determine  |
      which  interface  will  be  used  to  transmit  the  specified destination network through any network
       interface; if so, message to its  |
      destination, and a local  IPv6 unicast address  corresponding  belonging  to  that  interface may  |
      must be chosen.

       If used as 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 Source Address of  default  routers.  As  default  routers  may   be
       associated  with  a  preference,  chose the  highest  preference
       router. message.                  |

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

          (d.3.)                                                          |
               a packet sent as a link-layer multicast,  (the  exception  |
               from d.2.  applies to this case too) or

          (d.4.)a                    |

          (d.4.)
               a packet sent as a link-layer broadcast,  (the  exception  |
               from d.2.  applies to this case too) 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 an erroneous data packet, an IPv6
            node
            MUST limit the rate of ICMP error messages sent, in order to  |
            limit the bandwidth and forwarding costs incurred by the the  |
            error messages when a generator of  erroneous  packets  does  |
            not   respond   to  those  error  messages  by  ceasing  its  |
            transmissions.  There are a variety of ways of  implementing  |
            the rate-limiting function, for example:                      |

          (e.1.)Timer-based  -  for  example,  limiting  the   rate   of ICMP  |
               transmission  of  error messages sent. One
            could limit to a given source, or to  |
               any source, to at most once every T milliseconds.          |

          (e.2.)Bandwidth-based - for  example,  limiting  the  rate based on not sending more than  N  ICMP  at  |
               which error messages per second to a certain destination. For such
            an implementation are sent from a value particular interface  |
               to some fraction F of <TBD> the attached link's bandwidth.       |

            The limit parameters (e.g., T or F in  the  above  examples)  |
            MUST  be  configurable  for N is recommended.  the  node,  with a conservative  |
            default value (e.g., T = 1 second, NOT 0 seconds, or F  =  2  |
            percent, NOT 100 percent).                                    |

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

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

IPv6 Fields:

   Source                                                              |

   Destination Address
                  The IPv6 address of the node that composes
                  (sends)                                                    |
                  Copied from the ICMP message.

   Destination Source Address
                  The IPv6 address field of the node to which the
                  ICMP message is sent. invoking    |
                  packet.                                                 |

IPv6 ICMP Fields:                                                         |

   Type           3           1                                                       |

   Code           0 - intermediate router unreachable no route to destination                             |
                  1 - communication with destination address unreachable (last hop)
                  2 - unused                      |
                        administratively prohibited                       |
                  3 - port address 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) port unreachable                                    |

   Unused         This field is unused for all code values.
                  It must be initialized to zero by the sender
                  and ignored by the receiver.

Description

   A Destination Unreachable message SHOULD be sent generated by a router router, or  |
   by  the  IPv6  layer in the originating node, in response to a packet  which  it  |
   that cannot  forward  either  because  the  next router be delivered to its destination address for reasons other  |
   than  congestion.  (If a packet is unreachable (code  0), dropped due to congestion, no ICMP  |
   error message is generated.)   If  the  node  destination
   address  reason  for  the  failure  to  |
   deliver  is unreachable (code 1), lack of a matching entry in the forwarding node's routing  |
   table, the Code field is set to 0 (NOTE: this error can occur only in  |
   routers  that do not hold a "default route" in their routing tables).  |
   If  the next router destination address
   is unknown (code 6),  reason  for  the node destination address  failure  to  deliver   is  unknown  (code
   7),  or  if   administrative  |
   prohibition,  e.g.,  a "firewall filter", the router Code field is administratively prohibited from forwarding
   packets set to 1.  |
   If there is any other  reason  for  the destination of  failure  to  deliver,  e.g.,  |
   inability   to   resolve   the   IPv6  packet  either  to   destination  address  into  a  router
   (code 11),  |
   corresponding link address, or to a link-specific problem of some  sort,  |
   then the final destination which Code field is a node (code 12). set to 3.                                       |

   A host destination node SHOULD generate send a Destination Unreachable message with  |
   Code  4  in  response  to  a  packet when for which the transport protocol indicated by the Next Header
   Type field (such as  |
   (e.g., UDP) is unable to demultiplex the packet (code 3)
   but has no  listener,  if  that  transport  protocol mechanisms  has  no  |
   alternative means 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.                                                       |

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                                                              |

   Destination Address
                  The IPv6 address of the node that composes
                  (sends)                                                    |
                  Copied from the ICMP message.

   Destination Source Address
                  The IPv6 address field of the node to which the
                  ICMP message is sent. invoking    |
                  packet.                                                 |

IPv6 ICMP Fields:                                                         |

   Type           TBD           2                                                       |

   Code           0

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

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 in
   response to
   the  packets exceeding the MTU of the next-hop link will receive from a packet that router it cannot forward  because  the ICMP Packet Too Big message,  reporting  packet  is  |
   larger  than  the  MTU of
   that next-hop the outgoing link.  The node SHOULD store that PMTU information and use it for subsequent
   packets  sent  to  the same destination. Using in this mechanism, if  |
   message is used as part of the
   packets  are  traversing  several  networks  (forwarded  by   several
   routers), Path MTU Discovery process [RFC-1191].  |

   Sending a  node  may  receive several ICMP Packet Too Big messages
   until the PMTU to the final destination is learned.  It is up Message makes an exception to the
   transport  or  application  protocol  rules  of  |
   when to  make sure send an ICMP error message, in that packets lost
   because of inadequate PMTU are retransmitted.

   The minimum legal value of the next-hop MTU field unlike other messages, it  |
   is sent in response to a  "packet  too
   big"  message  (code 4)  packet  received by  with  an  IPv6 node is 68 octets.  While
   IPv6 requires all links in the Internet to have an MTU of 576  octets  multicast  |
   destination   address,   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]).  a  link-layer  multicast  or  link-layer  |
   broadcast address.                                                     |

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

IPv6 Fields:

   Source                                                              |

   Destination Address
                  The IPv6 address of the node that composes
                  (sends)                                                    |
                  Copied from the ICMP message.

   Destination Source Address
                  The IPv6 address field of the node to which the
                  ICMP message is sent. invoking    |
                  packet.                                                 |

IPv6 ICMP Fields:                                                         |

   Type           11           3                                                       |

   Code           0 - hop limit exceeded in transit

                  1 - fragment reassembly time exceeded

   Unused         This field is unused for all code values.               |
                  It must be initialized to zero by the sender            |
                  and igmored ignored 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.
   Code 0 to the source of the packet.  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  |
   protocols.    All   IPv6  hosts  MUST  implement  implementations  are  required  to  support  |
   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 packet 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. Code 1 to the source  of  the  |
   fragment.                                                              |

Upper layer notification

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

2.5.

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

   Destination Address
                  The IPv6 address of the node that composes
                  (sends)                                                    |
                  Copied from the ICMP message.

   Destination Source Address
                  The IPv6 address field of the node to which the
                  ICMP message should be sent. invoking    |
                  packet.                                                 |

IPv6 ICMP Fields:                                                         |

   Type           12           4                                                       |

   Code           0 means Pointer - erroneous header field indicates incorrect parameter. encountered                  |

                  1 means - unrecognized Next Header type encountered           |

                  2 means - unrecognized IPv6 option encountered                |

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

                  The pointer will point beyond the end of the ICMP packet,       |
                  packet if the parameter field 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 a  field  in  |
   the  IPv6  header  or  extension headers such that it cannot com-
   plete complete  |
   processing the packet, it MUST discard the packet and SHOULD send  an  |
   ICMP Parameter Problem message. message to the packet's source, indicating the  |
   type and location of the problem.                                      |

Upper layer notification

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

4.                                                                        |
     ICMP Non-Error Informational Messages                                          |

4.1.
     Echo Request 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                                                    |
                  Any legal IPv6 address of the node to which the
                  ICMP message should be sent. address.                                 |
                                                                          |
IPv6 ICMP Fields:

   Type           8 - Echo Message           128                                                     |

   Code           0

   Identifier     If code = 0, some an identifier to match echo messages
                  with echo replies. aid in matching           |
                  Echo Replies to this Echo Request.  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       |
   Number         Echo Reply sent in  response Replies to  a  unicast this Echo message MUST Request.  May be the same as the destination address zero.        |

   Data           If code = 0, zero or more octets of arbitrary data.     |

Description

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

Upper layer notification                                                  |

   A node receiving this ICMP message MUST MAY 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                                                              |

   Destination Address
                  The IPv6 address of the node that composes
                  (sends)                                                    |
                  Copied from the ICMP message.

   Destination Source Address
                  The IPv6 address field of the node to which the
                  ICMP message should be sent. invoking    |
                  Echo Request packet.                                    |

IPv6 ICMP Fields:                                                         |

   Type           0 - Echo Reply Message           129                                                     |

   Code           0

   Identifier     If code = 0, some the identifier to match echo messages
                  with echo replies.  May be zero. from the invoking           |
                  Echo Request message.                                   |

   Sequence Number       If code = 0, a the sequence number to aid in matching
                  echo messages with echo replies.  May be zero. from the invoking      |
   Number         Echo Request message.                                   |

   Data           If code = 0, the data from the invoking                 |
                  Echo Request message                                    |

Description

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

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

   An Echo Reply SHOULD be sent in response to an Echo  Request  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 Request 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 Request message MUST  be  returned  |
   entirely  and  unmodified  in the ICMP Echo Reply message. However, if message, unless the  |
   Echo Reply would exceed  the  path  MTU  of  the  path  back  to  the  Echo
   requestor,  then the Echo Reply message MUST be  |
   requester, in which case the data is truncated to the fit that path
   MTU size and sent. MTU.   |

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.

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             |   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
      |     Maximum Response Delay    |          Unused               |   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                          Multicast                            |
      +                                                               +
      |                           Address                             |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6 Fields:

   Source                                                              |

   Destination Address
                  The IPv6                                                    |
                  In a Group Membership Query message, the multicast      |
                  address of the node that composes (sends) group being queried, or the
                  ICMP message.

   Destination Address
                  The IPv6 Link-Local   |
                  All-Nodes multicast address.                            |

                  In a Group Membership Report or a Group Membership      |
                  Termination message, the multicast address of the node to which the ICMP message
                  is sent.       |
                  group being reported or terminated.                     |

   Hop Limit      1                                                       |

IPv6 ICMP Fields:

   Type           TBD           130 - Group Membership Query
                  TBD                            |
                  131 - Group Membership Report
                  TBD                           |
                  132 - Group Membership Termination                      |

   Code           0                                                       |

   Maximum Response Delay                                                 |
                  In Query messages, the Code field specifies the maximum time that responding Reports     |
                  Report messages may be delayed. delayed, in milliseconds.        |

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

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

   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  used  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        |
          February 1995                                                   |

     [IPv6-ADDR]
          R.  Hinden.  IP  Hinden,  "IP  Next  Generation  Addressing   Architecture.
          Internet Draft <DRAFT-HINDEN-IPNG-ADDR-00.TXT>.  October 1994.  Architecture",  |
          February 1995                                                   |
     [IPv6-DISC]
          W. A. Simpson "Neighbor Simpson, "IPv6 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 February 1995         |

     [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

   The working group and feedback was provided by particularly Robert Elz, Jim  Bound,  and others.  Bill  |
   Simpson provided extensive review information and feedback.            |

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