On Aug 12, 2015, at 21:35, Henning Rogge <hro...@gmail.com> wrote:
> On Wed, Aug 12, 2015 at 10:13 PM, Joe Touch <to...@isi.edu> wrote:
>> 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).
> 
> If you have a duplicate MAC then DAD will not safe you... you cannot
> communicate anyways because of a layer-2 problem.

Yes, and DAD also has logic that limits the damage on the entire network when 
hosts join with duplicate L2 addresses, c.f. section 5.4.5 of RFC 4862.

>    If the address is a link-local address formed from an interface
>    identifier based on the hardware address, which is supposed to be
>    uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP
>    operation on the interface SHOULD be disabled.

It’s worth noting that the presence of network sleep proxies can make this 
recommendation problematic. It would be better to disable the whole interface 
only when the actual L2 address is discovered to be duplicated, not just the 
link-local IPv6 address w/ embedded EUI-64 IID, which would allow DAD failures 
with sleep proxies on link-local addresses to be treated like a DAD failure 
with a sleep proxy on any other address. Alas, earwax.

—james

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to