home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipngwg-icmp-v2-00.txt < prev    next >
Text File  |  1997-10-27  |  32KB  |  1,118 lines
  1.  
  2. INTERNET-DRAFT                                         A. Conta, Lucent
  3. October 22, 1997                              S. Deering, Cisco Systems
  4.  
  5.  
  6.  
  7.                Internet Control Message Protocol (ICMPv6)
  8.                for the Internet Protocol Version 6 (IPv6)
  9.                              Specification
  10.  
  11.                    <draft-ietf-ipngwg-icmp-v2-00.txt>
  12.  
  13.  
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This document is an Internet-Draft.  Internet-Drafts are working
  19.    documents of the Internet Engineering Task Force (IETF), its areas,
  20.    and its working groups.  Note that other groups may also distribute
  21.    working documents as Internet-Drafts.
  22.  
  23.    Internet-Drafts are draft documents valid for a maximum of six months
  24.    and may be updated, replaced, or obsoleted by other documents at any
  25.    time.  It is inappropriate to use Internet- Drafts as reference
  26.    material or to cite them other than as "work in progress."
  27.  
  28.    To learn the current status of any Internet-Draft, please check the
  29.    "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
  30.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  31.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  32.    Rim).
  33.  
  34.    This Internet Draft expires April 22, 1998.
  35.  
  36.  
  37.    Abstract
  38.  
  39.    This document specifies a set of Internet Control Message Protocol
  40.    (ICMP) messages for use with version 6 of the Internet Protocol
  41.    (IPv6).
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53. draft-ietf-ipngwg-icmp-v2-00.txt                                [Page 1]
  54.  
  55. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  56.  
  57.  
  58. Table of Contents
  59.  
  60.  
  61.  
  62.    1. Introduction........................................3
  63.  
  64.    2. ICMPv6 (ICMP for IPv6)..............................3
  65.  
  66.          2.1 Message General Format.......................3
  67.  
  68.          2.2 Message Source Address Determination.........4
  69.  
  70.          2.3 Message Checksum Calculation.................5
  71.  
  72.          2.4 Message Processing Rules.....................5
  73.  
  74.    3. ICMPv6 Error Messages...............................8
  75.  
  76.          3.1 Destination Unreachable Message..............8
  77.  
  78.          3.2 Packet Too Big Message......................10
  79.  
  80.          3.3 Time Exceeded Message.......................11
  81.  
  82.          3.4 Parameter Problem Message...................12
  83.  
  84.    4. ICMPv6 Informational Messages......................14
  85.  
  86.          4.1 Echo Request Message........................14
  87.  
  88.          4.2 Echo Reply Message..........................15
  89.  
  90.    5. Security Considerations............................17
  91.  
  92.    6. References.........................................19
  93.  
  94.    7. Acknowledgments....................................19
  95.  
  96.    8. Authors' Addresses.................................20
  97.  
  98.    Appendix A - Changes since RFC 1885
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109. draft-ietf-ipngwg-icmp-v2-00.txt                                [Page 2]
  110.  
  111. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  112.  
  113.  
  114. 1. Introduction
  115.  
  116.    The Internet Protocol, version 6 (IPv6) is a new version of IP.  IPv6
  117.    uses the Internet Control Message Protocol (ICMP) as defined for IPv4
  118.    [RFC-792], with a number of changes.  The resulting protocol is
  119.    called ICMPv6, and has an IPv6 Next Header value of 58.
  120.  
  121.    This document describes the format of a set of control messages used
  122.    in ICMPv6.  It does not describe the procedures for using these
  123.    messages to achieve functions like Path MTU discovery ; such
  124.    procedures are described in other documents (e.g., [RFC-1981]).
  125.    Other documents may also introduce additional ICMPv6 message types,
  126.    such as Neighbor Discovery messages [IPv6-DISC], subject to the
  127.    general rules for ICMPv6 messages given in section 2 of this
  128.    document.
  129.  
  130.    Terminology defined in the IPv6 specification [IPv6] and the IPv6
  131.    Routing and Addressing specification [IPv6-ADDR] applies to this
  132.    document as well.
  133.  
  134.  
  135. 2. ICMPv6 (ICMP for IPv6)
  136.  
  137.    ICMPv6 is used by IPv6 nodes to report errors encountered in
  138.    processing packets, and to perform other internet-layer functions,
  139.    such as diagnostics (ICMPv6 "ping").  ICMPv6 is an integral part of
  140.    IPv6 and MUST be fully implemented by every IPv6 node.
  141.  
  142.  
  143. 2.1 Message General Format
  144.  
  145.    ICMPv6 messages are grouped into two classes: error messages and
  146.    informational messages.  Error messages are identified as such by
  147.    having a zero in the high-order bit of their message Type field
  148.    values.  Thus, error messages have message Types from 0 to 127;
  149.    informational messages have message Types from 128 to 255.
  150.  
  151.    This document defines the message formats for the following ICMPv6
  152.    messages:
  153.  
  154.         ICMPv6 error messages:
  155.  
  156.              1    Destination Unreachable      (see section 3.1)
  157.              2    Packet Too Big               (see section 3.2)
  158.              3    Time Exceeded                (see section 3.3)
  159.              4    Parameter Problem            (see section 3.4)
  160.  
  161.  
  162.  
  163.  
  164.  
  165. draft-ietf-ipngwg-icmp-v2-00.txt                                [Page 3]
  166.  
  167. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  168.  
  169.  
  170.         ICMPv6 informational messages:
  171.  
  172.              128  Echo Request                 (see section 4.1)
  173.              129  Echo Reply                   (see section 4.2)
  174.  
  175.  
  176.    Every ICMPv6 message is preceded by an IPv6 header and zero or more
  177.    IPv6 extension headers. The ICMPv6 header is identified by a Next
  178.    Header value of 58 in the immediately preceding header.  (NOTE: this
  179.    is different than the value used to identify ICMP for IPv4.)
  180.  
  181.    The ICMPv6 messages have the following general format:
  182.  
  183.        0                   1                   2                   3
  184.        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
  185.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  186.       |     Type      |     Code      |          Checksum             |
  187.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  188.       |                                                               |
  189.       +                         Message Body                          +
  190.       |                                                               |
  191.  
  192.    The type field indicates the type of the message. Its value
  193.    determines the format of the remaining data.
  194.  
  195.    The code field depends on the message type. It is used to create an
  196.    additional level of message granularity.
  197.  
  198.    The checksum field is used to detect data corruption in the ICMPv6
  199.    message and parts of the IPv6 header.
  200.  
  201.  
  202. 2.2 Message Source Address Determination
  203.  
  204.    A node that sends an ICMPv6 message has to determine both the Source
  205.    and Destination IPv6 Addresses in the IPv6 header before calculating
  206.    the checksum.  If the node has more than one unicast address, it must
  207.    choose the Source Address of the message as follows:
  208.  
  209.     (a) If the message is a response to a message sent to one of the
  210.         node's unicast addresses, the Source Address of the reply must
  211.         be that same address.
  212.  
  213.     (b) If the message is a response to a message sent to a multicast or
  214.         anycast group in which the node is a member, the Source Address
  215.         of the reply must be a unicast address belonging to the
  216.         interface on which the multicast or anycast packet was received.
  217.  
  218.  
  219.  
  220.  
  221. draft-ietf-ipngwg-icmp-v2-00.txt                                [Page 4]
  222.  
  223. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  224.  
  225.  
  226.     (c) If the message is a response to a message sent to an address
  227.         that does not belong to the node, the Source Address should be
  228.         that unicast address belonging to the node that will be most
  229.         helpful in diagnosing the error. For example, if the message is
  230.         a response to a packet forwarding action that cannot complete
  231.         successfully, the Source Address should be a unicast address
  232.         belonging to the interface on which the packet forwarding
  233.         failed.
  234.  
  235.     (d) Otherwise, the node's routing table must be examined to
  236.         determine which interface will be used to transmit the message
  237.         to its destination, and a unicast address belonging to that
  238.         interface must be used as the Source Address of the message.
  239.  
  240.  
  241. 2.3 Message Checksum Calculation
  242.  
  243.    The checksum is the 16-bit one's complement of the one's complement
  244.    sum of the entire ICMPv6 message starting with the ICMPv6 message
  245.    type field, prepended with a "pseudo-header" of IPv6 header fields,
  246.    as specified in [IPv6, section 8.1].  The Next Header value used in
  247.    the pseudo-header is 58.  (NOTE: the inclusion of a pseudo-header in
  248.    the ICMPv6 checksum is a change from IPv4; see [IPv6] for the
  249.    rationale for this change.)
  250.  
  251.    For computing the checksum, the checksum field is set to zero.
  252.  
  253.  
  254. 2.4 Message Processing Rules
  255.  
  256.    Implementations MUST observe the following rules when processing
  257.    ICMPv6 messages (from [RFC-1122]):
  258.  
  259.     (a) If an ICMPv6 error message of unknown type is received, it MUST
  260.         be passed to the upper layer.
  261.  
  262.     (b) If an ICMPv6 informational message of unknown type is received,
  263.         it MUST be silently discarded.
  264.  
  265.     (c) Every ICMPv6 error message (type < 128) includes as much of the
  266.         IPv6 offending (invoking) packet (the packet that caused the
  267.         error) as will fit without making the error message packet
  268.         exceed 576 octets.
  269.  
  270.     (d) In those cases where the internet-layer protocol is required to
  271.         pass an ICMPv6 error message to the upper-layer protocol, the
  272.         upper-layer protocol type is extracted from the original packet
  273.         (contained in the body of the ICMPv6 error message) and used to
  274.  
  275.  
  276.  
  277. draft-ietf-ipngwg-icmp-v2-00.txt                                [Page 5]
  278.  
  279. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  280.  
  281.  
  282.         select the appropriate upper-layer protocol entity to handle the
  283.         error.
  284.  
  285.         If the original packet had an unusually large amount of
  286.         extension headers, it is possible that the upper-layer protocol
  287.         type may not be present in the ICMPv6 message, due to truncation
  288.         of the original packet to meet the 576-octet limit.  In that
  289.         case, the error message is silently dropped after any IPv6-layer
  290.         processing.
  291.  
  292.     (e) An ICMPv6 error message MUST NOT be sent as a result of
  293.         receiving:
  294.  
  295.          (e.1) an ICMPv6 error message, or
  296.  
  297.          (e.2) a packet destined to an IPv6 multicast address (there are
  298.                two exceptions to this rule: (1) the Packet Too Big
  299.                Message - Section 3.2 - to allow Path MTU discovery to
  300.                work for IPv6 multicast, and (2) the Parameter Problem
  301.                Message, Code 2 - Section 3.4 - reporting an unrecognized
  302.                IPv6 option that has the Option Type highest-order two
  303.                bits set to 10), or
  304.  
  305.          (e.3) a packet sent as a link-layer multicast, (the exception
  306.                from e.2 applies to this case too), or
  307.  
  308.          (e.4) a packet sent as a link-layer broadcast, (the exception
  309.                from e.2 applies to this case too), or
  310.  
  311.          (e.5) a packet whose source address does not uniquely identify
  312.                a single node -- e.g., the IPv6 Unspecified Address, an
  313.                IPv6 multicast address, or an address known by the ICMP
  314.                message sender to be an IPv6 anycast address.
  315.  
  316.     (f) Finally, to each sender of informational requests and erroneous
  317.         data packet, an IPv6 node MUST limit the rate of informational
  318.         replies and ICMPv6 error messages sent, in order to limit the
  319.         bandwidth and forwarding costs incurred by these messages when a
  320.         generator of these messages is sending too many and/or sending
  321.         erroneous packets and does not respond to those error messages
  322.         by ceasing its transmissions.  There are a variety of ways of
  323.         implementing the rate-limiting function, for example:
  324.  
  325.          (f.1) Timer-based - for example, limiting the rate of
  326.                transmission of informational reply or error messages to
  327.                a given source, or to any source, to at most once every T
  328.                milliseconds.
  329.  
  330.  
  331.  
  332.  
  333. draft-ietf-ipngwg-icmp-v2-00.txt                                [Page 6]
  334.  
  335. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  336.  
  337.  
  338.          (f.2)  Bandwidth-based - for example, limiting the rate at
  339.                which informational reply or error messages are sent from
  340.                a particular interface to some fraction F of the attached
  341.                link's bandwidth.
  342.  
  343.         The limit parameters (e.g., T or F in the above examples) MUST
  344.         be configurable for the node, with a conservative default value
  345.         (e.g., T = 1 second, NOT 0 seconds, or F = 2 percent, NOT 100
  346.         percent).
  347.  
  348.    The following sections describe the message formats for the above
  349.    ICMPv6 messages.
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389. draft-ietf-ipngwg-icmp-v2-00.txt                                [Page 7]
  390.  
  391. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  392.  
  393.  
  394. 3. ICMPv6 Error Messages
  395.  
  396. 3.1 Destination Unreachable Message
  397.  
  398.        0                   1                   2                   3
  399.        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
  400.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  401.       |     Type      |     Code      |          Checksum             |
  402.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  403.       |                             Unused                            |
  404.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  405.       |                    As much of invoking packet                 |
  406.       +                as will fit without the ICMPv6 packet          +
  407.       |                       exceeding 576 octets                    |
  408.  
  409.    IPv6 Fields:
  410.  
  411.    Destination Address
  412.  
  413.                   Copied from the Source Address field of the invoking
  414.                   packet.
  415.  
  416.    ICMPv6 Fields:
  417.  
  418.    Type           1
  419.  
  420.    Code           0 - no route to destination
  421.                   1 - communication with destination
  422.                         administratively prohibited
  423.                   2 - not a neighbor
  424.                   3 - address unreachable
  425.                   4 - port unreachable
  426.  
  427.    Unused         This field is unused for all code values.
  428.                   It must be initialized to zero by the sender
  429.                   and ignored by the receiver.
  430.    Description
  431.  
  432.    A Destination Unreachable message SHOULD be generated by a router, or
  433.    by the IPv6 layer in the originating node, in response to a packet
  434.    that cannot be delivered to its destination address for reasons other
  435.    than congestion.  (An ICMPv6 message MUST NOT be generated if a
  436.    packet is dropped due to congestion.)
  437.  
  438.    If the reason for the failure to deliver is lack of a matching entry
  439.    in the forwarding node's routing table, the Code field is set to 0
  440.    (NOTE: this error can occur only in nodes that do not hold a "default
  441.    route" in their routing tables).
  442.  
  443.  
  444.  
  445. draft-ietf-ipngwg-icmp-v2-00.txt                                [Page 8]
  446.  
  447. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  448.  
  449.  
  450.    If the reason for the failure to deliver is administrative
  451.    prohibition, e.g., a "firewall filter", the Code field is set to 1.
  452.  
  453.    If the reason for the failure to deliver is that the next destination
  454.    address in the Routing header is not a neighbor of the processing
  455.    node but the "strict" bit is set for that address, then the Code
  456.    field is set to 2.
  457.  
  458.    If there is any other reason for the failure to deliver, e.g.,
  459.    inability to resolve the IPv6 destination address into a
  460.    corresponding link address, or a link-specific problem of some sort,
  461.    then the Code field is set to 3.
  462.  
  463.    A destination node SHOULD send a Destination Unreachable message with
  464.    Code 4 in response to a packet for which the transport protocol
  465.    (e.g., UDP) has no listener, if that transport protocol has no
  466.    alternative means to inform the sender.
  467.  
  468.    Upper layer notification
  469.  
  470.    A node receiving the ICMPv6 Destination Unreachable message MUST
  471.    notify the upper-layer protocol.
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501. draft-ietf-ipngwg-icmp-v2-00.txt                                [Page 9]
  502.  
  503. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  504.  
  505.  
  506. 3.2 Packet Too Big Message
  507.  
  508.        0                   1                   2                   3
  509.        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
  510.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  511.       |     Type      |     Code      |          Checksum             |
  512.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  513.       |                             MTU                               |
  514.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  515.       |                    As much of invoking packet                 |
  516.       +               as will fit without the ICMPv6 packet           +
  517.       |                       exceeding 576 octets                    |
  518.  
  519.    IPv6 Fields:
  520.  
  521.    Destination Address
  522.  
  523.                   Copied from the Source Address field of the invoking
  524.                   packet.
  525.  
  526.    ICMPv6 Fields:
  527.  
  528.    Type           2
  529.  
  530.    Code           0
  531.  
  532.    MTU            The Maximum Transmission Unit of the next-hop link.
  533.  
  534.    Description
  535.  
  536.    A Packet Too Big MUST be sent by a router in response to a packet
  537.    that it cannot forward because the packet is larger than the MTU of
  538.    the outgoing link.  The information in this message is used as part
  539.    of the Path MTU Discovery process [RFC-1981].
  540.  
  541.    Sending a Packet Too Big Message makes an exception to one of the
  542.    rules of when to send an ICMPv6 error message, in that unlike other
  543.    messages, it is sent in response to a packet received with an IPv6
  544.    multicast destination address, or a link-layer multicast or link-
  545.    layer broadcast address.
  546.  
  547.    Upper layer notification
  548.  
  549.    An incoming Packet Too Big message MUST be passed to the upper-layer
  550.    protocol.
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557. draft-ietf-ipngwg-icmp-v2-00.txt                               [Page 10]
  558.  
  559. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  560.  
  561.  
  562. 3.3 Time Exceeded Message
  563.  
  564.        0                   1                   2                   3
  565.        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
  566.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  567.       |     Type      |     Code      |          Checksum             |
  568.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  569.       |                             Unused                            |
  570.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  571.       |                    As much of invoking packet                 |
  572.       +               as will fit without the ICMPv6 packet           +
  573.       |                       exceeding 576 octets                    |
  574.  
  575.    IPv6 Fields:
  576.  
  577.    Destination Address
  578.                   Copied from the Source Address field of the invoking
  579.                   packet.
  580.  
  581.    ICMPv6 Fields:
  582.  
  583.    Type           3
  584.  
  585.    Code           0 - hop limit exceeded in transit
  586.  
  587.                   1 - fragment reassembly time exceeded
  588.  
  589.    Unused         This field is unused for all code values.
  590.                   It must be initialized to zero by the sender
  591.                   and ignored by the receiver.
  592.  
  593.    Description
  594.  
  595.    If a router receives a packet with a Hop Limit of zero, or a router
  596.    decrements a packet's Hop Limit to zero, it MUST discard the packet
  597.    and send an ICMPv6 Time Exceeded message with Code 0 to the source of
  598.    the packet.  This indicates either a routing loop or too small an
  599.    initial Hop Limit value.
  600.  
  601.    The rules for selecting the Source Address of this message are
  602.    defined in section 2.2.
  603.  
  604.    Upper layer notification
  605.  
  606.    An incoming Time Exceeded message MUST be passed to the upper-layer
  607.    protocol.
  608.  
  609.  
  610.  
  611.  
  612.  
  613. draft-ietf-ipngwg-icmp-v2-00.txt                               [Page 11]
  614.  
  615. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  616.  
  617.  
  618. 3.4 Parameter Problem Message
  619.  
  620.        0                   1                   2                   3
  621.        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
  622.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  623.       |     Type      |     Code      |          Checksum             |
  624.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  625.       |                            Pointer                            |
  626.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  627.       |                    As much of invoking packet                 |
  628.       +               as will fit without the ICMPv6 packet           +
  629.       |                       exceeding 576 octets                    |
  630.  
  631.    IPv6 Fields:
  632.  
  633.    Destination Address
  634.  
  635.                   Copied from the Source Address field of the invoking
  636.                   packet.
  637.  
  638.    ICMPv6 Fields:
  639.  
  640.    Type           4
  641.  
  642.    Code           0 - erroneous header field encountered
  643.  
  644.                   1 - unrecognized Next Header type encountered
  645.  
  646.                   2 - unrecognized IPv6 option encountered
  647.  
  648.    Pointer        Identifies the octet offset within the
  649.                   invoking packet where the error was detected.
  650.  
  651.                   The pointer will point beyond the end of the ICMPv6
  652.                   packet if the field in error is beyond what can fit
  653.                   in the 576-byte limit of an ICMPv6 error message.
  654.  
  655.    Description
  656.  
  657.    If an IPv6 node processing a packet finds a problem with a field in
  658.    the IPv6 header or extension headers such that it cannot complete
  659.    processing the packet, it MUST discard the packet and SHOULD send an
  660.    ICMPv6 Parameter Problem message to the packet's source, indicating
  661.    the type and location of the problem.
  662.  
  663.    The pointer identifies the octet of the original packet's header
  664.    where the error was detected. For example, an ICMPv6 message with
  665.    Type field = 4, Code field = 1, and Pointer field = 40 would indicate
  666.  
  667.  
  668.  
  669. draft-ietf-ipngwg-icmp-v2-00.txt                               [Page 12]
  670.  
  671. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  672.  
  673.  
  674.    that the IPv6 extension header following the IPv6 header of the
  675.    original packet holds an unrecognized Next Header field value.
  676.  
  677.    Upper layer notification
  678.  
  679.    A node receiving this ICMPv6 message MUST notify the upper-layer
  680.    protocol.
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725. draft-ietf-ipngwg-icmp-v2-00.txt                               [Page 13]
  726.  
  727. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  728.  
  729.  
  730. 4. ICMPv6 Informational Messages
  731.  
  732. 4.1 Echo Request Message
  733.  
  734.        0                   1                   2                   3
  735.        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
  736.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  737.       |     Type      |     Code      |          Checksum             |
  738.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  739.       |           Identifier          |        Sequence Number        |
  740.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  741.       |     Data ...
  742.       +-+-+-+-+-
  743.  
  744.    IPv6 Fields:
  745.  
  746.    Destination Address
  747.  
  748.                   Any legal IPv6 address.
  749.  
  750.    ICMPv6 Fields:
  751.  
  752.    Type           128
  753.  
  754.    Code           0
  755.  
  756.    Identifier     An identifier to aid in matching Echo Replies
  757.                   to this Echo Request.  May be zero.
  758.  
  759.    Sequence Number
  760.  
  761.                   A sequence number to aid in matching Echo Replies
  762.                   to this Echo Request.  May be zero.
  763.  
  764.    Data           Zero or more octets of arbitrary data.
  765.  
  766.    Description
  767.  
  768.    Every node MUST implement an ICMPv6 Echo responder function that
  769.    receives Echo Requests and sends corresponding Echo Replies.  A node
  770.    SHOULD also implement an application-layer interface for sending Echo
  771.    Requests and receiving Echo Replies, for diagnostic purposes.
  772.  
  773.    Upper layer notification
  774.  
  775.    A node receiving this ICMPv6 message MAY notify the upper-layer
  776.    protocol.
  777.  
  778.  
  779.  
  780.  
  781. draft-ietf-ipngwg-icmp-v2-00.txt                               [Page 14]
  782.  
  783. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  784.  
  785.  
  786. 4.2 Echo Reply Message
  787.  
  788.        0                   1                   2                   3
  789.        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
  790.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  791.       |     Type      |     Code      |          Checksum             |
  792.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  793.       |           Identifier          |        Sequence Number        |
  794.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  795.       |     Data ...
  796.       +-+-+-+-+-
  797.  
  798.    IPv6 Fields:
  799.  
  800.    Destination Address
  801.  
  802.                   Copied from the Source Address field of the invoking
  803.                   Echo Request packet.
  804.  
  805.    ICMPv6 Fields:
  806.  
  807.    Type           129
  808.  
  809.    Code           0
  810.  
  811.    Identifier     The identifier from the invoking Echo Request message.
  812.  
  813.    Sequence       The sequence number from the invoking Echo Request
  814.    Number         message.
  815.  
  816.    Data           The data from the invoking Echo Request message.
  817.  
  818.    Description
  819.  
  820.    Every node MUST implement an ICMPv6 Echo responder function that
  821.    receives Echo Requests and sends corresponding Echo Replies.  A node
  822.    SHOULD also implement an application-layer interface for sending Echo
  823.    Requests and receiving Echo Replies, for diagnostic purposes.
  824.  
  825.    The source address of an Echo Reply sent in response to a unicast
  826.    Echo Request message MUST be the same as the destination address of
  827.    that Echo Request message.
  828.  
  829.    An Echo Reply SHOULD be sent in response to an Echo Request message
  830.    sent to an IPv6 multicast address.  The source address of the reply
  831.    MUST be a unicast address belonging to the interface on which the
  832.    multicast Echo Request message was received.
  833.  
  834.  
  835.  
  836.  
  837. draft-ietf-ipngwg-icmp-v2-00.txt                               [Page 15]
  838.  
  839. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  840.  
  841.  
  842.    The data received in the ICMPv6 Echo Request message MUST be returned
  843.    entirely and unmodified in the ICMPv6 Echo Reply message.
  844.  
  845.    Upper layer notification
  846.  
  847.    Echo Reply messages MUST be passed to the ICMPv6 user interface,
  848.    unless the corresponding Echo Request originated in the IP layer.
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893. draft-ietf-ipngwg-icmp-v2-00.txt                               [Page 16]
  894.  
  895. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  896.  
  897.  
  898. 5. Security Considerations
  899.  
  900. 5.1 Authentication and Encryption of ICMP messages
  901.  
  902.    ICMP protocol packet exchanges can be authenticated using the IP
  903.    Authentication Header [IPv6-AUTH].  A node SHOULD include an
  904.    Authentication Header when sending ICMP messages if a security
  905.    association for use with the IP Authentication Header exists for the
  906.    destination address.  The security associations may have been created
  907.    through manual configuration or through the operation of some key
  908.    management protocol.
  909.  
  910.    Received Authentication Headers in ICMP packets MUST be verified for
  911.    correctness and packets with incorrect authentication MUST be ignored
  912.    and discarded.
  913.  
  914.    It SHOULD be possible for the system administrator to configure a
  915.    node to ignore any ICMP messages that are not authenticated using
  916.    either the Authentication Header or Encapsulating Security Payload.
  917.    Such a switch SHOULD default to allowing unauthenticated messages.
  918.  
  919.    Confidentiality issues are addressed by the IP Security Architecture
  920.    and the IP Encapsulating Security Payload documents [IPv6-SA,
  921.    IPv6-ESP].
  922.  
  923. 5.2 ICMP Attacks
  924.  
  925.    ICMP messages may be subject to various attacks.  The following is a
  926.    discussion of such attacks and their prevention:
  927.  
  928.    1. ICMP messages may be subject to actions intended to cause the
  929.       receiver believe the message came from a different source than the
  930.       message originator.  The protection against this attack can be
  931.       achieved by applying the IPv6 Authentication mechanism [IPv6-Auth]
  932.       to the ICMP message.
  933.  
  934.    2. ICMP messages may be subject to actions intended to cause the
  935.       message or the reply to it go to a destination different than the
  936.       message originator's intention.  The ICMP checksum calculation
  937.       provides a protection mechanism against changes by a malicious
  938.       interceptor in the destination and source address of the IP packet
  939.       carrying that message, provided the ICMP checksum field is
  940.       protected against change by the encryption [IPv6-ESP] of the ICMP
  941.       message.
  942.  
  943.    3. ICMP messages may be subject to changes in the message fields, or
  944.       payload.  The encryption [IPv6-ESP] of the ICMP message is a
  945.       protection against such actions.
  946.  
  947.  
  948.  
  949. draft-ietf-ipngwg-icmp-v2-00.txt                               [Page 17]
  950.  
  951. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  952.  
  953.  
  954.    4. ICMP messages may be used as attempts to perform denial of service
  955.       attacks by sending back to back erroneous IP packets.  An
  956.       implementation that correctly followed section 2.4, paragraph (f)
  957.       of this specifications, would be protected by the ICMP error rate
  958.       limiting mechanism.
  959.  
  960.    5. ICMP messages may be used as attempts to perform denial of service
  961.       attacks by sending back to back ICMP "echo" messages that cause
  962.       the generation of back to back ICMP "echo reply" messages.  An
  963.       implementation that correctly followed section 2.4, paragraph (f)
  964.       of this specifications, would be protected by the ICMP rate
  965.       limiting mechanism.
  966.  
  967.  
  968.  
  969.  
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005. draft-ietf-ipngwg-icmp-v2-00.txt                               [Page 18]
  1006.  
  1007. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  1008.  
  1009.  
  1010. 6. References
  1011.  
  1012.    [IPv6]       Deering, S., R. Hinden, "Internet Protocol, Version 6,
  1013.                 Specification", RFC1883, December 1995.
  1014.  
  1015.    [IPv6-ADDR]  Hinden, R., S. Deering, "IP Version 6 Addressing
  1016.                 Architecture", RFC1884, December 1995.
  1017.  
  1018.    [IPv6-DISC]  Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery
  1019.                 for IP Version 6 (IPv6)", RFC1970, August 1996.
  1020.  
  1021.    [RFC-792]    Postel, J., "Internet Control Message Protocol", RFC792.
  1022.  
  1023.    [RFC-1122]   Braden, R., "Requirements for Internet Hosts -
  1024.                 Communication Layers", RFC1122.
  1025.  
  1026.    [RFC-1981]   McCann, J., S. Deering, J. Mogul, "Path MTU Discovery
  1027.                 for IP version 6", RFC1981, August 1996.
  1028.  
  1029.    [IPv6-SA]    Atkinson, R., Security Architecture for the Internet
  1030.                 Protocol, RFC-1825, August 1995.
  1031.  
  1032.    [IPv6-Auth]  Atkinson, R., IP Authentication Header, RFC-1826, August
  1033.                 1995.
  1034.  
  1035.    [IPv6-ESP]   Atkinson, R., IP Encapsulating Security Protocol (ESP),
  1036.                 RFC-1827, August 1995.
  1037.  
  1038. 7. Acknowledgments
  1039.  
  1040.    The document is derived from previous ICMP drafts of the SIPP and
  1041.    IPng working group.
  1042.  
  1043.    The IPng working group and particularly Robert Elz, Jim Bound, Bill
  1044.    Simpson, Thomas Narten, Charlie Lynn, Bill Fink, Scott Bradner,
  1045.    Dimitri Haskin, and Bob Hinden (in chronological order) provided
  1046.    extensive review information and feedback.
  1047.  
  1048. 8. Authors' Addresses
  1049.  
  1050.    Alex Conta                            Stephen Deering
  1051.    Lucent Technologies Inc.              Cisco Systems, Inc.
  1052.    300 Baker Ave, Suite 100              170 West Tasman Drive
  1053.    Concord, MA 01742                     San Jose, CA 95134-1706
  1054.    USA                                   USA
  1055.  
  1056.    phone: +1 508 287-2842                phone: +1 408 527-8213
  1057.    email: aconta@lucent.com              email: deering@parc.xerox.com
  1058.  
  1059.  
  1060.  
  1061. draft-ietf-ipngwg-icmp-v2-00.txt                               [Page 19]
  1062.  
  1063. INTERNET-DRAFT           ICMPv6 (ICMP for IPv6)             October 1997
  1064.  
  1065.  
  1066. Appendix A - Changes since RFC 1885
  1067.  
  1068.     - Remove section 2.4 on Group Management ICMP messages
  1069.     - Remove references to IGMP in Abstract and Section 1.
  1070.     - Update references to other IPv6 documents
  1071.     - Remove references to RFC-1112 in Abstract, and Section 1, and to
  1072.       RFC-1191 in section 1, and section 3.2
  1073.     - Add security section
  1074.     - Add Appendix A - changes
  1075.  
  1076.  
  1077.  
  1078.  
  1079.  
  1080.  
  1081.  
  1082.  
  1083.  
  1084.  
  1085.  
  1086.  
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117. draft-ietf-ipngwg-icmp-v2-00.txt                               [Page 20]
  1118.