DAD/tentative addresses vs system boot with network links down

[Lutz Preßler]

Hello,

the following problem occured on a Linux system with kernel 2.6.32
(Debian squeeze) and is reproducible with older kernel versions.
I haven't tested newer ones or other OSes yet.

If one
- configures a static IPv6 address on some interface with normal
  (giving "ip address add ADDRESS dev DEV") config mechanisms
- uses this address in daemon configurations as "bind address"
- boots the system with link of DEV down
... those daemons will fail to start.

The reason is, that an address is in state "tentative" until
duplicate address detection can be completed - which is 
(per definition?) not possible on an unavailable link.

The question is: who is at fault (this cannot be the intended
high level behaviour), and what to do against it apart from having
distribution mechanisms which try to start a daemon after a
necessary address is available (don't know if systemd for linux
is able to do this).

A remedy is to configure all static addresses with "nodad" flag,
that is "ip address add ADDRESS dev DEV nodad", which is in Debian
only possible with totally manually ("up"/"down" statements) in
interfaces configuration file.
At first thought, this may be the correct solution for manually
assigned interface identifiers, as a address conflict cannot
be handled sensibly automatically anyway - and distributions
could be changed to set "nodad" in those cases. But DAD 

Or should the semantic/implementation of bind(2) be changed
for addresses in tentative state (allow bind anyway, give error
later in case of conflict)?

As the address will not change to "tentative" again if the
link goes down even though an address conflict can arise running
systems (booted inbetween) are (re)connected afterwards.
So what about ending tentative state if an interface goes or is up
while not running (link down)?

Are there any normative references concerning this problem?
Opinions? Maybe those and information about other OSes behaviour
can be used on linux lists afterwards.

Regards,
  Lutz