Duplicate Address Detection bug

Discussion:

(too old to reply)

Patrik Lahti

2009-10-16 19:37:08 UTC

Hi,

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.

I can file a bug report if that's appropriate. Please note that while
I've used NetBSD and have hacked networking code based upon it, I am a
little new to coding in NetBSD proper. I have been looking into how to
fix it and have some idea, but would appreciate other ideas.

Cheers!
/P

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

JINMEI Tatuya / 神明達哉

2009-10-25 03:36:04 UTC

Permalink

At Fri, 16 Oct 2009 15:37:08 -0400,

Post by Patrik Lahti
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.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Patrik Lahti

2009-11-02 18:50:23 UTC

Permalink

Post by JINMEI Tatuya / ç¥æéå
At Fri, 16 Oct 2009 15:37:08 -0400,

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
- 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
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.

Hi Jinmei,

Thanks for your email. I admire your contribution as part of the IPv6
development team.

I hear you regarding striking a balance between implementation
complexity (and development time) vs. complying with all requirements.

In my opinion, when the link is flapping then there are bigger problems.
Most connections won't manage to stay up anyways. But I can see your
point, it's good to try be as good as possible... More importantly, it
is the uncommon case. And IMHO it would be preferable to have things
work correctly for the common case "out of the box" and have
configurable options to handle the uncommon cases rather than the other
way around.

You've certainly convinced me that the behavior should be configurable.
And I was thinking that before too, just because somebody out there may
depend on the old behavior. That's why I'm now wondering about what the
default should be...?

I agree the RFC algorithm is not perfect (not designed to be), but we're
talking about cases where the node is aware and hence very able to do
something, not cases where the node is unaware (as in when the link is
segmented elsewhere).

I agree that address duplication should be rare, especially when using
EUI-64-based addresses and DHCPv6, but it is obviously a concern
otherwise it wouldn't be required for ALL addresses regardless of
origin. More importantly, it is really when you're NOT using
EUI-64-based addresses and DHCPv6 that you really need it to work! E.g.
when doing manual configuration it is common that human mistakes lead to
duplicate addresses and that's when you really want it to work.

FWIW, I've actually seen duplicate addresses assigned by DHCP
implementations too, so that's a real problem. :-)

I think the fix is very easy and have little complexity. It's just
taking me time because I'm new to NetBSD development and just getting up
to speed on the whole development environment, and then finding the time
to do it with everything else going on...

Kind regards,
/P

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de