All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
Cc: "Rocco Yue" <rocco.yue@mediatek.com>,
	"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>,
	"Linux NetDev" <netdev@vger.kernel.org>,
	lkml <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 (王國鴻)" <kuohong.wang@mediatek.com>,
	"Zhuoliang Zhang (张卓亮)" <zhuoliang.zhang@mediatek.com>
Subject: Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
Date: Thu, 9 Sep 2021 13:12:37 -0600	[thread overview]
Message-ID: <6a8f0e91-225a-e2a8-3745-12ff1710a8df@gmail.com> (raw)
In-Reply-To: <CAKD1Yr2aijPe_aq+SRm-xv0ZPoz_gKjYrEX97R1NJyYpSnv4zg@mail.gmail.com>

On 9/9/21 12:20 AM, Lorenzo Colitti wrote:
>> 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,
> 
> I think the real requirement here (which wasn't clear in this thread)
> is that the network needs to control the interface ID (i.e., the
> bottom 64 bits) of the link-local address, but the device is free to
> use whatever interface IDs to form global addresses. See:
> https://www.etsi.org/deliver/etsi_ts/129000_129099/129061/15.03.00_60/ts_129061v150300p.pdf
> 
> How do you think that would best be implemented?

There is an established paradigm for configuring how an IPv6 address is
created or whether it is created at all - the IFLA_INET6_ADDR_GEN_MODE
attribute.

> 
> 1. The actual interface ID could be passed in using IFLA_INET6_TOKEN,
> but there is only one token, so that would cause all future addresses
> to use the token, disabling things like privacy addresses (bad).
> 2. We could add new IN6_ADDR_GEN_MODE_STABLE_PRIVACY_LL_TOKEN,
> IN6_ADDR_GEN_MODE_RANDOM_LL_TOKEN, etc., but we'd need to add one such
> mode for every new mode we add.
> 3. We could add a separate sysctl for the link-local address, but you
> said that per-device sysctls aren't free.

per-device sysctl's are one of primary causes of per netdev memory usage.

Besides that there is no reason to add complexity by having a link
attribute and a sysctl for this feature.

> 4. We could change the behaviour so that if the user configures a
> token and then sets IN6_ADDR_GEN_MODE_*, then we use the token only
> for the link-local address. But that would impact backwards
> compatibility.
> 
> Thoughts?

We can have up to 255 ADDR_GEN_MODEs (GEN_MODE is a u8). There is
established code for handling the attribute and changes to it. Let's
reuse it.

WARNING: multiple messages have this Message-ID (diff)
From: David Ahern <dsahern@gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
Cc: "Rocco Yue" <rocco.yue@mediatek.com>,
	"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>,
	"Linux NetDev" <netdev@vger.kernel.org>,
	lkml <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 (王國鴻)" <kuohong.wang@mediatek.com>,
	"Zhuoliang Zhang (张卓亮)" <zhuoliang.zhang@mediatek.com>
Subject: Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
Date: Thu, 9 Sep 2021 13:12:37 -0600	[thread overview]
Message-ID: <6a8f0e91-225a-e2a8-3745-12ff1710a8df@gmail.com> (raw)
In-Reply-To: <CAKD1Yr2aijPe_aq+SRm-xv0ZPoz_gKjYrEX97R1NJyYpSnv4zg@mail.gmail.com>

On 9/9/21 12:20 AM, Lorenzo Colitti wrote:
>> 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,
> 
> I think the real requirement here (which wasn't clear in this thread)
> is that the network needs to control the interface ID (i.e., the
> bottom 64 bits) of the link-local address, but the device is free to
> use whatever interface IDs to form global addresses. See:
> https://www.etsi.org/deliver/etsi_ts/129000_129099/129061/15.03.00_60/ts_129061v150300p.pdf
> 
> How do you think that would best be implemented?

There is an established paradigm for configuring how an IPv6 address is
created or whether it is created at all - the IFLA_INET6_ADDR_GEN_MODE
attribute.

> 
> 1. The actual interface ID could be passed in using IFLA_INET6_TOKEN,
> but there is only one token, so that would cause all future addresses
> to use the token, disabling things like privacy addresses (bad).
> 2. We could add new IN6_ADDR_GEN_MODE_STABLE_PRIVACY_LL_TOKEN,
> IN6_ADDR_GEN_MODE_RANDOM_LL_TOKEN, etc., but we'd need to add one such
> mode for every new mode we add.
> 3. We could add a separate sysctl for the link-local address, but you
> said that per-device sysctls aren't free.

per-device sysctl's are one of primary causes of per netdev memory usage.

Besides that there is no reason to add complexity by having a link
attribute and a sysctl for this feature.

> 4. We could change the behaviour so that if the user configures a
> token and then sets IN6_ADDR_GEN_MODE_*, then we use the token only
> for the link-local address. But that would impact backwards
> compatibility.
> 
> Thoughts?

We can have up to 255 ADDR_GEN_MODEs (GEN_MODE is a u8). There is
established code for handling the attribute and changes to it. Let's
reuse it.

_______________________________________________
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: David Ahern <dsahern@gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
Cc: "Rocco Yue" <rocco.yue@mediatek.com>,
	"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>,
	"Linux NetDev" <netdev@vger.kernel.org>,
	lkml <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 (王國鴻)" <kuohong.wang@mediatek.com>,
	"Zhuoliang Zhang (张卓亮)" <zhuoliang.zhang@mediatek.com>
Subject: Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
Date: Thu, 9 Sep 2021 13:12:37 -0600	[thread overview]
Message-ID: <6a8f0e91-225a-e2a8-3745-12ff1710a8df@gmail.com> (raw)
In-Reply-To: <CAKD1Yr2aijPe_aq+SRm-xv0ZPoz_gKjYrEX97R1NJyYpSnv4zg@mail.gmail.com>

On 9/9/21 12:20 AM, Lorenzo Colitti wrote:
>> 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,
> 
> I think the real requirement here (which wasn't clear in this thread)
> is that the network needs to control the interface ID (i.e., the
> bottom 64 bits) of the link-local address, but the device is free to
> use whatever interface IDs to form global addresses. See:
> https://www.etsi.org/deliver/etsi_ts/129000_129099/129061/15.03.00_60/ts_129061v150300p.pdf
> 
> How do you think that would best be implemented?

There is an established paradigm for configuring how an IPv6 address is
created or whether it is created at all - the IFLA_INET6_ADDR_GEN_MODE
attribute.

> 
> 1. The actual interface ID could be passed in using IFLA_INET6_TOKEN,
> but there is only one token, so that would cause all future addresses
> to use the token, disabling things like privacy addresses (bad).
> 2. We could add new IN6_ADDR_GEN_MODE_STABLE_PRIVACY_LL_TOKEN,
> IN6_ADDR_GEN_MODE_RANDOM_LL_TOKEN, etc., but we'd need to add one such
> mode for every new mode we add.
> 3. We could add a separate sysctl for the link-local address, but you
> said that per-device sysctls aren't free.

per-device sysctl's are one of primary causes of per netdev memory usage.

Besides that there is no reason to add complexity by having a link
attribute and a sysctl for this feature.

> 4. We could change the behaviour so that if the user configures a
> token and then sets IN6_ADDR_GEN_MODE_*, then we use the token only
> for the link-local address. But that would impact backwards
> compatibility.
> 
> Thoughts?

We can have up to 255 ADDR_GEN_MODEs (GEN_MODE is a u8). There is
established code for handling the attribute and changes to it. Let's
reuse it.

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

  reply	other threads:[~2021-09-09 19:12 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
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 [this message]
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=6a8f0e91-225a-e2a8-3745-12ff1710a8df@gmail.com \
    --to=dsahern@gmail.com \
    --cc=chao.song@mediatek.com \
    --cc=davem@davemloft.net \
    --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=lorenzo@google.com \
    --cc=matthias.bgg@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=rocco.yue@gmail.com \
    --cc=rocco.yue@mediatek.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.