[PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

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.

The reasons why the kernel does not need to automatically
generate the ipv6 link-local address are as follows:

(1) In the 3GPP TS 29.061, here is a description as follows:
"in order to avoid any conflict between the link-local address
of the MS and that of the GGSN, the Interface-Identifier used
by the MS to build its link-local address shall be assigned by
the GGSN. The GGSN ensures the uniqueness of this Interface-
Identifier. The MT shall then enforce the use of this
Interface-Identifier by the TE"

In other words, in the cellular network, GGSN determines whether
to reply a solicited RA message by identifying the low 64 bits
of the source address of the received RS message. Therefore,
cellular network device's ipv6 link-local address should be set
as the format of fe80::(GGSN assigned IID).

For example: When using a new kernel and ARPHRD_RAWIP, kernel
will generate an EUI64 format ipv6 link-local address, and the
Linux kernel will uses this link-local address to send RS message.
The result is that the GGSN will not reply to the RS message with
a solicited RA message.

Although the combination of IN6_ADDR_GEN_MODE_NONE + ARPHRD_NONE
can avoid the above problem (1), when the addr_gen_mode is changed
to the IN6_ADDR_GEN_MODE_STABLE_PRIVACY, the above problem still
exist. The detail as follows:

(2) Among global mobile operators, some operators have already
request MT (Mobile Terminal) to support RFC7217, such as AT&T.
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.

Obviously using APRHRD_NONE and IN6_ADDR_GEN_MODE_STABLE_PRIVACY
mode cannot achieve this.

In summary, using the "disable_gen_linklocal_addr" proc file can
disable kernel auto generate ipv6 link-local address no matter
which addr_gen_mode is used.

Signed-off-by: Rocco Yue <rocco.yue@mediatek.com>
---
 include/linux/ipv6.h      |  1 +
 include/uapi/linux/ipv6.h |  1 +
 net/ipv6/addrconf.c       | 16 ++++++++++++++++
 3 files changed, 18 insertions(+)

diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 70b2ad3b9884..60c5da76e207 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -76,6 +76,7 @@ struct ipv6_devconf {
 	__s32		disable_policy;
 	__s32           ndisc_tclass;
 	__s32		rpl_seg_enabled;
+	__s32		disable_gen_linklocal_addr;
 
 	struct ctl_table_header *sysctl_header;
 };
diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
index 70603775fe91..0449d908b8c2 100644
--- a/include/uapi/linux/ipv6.h
+++ b/include/uapi/linux/ipv6.h
@@ -190,6 +190,7 @@ enum {
 	DEVCONF_NDISC_TCLASS,
 	DEVCONF_RPL_SEG_ENABLED,
 	DEVCONF_RA_DEFRTR_METRIC,
+	DEVCONF_DISABLE_GEN_LINKLOCAL_ADDR,
 	DEVCONF_MAX
 };
 
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 701eb82acd1c..0035f935b25a 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -237,6 +237,7 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
 	.addr_gen_mode		= IN6_ADDR_GEN_MODE_EUI64,
 	.disable_policy		= 0,
 	.rpl_seg_enabled	= 0,
+	.disable_gen_linklocal_addr = 0,
 };
 
 static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
@@ -293,6 +294,7 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
 	.addr_gen_mode		= IN6_ADDR_GEN_MODE_EUI64,
 	.disable_policy		= 0,
 	.rpl_seg_enabled	= 0,
+	.disable_gen_linklocal_addr = 0,
 };
 
 /* Check if link is ready: is it up and is a valid qdisc available */
@@ -3352,6 +3354,12 @@ static void addrconf_dev_config(struct net_device *dev)
 	if (IS_ERR(idev))
 		return;
 
+	if (idev->cnf.disable_gen_linklocal_addr) {
+		pr_info("%s: IPv6 link-local address being disabled\n",
+			idev->dev->name);
+		return;
+	}
+
 	/* this device type has no EUI support */
 	if (dev->type == ARPHRD_NONE &&
 	    idev->cnf.addr_gen_mode == IN6_ADDR_GEN_MODE_EUI64)
@@ -5526,6 +5534,7 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
 	array[DEVCONF_DISABLE_POLICY] = cnf->disable_policy;
 	array[DEVCONF_NDISC_TCLASS] = cnf->ndisc_tclass;
 	array[DEVCONF_RPL_SEG_ENABLED] = cnf->rpl_seg_enabled;
