>The main point Thomas made is that DAD failure for an EUI-64 based >address is likely to indicate MAC address collision, in which case >disabling the entire interface is better rather than trying hopeless >recovery which may even make it harder to diagnose the real problem. >(I believe the current text of rfc2462bis clearly made the point, BTW) > >In that sense, "try again with random-number-generated linklocal >address" doesn't make sense. We could "call operator with a beep", >but we'd not be able to do that via network if the MAC address >collides. So, IMO, it is not very convincing to argue we could rely >on such an outbound mechanism in a discussion about a network protocol >specification. > >Meanwhile, we could also make a more fundamental question on whether >the analysis that Thomas provided (i.e., DAD failure for EUI-64 based >address probably means MAC collision) is valid. If not, this can be >another reason to reconsider the current text. I personally think >his analysis is quite reasonable though.
today we are using Ethernet-based technology, hence EUI64 is generated by MAC address. however we don't know what kind of technology we will be using for coming decade (it could be 10Tbase-TX, it could be something else, we just cannot predict). i personally think the analysis (by Thomas Narten) is short-sighted. moreover, if MAC address is under collision, IPv4 does not work, Appletalk does not work (i guess). so there's no point in IPv6 making a judgement call to disable *interface*. it is like IPv6 is saying "i'm the law on this interface, other protocol must obey me". if it is to disable *the use of IPv6 on the interface*, or disable *the particular address which failed DAD*, it makes more sense. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------