Re: [DNA] when to rerun DAD

[Greg Daley <gregd@research.panasonic.com>]

Hi Thomas,


Thomas Narten wrote:
> JinHyeock Choi <jinchoe@gmail.com> writes:
> 
>>> Some key questions for DNA.
>>>
>>> 1) when reusing "old" config, do we need to do anything special? E.g.,
>>>   change state of ND entries to STALE? Put addresses in Optimistic
>>>   state? Take into account how much time has elapsed since we were
>>>   last attached (or just assume this happens as part of normal ND
>>>   timers?)
>>>
>>>   What harm can occur from continuing to use the same information?
>>>   how does this compare with the harm of delaying the configuration
>>>   of an interface until one is more certain?
> 
>> It may cause address conflict if a host continues to use the existing
>> 'IP address' without DAD. While the host is away from the link, it's
>> possible that another node happens to configure the host's IP address,
>> because there was nobody to defend the address.
> 
> IMO, we may want to think about having a separate discussion about
> "when to run DAD". The blanket "rerun DAD at all times there is some
> doubt" strikes me as overkill. For example, why rerun DAD if one has
> been disconnected only 10 seconds? or 30? Maybe we should if we've
> been disconnected for an hour (but then, do we need to bother with
> DNA?).  Also, why rerun DAD if one has generated an address using the
> IEEE Identifier (and one has run DAD on it before)? That is, different
> types of addresses have different "probability of possible collision"
> risks in terms of other hosts attempting to use such addresses.

Personally, I'm really loathe to introduce any situation where DAD
is neglected, as it's really an all nodes or none approach.

That said, we can certainly be a lot more clever about DAD and
not sending DAD-NS packets inappropriately.

I think it may be worthwhile to RECOMMEND that hosts do optimistic
DAD if they have been away longer than a second, on the understanding
that this shouldn't necessarily result in packets being sent
to the link.  In fact, explicitly rate-limiting active DAD NSs
may be a good idea.

It's notable that the collision rates for pseudo-random variables
produce as low as 1 in 2^62 chance that collisions occur.

Ideally with IEEE identifiers, multiple devices can't have the same
address.  I've worked for an organization where (in the early days) an
entire box of NICs had the same MAC address.  Additionally, MAC
addresses may be programmed into cards (0x00FEEDABBA01) without
the Layer 3 necessarily knowing.

So the probability of collision is potentially higher than that
for (say) CGA addresses which use SHA-1, or 3041 addresses which
actually follow the recommendations of RFC1750.

That said, neither of these are guaranteed either.


Optimistic DAD may be useful as a passive system as it ensures that
the re-arriving node doesn't displace the state held by a router.
So assuming that no DAD NS is sent, the DNA host has to remain
optimistic until it has performed the operation (which could be
strongly rate limited, when remaining in the same link).

A host which doesn't need to talk directly to neighbours (but can
learn addresses of routers through RA) can still operate effectively
even though it can't send multicast NS's and cannot send an NA,O=1.

If the router isn't sending you packets for a while, and if the
host's NCE for the router goes to PROBE (haven't worked this part
out yet), the host will send a unicast NS, but won't be able to
get back a response from the router, if there's an existing NCE for
another device. In the case of no response, it's time to send DAD
NS, if DNA still indicates the router is available.

If there's no existing NCE, the router will resolve the host, which
will NA O=0 to the router, and the router can send the NA based on the
new NCE.

If the router already had the NCE of this device, DAD NS can be delayed
further until Neighbour Resolution is required, or a timer expires.

So if a host is prepared to accept optimistic operation, and not send
a DAD NS, it's possible to reduce the rate of messages without
necessarily impinging on DAD.

Greg