Re: [DNA] [Issue 15] [Issue 16] DAD and MLD Interaction

[Erik Nordmark <erik.nordmark@sun.com>]

James Kempf wrote:

> You mean "no need to send an NS" I think.

Oops - yes.

> Well, there is unfortunately an off chance that, while the host is in
> transit from one wireless AP to another, someone comes on the link, sends
> out one NS to DAD an address that the in-transit host had claimed, and gets
> back no response. The new host would therefore conclude that the address was
> not a duplicate, but when the in-transit host came back on the link, it
> would be a duplicate. Considering the low probability of a collision in
> general (which is what makes oDAD statistically possible in the first
> place), this case is even more wildly unlikely, but it is still not
> completely impossible. :-(

There is also an off chance with a wired Ethernet and hosts that never 
move, that when A boots up and sends the NS, the some switch or link is 
overloaded so that it drops the single NS, hence B (which has the same 
address as A) never sees the NS.

The point is that DAD was not designed to discover duplicates under any 
assumptions; it was designed to be a light-weight mechanism to discover 
(infrequently occurring) duplicate address with a reasonable 
probability, since without any DAD, should a duplicate exist, it is 
quite painful to debug for the user/operator.

> OK. So moving to Optimistic prior to sending the RS rather than to Tentative
> is probably OK. I think this aligns with what I mentioned in my response to
> Nick, that handling packets sent to an address while the host is in transit
> is out of scope for DNA.
> 
> Do you think making the addresses Deprecated on Link Down is OK, like Nick
> suggested? This would prevent any new applications from opening sockets on
> them. If the host is multi-interface, these sockets would be directed to a
> Confirmed or Optimistic address on another interface, which might or might
> not be a benefit.

Multihoming is out of scope of RFC 2461 for a good reason :-)

I actually don't think we want to overload the deprecated or any other 
existing state with the notion that an interface is (suspected to be) 
not working, or flaky, or high packet loss. I think all those quality 
metrics should be captured using a separate mechanism. The the stack, 
when it has multiple interfaces to choose from, take those quality 
metrics into account.

My 2 cents,
    Erik