rfc2462.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,404 行 · 第 1/4 页

   stateless and stateful protocols since both may be enabled at the
   same time.  It is also possible that the values of other
   configuration parameters such as MTU size and hop limit will be
   learned from both Router Advertisements and the stateful
   autoconfiguration protocol.  If the same configuration information is
   provided by multiple sources, the value of this information should be
   consistent. However, it is not considered a fatal error if
   information received from multiple sources is inconsistent. Hosts
   accept the union of all information received via the stateless and



Thomson & Narten            Standards Track                    [Page 19]

RFC 2462        IPv6 Stateless Address Autoconfiguration   December 1998


   stateful protocols. If inconsistent information is learned different
   sources, the most recently obtained values always have precedence
   over information learned earlier.

6.  SECURITY CONSIDERATIONS

   Stateless address autoconfiguration allows a host to connect to a
   network, configure an address and start communicating with other
   nodes without ever registering or authenticating itself with the
   local site.  Although this allows unauthorized users to connect to
   and use a network, the threat is inherently present in the
   Internet        architecture. Any node with a physical attachment to
   a network can generate an address (using a variety of ad hoc
   techniques) that provides connectivity.

   The use of Duplicate Address Detection opens up the possibility of
   denial of service attacks. Any node can respond to Neighbor
   Solicitations for a tentative address, causing the other node to
   reject the address as a duplicate.  This attack is similar to other
   attacks involving the spoofing of Neighbor Discovery messages and can
   be addressed by requiring that Neighbor Discovery packets be
   authenticated [RFC2402].

7.  References

   [RFC2402]    Kent, S. and R. Atkinson, "IP Authentication Header",
                RFC 2402, November 1998.

   [IPv6-ETHER] Crawford, M., "A Method for the Transmission of
                IPv6        Packets over Ethernet Networks", RFC 2464,
                December 1998.

   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March
                1997.

   [RFC1112]    Deering, S., "Host Extensions for IP Multicasting", STD
                5, RFC 1112, August
                1989.

   [ADDR-ARCH]  Hinden, R. and S. Deering, "Internet Protocol Version
                (IPv6) Addressing Architecture", RFC 2373, July 1998

   [DHCPv6]     Bound, J. and C. Perkins, "Dynamic Host Configuration
                Protocol for IPv6 (DHCPv6)", Work in Progress.






Thomson & Narten            Standards Track                    [Page 20]

RFC 2462        IPv6 Stateless Address Autoconfiguration   December 1998


   [DISCOVERY]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor
                Discovery for IP Version 6 (IPv6)", RFC 2461, December
                1998.

8.  Acknowledgements

   The authors would like to thank the members of both the IPNG and
   ADDRCONF working groups for their input. In particular, thanks to Jim
   Bound, Steve Deering, Richard Draves, and Erik Nordmark.  Thanks also
   goes to John Gilmore for alerting the WG of the "0 Lifetime Prefix
   Advertisement" denial of service attack vulnerability; this document
   incorporates changes that address this vulnerability.

AUTHORS' ADDRESSES

   Susan Thomson
   Bellcore
   445 South Street
   Morristown, NJ 07960
   USA

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


   Thomas Narten
   IBM Corporation
   P.O. Box 12195
   Research Triangle Park, NC 27709-2195
   USA

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


















Thomson & Narten            Standards Track                    [Page 21]

RFC 2462        IPv6 Stateless Address Autoconfiguration   December 1998


9.  APPENDIX A: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION

   Determining whether a received multicast solicitation was looped back
   to the sender or actually came from another node is implementation-
   dependent.  A problematic case occurs when two interfaces attached to
   the same link happen to have the same identifier and link-layer
   address, and they both send out packets with identical contents at
   roughly the same time (e.g., Neighbor Solicitations for a tentative
   address as part of Duplicate Address Detection messages). Although a
   receiver will receive both packets, it cannot determine which packet
   was looped back and which packet came from the other node by simply
   comparing packet contents (i.e., the contents are identical). In this
   particular case, it is not necessary to know precisely which packet
   was looped back and which was sent by another node; if one receives
   more solicitations than were sent, the tentative address is a
   duplicate. However, the situation may not always be this
   straightforward.

   The IPv4 multicast specification [RFC1112] recommends that the
   service interface provide a way for an upper-layer protocol to
   inhibit local delivery of packets sent to a multicast group that the
   sending host is a member of. Some applications know that there will
   be no other group members on the same host, and suppressing loopback
   prevents them from having to receive (and discard) the packets they
   themselves send out.  A straightforward way to implement this
   facility is to disable loopback at the hardware level (if supported
   by the hardware), with packets looped back (if requested) by
   software.  On interfaces in which the hardware itself suppresses
   loopbacks, a node running Duplicate Address Detection simply counts
   the number of Neighbor Solicitations received for a tentative address
   and compares them with the number expected. If there is a mismatch,
   the tentative address is a duplicate.

   In those cases where the hardware cannot suppress loopbacks, however,
   one possible software heuristic to filter out unwanted loopbacks is
   to discard any received packet whose link-layer source address is the
   same as the receiving interface's.  Unfortunately, use of that
   criteria also results in the discarding of all packets sent by
   another node using the same link-layer address. Duplicate Address
   Detection will fail on interfaces that filter received packets in
   this manner:

      o If a node performing Duplicate Address Detection discards
        received packets having the same source link-layer address as
        the receiving interface, it will also discard packets from other
        nodes also using the same link-layer address, including Neighbor
        Advertisement and Neighbor Solicitation messages required to
        make Duplicate Address Detection work correctly.  This



Thomson & Narten            Standards Track                    [Page 22]

RFC 2462        IPv6 Stateless Address Autoconfiguration   December 1998


        particular problem can be avoided by temporarily disabling the
        software suppression of loopbacks while a node performs
        Duplicate Address Detection.

      o If a node that is already using a particular IP address discards
        received packets having the same link-layer source address as
        the interface, it will also discard Duplicate Address
        Detection-related Neighbor Solicitation messages sent by another
        node also using the same link-layer address.  Consequently,
        Duplicate Address Detection will fail, and the other node will
        configure a non-unique address. Since it is generally impossible
        to know when another node is performing Duplicate Address
        Detection, this scenario can be avoided only if software
        suppression of loopback is permanently disabled.

   Thus, to perform Duplicate Address Detection correctly in the case
   where two interfaces are using the same link-layer address, an
   implementation must have a good understanding of the interface's
   multicast loopback semantics, and the interface cannot discard
   received packets simply because the source link-layer address is the
   same as the interfaces.






























Thomson & Narten            Standards Track                    [Page 23]

RFC 2462        IPv6 Stateless Address Autoconfiguration   December 1998


10.  APPENDIX B: CHANGES SINCE RFC 1971

   o Changed document to use term "interface identifier" rather than
     "interface token" for consistency with other IPv6 documents.

   o Clarified definition of deprecated address to make clear it is OK
     to continue sending to or from deprecated addresses.

   o Reworded section 5.4 for clarity (no substantive change).

   o Added rules to Section 5.5.3 Router Advertisement processing to
     address potential denial-of-service attack when prefixes are
     advertised with very short Lifetimes.

   o Clarified wording in Section 5.5.4 to make clear that all upper
     layer protocols must process (i.e., send and receive) packets sent
     to deprecated addresses.


































Thomson & Narten            Standards Track                    [Page 24]

RFC 2462        IPv6 Stateless Address Autoconfiguration   December 1998


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
























Thomson & Narten            Standards Track                    [Page 25]