* Antony Antony
DAD seems a good theory to look into. Thanks for the tip Lorenzo! I will try reproduce the issue.
Agreed, failing DAD could explain the problem.
This idea has been around but we never got around verifying it thoroughly. We did not want create loops at RIPE NCC office network to verify it. So if it is true, some how the probe triggers Duplicate Address Detection(DAD) and disable it's own IPv6 address. May be due to temporary layer two loop? One puzzle is in some cases the probe disable the address after a while(it can be hours later, say 6 hours after a reboot) and in some other cases right after a reboot.
In my case, there are no physical loops in the network, but since it's connected straight to a CPE (which contains internal software bridges and switch modules and the like) it's certainly not impossible that some packets are being looped during initialisation/bootup. In my experience, CPEs do all sorts of crazy things...
Is the DAD continuously running in the Linux Kernel? or only when configuring an IPv6 address? I will try to figure out. I have herd other annoyances due DAD.
DAD is run when an address is added to an interface, or when the interface transitions to the UP state, I believe. When completed (either successfully or unsuccessfully), it is never retried. As I understand it, anyway. (DAD can be a very nice DoS attack actually!) One theory could be that the CPE rebooted, which made the probe's uplink go DOWN/UP, triggering DAD. If the CPE was retransmitting the probe's own packets back to itself at this point, DAD could have failed, and the probe would be left without IPv6 connectivity. OTOH unplugging/replugging the probe didn't solve the problem for me, but perhaps once the address goes into a DAD-failed state, a link DOWN/UP event won't help either. Or maybe I was too quick, so that the probe didn't register the DOWN/UP events. Tore