All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rocco Yue <rocco.yue@mediatek.com>
To: David Ahern <dsahern@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>, <wsd_upstream@mediatek.com>,
	<rocco.yue@gmail.com>, <chao.song@mediatek.com>,
	<kuohong.wang@mediatek.com>, <zhuoliang.zhang@mediatek.com>,
	Rocco Yue <rocco.yue@mediatek.com>
Subject: Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
Date: Thu, 1 Jul 2021 11:39:20 +0800	[thread overview]
Message-ID: <20210701033920.5167-1-rocco.yue@mediatek.com> (raw)
In-Reply-To: <3c0e5c52-4204-ae1e-526a-5f3a5c9738c2@gmail.com>

On Wed, 2021-06-30 at 21:03 -0600, David Ahern wrote:
On 6/30/21 7:59 PM, Rocco Yue wrote:
>> This patch provides an ipv6 proc file named
>> "disable_gen_linklocal_addr", its absolute path is as follows:
>> "/proc/sys/net/ipv6/conf/<iface>/disable_gen_linklocal_addr".
>> 
>> When the "disable_gen_linklocal_addr" value of a device is 1,
>> it means that this device does not need the Linux kernel to
>> automatically generate the ipv6 link-local address no matter
>> which IN6_ADDR_GEN_MODE is used.
>> 
> 
> doesn't this duplicate addr_gen_mode == 1 == IN6_ADDR_GEN_MODE_NONE?
> 

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.

But when the addr_gen_mode == IN6_ADDR_GEN_MODE_STABLE_PRIVACY, the
Linux kernel will still automatically generate an ipv6 link-local
address.

Among global mobile operators, some operators have already request
MT (Mobile Terminal) to support RFC7217, such as AT&T. In this case,
addr_gen_mode will be set to IN6_ADDR_GEN_MODE_STABLE_PRIVACY to
support RFC7217. This means that the device not only needs the IID
assigned by the GGSN to build the ipv6 link-local address to trigger
the RS message, but also needs to use the stable privacy mode to build
the ipv6 global address after receiving the RA.

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.

Thanks,
Rocco

WARNING: multiple messages have this Message-ID (diff)
From: Rocco Yue <rocco.yue@mediatek.com>
To: David Ahern <dsahern@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	 <wsd_upstream@mediatek.com>, <rocco.yue@gmail.com>,
	<chao.song@mediatek.com>,  <kuohong.wang@mediatek.com>,
	<zhuoliang.zhang@mediatek.com>,
	Rocco Yue <rocco.yue@mediatek.com>
Subject: Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
Date: Thu, 1 Jul 2021 11:39:20 +0800	[thread overview]
Message-ID: <20210701033920.5167-1-rocco.yue@mediatek.com> (raw)
In-Reply-To: <3c0e5c52-4204-ae1e-526a-5f3a5c9738c2@gmail.com>

On Wed, 2021-06-30 at 21:03 -0600, David Ahern wrote:
On 6/30/21 7:59 PM, Rocco Yue wrote:
>> This patch provides an ipv6 proc file named
>> "disable_gen_linklocal_addr", its absolute path is as follows:
>> "/proc/sys/net/ipv6/conf/<iface>/disable_gen_linklocal_addr".
>> 
>> When the "disable_gen_linklocal_addr" value of a device is 1,
>> it means that this device does not need the Linux kernel to
>> automatically generate the ipv6 link-local address no matter
>> which IN6_ADDR_GEN_MODE is used.
>> 
> 
> doesn't this duplicate addr_gen_mode == 1 == IN6_ADDR_GEN_MODE_NONE?
> 

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.

But when the addr_gen_mode == IN6_ADDR_GEN_MODE_STABLE_PRIVACY, the
Linux kernel will still automatically generate an ipv6 link-local
address.

Among global mobile operators, some operators have already request
MT (Mobile Terminal) to support RFC7217, such as AT&T. In this case,
addr_gen_mode will be set to IN6_ADDR_GEN_MODE_STABLE_PRIVACY to
support RFC7217. This means that the device not only needs the IID
assigned by the GGSN to build the ipv6 link-local address to trigger
the RS message, but also needs to use the stable privacy mode to build
the ipv6 global address after receiving the RA.

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.

Thanks,
Rocco
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Rocco Yue <rocco.yue@mediatek.com>
To: David Ahern <dsahern@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	 <wsd_upstream@mediatek.com>, <rocco.yue@gmail.com>,
	<chao.song@mediatek.com>,  <kuohong.wang@mediatek.com>,
	<zhuoliang.zhang@mediatek.com>,
	Rocco Yue <rocco.yue@mediatek.com>
