On 8/12/2015 12:39 PM, Henning Rogge wrote: > On Wed, Aug 12, 2015 at 8:23 PM, Joe Touch <[email protected]> wrote: >> That's true, but specific protocol behaviors do address this issue >> already, e.g., RFC 7559 uses exponential backoffs for soliciting RAs. >> >> DAD is a "negative information" protocol, i.e., a lossy link can give a >> false positive. This issue is already addressed Sec 4.4 of RFC 4429: the >> effect of L2 losses can be mitigated by recommending a different value >> for DupAddrDetectTransmits. RFC 4862 Sec 5.1 already notes that this >> parameter might need to be defaulted to a different value for particular >> link types, and such might need to be the case for 802.11. > > Luckily DAD is mostly needed for randomized IPv6 addresses... if you > use the MAC address for generating the IP you are either fine or you > have a MAC level collision, which means you have an unsolvable > problem.
DAD is also needed to detect duplicates due to host misconfiguration, such as when a cloned MAC is added to the same network or when addresses are duplicated by other means (e.g., DHCPv6 misconfiguration). I couldn't confirm, but isn't this also not a local decision? I.e., if DAD fails you might end up with a duplicate address even when you set your IP addresses based on the burned-in MAC because others could select the same address randomly (I didn't see how that was avoided by the self-assignment algorithm). Joe _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
