DAD and link local address

Question

I'm a new guy in IPV6, and now I encounter a question, when ipv6 policy is Auto configuration, is it necessary to DAD on Link local address?

my question is, since link local address is created from MAC, why need to DAD? or is it necessary? Can I turn off the DAD on Link local address?

I've been looking for this answer in spec for a long time, but I still cannot find the answer.

Could somebody can kindly explain for this specifically

Thank you very much.

Answer 1

What are you trying to accomplish with turning of DAD?

RFC4862 Sec, 5.4

Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface, regardless of whether they are obtained through stateless autoconfiguration, DHCPv6, or manual configuration, with the following exceptions: [...]

And a MAC address is supposed to be unique but sometimes it's not. Think of cloned VMs, vendors reusing Prefixes or cheap stuff with faked addresses. A former colleague once bought a couple of very cheap 4 port NICs. all with the same MAC on all interfaces.

Answer 2

First of all, the question is based on the false premise that a link-local address is always based on the MAC address. In fact, there is no non-obsolete RFC that states this and even more RFC 8064 (admittedly more recent) exlicitly recommends against this practice, at least in autoconfig environments.

Why many implementations do it? Because MAC-based EUI64's were defined early on and actually recommended so, see the now obsoleted RFC2373 (this has been demoted to 'may' by RFC 4862). Also, for many non-host systems it is still a viable choice.

When [...] MAC addresses are available (on an interface or a node), an implementation should use them [...] to create interface identifiers

So now for your actual questions

why need to DAD?

Because per the above interface-identifiers can be based on 'whatever'. I actually have known of multiple issues (I work on big IP gateways):

• I've seen several hard-coded interface-identifiers (e.g. simply use ::1)
• There are multiple cheap devices out there that simply use the same MAC everywhere. Or worse, that reuse MAC ranges. This has gotten worse with VMs.
• I've also encountered an (old) implementation that used random interface-identifiers but at some point the random generator was bugged, leading to very poor entropy (that was fixed as far as I know).

or is it necessary? Can I turn off the DAD on Link local address?

These go together: Yes, you can turn it off, RFC 4862 covers this by allowing DupAddrDetectTransmits to be set to 0. Not all implementations will allow this and usually it will be very well hidden. Typically these kind of things are there not for end users (even power users) but for very specific usecases where DAD does not make sense at all. For example, PPP IPv6CP allows DAD to be disabled because it's a point to point link where the other end tells you its interface-identifier during link setup. Other cases may be very low energy devices where the cost of even a dad transmission may far outweigh the risk of handling actual duplicates.

The better question is "should I turn it off?" and the answer is "if you have to ask: no", you know when you are in a usecase such as above. If you disable DAD and there is a duplicate in your network you'll have a hell debugging it. If you keep it enabled the OS will either give you a clear error, or any modern OS that implements RFC 7217 will simply try again until it has a non-conflicting address.