From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net ([184.105.139.130]:43432 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751697AbeBZP5N (ORCPT ); Mon, 26 Feb 2018 10:57:13 -0500 Date: Mon, 26 Feb 2018 10:57:11 -0500 (EST) Message-Id: <20180226.105711.81890471902412308.davem@davemloft.net> To: sd@queasysnail.net Cc: dsahern@gmail.com, netdev@vger.kernel.org Subject: Re: [PATCH net-next] ipv6: allow userspace to add IFA_F_OPTIMISTIC addresses From: David Miller In-Reply-To: <20180226154132.GA7083@bistromath.localdomain> References: <20180220181717.GA12711@bistromath.localdomain> <20180221.153421.1122190571211818853.davem@davemloft.net> <20180226154132.GA7083@bistromath.localdomain> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: 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. 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. 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 really don't like this situation where a fundamental protocol is conditionally the responsibility of the kernel, it's really bad design decision overall.