Subject: Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
Date: Thu, 1 Jul 2021 11:39:20 +0800	[thread overview]
Message-ID: <20210701033920.5167-1-rocco.yue@mediatek.com> (raw)
In-Reply-To: <3c0e5c52-4204-ae1e-526a-5f3a5c9738c2@gmail.com>

On Wed, 2021-06-30 at 21:03 -0600, David Ahern wrote:
On 6/30/21 7:59 PM, Rocco Yue wrote:
>> This patch provides an ipv6 proc file named
>> "disable_gen_linklocal_addr", its absolute path is as follows:
>> "/proc/sys/net/ipv6/conf/<iface>/disable_gen_linklocal_addr".
>> 
>> When the "disable_gen_linklocal_addr" value of a device is 1,
>> it means that this device does not need the Linux kernel to
>> automatically generate the ipv6 link-local address no matter
>> which IN6_ADDR_GEN_MODE is used.
>> 
> 
> doesn't this duplicate addr_gen_mode == 1 == IN6_ADDR_GEN_MODE_NONE?
> 

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.

But when the addr_gen_mode == IN6_ADDR_GEN_MODE_STABLE_PRIVACY, the
Linux kernel will still automatically generate an ipv6 link-local
address.

Among global mobile operators, some operators have already request
MT (Mobile Terminal) to support RFC7217, such as AT&T. In this case,
addr_gen_mode will be set to IN6_ADDR_GEN_MODE_STABLE_PRIVACY to
support RFC7217. This means that the device not only needs the IID
assigned by the GGSN to build the ipv6 link-local address to trigger
the RS message, but also needs to use the stable privacy mode to build
the ipv6 global address after receiving the RA.

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.

Thanks,
Rocco
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-01  3:55 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-01  1:59 [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode Rocco Yue
2021-07-01  1:59 ` Rocco Yue
2021-07-01  1:59 ` Rocco Yue
2021-07-01  3:03 ` David Ahern
2021-07-01  3:03   ` David Ahern
2021-07-01  3:03   ` David Ahern
2021-07-01  3:39   ` Rocco Yue [this message]
2021-07-01  3:39     ` Rocco Yue
2021-07-01  3:39     ` Rocco Yue
2021-07-01  4:41     ` David Ahern
2021-07-01  4:41       ` David Ahern
2021-07-01  4:41       ` David Ahern
2021-07-01  8:51       ` Rocco Yue
2021-07-01  8:51         ` Rocco Yue
2021-07-01  8:51         ` Rocco Yue
2021-07-05  5:48         ` Rocco Yue
2021-07-05  5:48           ` Rocco Yue
2021-07-05  5:48           ` Rocco Yue
2021-07-05 16:35         ` David Ahern
2021-07-05 16:35           ` David Ahern
2021-07-05 16:35           ` David Ahern
2021-07-06 12:37           ` Rocco Yue
2021-07-06 12:37             ` Rocco Yue
2021-07-06 12:37             ` Rocco Yue
2021-07-07 14:39             ` David Ahern
2021-07-07 14:39               ` David Ahern
2021-07-07 14:39               ` David Ahern
2021-07-13  1:49               ` Rocco Yue
2021-07-13  1:49                 ` Rocco Yue
2021-07-13  1:49                 ` Rocco Yue
2021-09-09  6:20           ` Lorenzo Colitti
2021-09-09  6:20             ` Lorenzo Colitti
2021-09-09  6:20             ` Lorenzo Colitti
2021-09-09 19:12             ` David Ahern
2021-09-09 19:12               ` David Ahern
2021-09-09 19:12               ` David Ahern
2021-09-12 15:47               ` Mark Smith
2021-09-12 15:47                 ` Mark Smith
2021-09-12 15:47                 ` Mark Smith
2021-09-13  9:38                 ` Lorenzo Colitti
2021-09-13  9:38                   ` Lorenzo Colitti
2021-09-13  9:38                   ` Lorenzo Colitti
2021-09-13 15:22                   ` Mark Smith
2021-09-13 15:22                     ` Mark Smith
2021-09-13 15:22                     ` Mark Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210701033920.5167-1-rocco.yue@mediatek.com \
    --to=rocco.yue@mediatek.com \
    --cc=chao.song@mediatek.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=dsahern@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=rocco.yue@gmail.com \
    --cc=wsd_upstream@mediatek.com \
    --cc=yoshfuji@linux-ipv6.org \
    --cc=zhuoliang.zhang@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.