Duplicate Address Detection bug

[Patrik Lahti]

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

[JINMEI Tatuya / 神明達哉-2]

At Fri, 16 Oct 2009 15:37:08 -0400,
Patrik Lahti <plahti@...> 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.

[Patrik Lahti]

JINMEI Tatuya / 神明達哉 wrote:

> At Fri, 16 Oct 2009 15:37:08 -0400,
> Patrik Lahti <plahti@...> 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.
>  

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