Re: Duplicate Address Detection bug

[JINMEI Tatuya / 神明達哉 <jinmei%wide.ad.jp@localhost>]

At Fri, 16 Oct 2009 15:37:08 -0400,
Patrik Lahti <plahti%qnx.com@localhost> wrote:

> I have observed the following behavior in NetBSD5. When I first bring up 
> an interface it will auto-configure a link-local address and perform 
> Duplicate Address Detection (DAD) correctly for it. But after 
> subsequently bringing it down and then up again, it does not perform DAD 
> again for that address. Disconnecting the cable and re-connecting it 
> again, has the same problem.
> 
> As I understand RFC 4862 a node should do DAD each time the interface is 
> enabled (connected), not just the first time it is enabled. Otherwise, 
> while being disabled (or disconnected), another node may come along and 
> successfully do DAD for the same address and start using it, and when 
> the original node's interface is re-enabled (or re-connected) there will 
> be duplicate addresses in use. Exactly the situation DAD is created to 
> avoid!
> 
> I would appreciate any insight into this.

As you pointed out the implementation behavior does not follow the RFC
in a strict sense, but it was an implementation decision.

I don't remember how exactly we came to that decision (I was
previously in the development team of the IPv6 stack), but in my vague
memory the rationale was something like this:

- we may not always want to automatically trigger DAD when manually
  disabling/enabling an interface (for some administrative reason).
  So, rather than doing it automatically and unconditionally, we also
  left it to the administrator's decision: you can trigger DAD in this
  case by:
  # ifconfig <ifname> down
  # ifconfig <ifname> <address> tentative
  # ifconfig <ifname> up

- in the case of unplugging-then-plugging a cable, we might rather
  make it automatic, but again, we might rather avoid that.  for
  example, consider a relatively low-quality WIFI network and you see
  intermittent link downs/ups but can some how keep some level of
  communication.  in such a case you might rather avoid the additional
  delay due to DAD at the (very low) risk of having duplicate.

- as noted in RFC4862, DAD is not a perfect algorithm to avoid
  duplicates anyway.  on the other hand, it should be normally
  extremely rare we actually encounter a duplicate address especially
  when most of the nodes use MAC-based IFID or DHCPv6 (which should be
  the typical operational case).  so, IMO, the gained benefit by
  making it perfect as described in RFC4862 may not be worth the
  implementation complexity.

This is not to prevent you from trying to fix it, though.  If you
still think it makes sense, taking into account the background and the
cost/benefit balance, please go ahead.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.