[ipv6hackers] DAD and Link-Local
owend at he.net
Sat Jul 14 10:29:40 CEST 2012
I believe you are correct, but, it is not the first RFC to be commonly broken.
In terms of Point to Point links, I believe that BCP dictates disabling DAD so as to avoid
having a meaningless accidental address duplication causing a shutdown of the link
to transit traffic.
On Jul 14, 2012, at 1:05 AM, Marc Heuse wrote:
> dont nail me to that, but I remember that the rfc says that DAD has to
> be performed everytime, for manual, SLAAC and dhcp address configuration.
> they can all conflict, my chance or by mistake.
> the chances of conflict are slim, but ipv6 tries not to work 99.99% of
> the time but 100% :-)
> Am 13.07.2012 20:35, schrieb Owen DeLong:
>> DAD can be disabled if you are sure that there is no chance of collision.
>> With randomly chosen IID, you're not sure, but it's highly unlikely.
>> With MAC-based IID, you can check once and be sure until the hardware changes.
>> On a point-to-point link disabling DAD is probably harmless even if there is a collision.
>> On Jul 13, 2012, at 6:49 AM, <daniel.bartram at bt.com> <daniel.bartram at bt.com> wrote:
>>> After some advice...
>>> Aware that DAD is performed on link-local as well as global addresses to ensure uniqueness, but if the link-local is a randomly generated value, or even the IID for that matter, on a P2P link using only link-local addresses, what are the chances of those addresses ever matching? In which case, can DAD be disabled?
>>> Ipv6hackers mailing list
>>> Ipv6hackers at lists.si6networks.com
>> Ipv6hackers mailing list
>> Ipv6hackers at lists.si6networks.com
> Marc Heuse
> Mobil: +49 177 9611560
> Fax: +49 30 37309726
> Marc Heuse - IT-Security Consulting
> Winsstr. 68
> 10405 Berlin
> Ust.-Ident.-Nr.: DE244222388
> PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A
More information about the Ipv6hackers