On Mon, Nov 13, 2017 at 3:21 PM, Erik Kline <e...@google.com> wrote:
> Should we consider rolling back the patch that caused this?
> "accept_dad = 1" is the proper IETF-expected default behaviour.
>
> Alternatively, if we really want to make all, default, and ifname
> useful perhaps we need to investigate a tristate option (for currently
> boolean values, at least).  -1 could mean no preference, for example.
>
> On 13 November 2017 at 13:45, Nicolas Dichtel <nicolas.dich...@6wind.com> 
> wrote:
>> The commit a2d3f3e33853 modifies the way to disable dad on an interface.
>> Before the patch, setting <iface>.accept_dad to 0 was enough to disable it.
>> Because all.accept_dad is set to 1 by default, after the patch, the user
>> needs to set both all.accept_dad and <iface>.accept_dad to 0 to disable it.
>>
>> This is not backward compatible. When a user updates its kernel, the dad
>> may be enabled by error.
>>
>> Let's set all.accept_dad to 0 by default to restore the previous behavior.
>>
>> Fixes: a2d3f3e33853 ("ipv6: fix net.ipv6.conf.all.accept_dad behaviour for 
>> real")
>> CC: Stefano Brivio <sbri...@redhat.com>
>> CC: Matteo Croce <mcr...@redhat.com>
>> CC: Erik Kline <e...@google.com>
>> Signed-off-by: Nicolas Dichtel <nicolas.dich...@6wind.com>
>> ---
>>  net/ipv6/addrconf.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index 8a1c846d3df9..ef5b61507b9a 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -231,7 +231,7 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
>>         .proxy_ndp              = 0,
>>         .accept_source_route    = 0,    /* we do not accept RH0 by default. 
>> */
>>         .disable_ipv6           = 0,
>> -       .accept_dad             = 1,
>> +       .accept_dad             = 0,
>>         .suppress_frag_ndisc    = 1,
>>         .accept_ra_mtu          = 1,
>>         .stable_secret          = {
>> --
>> 2.13.2
>>

Another way could be putting the "all" and per interface handlers in
logical AND.
The fact is before the patch, the "all" handler really was a noop.
What do you think?

-- 
Matteo Croce
per aspera ad upstream

Reply via email to