+	array[DEVCONF_DISABLE_GEN_LINKLOCAL_ADDR] = cnf->disable_gen_linklocal_addr;
 }
 
 static inline size_t inet6_ifla6_size(void)
@@ -6932,6 +6941,13 @@ static const struct ctl_table addrconf_sysctl[] = {
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec,
 	},
+	{
+		.procname	= "disable_gen_linklocal_addr",
+		.data		= &ipv6_devconf.disable_gen_linklocal_addr,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+	},
 	{
 		/* sentinel */
 	}
-- 
2.18.0

[PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

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.

The reasons why the kernel does not need to automatically
generate the ipv6 link-local address are as follows:

(1) In the 3GPP TS 29.061, here is a description as follows:
"in order to avoid any conflict between the link-local address
of the MS and that of the GGSN, the Interface-Identifier used
by the MS to build its link-local address shall be assigned by
the GGSN. The GGSN ensures the uniqueness of this Interface-
Identifier. The MT shall then enforce the use of this
Interface-Identifier by the TE"

In other words, in the cellular network, GGSN determines whether
to reply a solicited RA message by identifying the low 64 bits
of the source address of the received RS message. Therefore,
cellular network device's ipv6 link-local address should be set
as the format of fe80::(GGSN assigned IID).

For example: When using a new kernel and ARPHRD_RAWIP, kernel
will generate an EUI64 format ipv6 link-local address, and the
Linux kernel will uses this link-local address to send RS message.
The result is that the GGSN will not reply to the RS message with
a solicited RA message.

Although the combination of IN6_ADDR_GEN_MODE_NONE + ARPHRD_NONE
can avoid the above problem (1), when the addr_gen_mode is changed
to the IN6_ADDR_GEN_MODE_STABLE_PRIVACY, the above problem still
exist. The detail as follows:

(2) Among global mobile operators, some operators have already
request MT (Mobile Terminal) to support RFC7217, such as AT&T.
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.

Obviously using APRHRD_NONE and IN6_ADDR_GEN_MODE_STABLE_PRIVACY
mode cannot achieve this.

In summary, using the "disable_gen_linklocal_addr" proc file can
disable kernel auto generate ipv6 link-local address no matter
which addr_gen_mode is used.

Signed-off-by: Rocco Yue <rocco.yue@mediatek.com>
---
 include/linux/ipv6.h      |  1 +
 include/uapi/linux/ipv6.h |  1 +
 net/ipv6/addrconf.c       | 16 ++++++++++++++++
 3 files changed, 18 insertions(+)

diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 70b2ad3b9884..60c5da76e207 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -76,6 +76,7 @@ struct ipv6_devconf {
 	__s32		disable_policy;
 	__s32           ndisc_tclass;
 	__s32		rpl_seg_enabled;
+	__s32		disable_gen_linklocal_addr;
 
 	struct ctl_table_header *sysctl_header;
 };
diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
index 70603775fe91..0449d908b8c2 100644
--- a/include/uapi/linux/ipv6.h
+++ b/include/uapi/linux/ipv6.h
@@ -190,6 +190,7 @@ enum {
 	DEVCONF_NDISC_TCLASS,
 	DEVCONF_RPL_SEG_ENABLED,
 	DEVCONF_RA_DEFRTR_METRIC,
+	DEVCONF_DISABLE_GEN_LINKLOCAL_ADDR,
 	DEVCONF_MAX
 };
 
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 701eb82acd1c..0035f935b25a 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -237,6 +237,7 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
 	.addr_gen_mode		= IN6_ADDR_GEN_MODE_EUI64,
 	.disable_policy		= 0,
 	.rpl_seg_enabled	= 0,
+	.disable_gen_linklocal_addr = 0,
 };
 
 static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
@@ -293,6 +294,7 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
 	.addr_gen_mode		= IN6_ADDR_GEN_MODE_EUI64,
 	.disable_policy		= 0,
 	.rpl_seg_enabled	= 0,
+	.disable_gen_linklocal_addr = 0,
 };
 
 /* Check if link is ready: is it up and is a valid qdisc available */
