From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99847C433F5 for ; Wed, 20 Oct 2021 13:24:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 598EA610A2 for ; Wed, 20 Oct 2021 13:24:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229943AbhJTN0r (ORCPT ); Wed, 20 Oct 2021 09:26:47 -0400 Received: from s2.neomailbox.net ([5.148.176.60]:13605 "EHLO s2.neomailbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229639AbhJTN0q (ORCPT ); Wed, 20 Oct 2021 09:26:46 -0400 X-Greylist: delayed 1562 seconds by postgrey-1.27 at vger.kernel.org; Wed, 20 Oct 2021 09:26:46 EDT To: Stephen Suryaputra , netdev@vger.kernel.org References: <20211020013005.GA4864@ICIPI.localdomain> From: Antonio Quartulli Subject: Re: Sysctl addr_gen_mode does not control tunnel link-local addr Message-ID: Date: Wed, 20 Oct 2021 14:59:01 +0200 MIME-Version: 1.0 In-Reply-To: <20211020013005.GA4864@ICIPI.localdomain> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi, On 20/10/2021 03:30, Stephen Suryaputra wrote: > Hi, > > I noticed that tunnels, especially sit before commit e5dd729460ca8 > ("ip/ip6_gre: use the same logic as SIT interfaces when computing v6LL > address"), generates link-local addr regardless of addr_gen_mode > setting. Is this a bug, or is there a specific reason? > > In my system, the link-local addr are generated by a userspace process. > So, we set net.ipv6.conf..addr_gen_mode to 1 (IN6_ADDR_GEN_MODE_NONE). > > The commit e5dd729460ca8 doesn't change the behavior as it is renaming > sit_add_v4_addrs() to add_v4_addrs() as make it generic for GRE/IP6GRE > cases. I'm not sure what the current behavior is for GRE, i.e. whether > addr_gen_mode can control the generation of link-local addr. > > If this is a bug or oversight, I think this diff should fix it and I can > put a formal patch. When I implemented this behavior for SIT interfaces I basically ported what is currently happening for GRE. Therefore, any change you apply to SIT, should also be reflected in the GRE code path. As of now, the SIT/GRE addrgen logic does not consider the mode setting at all. But I am not sure it'd be easy to support all the values. For sure, supporting IN6_ADDR_GEN_MODE_NONE is a low hanging fruit and should be implemented. > > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c > index c6a90b7bbb70..da7e83699eef 100644 > --- a/net/ipv6/addrconf.c > +++ b/net/ipv6/addrconf.c > @@ -3392,6 +3392,8 @@ static void addrconf_sit_config(struct net_device > *dev) > return; > } > > + if (idev->cnf.addr_gen_mode == IN6_ADDR_GEN_MODE_NONE) > + return; Please add an empty line here. > add_v4_addrs(idev); > > if (dev->flags&IFF_POINTOPOINT) > > The commit mention about addressing violation of RFC4291 on GRE and the diff > above doesn't cause it to change as the default addr_gen_mode is 0 > (IN6_ADDR_GEN_MODE_EUI64). Other than my nitpick above, I'd suggest applying the same change to the GRE code path, as the behavior should be the same. Moreover, do you think that addrconf_add_mroute() should not be executed in this case? Otherwise you could simply add your new code into add_v4_addrs(). Regards, -- Antonio Quartulli