Re: Bridge stays down until a port is added

[Stephen Hemminger <shemminger@vyatta.com>]

On Mon, 26 Sep 2011 22:02:21 +0200
Nicolas de Pesloüan <nicolas.2p.debian@gmail.com> wrote:

> Le 26/09/2011 17:47, Stephen Hemminger a écrit :
> > The root of this whole problem is really that IPv6 reports addresses
> > in a tentative state to applications that can not be passed to the bind() system call.
> > For most cases, this problem never happens because the tentative addresses are
> > resolved by Duplicate Address Detection before the application starts. But
> > I have seen (and fixed) this happen before this whole discussion started.
> >
> > 1. The problem is not unique to bridges. It happens with bridge, macvtap,
> >     even on wireless networks where the device is available but carrier is
> >     not asserted.
> >
> > 2. Any change to what the kernel does (like not reporting tentative addresses)
> >     would break applications even worse.
> >
> > 3. When the bridge was always reporting carrier, it was in effect breaking
> >     IPv6 Duplicate Address Detection. And that is bad.
> 
> Stephen,
> 
> What do you think about a generic per-interface option that would cause bind() to accept tentative 
> address hold by a particular interface? This of course violate IPv6 principle, but we are talking 
> about interfaces that are unable to do DAD, either permanently or until something happens on the 
> underlying device.
> 
> echo 1 > /sys/class/net/br0/allow_bind_on_tentative_address
> echo 1 > /sys/class/net/dummy0/allow_bind_on_tentative_address
> echo 1 > /sys/class/net/wlan0/allow_bind_on_tentative_address
> and so on...
> 
> And we may possibly automatically reset this option to 0 if DAD eventually causes the address to be 
> considered duplicate.

The issue is that if DAD rejects a duplicate, the socket is dead and application is
out of luck.

Has anyone looked at this issue in relation to systemd which does early
opportunistic binding of services?