@@ -3352,6 +3354,12 @@ static void addrconf_dev_config(struct net_device *dev)
 	if (IS_ERR(idev))
 		return;
 
+	if (idev->cnf.disable_gen_linklocal_addr) {
+		pr_info("%s: IPv6 link-local address being disabled\n",
+			idev->dev->name);
+		return;
+	}
+
 	/* this device type has no EUI support */
 	if (dev->type == ARPHRD_NONE &&
 	    idev->cnf.addr_gen_mode == IN6_ADDR_GEN_MODE_EUI64)
@@ -5526,6 +5534,7 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
 	array[DEVCONF_DISABLE_POLICY] = cnf->disable_policy;
 	array[DEVCONF_NDISC_TCLASS] = cnf->ndisc_tclass;
 	array[DEVCONF_RPL_SEG_ENABLED] = cnf->rpl_seg_enabled;
+	array[DEVCONF_DISABLE_GEN_LINKLOCAL_ADDR] = cnf->disable_gen_linklocal_addr;
 }
 
 static inline size_t inet6_ifla6_size(void)
@@ -6932,6 +6941,13 @@ static const struct ctl_table addrconf_sysctl[] = {
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec,
 	},
+	{
+		.procname	= "disable_gen_linklocal_addr",
+		.data		= &ipv6_devconf.disable_gen_linklocal_addr,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+	},
 	{
 		/* sentinel */
 	}
-- 
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

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.

The reasons why the kernel does not need to automatically
generate the ipv6 link-local address are as follows:

(1) In the 3GPP TS 29.061, here is a description as follows:
"in order to avoid any conflict between the link-local address
of the MS and that of the GGSN, the Interface-Identifier used
by the MS to build its link-local address shall be assigned by
the GGSN. The GGSN ensures the uniqueness of this Interface-
Identifier. The MT shall then enforce the use of this
Interface-Identifier by the TE"

In other words, in the cellular network, GGSN determines whether
to reply a solicited RA message by identifying the low 64 bits
of the source address of the received RS message. Therefore,
cellular network device's ipv6 link-local address should be set
as the format of fe80::(GGSN assigned IID).

For example: When using a new kernel and ARPHRD_RAWIP, kernel
will generate an EUI64 format ipv6 link-local address, and the
Linux kernel will uses this link-local address to send RS message.
The result is that the GGSN will not reply to the RS message with
a solicited RA message.

Although the combination of IN6_ADDR_GEN_MODE_NONE + ARPHRD_NONE
can avoid the above problem (1), when the addr_gen_mode is changed
to the IN6_ADDR_GEN_MODE_STABLE_PRIVACY, the above problem still
exist. The detail as follows:

(2) Among global mobile operators, some operators have already
request MT (Mobile Terminal) to support RFC7217, such as AT&T.
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.

Obviously using APRHRD_NONE and IN6_ADDR_GEN_MODE_STABLE_PRIVACY
mode cannot achieve this.

In summary, using the "disable_gen_linklocal_addr" proc file can
disable kernel auto generate ipv6 link-local address no matter
which addr_gen_mode is used.

Signed-off-by: Rocco Yue <rocco.yue@mediatek.com>
---
 include/linux/ipv6.h      |  1 +
 include/uapi/linux/ipv6.h |  1 +
 net/ipv6/addrconf.c       | 16 ++++++++++++++++
 3 files changed, 18 insertions(+)

diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 70b2ad3b9884..60c5da76e207 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -76,6 +76,7 @@ struct ipv6_devconf {
 	__s32		disable_policy;
 	__s32           ndisc_tclass;
 	__s32		rpl_seg_enabled;
+	__s32		disable_gen_linklocal_addr;
 
 	struct ctl_table_header *sysctl_header;
 };
diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
index 70603775fe91..0449d908b8c2 100644
--- a/include/uapi/linux/ipv6.h
+++ b/include/uapi/linux/ipv6.h
@@ -190,6 +190,7 @@ enum {
 	DEVCONF_NDISC_TCLASS,
 	DEVCONF_RPL_SEG_ENABLED,
 	DEVCONF_RA_DEFRTR_METRIC,
+	DEVCONF_DISABLE_GEN_LINKLOCAL_ADDR,
 	DEVCONF_MAX
 };
 
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 701eb82acd1c..0035f935b25a 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -237,6 +237,7 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
 	.addr_gen_mode		= IN6_ADDR_GEN_MODE_EUI64,
 	.disable_policy		= 0,
 	.rpl_seg_enabled	= 0,
