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.