2

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.

  • The modern auto-configuration of IPv6 addressing uses random addresses with privacy extensions, so it is necessary to determine that another host on the same network is not already using the address. Given that there are a possible 18,446,744,073,709,551,616 addresses on a /64 network, it is unlikely that you would have an address conflict, but the RFC requires it because there is always the chance. It takes very little time at the assignment of the address to do this. – Ron Maupin Feb 17 at 14:53
  • @RonMaupin thank you for reply. And without any human factor, what if we just discuss about link local address is created from MAC, is there any concern if turn off DAD on link local address? thank you sir. – tw en Feb 17 at 15:11
  • Yes, of course there is. What if my PC randomly chooses the address your PC wants to use based on its MAC address? It seems Windows is now using random addressing even for its Link-Local addresses. I cannot answer for other OSes. There really is absolutely nothing to gain from disabling DAD, and the possibility is that you could introduce a serious, hard-to-troubleshoot problem by disabling it. – Ron Maupin Feb 17 at 15:14
  • @RonMaupin thank you, now I'm getting better understanding. And if there's a scenario: A- client, B- DhcpV6 httpboot server, A wants to boot in B. in this environment, if we discuss about link local address is created from MAC, is there any concern if turn off DAD on link local address, thank you very much. – tw en Feb 17 at 15:44
3

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.

|improve this answer|||||
  • @JensLink, sounds reasonable, but it seems that it depends mostly on human factor. According to SPEC: tools.ietf.org/html/rfc4291#page-21, it mentions MAC availability and uniqueness properties. Base on that, what if we just discuss about link local address is created from MAC, is there any concern if turn off DAD on link local address? thank you for your prompt reply. – tw en Feb 17 at 14:50
1

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.

|improve this answer|||||
  • Thank you for reply, please allow me to ask a question, if there's a scenario: A- client, B- DhcpV6 httpboot server, A wants to boot in B. in this environment, if we discuss about link local address is created from MAC, is there any concern if turn off DAD on link local address, thank you very much – tw en Feb 19 at 13:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.