On 2004-08-04, Erik Nordmark wrote:
>
> > > Section 2.6 doesn't say anything useful for an implementor.
> > > Do we want to say that optimistic nodes should retransmit the DAD probe 3
> > > times? This wouldn't have much of a performance effect and it would improve
> > > detection in the presence of packet loss. Given that optimstic support
> > > might be common on nodes with wireless interfaces (which have higher packet
> > > loss in many cases) this might be a reasonable improvement.
> >
> > Would seem okay to me ... should that be a SHOULD?
>
> A SHOULD is fine with me, but the question is in what context it should apply.
> For instance, we could RECOMMEND that everybody that implements optiDAD
> uses 3 probes, or we could RECOMMEND this for certain link types ("wireless"
> even though it is not well-defined - presumably it includes free space lasers
> etc :-)
Hmmm ... since we're dealing with probabilities here, it would
almost make sense to say "on a media with packet loss probability
P_loss, send it N times where P_loss ^ N >= P_acceptable". But
then we're stuck trying to make a decision about P_acceptable,
and in any case P_loss is unlikely to be trivially estimable
(and unlikely to be truly independant ...)
(re: sending NA O=1 after completing DAD)
> > >
> > > I don't see this solving any problem. If the NCEs have stale information
> > > (for whatever reason) NUD will take care of that. And there is nothing
> > > in the operation of optimistic DAD which will create stale information
> > > when there is no duplicate.
> > > Thus sending unsoliciated NAs doesn't seem to help when there is no duplicate.
> >
> > It was basically there because if there _is_ a stale entry hanging
> > about, nothing the node sent while Optimistic will remove it.
> > But there's no need for OptiDAD to specify it anyway, since it's
> > allowed by RFC 2461 7.2.6 anyway.
>
> But this isn't any different than in regular DAD, is it?
No, except that the ON is presumably in more of a hurry.
But I think it's a rare enough case that the NUD delay
is tolerable.
Thanks for your comments, I'm munging them into the issues list /
slides right now.
-----Nick
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