+	.disable_gen_linklocal_addr = 0,
 };
 
 static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
@@ -293,6 +294,7 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
 	.addr_gen_mode		= IN6_ADDR_GEN_MODE_EUI64,
 	.disable_policy		= 0,
 	.rpl_seg_enabled	= 0,
+	.disable_gen_linklocal_addr = 0,
 };
 
 /* Check if link is ready: is it up and is a valid qdisc available */
@@ -3352,6 +3354,12 @@ static void addrconf_dev_config(struct net_device *dev)
 	if (IS_ERR(idev))
 		return;
 
+	if (idev->cnf.disable_gen_linklocal_addr) {
+		pr_info("%s: IPv6 link-local address being disabled\n",
+			idev->dev->name);
+		return;
+	}
+
 	/* this device type has no EUI support */
 	if (dev->type == ARPHRD_NONE &&
 	    idev->cnf.addr_gen_mode == IN6_ADDR_GEN_MODE_EUI64)
@@ -5526,6 +5534,7 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
 	array[DEVCONF_DISABLE_POLICY] = cnf->disable_policy;
 	array[DEVCONF_NDISC_TCLASS] = cnf->ndisc_tclass;
 	array[DEVCONF_RPL_SEG_ENABLED] = cnf->rpl_seg_enabled;
+	array[DEVCONF_DISABLE_GEN_LINKLOCAL_ADDR] = cnf->disable_gen_linklocal_addr;
 }
 
 static inline size_t inet6_ifla6_size(void)
@@ -6932,6 +6941,13 @@ static const struct ctl_table addrconf_sysctl[] = {
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec,
 	},
+	{
+		.procname	= "disable_gen_linklocal_addr",
+		.data		= &ipv6_devconf.disable_gen_linklocal_addr,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+	},
 	{
 		/* sentinel */
 	}
-- 
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

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?

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

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?

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

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?

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

On 6/30/21 9:39 PM, Rocco Yue wrote:
> 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.
> 

...

> 
> 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?

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

On 6/30/21 9:39 PM, Rocco Yue wrote:
> 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.
> 

...

> 
> 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?


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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

On 6/30/21 9:39 PM, Rocco Yue wrote:
> 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.
> 

...

> 
> 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?


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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

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
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

On Thu, 2021-07-01 at 16:51 +0800, Rocco Yue wrote:
> 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
> 

Hi David,

Gentle ping for this patch.

Thanks,
Rocco

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

On Thu, 2021-07-01 at 16:51 +0800, Rocco Yue wrote:
> 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
> 

Hi David,

Gentle ping for this patch.

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

On Thu, 2021-07-01 at 16:51 +0800, Rocco Yue wrote:
> 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
> 

Hi David,

Gentle ping for this patch.

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

On 7/1/21 2:51 AM, Rocco Yue wrote:
> 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.
> 

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.

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

On 7/1/21 2:51 AM, Rocco Yue wrote:
> 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.
> 

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.

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

On 7/1/21 2:51 AM, Rocco Yue wrote:
> 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.
> 

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.

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

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/<iface>/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/<iface>/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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

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/<iface>/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/<iface>/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
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

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/<iface>/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/<iface>/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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

On 7/6/21 6:37 AM, Rocco Yue wrote:
> 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/<iface>/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".

and that can be updated. If the default (inherited) setting is
IN6_ADDR_GEN_MODE_STABLE_PRIVACY_NO_LLA, then do not change to
IN6_ADDR_GEN_MODE_STABLE_PRIVACY.

> 
> 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/<iface>/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.

per device sysctl's are not free. I do not see a valid reason for a
separate disable knob.

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

On 7/6/21 6:37 AM, Rocco Yue wrote:
> 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/<iface>/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".

and that can be updated. If the default (inherited) setting is
IN6_ADDR_GEN_MODE_STABLE_PRIVACY_NO_LLA, then do not change to
IN6_ADDR_GEN_MODE_STABLE_PRIVACY.

> 
> 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/<iface>/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.

per device sysctl's are not free. I do not see a valid reason for a
separate disable knob.

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

