doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc2463.txt b/doc/rfc/rfc2463.txt
new file mode 100644
index 0000000..1d5e0dd
--- /dev/null
+++ b/doc/rfc/rfc2463.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                           A. Conta
+Request for Comments: 2463                                        Lucent
+Obsoletes: 1885                                               S. Deering
+Category: Standards Track                                  Cisco Systems
+                                                           December 1998
+
+
+               Internet Control Message Protocol (ICMPv6)
+               for the Internet Protocol Version 6 (IPv6)
+                             Specification
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   This document specifies a set of Internet Control Message Protocol
+   (ICMP) messages for use with version 6 of the Internet Protocol
+   (IPv6).
+
+Table of Contents
+
+      1. Introduction........................................2
+      2. ICMPv6 (ICMP for IPv6)..............................2
+            2.1 Message General Format.......................2
+            2.2 Message Source Address Determination.........3
+            2.3 Message Checksum Calculation.................4
+            2.4 Message Processing Rules.....................4
+      3. ICMPv6 Error Messages...............................6
+            3.1 Destination Unreachable Message..............6
+            3.2 Packet Too Big Message...................... 8
+            3.3 Time Exceeded Message....................... 9
+            3.4 Parameter Problem Message...................10
+      4. ICMPv6 Informational Messages......................11
+            4.1 Echo Request Message........................11
+            4.2 Echo Reply Message..........................12
+      5. Security Considerations............................13
+      6. References.........................................14
+      7. Acknowledgments....................................15
+
+
+
+Conta & Deering             Standards Track                     [Page 1]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+      8. Authors' Addresses.................................16
+      Appendix A - Changes since RFC 1885...................17
+      Full Copyright Statement..............................18
+
+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 number of changes.  The resulting protocol is
+   called ICMPv6, and has an IPv6 Next Header value of 58.
+
+   This document describes the format of a set of control messages used
+   in ICMPv6.  It does not describe the procedures for using these
+   messages to achieve functions like Path MTU discovery; such
+   procedures are described in other documents (e.g., [PMTU]).  Other
+   documents may also introduce additional ICMPv6 message types, such as
+   Neighbor Discovery messages [IPv6-DISC], subject to the general rules
+   for ICMPv6 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.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC-2119].
+
+2. ICMPv6 (ICMP for IPv6)
+
+   ICMPv6 is used by IPv6 nodes to report errors encountered in
+   processing packets, and to perform other internet-layer functions,
+   such as diagnostics (ICMPv6 "ping").  ICMPv6 is an integral part of
+   IPv6 and MUST be fully implemented by every IPv6 node.
+
+2.1 Message General Format
+
+   ICMPv6 messages are grouped into two classes: error messages and
+   informational messages.  Error messages are identified as such by
+   having a zero in the high-order bit of their message Type field
+   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 ICMPv6
+   messages:
+
+
+
+
+
+
+
+Conta & Deering             Standards Track                     [Page 2]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+        ICMPv6 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)
+
+        ICMPv6 informational messages:
+
+             128  Echo Request                 (see section 4.1)
+             129  Echo Reply                   (see section 4.2)
+
+
+   Every ICMPv6 message is preceded by an IPv6 header and zero or more
+   IPv6 extension headers. The ICMPv6 header is identified by a Next
+   Header value of 58 in the immediately preceding header.  (NOTE: this
+   is different than the value used to identify ICMP for IPv4.)
+
+   The ICMPv6 messages have the following general format:
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |     Code      |          Checksum             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +                         Message Body                          +
+      |                                                               |
+
+   The type field indicates the type of the message. Its value
+   determines the format of the remaining data.
+
+   The code field depends on the message type. It is used to create an
+   additional level of message granularity.
+
+   The checksum field is used to detect data corruption in the ICMPv6
+   message and parts of the IPv6 header.
+
+2.2 Message Source Address Determination
+
+   A node that sends an ICMPv6 message has to determine both the Source
+   and Destination IPv6 Addresses in the IPv6 header before calculating
+   the checksum.  If the node has more than one unicast address, it must
+   choose the Source Address of the message as follows:
+
+    (a) If the message is a response to a message sent to one of the
+        node's unicast addresses, the Source Address of the reply must
+        be that same address.
+
+
+
+Conta & Deering             Standards Track                     [Page 3]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+    (b) If the message is a response to a message sent to a multicast or
+        anycast group in which the node is a member, the Source Address
+        of the reply must be a unicast address belonging to the
+        interface on which the multicast or anycast packet was received.
+
+    (c) If the message is a response to a message sent to an address
+        that does not belong to the node, the Source Address should be
+        that unicast address belonging to the node that will be most
+        helpful in diagnosing the error. For example, if the message is
+        a response to a packet forwarding action that cannot complete
+        successfully, the Source Address should be a unicast address
+        belonging to the interface on which the packet forwarding
+        failed.
+
+    (d) Otherwise, the node's routing table must be examined to
+        determine which interface will be used to transmit the message
+        to its destination, and a unicast address belonging to that
+        interface must be used as the Source Address of the message.
+
+2.3 Message Checksum Calculation
+
+   The checksum is the 16-bit one's complement of the one's complement
+   sum of the entire ICMPv6 message starting with the ICMPv6 message
+   type field, prepended with a "pseudo-header" of IPv6 header fields,
+   as specified in [IPv6, section 8.1].  The Next Header value used in
+   the pseudo-header is 58.  (NOTE: the inclusion of a pseudo-header in
+   the ICMPv6 checksum is a change from IPv4; see [IPv6] for the
+   rationale for this change.)
+
+   For computing the checksum, the checksum field is set to zero.
+
+2.4 Message Processing Rules
+
+   Implementations MUST observe the following rules when processing
+   ICMPv6 messages (from [RFC-1122]):
+
+    (a) If an ICMPv6 error message of unknown type is received, it MUST
+        be passed to the upper layer.
+
+    (b) If an ICMPv6 informational message of unknown type is received,
+        it MUST be silently discarded.
+
+    (c) Every ICMPv6 error message (type < 128) includes as much of the
+        IPv6 offending (invoking) packet (the packet that caused the
+        error) as will fit without making the error message packet
+        exceed the minimum IPv6 MTU [IPv6].
+
+
+
+
+
+Conta & Deering             Standards Track                     [Page 4]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+    (d) In those cases where the internet-layer protocol is required to
+        pass an ICMPv6 error message to the upper-layer process, the
+        upper-layer protocol type is extracted from the original packet
+        (contained in the body of the ICMPv6 error message) and used to
+        select the appropriate upper-layer process to handle the error.
+
+        If the original packet had an unusually large amount of
+        extension headers, it is possible that the upper-layer protocol
+        type may not be present in the ICMPv6 message, due to truncation
+        of the original packet to meet the minimum IPv6 MTU [IPv6]
+        limit.  In that case, the error message is silently dropped
+        after any IPv6-layer processing.
+
+    (e) An ICMPv6 error message MUST NOT be sent as a result of
+        receiving:
+
+         (e.1) an ICMPv6 error message, or
+
+         (e.2) a packet destined to an IPv6 multicast address (there are
+               two exceptions to this rule: (1) the Packet Too Big
+               Message - Section 3.2 - to allow Path MTU discovery to
+               work for IPv6 multicast, and (2) the Parameter Problem
+               Message, Code 2 - Section 3.4 - reporting an unrecognized
+               IPv6 option that has the Option Type highest-order two
+               bits set to 10), or
+
+         (e.3) a packet sent as a link-layer multicast, (the exception
+               from e.2 applies to this case too), or
+
+         (e.4) a packet sent as a link-layer broadcast, (the exception
+               from e.2 applies to this case too), or
+
+         (e.5) a packet whose source address does not uniquely identify
+               a single node -- e.g., the IPv6 Unspecified Address, an
+               IPv6 multicast address, or an address known by the ICMP
+               message sender to be an IPv6 anycast address.
+
+    (f) Finally, in order to limit the bandwidth and forwarding costs
+        incurred sending ICMPv6 error messages, an IPv6 node MUST limit
+        the rate of ICMPv6 error messages it sends.  This situation may
+        occur when a source sending a stream of erroneous packets fails
+        to heed the resulting ICMPv6 error messages.  There are a
+        variety of ways of implementing the rate-limiting function, for
+        example:
+
+         (f.1) Timer-based - for example, limiting the rate of
+               transmission of error messages to a given source, or to
+               any source, to at most once every T milliseconds.
+
+
+
+Conta & Deering             Standards Track                     [Page 5]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+         (f.2) Bandwidth-based - for example, limiting the rate at which
+               error messages are sent from a particular interface to
+               some fraction F of the attached link's bandwidth.
+
+        The limit parameters (e.g., T or F in the above examples) MUST
+        be configurable for 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
+   ICMPv6 messages.
+
+3. ICMPv6 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 the ICMPv6 packet          +
+      |                exceeding the minimum IPv6 MTU [IPv6]          |
+
+   IPv6 Fields:
+
+   Destination Address
+
+                  Copied from the Source Address field of the invoking
+                  packet.
+
+   ICMPv6 Fields:
+
+   Type           1
+
+   Code           0 - no route to destination
+                  1 - communication with destination
+                        administratively prohibited
+                  2 - (not assigned)
+                  3 - address unreachable
+                  4 - 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.
+
+
+
+Conta & Deering             Standards Track                     [Page 6]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+   Description
+
+   A Destination Unreachable message SHOULD be generated by a router, or
+   by the IPv6 layer in the originating node, in response to a packet
+   that cannot be delivered to its destination address for reasons other
+   than congestion.  (An ICMPv6 message MUST NOT be generated if a
+   packet is dropped due to congestion.)
+
+   If the reason for the failure to deliver is 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 nodes that do not hold a "default
+   route" in their routing tables).
+
+   If the reason for the failure to deliver is administrative
+   prohibition, e.g., a "firewall filter", the Code field is set to 1.
+
+   If there is any other reason for the failure to deliver, e.g.,
+   inability to resolve the IPv6 destination address into a
+   corresponding link address, or a link-specific problem of some sort,
+   then the Code field is set to 3.
+
+   A destination node SHOULD send a Destination Unreachable message with
+   Code 4 in response to a packet for which the transport protocol
+   (e.g., UDP) has no listener, if that transport protocol has no
+   alternative means to inform the sender.
+
+   Upper layer notification
+
+   A node receiving the ICMPv6 Destination Unreachable message MUST
+   notify the upper-layer process.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta & Deering             Standards Track                     [Page 7]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+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 the ICMPv6 packet           +
+      |               exceeding the minimum IPv6 MTU [IPv6]           |
+
+   IPv6 Fields:
+
+   Destination Address
+
+                  Copied from the Source Address field of the invoking
+                  packet.
+
+   ICMPv6 Fields:
+
+   Type           2
+
+   Code           Set to 0 (zero) by the sender and ignored by the
+                  receiver
+
+   MTU            The Maximum Transmission Unit of the next-hop link.
+
+  Description
+
+   A Packet Too Big MUST be sent by a router in response to a packet
+   that it cannot forward because the packet is larger than the MTU of
+   the outgoing link.  The information in this message is used as part
+   of the Path MTU Discovery process [PMTU].
+
+   Sending a Packet Too Big Message makes an exception to one of the
+   rules of when to send an ICMPv6 error message, in that unlike other
+   messages, it is sent in response to a packet received with an IPv6
+   multicast destination address, or a link-layer multicast or link-
+   layer broadcast address.
+
+   Upper layer notification
+
+   An incoming Packet Too Big message MUST be passed to the upper-layer
+   process.
+
+
+
+
+
+Conta & Deering             Standards Track                     [Page 8]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+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 the ICMPv6 packet           +
+      |               exceeding the minimum IPv6 MTU [IPv6]           |
+
+   IPv6 Fields:
+
+   Destination Address
+                  Copied from the Source Address field of the invoking
+                  packet.
+
+   ICMPv6 Fields:
+
+   Type           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 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 MUST discard the packet
+   and send an ICMPv6 Time Exceeded message with Code 0 to the source of
+   the packet.  This indicates either a routing loop or too small an
+   initial Hop Limit value.
+
+   The rules for selecting the Source Address of this message are
+   defined in section 2.2.
+
+   Upper layer notification
+
+   An incoming Time Exceeded message MUST be passed to the upper-layer
+   process.
+
+
+
+
+
+Conta & Deering             Standards Track                     [Page 9]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+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 the ICMPv6 packet           +
+      |               exceeding the minimum IPv6 MTU [IPv6]           |
+
+   IPv6 Fields:
+
+   Destination Address
+
+                  Copied from the Source Address field of the invoking
+                  packet.
+
+   ICMPv6 Fields:
+
+   Type           4
+
+   Code           0 - erroneous header field encountered
+
+                  1 - unrecognized Next Header type encountered
+
+                  2 - unrecognized IPv6 option encountered
+
+   Pointer        Identifies the octet offset within the
+                  invoking packet where the error was detected.
+
+                  The pointer will point beyond the end of the ICMPv6
+                  packet if the field in error is beyond what can fit
+                  in the maximum size of an ICMPv6 error message.
+
+   Description
+
+   If an IPv6 node processing a packet finds a problem with a field in
+   the IPv6 header or extension headers such that it cannot complete
+   processing the packet, it MUST discard the packet and SHOULD send an
+   ICMPv6 Parameter Problem message to the packet's source, indicating
+   the type and location of the problem.
+
+   The pointer identifies the octet of the original packet's header
+   where the error was detected. For example, an ICMPv6 message with
+   Type field = 4, Code field = 1, and Pointer field = 40 would indicate
+
+
+
+Conta & Deering             Standards Track                    [Page 10]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+   that the IPv6 extension header following the IPv6 header of the
+   original packet holds an unrecognized Next Header field value.
+
+   Upper layer notification
+
+   A node receiving this ICMPv6 message MUST notify the upper-layer
+   process.
+
+4. ICMPv6 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:
+
+   Destination Address
+
+                  Any legal IPv6 address.
+
+   ICMPv6 Fields:
+
+   Type           128
+
+   Code           0
+
+   Identifier     An identifier to aid in matching Echo Replies
+                  to this Echo Request.  May be zero.
+
+   Sequence Number
+
+                  A sequence number to aid in matching Echo Replies
+                  to this Echo Request.  May be zero.
+
+   Data           Zero or more octets of arbitrary data.
+
+
+
+
+
+
+
+
+Conta & Deering             Standards Track                    [Page 11]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+   Description
+
+   Every node MUST implement an ICMPv6 Echo responder function that
+   receives Echo 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
+
+   Echo Request messages MAY be passed to processes receiving ICMP
+   messages.
+
+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:
+
+   Destination Address
+
+                  Copied from the Source Address field of the invoking
+                  Echo Request packet.
+
+   ICMPv6 Fields:
+
+   Type           129
+
+   Code           0
+
+   Identifier     The identifier from the invoking Echo Request message.
+
+   Sequence       The sequence number from the invoking Echo Request
+   Number         message.
+
+   Data           The data from the invoking Echo Request message.
+
+
+
+
+
+
+
+
+Conta & Deering             Standards Track                    [Page 12]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+   Description
+
+   Every node MUST implement an ICMPv6 Echo responder function that
+   receives Echo 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.
+
+   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 data received in the ICMPv6 Echo Request message MUST be returned
+   entirely and unmodified in the ICMPv6 Echo Reply message.
+
+   Upper layer notification
+
+   Echo Reply messages MUST be passed to the process that originated an
+   Echo Request message.  It may be passed to processes that did not
+   originate the Echo Request message.
+
+5. Security Considerations
+
+5.1 Authentication and Encryption of ICMP messages
+
+   ICMP protocol packet exchanges can be authenticated using the IP
+   Authentication Header [IPv6-AUTH].  A node SHOULD include an
+   Authentication Header when sending ICMP messages if a security
+   association for use with the IP Authentication Header exists for the
+   destination address.  The security associations may have been created
+   through manual configuration or through the operation of some key
+   management protocol.
+
+   Received Authentication Headers in ICMP packets MUST be verified for
+   correctness and packets with incorrect authentication MUST be ignored
+   and discarded.
+
+   It SHOULD be possible for the system administrator to configure a
+   node to ignore any ICMP messages that are not authenticated using
+   either the Authentication Header or Encapsulating Security Payload.
+   Such a switch SHOULD default to allowing unauthenticated messages.
+
+
+
+
+
+
+Conta & Deering             Standards Track                    [Page 13]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+   Confidentiality issues are addressed by the IP Security Architecture
+   and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6-
+   ESP].
+
+5.2 ICMP Attacks
+
+   ICMP messages may be subject to various attacks.  A complete
+   discussion can be found in the IP Security Architecture [IPv6-SA].  A
+   brief discussion of such attacks and their prevention is as follows:
+
+   1. ICMP messages may be subject to actions intended to cause the
+      receiver believe the message came from a different source than the
+      message originator.  The protection against this attack can be
+      achieved by applying the IPv6 Authentication mechanism [IPv6-Auth]
+      to the ICMP message.
+
+   2. ICMP messages may be subject to actions intended to cause the
+      message or the reply to it go to a destination different than the
+      message originator's intention.  The ICMP checksum calculation
+      provides a protection mechanism against changes by a malicious
+      interceptor in the destination and source address of the IP packet
+      carrying that message, provided the ICMP checksum field is
+      protected against change by authentication [IPv6-Auth] or
+      encryption [IPv6-ESP] of the ICMP message.
+
+   3. ICMP messages may be subject to changes in the message fields, or
+      payload.  The authentication [IPv6-Auth] or encryption [IPv6-ESP]
+      of the ICMP message is a protection against such actions.
+
+   4. ICMP messages may be used as attempts to perform denial of service
+      attacks by sending back to back erroneous IP packets.  An
+      implementation that correctly followed section 2.4, paragraph (f)
+      of this specifications, would be protected by the ICMP error rate
+      limiting mechanism.
+
+6. References
+
+   [IPv6]       Deering, S. and R. Hinden, "Internet Protocol, Version
+                6, (IPv6) Specification", RFC 2460, December 1998.
+
+   [IPv6-ADDR]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+                Architecture", RFC 2373, July 1998.
+
+   [IPv6-DISC]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor
+                Discovery for IP Version 6 (IPv6)", RFC 2461, December
+                1998.
+
+
+
+
+
+Conta & Deering             Standards Track                    [Page 14]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+   [RFC-792]    Postel, J., "Internet Control Message Protocol", STD 5,
+                RFC 792, September 1981.
+
+   [RFC-1122]   Braden, R., "Requirements for Internet Hosts -
+                Communication Layers", STD 5, RFC 1122, August 1989.
+
+   [PMTU]       McCann, J., Deering, S. and J. Mogul, "Path MTU
+                Discovery for IP version 6", RFC 1981, August 1996.
+
+   [RFC-2119]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [IPv6-SA]    Kent, S. and R. Atkinson, "Security Architecture for the
+                Internet Protocol", RFC 2401, November 1998.
+
+   [IPv6-Auth]  Kent, S. and R. Atkinson, "IP Authentication Header",
+                RFC 2402, November 1998.
+
+   [IPv6-ESP]   Kent, S. and R. Atkinson, "IP Encapsulating Security
+                Protocol (ESP)", RFC 2406, November 1998.
+
+7. Acknowledgments
+
+   The document is derived from previous ICMP drafts of the SIPP and
+   IPng working group.
+
+   The IPng working group and particularly Robert Elz, Jim Bound, Bill
+   Simpson, Thomas Narten, Charlie Lynn, Bill Fink, Scott Bradner,
+   Dimitri Haskin, and Bob Hinden (in chronological order) provided
+   extensive review information and feedback.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta & Deering             Standards Track                    [Page 15]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+8. Authors' Addresses
+
+   Alex Conta
+   Lucent Technologies Inc.
+   300 Baker Ave, Suite 100
+   Concord, MA 01742
+   USA
+
+   Phone: +1 978 287-2842
+   EMail: aconta@lucent.com
+
+
+   Stephen Deering
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   USA
+
+   Phone: +1 408 527-8213
+   EMail: deering@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta & Deering             Standards Track                    [Page 16]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+Appendix A - Changes from RFC 1885
+
+   Version 2-02
+
+    - Excluded mentioning informational replies from paragraph (f.2) of
+      section 2.4.
+    - In "Upper layer notification" sections changed "upper-layer
+      protocol" and "User Interface" to "process".
+    - Changed section 5.2, item 2 and 3 to also refer to AH
+      authentication.
+    - Removed item 5. from section 5.2 on denial of service attacks.
+    - Updated phone numbers and Email addresses in the "Authors'
+      Addresses" section.
+
+   Version 2-01
+
+    - Replaced all references to "576 octets" as the maximum for an ICMP
+      message size with "minimum IPv6 MTU" as defined by the base IPv6
+      specification.
+    - Removed rate control from informational messages.
+    - Added requirement that receivers ignore Code value in Packet Too
+      Big message.
+    - Removed "Not a Neighbor" (code 2) from destination unreachable
+      message.
+    - Fixed typos and update references.
+
+   Version 2-00
+
+    - Applied rate control to informational messages
+    - Removed section 2.4 on Group Management ICMP messages
+    - Removed references to IGMP in Abstract and Section 1.
+    - Updated references to other IPv6 documents
+    - Removed references to RFC-1112 in Abstract, and Section 1, and to
+      RFC-1191 in section 1, and section 3.2
+    - Added security section
+    - Added Appendix A - changes
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta & Deering             Standards Track                    [Page 17]
+
+RFC 2463                 ICMPv6 (ICMP for IPv6)            December 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conta & Deering             Standards Track                    [Page 18]
+