Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp464756pxv; Thu, 1 Jul 2021 02:09:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxt5U1zGLvi2Ib8eBiyk8EuR5dlSjU2vbkpOfEJl+EcIe+N1s3z+UVRcIAhOUs2qirpaSe5 X-Received: by 2002:a50:99cf:: with SMTP id n15mr4755791edb.146.1625130562051; Thu, 01 Jul 2021 02:09:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625130562; cv=none; d=google.com; s=arc-20160816; b=zgPpnV96pBE2/VGG81xXx2hXL0VqiPr5lQWNZJSbJpx9+MQSPQrf+o9ZrZ6kg2dmo8 SKwWIueRV++EkCRbLzGqibMux4WXK7r7yCSwXPq6OamQMtT9yOSl5hMZb22D5H35Be+M o6H6JoYgu9aXGL7RiHmawK0PaLLI24lrB5xLPnHliD0tfTL23dMgkbOfa5xFJKBWeN0X ROJG3hSpIPdQ/CrMQdUvli+zD1UWW3Izg9WRDG8NcBxzJCuLo2WUmVFKNgL8DMvJqDjq lOXbI+RWGEXUlgwYHHx7FTtFVNruZ6j2lYRTY5oQLvFd+CJ3/iHIfZa+bkmKefOOIYpE NfnQ== 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=jcO4rE+Mq+oG4d5FDxMz0DUMzpuAkF2rgTuilmDJPNs=; b=TPrR5dJ3CDaWl8MH5PUgu0EZ8k5GZidvsi2JfyBqW0FaMoUAzS4ZF5iVPCymwO76DN 4FwcTAZxlBnRkTJ+6sn8Yby1N0Nu00yqGUWGbGEvOS6cTlGVAG572EZyCJ0HAniy+HTI T77Q7j+UoeikdGz1mZ2/wX3mdSbn64ubyGUtFfdHA/ZOaz/DmvJCqjDvn5PJuCctgmZK 2j+ec7sYWjeJEBB3CLNtX504n09WeX+PKKakxAQRlI2BMMnu5hYrP2naaCE8mJkAIUpw 3Xb1wZv0IJgjrGw/kLJVr1upuBlYDibw8sIh5Mhk4be2r8G7bznIegYa9Rr1G4VzgxHL Mcqw== 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 b88si9079527edf.223.2021.07.01.02.08.58; Thu, 01 Jul 2021 02:09:22 -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 S235696AbhGAJJw (ORCPT + 99 others); Thu, 1 Jul 2021 05:09:52 -0400 Received: from mailgw01.mediatek.com ([60.244.123.138]:36881 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S235088AbhGAJJw (ORCPT ); Thu, 1 Jul 2021 05:09:52 -0400 X-UUID: e0d9a7106c684aef81196d6e901da683-20210701 X-UUID: e0d9a7106c684aef81196d6e901da683-20210701 Received: from mtkcas07.mediatek.inc [(172.21.101.84)] by mailgw01.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 2055808077; Thu, 01 Jul 2021 17:07:17 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs01n1.mediatek.inc (172.21.101.68) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 1 Jul 2021 17:07:09 +0800 Received: from localhost.localdomain (10.15.20.246) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 1 Jul 2021 17:07:08 +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: Thu, 1 Jul 2021 16:51:18 +0800 Message-ID: <20210701085117.19018-1-rocco.yue@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <46a9dbf2-9748-330a-963e-57e615a15440@gmail.com> References: <46a9dbf2-9748-330a-963e-57e615a15440@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 Wed, 2021-06-30 at 22:41 -0600, David Ahern wrote: > On 6/30/21 9:39 PM, Rocco Yue wrote: >> >> Hi David, >> >> Thanks for your review. >> >> This patch is different with IN6_ADDR_GEN_MODE_NONE. >> >> When the addr_gen_mode == IN6_ADDR_GEN_MODE_NONE, the Linux kernel >> doesn't automatically generate the ipv6 link-local address. >> > > ... > >> >> After this patch, when the "disable_gen_linklocal_addr" value of a device >> is 1, no matter in which addr_gen_mode, the Linux kernel will not automatically >> generate an ipv6 link-local for this device. >> > > those 2 sentences are saying the same thing to me. > > for your use case, why is setting addr_gen_mode == 1 for the device not > sufficient? > 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. Thanks, Rocco