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
>
smime.p7s
Description: S/MIME Cryptographic Signature
