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

[James Kempf <kempf@docomolabs-usa.com>]

> > 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, sounds fine. Then I guess we can say that the host moves the addresses
to Optimistic before it sends the RS, but defers NS until it knows whether
or not it is on a new IP link.

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

So then it sounds like we should keep the address state unchanged until the
Link Up, and only then change to Optimistic.

> My 2 cents,

Anybody else have a comment?

            jak