[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Duplicate Address Detection bug
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
> 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
# 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
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.
Internet Systems Consortium, Inc.
Main Index |
Thread Index |