> My question is: what happens if any of them discovers that it has created an > address that is already in use in the network? > > There would appear to be two options: > (1) "ah, OK, I guess I didn't really want to talk today" > (2) Following RFC 4941, guess again until one creates a unique address > > Is it fair to assume that implementations do DAD and follow (2)?
>From the perspective of the CE router... BBF decided on the following recommendation: If DAD (on the WAN) fails for link-local or SLAAC, "vendor should implement graceful handling, including trying other addresses". Router vendors felt this provided reasonable advice without limiting how they accomplished it. Some thought it would be reasonable to try using MAC addresses associated with other interfaces (from a LAN Ethernet or Wi-Fi interface), increment the previously tried value by 1 or x, and other possibilities. Once there was greater experience with real deployments, where it could be seen what worked and was easy, there would probably be convergence on "best practices". But it was acknowledged that (1) such duplication of MAC addresses exists and is reasonably prevalent (all service providers see this), (2) it is unlikely that we can stop this from happening, (3) allowing such a CE router to become a brick would generate trouble calls and serve no useful purpose, and (4) implementing code that would try a different value was simple and had no perceived downside (as long as all CE routers had code to try other values). As has been pointed out, using 1:1 VLAN would prevent this problem. But my perspective is that the CE router doesn't know what access network it will land in, and needs to be resilient when finding itself in a N:1 VLAN environment. As Ole pointed out, RFC 4941 explicitly mandates generation of a different privacy address when DAD fails. RFC 3315 recommends use of DAD and telling the DHCPv6 server (Decline) if DAD fails. But this case isn't perceived to be a problem (unless the DHCPv6 server is misconfigured or someone managed to get that IPv6 Attack Toolkit that Dominik mentioned into the access network -- in which case we have bigger problems). A bigger problem for DHCPv6 servers may be the one of duplicate DUIDs, which may cause a DHCPv6 server to refuse to provide a IA_NA. This apparently is sufficiently prevalent that Microsoft had to provide info on how to fix it: http://support.microsoft.com/kb/2711727 Barbara -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