On 7/6/21 6:37 AM, Rocco Yue wrote:
> 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/<iface>/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".

and that can be updated. If the default (inherited) setting is
IN6_ADDR_GEN_MODE_STABLE_PRIVACY_NO_LLA, then do not change to
IN6_ADDR_GEN_MODE_STABLE_PRIVACY.

> 
> 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/<iface>/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.

per device sysctl's are not free. I do not see a valid reason for a
separate disable knob.

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

>> 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/<iface>/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".
> 
> and that can be updated. If the default (inherited) setting is
> IN6_ADDR_GEN_MODE_STABLE_PRIVACY_NO_LLA, then do not change to
> IN6_ADDR_GEN_MODE_STABLE_PRIVACY.
> 
>> 
>> 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/<iface>/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.
> 
> per device sysctl's are not free. I do not see a valid reason for a
> separate disable knob.

Hi David,

Thanks for your reply,

honstly, this separate sysctl is really useful and convenient.

It allows users to simply configure the disable_gen_linklocal_addr
proc file to achieve customized configuration of ipv6 link-local
address without worrying about when the kernel will automatically
generate a link-local address.

At the same time, maybe a new addr_gen_mode will be added in the
future. If the method of adding a sysctl is adopted, we don't need
to consider the existing addr_gen_mode and the impact of adding
another new addr_gen_mode in the future.

Just simply echoing different values to the disable_gen_linklocal_addr
proc file can achieve this needs.

Thanks,
Rocco

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

>> 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/<iface>/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".
> 
> and that can be updated. If the default (inherited) setting is
> IN6_ADDR_GEN_MODE_STABLE_PRIVACY_NO_LLA, then do not change to
> IN6_ADDR_GEN_MODE_STABLE_PRIVACY.
> 
>> 
>> 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/<iface>/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.
> 
> per device sysctl's are not free. I do not see a valid reason for a
> separate disable knob.

Hi David,

Thanks for your reply,

honstly, this separate sysctl is really useful and convenient.

It allows users to simply configure the disable_gen_linklocal_addr
proc file to achieve customized configuration of ipv6 link-local
address without worrying about when the kernel will automatically
generate a link-local address.

At the same time, maybe a new addr_gen_mode will be added in the
future. If the method of adding a sysctl is adopted, we don't need
to consider the existing addr_gen_mode and the impact of adding
another new addr_gen_mode in the future.

Just simply echoing different values to the disable_gen_linklocal_addr
proc file can achieve this needs.

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Rocco Yue]

>> 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/<iface>/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".
> 
> and that can be updated. If the default (inherited) setting is
> IN6_ADDR_GEN_MODE_STABLE_PRIVACY_NO_LLA, then do not change to
> IN6_ADDR_GEN_MODE_STABLE_PRIVACY.
> 
>> 
>> 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/<iface>/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.
> 
> per device sysctl's are not free. I do not see a valid reason for a
> separate disable knob.

Hi David,

Thanks for your reply,

honstly, this separate sysctl is really useful and convenient.

It allows users to simply configure the disable_gen_linklocal_addr
proc file to achieve customized configuration of ipv6 link-local
address without worrying about when the kernel will automatically
generate a link-local address.

At the same time, maybe a new addr_gen_mode will be added in the
future. If the method of adding a sysctl is adopted, we don't need
to consider the existing addr_gen_mode and the impact of adding
another new addr_gen_mode in the future.

Just simply echoing different values to the disable_gen_linklocal_addr
proc file can achieve this needs.

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Lorenzo Colitti]

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Lorenzo Colitti]

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Lorenzo Colitti]

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

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.

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[David Ahern]

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Mark Smith]

This is all going in the wrong direction. Link-local addresses are not
optional on an interface, all IPv6 enabled interfaces are required to
have one:

RFC4291, "IP Version 6 Addressing Architecture"

"2.1.  Addressing Model

All interfaces are required to have at least one Link-Local unicast
   address (see Section 2.8 for additional required addresses)."

Regards,
Mark.



On Fri, 10 Sept 2021 at 05:13, David Ahern <dsahern@gmail.com> wrote:
>
> 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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Mark Smith]

This is all going in the wrong direction. Link-local addresses are not
optional on an interface, all IPv6 enabled interfaces are required to
have one:

RFC4291, "IP Version 6 Addressing Architecture"

