From: Lorenzo Colitti <lorenzo@google.com>
To: David Ahern <dsahern@gmail.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 15:20:51 +0900 [thread overview]
Message-ID: <CAKD1Yr2aijPe_aq+SRm-xv0ZPoz_gKjYrEX97R1NJyYpSnv4zg@mail.gmail.com> (raw)
In-Reply-To: <62c9f5b7-84bd-d809-4e33-39fed7a9d780@gmail.com>
David,
sorry for reviving this discussion, but it felt better than starting a
new thread about this. We (Android) added a vendor hook for this, but
IMO that's the wrong solution and I think we'd still like to see this
fixed the right way.
> 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?
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.
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?
Cheers,
Lorenzo
WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Colitti <lorenzo@google.com>
To: David Ahern <dsahern@gmail.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 15:20:51 +0900 [thread overview]
Message-ID: <CAKD1Yr2aijPe_aq+SRm-xv0ZPoz_gKjYrEX97R1NJyYpSnv4zg@mail.gmail.com> (raw)
In-Reply-To: <62c9f5b7-84bd-d809-4e33-39fed7a9d780@gmail.com>
David,
sorry for reviving this discussion, but it felt better than starting a
new thread about this. We (Android) added a vendor hook for this, but
IMO that's the wrong solution and I think we'd still like to see this
fixed the right way.
> 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?
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.
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?
Cheers,
Lorenzo
_______________________________________________
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: Lorenzo Colitti <lorenzo@google.com>
To: David Ahern <dsahern@gmail.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 15:20:51 +0900 [thread overview]
Message-ID: <CAKD1Yr2aijPe_aq+SRm-xv0ZPoz_gKjYrEX97R1NJyYpSnv4zg@mail.gmail.com> (raw)
In-Reply-To: <62c9f5b7-84bd-d809-4e33-39fed7a9d780@gmail.com>
David,
sorry for reviving this discussion, but it felt better than starting a
new thread about this. We (Android) added a vendor hook for this, but
IMO that's the wrong solution and I think we'd still like to see this
fixed the right way.
> 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?
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.
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?
Cheers,
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-09-09 6:52 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 [this message]
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=CAKD1Yr2aijPe_aq+SRm-xv0ZPoz_gKjYrEX97R1NJyYpSnv4zg@mail.gmail.com \
--to=lorenzo@google.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=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.