From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:43648 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750757AbeBZQ4V (ORCPT ); Mon, 26 Feb 2018 11:56:21 -0500 Date: Mon, 26 Feb 2018 17:56:19 +0100 From: Sabrina Dubroca To: David Miller Cc: dsahern@gmail.com, netdev@vger.kernel.org Subject: Re: [PATCH net-next] ipv6: allow userspace to add IFA_F_OPTIMISTIC addresses Message-ID: <20180226165619.GA10603@bistromath.localdomain> References: <20180220181717.GA12711@bistromath.localdomain> <20180221.153421.1122190571211818853.davem@davemloft.net> <20180226154132.GA7083@bistromath.localdomain> <20180226.105711.81890471902412308.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180226.105711.81890471902412308.davem@davemloft.net> Sender: netdev-owner@vger.kernel.org List-ID: 2018-02-26, 10:57:11 -0500, David Miller wrote: > From: Sabrina Dubroca > Date: Mon, 26 Feb 2018 16:41:32 +0100 > > > What are you concerned about, if we let userspace set this flag? > > I am concerned that the kernel is no longer in charge of making sure > that all of the RFC rules are met in this area. This can already happen with IFA_F_NODAD or net.ipv6.conf.*.accept_dad. We'll send packets using non-unique addresses. > Userland is now repsonsible for implementing correct behavior when it > takes over this task, and therefore the kernel has no say in the > matter of proper ipv6 neighbor discovery and addrconf behavior. As an aside, that's also the case whenever userland uses packet sockets. > Unlike with things like DHCP, addrconf et al. in ipv6 are > fundamentally defined aspects of the protocol suite. > > This division of responsibility means that we will also run into > situations where who (kernel or user) must take care of X or Y might > be ambiguous or hard to pin down in certain circumstances. I don't think it's ambiguous here, but I can add documentation. > I really don't like this situation where a fundamental protocol is > conditionally the responsibility of the kernel, it's really bad design > decision overall. I understand. But I think with this patch, userspace could rely on the kernel's DAD, instead of having to perform DAD itself in order to avoid the delay that non-optimistic DAD introduces. -- Sabrina