"2.1.  Addressing Model

All interfaces are required to have at least one Link-Local unicast
   address (see Section 2.8 for additional required addresses)."

Regards,
Mark.



On Fri, 10 Sept 2021 at 05:13, David Ahern <dsahern@gmail.com> wrote:
>
> 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.

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Mark Smith]

This is all going in the wrong direction. Link-local addresses are not
optional on an interface, all IPv6 enabled interfaces are required to
have one:

RFC4291, "IP Version 6 Addressing Architecture"

"2.1.  Addressing Model

All interfaces are required to have at least one Link-Local unicast
   address (see Section 2.8 for additional required addresses)."

Regards,
Mark.



On Fri, 10 Sept 2021 at 05:13, David Ahern <dsahern@gmail.com> wrote:
>
> 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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Lorenzo Colitti]

On Mon, Sep 13, 2021 at 12:47 AM Mark Smith <markzzzsmith@gmail.com> wrote:
> This is all going in the wrong direction. Link-local addresses are not
> optional on an interface, all IPv6 enabled interfaces are required to
> have one:

The original patch did indeed disable the generation of the link-local
address, but that patch was rejected. It sounds like the right
approach here is to provide two new addressing modes:

IN6_ADDR_GEN_MODE_RANDOM_LL_TOKEN
IN6_ADDR_GEN_MODE_STABLE_PRIVACY_LL_TOKEN

which would form the link-local address from the token passed in via
IFLA_INET6_TOKEN, but would form non-link-local addresses (e.g.,
global addresses) via the specified means (either random or stable
privacy). I haven't looked at how to do that yet though.

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Lorenzo Colitti]

On Mon, Sep 13, 2021 at 12:47 AM Mark Smith <markzzzsmith@gmail.com> wrote:
> This is all going in the wrong direction. Link-local addresses are not
> optional on an interface, all IPv6 enabled interfaces are required to
> have one:

The original patch did indeed disable the generation of the link-local
address, but that patch was rejected. It sounds like the right
approach here is to provide two new addressing modes:

IN6_ADDR_GEN_MODE_RANDOM_LL_TOKEN
IN6_ADDR_GEN_MODE_STABLE_PRIVACY_LL_TOKEN

which would form the link-local address from the token passed in via
IFLA_INET6_TOKEN, but would form non-link-local addresses (e.g.,
global addresses) via the specified means (either random or stable
privacy). I haven't looked at how to do that yet though.

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Lorenzo Colitti]

On Mon, Sep 13, 2021 at 12:47 AM Mark Smith <markzzzsmith@gmail.com> wrote:
> This is all going in the wrong direction. Link-local addresses are not
> optional on an interface, all IPv6 enabled interfaces are required to
> have one:

The original patch did indeed disable the generation of the link-local
address, but that patch was rejected. It sounds like the right
approach here is to provide two new addressing modes:

IN6_ADDR_GEN_MODE_RANDOM_LL_TOKEN
IN6_ADDR_GEN_MODE_STABLE_PRIVACY_LL_TOKEN

which would form the link-local address from the token passed in via
IFLA_INET6_TOKEN, but would form non-link-local addresses (e.g.,
global addresses) via the specified means (either random or stable
privacy). I haven't looked at how to do that yet though.

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Mark Smith]

Hi Lorenzo,

On Mon, 13 Sept 2021 at 19:38, Lorenzo Colitti <lorenzo@google.com> wrote:
>
> On Mon, Sep 13, 2021 at 12:47 AM Mark Smith <markzzzsmith@gmail.com> wrote:
> > This is all going in the wrong direction. Link-local addresses are not
> > optional on an interface, all IPv6 enabled interfaces are required to
> > have one:
>
> The original patch did indeed disable the generation of the link-local
> address, but that patch was rejected. It sounds like the right
> approach here is to provide two new addressing modes:
>
> IN6_ADDR_GEN_MODE_RANDOM_LL_TOKEN
> IN6_ADDR_GEN_MODE_STABLE_PRIVACY_LL_TOKEN
>
> which would form the link-local address from the token passed in via
> IFLA_INET6_TOKEN, but would form non-link-local addresses (e.g.,
> global addresses) via the specified means (either random or stable
> privacy). I haven't looked at how to do that yet though.

