Re: PATCH to only announce RTM_NEWADDR once IPv6 DAD completes

[christos%astron.com@localhost (Christos Zoulas)]

In article <b18662cb2f9eb1c8b4ede6b6b31e9235%mail.marples.name@localhost>,
Roy Marples  <roy%marples.name@localhost> wrote:
>On 15/05/2013 12:07, Greg Troxel wrote:
>> It seems like this behavior should be documented in a man page
>> somewhere, probably route(4).  The change seems sensible, but it 
>> opens
>> up a question of what the invariant is.  I think it's something like
>>
>>   all configured addresses which are not tentative have had a NEWADDR
>>   sent (that has not been withdrawn by a DELADDR).
>>
>> Basically, I'd like a spec of how to take a stream of NEW/DEL and a 
>> set
>> of current addresses and say if the behavior is right.  I don't mean 
>> to
>> suggest that you've done anything that breaks what the spec ought to 
>> be,
>> but it feels tricky.
>
>You mean what happens when a conflict is detected?
>I'm not sure that generating DELADDR is the right thing to do as it 
>does exist within the kernel.
>Maybe a new message, RTM_DUPADDR? That suffers from the same possible 
>crash for badly written programs though.

Doesn't the tentative bit get passed in the rtm message? Why not pass
the full information to userland and let it do what it wishes?

christos