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
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.
10. APPENDIX B: CHANGES SINCE RFC1971
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.
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.