rfc2463.txt

中、英文RFC文档大全打包下载完全版 .

   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: [phone]
   EMail: [e-mail]


   Stephen Deering
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   USA

   Phone: [phone]
   EMail: [e-mail]































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]