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.