#ident "@(#)issues	1.7 05/09/21 SAC"

2005/314 IP Duplicate Address Detection
Submitter:	James Carlson

Issues for inception (09/21/2005):

wes-1 	when there is a transient usurper on the link, shouldn't DAD
	eventually self-heal when the usurper goes away?
	this design allows for a new attack: a "drive-by shooting" which
	to knocks a system off the link permanently (or until
	administrative intervention occurs).
	this is the worst kind of denial-of-service attack, since it
	leaves things broken and leaves little evidence of what happened.
	
wes-2 	nit: table 1 has 9 ndd variables in it but is prefaced with
	"five ndd parameters are added for /dev/arp"
	
gw-1	Sort of nits:
	a) Why wouldn't this qualify for a patch release binding?
	b) There seem to be lots of timers going off.  How do the timers
	   impact kernel and network performance?
	c) Network random numbers seem to be independent of kernel
	   random number provider from kcfd or /dev/[u]random.  Would it
	   be appropriate to just consume randomness from the kernel
	   provider?

eg-1	20q7
	Does this project maintain its own ARP table or does it
	re-use or replace the existing one?

seb-1   The IPv6 in.ndpd daemon has a per-interface tunable called
        DupAddrDetectTransmits, and it currently only applies to the
        duplicate address detection mechanism implemented inside of that
        daemon.  How will this be integrated into the new scheme?  The ndd
        tunables aren't per interface, but seem to be global parameters.

seb-2	The IFF_NOLOCAL flag had another side-effect, in that a network route
	remained for the local network even if DAD failed.  Is that a
	behavior that would be beneficial to preserve?