Mailing List Archive

DAD/tentative addresses vs system boot with network links down
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
RE: DAD/tentative addresses vs system boot with network links down [ In reply to ]
> 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.
>

Well, setting a sysctl for the interface might do it:

/etc/sysctl.conf

net.ipv6.conf.DEV.dad_transmits = 0

So you basically turn off DAD for the interface.
Re: DAD/tentative addresses vs system boot with network links down [ In reply to ]
Hello,

On Thu, 24 Mar 2011, George Bonser wrote:
> > 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.
> >
>
> Well, setting a sysctl for the interface might do it:
>
> /etc/sysctl.conf
>
> net.ipv6.conf.DEV.dad_transmits = 0
>
> So you basically turn off DAD for the interface.
Yes, thanks for reminding me of that option. But I don't think that disabling
DAD in general is a sensible way to handle this problem.
I'm a litte bit supprised that there are no other reactions here.
Don't you think this is a real operational problem for (Linux) server systems?
I do. And not only with normally unused interfaces, but there is also
the chance that after loss of power a (L3-)switch takes longer for starting
up than the server system...
I found out, that there is a Linux IPv4 socket option "IP_FREEBIND", but no
equivalent for IPv6.
Does anybody know how Windows Server is behaving?

Lutz
Re: DAD/tentative addresses vs system boot with network links down [ In reply to ]
(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@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.