> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[EMAIL PROTECTED]> > So, I'd now like to propose a concrete change. The simplest way to > implement the option would be to remove the second exception shown in > Section 5.4 of RFC2462. That is, the revised text would be: > > 5.4 Duplicate Address Detection > > Duplicate Address Detection is performed on unicast addresses prior > to assigning them to an interface whose DupAddrDetectTransmits > variable is greater than zero. Duplicate Address Detection MUST take > place on all unicast addresses, regardless of whether they are > obtained through stateful, stateless or manual configuration. On the > other hand, Duplicate Address Detection MUST NOT be performed on > anycast addresses. > > The procedure for detecting duplicate addresses uses Neighbor > Solicitation and Advertisement messages as described below... > > Can we live with this simple resolution?
You are ignoring the installed base. There are already out and delivered, and in real use, implementations which do the DAD only for the link local. And if the ID is used combined with global prefixes, the it is assumed DAD on link local is sufficient. This is valid as per currently valid RFC, and still consider this a sensible implementation. Apparently, nobody else truly supports the multiple IDs and prefixes, with full combination? In such case, doing DAD on each new combination for each announced prefix on RA is frightening. And even with single id and new prefix this is not good: on RA with a new global prefix, every node on the link is going to do DAD based on its ID and new prefix. And, as far as I know, there is no delay requirement here, so everyone is doing it at same time. -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
