Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4636337pxv; Tue, 6 Jul 2021 05:53:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJySdMB8mxdnxStYeq9Hi8lsSX1oo9DWrNrtmcFm0ITiJXFMLo+5kPkMO5jkgBDKismQeUPr X-Received: by 2002:a6b:b410:: with SMTP id d16mr15718730iof.196.1625575993022; Tue, 06 Jul 2021 05:53:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625575993; cv=none; d=google.com; s=arc-20160816; b=UEAp3MX7Siw+q6mEPfaohHUDpaGRAQlqBakna6ov3ArBVC9aBksBqsmyDWkzNucMeZ Qbh5IE3n7gt0lTfaeoOK6nO5CwiUb2LpAnn9nrlq7As0FqrMaIlMcVPPPwhYp2e0Tq3R zIGBoCJzeg19fR7xXby8aPmz+lngIBaKCfDonejCopYCxhBgrj83m0sL9FPY6suxKB2I SZ0bWbFBbx+/DBtE+HOSlowywqzJD3bCYCLLXj662bpXbrKcx2KDoBiKxocsNVhjEL/i HQFeL0dTZcsyGK5eCAqH2Up+5XfOdsHhc3Kynxwc53OdcaVN6Nz3V4gvXNehNFep4DW8 iRSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from; bh=0vDs98z8kIMiuIv5vozMqsIHvt6ReKZDcAnHIyrdu/o=; b=qfrpxSWPH7UyTxkehW3ejCKLHjpTnd+ZP+gBDPWx+6QQNfGT2LyQ3BXOzbUR9kaWrN tz/O2FPsl9k0SunvFHAs277uVGN8ehi6kp/wV65dEj9avuG+b9s+uJ8THz07ywSlPUMC mXGlmK0OoESBm3nWAG/m4dFrx5SMLxabUn1ncSLavgomCEXdIfxouHvgDt1tlRkxnC+n yDnMhxakIusMJb2NOdt6alQ5SaRlTPaL6CkJh0NbN59ArTEQ/GI6dC+Gxc5nwtYARHYz b/fMN7qwf/TUA/aX3SHyksCm9dFbvy4O3+X8l4HIHVlD1h7iqEfXqrBJLUMOBzi3Vr7t zeew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i14si18680250ioi.87.2021.07.06.05.53.01; Tue, 06 Jul 2021 05:53:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235309AbhGFMzD (ORCPT + 99 others); Tue, 6 Jul 2021 08:55:03 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:46848 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S235125AbhGFMzD (ORCPT ); Tue, 6 Jul 2021 08:55:03 -0400 X-UUID: cbc380d870e948d9afe3487eb0f8f4d8-20210706 X-UUID: cbc380d870e948d9afe3487eb0f8f4d8-20210706 Received: from mtkcas06.mediatek.inc [(172.21.101.30)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1261492797; Tue, 06 Jul 2021 20:52:21 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs01n2.mediatek.inc (172.21.101.79) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 6 Jul 2021 20:52:20 +0800 Received: from localhost.localdomain (10.15.20.246) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 6 Jul 2021 20:52:19 +0800 From: Rocco Yue To: David Ahern CC: "David S . Miller" , Hideaki YOSHIFUJI , David Ahern , Jakub Kicinski , Matthias Brugger , , , , , , , , , , Rocco Yue Subject: Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode Date: Tue, 6 Jul 2021 20:37:02 +0800 Message-ID: <20210706123702.29375-1-rocco.yue@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <62c9f5b7-84bd-d809-4e33-39fed7a9d780@gmail.com> References: <62c9f5b7-84bd-d809-4e33-39fed7a9d780@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2021-07-05 at 10:35 -0600, David Ahern wrote: > On 7/1/21 2:51 AM, Rocco Yue wrote: >> On Wed, 2021-06-30 at 22:41 -0600, David Ahern wrote: >> >> For mobile operators that don't need to support RFC7217, setting >> addr_gen_mode == 1 is sufficient; >> >> But for some other mobile operators that need to support RFC7217, such as AT&T, >> the mobile device's addr_gen_mode will be switched to the >> IN6_ADDR_GEN_MODE_STABLE_PRIVACY, instead of using IN6_ADDR_GEN_MODE_NONE. >> The purpose is: in the IN6_ADDR_GEN_MODE_STABLE_PRIVACY mode, kernel can >> gererate a stable privacy global ipv6 address after receiveing RA, and >> network processes can use this global address to communicate with the >> outside network. >> >> Of course, mobile operators that need to support RFC7217 should also meet >> the requirement of 3GPP TS 29.061, that is, MT should use IID assigned by >> the GGSN to build its ipv6 link-local address and use this address to send RS. >> We don't want the kernel to automatically generate an ipv6 link-local address >> when addr_gen_mode == 2. Otherwise, using the stable privacy ipv6 link-local >> address automatically generated by the kernel to send RS message, GGSN will >> not be able to respond to the RS and reply a RA message. >> >> Therefore, after this patch, kernel will not generate ipv6 link-local address >> for the corresponding device when addr_gen_mode == 1 or addr_gen_mode == 2. >> > > I think another addr_gen_mode is better than a separate sysctl. It looks > like IN6_ADDR_GEN_MODE_STABLE_PRIVACY and IN6_ADDR_GEN_MODE_RANDOM are > the ones used for RAs, so add something like: > > IN6_ADDR_GEN_MODE_STABLE_PRIVACY_NO_LLA, > IN6_ADDR_GEN_MODE_RANDOM_NO_LLA, > > to in6_addr_gen_mode. > Hi David, Thanks for your reply. According to your suggestion, I checked the ipv6 code again. In my opinion, adding another addr_gen_mode may not be suitable. (1) In the user space, the process enable the ipv6 stable privacy mode by setting the "/proc/sys/net/ipv6/conf//stable_secret". In the kernel, the addr_gen_mode of a networking device is switched to IN6_ADDR_GEN_MODE_STABLE_PRIVACY by judging the bool value of "cnf.stable_secret.initialized". So, although adding an additional IN6_ADDR_GEN_MODE_STABLE_PRIVACY_NO_LLA, user space process has some trouble to let kernel switch the iface's addr_gen_mode to the IN6_ADDR_GEN_MODE_STABLE_PRIVACY_NO_LLA. This is not as flexible as adding a separate sysctl. (2) After adding "proc/sys/net/ipv6//disable_gen_linklocal_addr", so that kernel can keep the original code logic of the stable_secret proc file, and expand when the subsequent kernel adds a new add_gen_mode more flexibility and applicability. And we only need to care about the networking device that do not generate an ipv6 link-local address, and not the addr_gen_mode that this device is using. Maybe adding a separate sysctl is a better choice. Looking forward to your professional reply again. Thanks, Rocco