DAD/tentative addresses vs system boot with network links down

[Mark Smith]

(ok, so you asked for a bit of (maybe not completely thought through)
opinion - I wrote this a week or so ago)

Hi,

On Thu, 24 Mar 2011 16:42:19 +0100
Lutz Preßler <Lutz.Pressler at SerNet.DE> wrote:

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

This would make sense to me. I think static overrides of automated
mechanisms means taking more responsibility for issues that the
automated mechanisms handle, such as avoiding duplicate addresses. 

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

Allowing bind(2) at this time would be probably be ok, what probably
matters more is what happens immediately after the bind call. How
should sending of traffic using the bound socket be handled
during this tentative address period? It would be legitimate to drop
UDP traffic, and TCP's retransmission of lost SYNs would cope with
initial traffic loss during the tentative period, so it may not be a
problem. 

> 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.

I'm surprised at this, I'd have assumed that DAD would have occurred
upon each link up event, not just and administrative up event.

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

Regards,
Mark.