[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-01.txt



> I think we should limit the applicability to hosts, and if
> NEMO WG needs a router equivalent let them develop it :-)
> Comments anyone?

Works for me.

> > How about saying
> >    When the DAD timer completes without incident,
> >    the address becomes a Preferred or a Deprecated address based on its
> >    preferred lifetime.
> 
> OK.  Jinmei was unhappy with 'DAD Timer', too ... any suggestions
> of how I can unambiguously explain what I mean?  I don't like
> "when DAD completes", because I don't think it's clear enough
> either ... 

Hm - this is the result of an implementation suggestion.
Conceptually the address is either preferred or deprecated, and
in addition it is marked as optimistic for some time
and all uses of the address should treat it as deprecated while
it is marked as optimistic.

Thus the implementation suggestion is to actually mark is as deprecated
while it is optimistic, and undo this when it is no longer optimistic.
Since this is about implementations, perhaps it can be lifed out to an appendix
where it can be explained in a bit more detail.

> > 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 :-)

> > 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?
I mean if there is some stale information for an IP address in some neighbor
cache on the link, the sending of the DAD NS will not remove the stale info.
Instead NUD when the stale entry is used will take care of it.

> Yeah, this has proved rather unpopular.  Originally, it was to
> address the concern that the ON may have invested in its new
> address (sending Binding Updates, that kind of thing) and so
> it would be better for the newcomer to change rather than the
> established ON.  A standard node will discard a Tentative
> address if it gets an NA for that address OR an NS for that
> address from ::.  Thus, in a collision between two Tentative
> nodes, both will discard the address.  

But this only helps when both perform DAD at the same time.
If the optiDAD is the newcomer it will loose, just as in DAD.
For this optimization to have use there has to be lots of duplicates
so that there are lots of crossing DAD NSes that discovery duplicates.
I don't think we want such a level of duplicates that is needed for
this to make any difference.

> In the current OptiDAD rules, an Optimistic Address will only
> be discarded if an NA is received for it.  If an NS
> from :: is received, the ON will defend the address with an NA,
> causing the newcomer to go away.  This reflects the 'semi
> tentative' status of an Optimistic Address ...

I must have missed that in the text.

> On the other hand, this is such a vanishingly unlikely 
> situation (~ N/2^62, where N is the number of nodes moving
> into the network in DupAddrTransmits * RETRANS_TIMER)
> that I'm happy to remove it simply because it's unnecessary!

ok

> If I was planning on reinventing this particular wheel I'd probably
> look at a continuous process ... but I'm sure that has its own
> problems, and its a quite well established wheel already :-)

Yes, a continues duplicate check (and giving up the address as a result)
would provide interesting opprtunities for DoS attacks.
Given the size of the interface ID, I don't think we need this for IPv6.

  Erik



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------