I think there is a broader issue here.

If RFC7217 is used to generate the Link-Local address, then the
likelihood of the Link-Local address being a duplicate with the GGSN
is very low, because RFC7217 uses a function such as SHA-1 or SHA-256.
RFC7217 also performs DAD just in case, and triggers RFC7217 again if
a duplicate does occur.

RFC8064 recommends RFC7217 for all stable IPv6 addresses by default
now, which includes Link-Local addresses.

Following RFC8064 by Implementing RFC7217 for all stable IPv6
addresses the Linux kernel generates would solve both the 3GPP's
duplicate Link-Local address concern, and also make the Linux kernel
compliant with the latest SLAAC recommendation for default IIDs and
stable IPv6 addresses.

Regards,
Mark.

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Mark Smith]

Hi Lorenzo,

On Mon, 13 Sept 2021 at 19:38, Lorenzo Colitti <lorenzo@google.com> wrote:
>
> On Mon, Sep 13, 2021 at 12:47 AM Mark Smith <markzzzsmith@gmail.com> wrote:
> > This is all going in the wrong direction. Link-local addresses are not
> > optional on an interface, all IPv6 enabled interfaces are required to
> > have one:
>
> The original patch did indeed disable the generation of the link-local
> address, but that patch was rejected. It sounds like the right
> approach here is to provide two new addressing modes:
>
> IN6_ADDR_GEN_MODE_RANDOM_LL_TOKEN
> IN6_ADDR_GEN_MODE_STABLE_PRIVACY_LL_TOKEN
>
> which would form the link-local address from the token passed in via
> IFLA_INET6_TOKEN, but would form non-link-local addresses (e.g.,
> global addresses) via the specified means (either random or stable
> privacy). I haven't looked at how to do that yet though.

I think there is a broader issue here.

If RFC7217 is used to generate the Link-Local address, then the
likelihood of the Link-Local address being a duplicate with the GGSN
is very low, because RFC7217 uses a function such as SHA-1 or SHA-256.
RFC7217 also performs DAD just in case, and triggers RFC7217 again if
a duplicate does occur.

RFC8064 recommends RFC7217 for all stable IPv6 addresses by default
now, which includes Link-Local addresses.

Following RFC8064 by Implementing RFC7217 for all stable IPv6
addresses the Linux kernel generates would solve both the 3GPP's
duplicate Link-Local address concern, and also make the Linux kernel
compliant with the latest SLAAC recommendation for default IIDs and
stable IPv6 addresses.

Regards,
Mark.

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

Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode

[Mark Smith]

Hi Lorenzo,

On Mon, 13 Sept 2021 at 19:38, Lorenzo Colitti <lorenzo@google.com> wrote:
>
> On Mon, Sep 13, 2021 at 12:47 AM Mark Smith <markzzzsmith@gmail.com> wrote:
> > This is all going in the wrong direction. Link-local addresses are not
> > optional on an interface, all IPv6 enabled interfaces are required to
> > have one:
>
> The original patch did indeed disable the generation of the link-local
> address, but that patch was rejected. It sounds like the right
> approach here is to provide two new addressing modes:
>
> IN6_ADDR_GEN_MODE_RANDOM_LL_TOKEN
> IN6_ADDR_GEN_MODE_STABLE_PRIVACY_LL_TOKEN
>
> which would form the link-local address from the token passed in via
> IFLA_INET6_TOKEN, but would form non-link-local addresses (e.g.,
> global addresses) via the specified means (either random or stable
> privacy). I haven't looked at how to do that yet though.

I think there is a broader issue here.

If RFC7217 is used to generate the Link-Local address, then the
likelihood of the Link-Local address being a duplicate with the GGSN
is very low, because RFC7217 uses a function such as SHA-1 or SHA-256.
RFC7217 also performs DAD just in case, and triggers RFC7217 again if
a duplicate does occur.

RFC8064 recommends RFC7217 for all stable IPv6 addresses by default
now, which includes Link-Local addresses.

Following RFC8064 by Implementing RFC7217 for all stable IPv6
addresses the Linux kernel generates would solve both the 3GPP's
duplicate Link-Local address concern, and also make the Linux kernel
compliant with the latest SLAAC recommendation for default IIDs and
stable IPv6 addresses.

Regards,
Mark.