* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-07-05 16:35 ` David Ahern
0 siblings, 0 replies; 45+ messages in thread
From: David Ahern @ 2021-07-05 16:35 UTC (permalink / raw)
To: Rocco Yue
Cc: David S . Miller, Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski,
Matthias Brugger, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek, wsd_upstream, rocco.yue, chao.song, kuohong.wang,
zhuoliang.zhang
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-07-05 16:35 ` David Ahern
0 siblings, 0 replies; 45+ messages in thread
From: David Ahern @ 2021-07-05 16:35 UTC (permalink / raw)
To: Rocco Yue
Cc: David S . Miller, Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski,
Matthias Brugger, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek, wsd_upstream, rocco.yue, chao.song, kuohong.wang,
zhuoliang.zhang
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
2021-07-05 16:35 ` David Ahern
(?)
@ 2021-07-06 12:37 ` Rocco Yue
-1 siblings, 0 replies; 45+ messages in thread
From: Rocco Yue @ 2021-07-06 12:37 UTC (permalink / raw)
To: David Ahern
Cc: David S . Miller, Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski,
Matthias Brugger, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek, wsd_upstream, rocco.yue, chao.song, kuohong.wang,
zhuoliang.zhang, 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-07-06 12:37 ` Rocco Yue
0 siblings, 0 replies; 45+ messages in thread
From: Rocco Yue @ 2021-07-06 12:37 UTC (permalink / raw)
To: David Ahern
Cc: David S . Miller, Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski,
Matthias Brugger, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek, wsd_upstream, rocco.yue, chao.song, kuohong.wang,
zhuoliang.zhang, 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-07-06 12:37 ` Rocco Yue
0 siblings, 0 replies; 45+ messages in thread
From: Rocco Yue @ 2021-07-06 12:37 UTC (permalink / raw)
To: David Ahern
Cc: David S . Miller, Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski,
Matthias Brugger, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek, wsd_upstream, rocco.yue, chao.song, kuohong.wang,
zhuoliang.zhang, 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
2021-07-06 12:37 ` Rocco Yue
(?)
@ 2021-07-07 14:39 ` David Ahern
-1 siblings, 0 replies; 45+ messages in thread
From: David Ahern @ 2021-07-07 14:39 UTC (permalink / raw)
To: Rocco Yue
Cc: David S . Miller, Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski,
Matthias Brugger, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek, wsd_upstream, rocco.yue, chao.song, kuohong.wang,
zhuoliang.zhang
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-07-07 14:39 ` David Ahern
0 siblings, 0 replies; 45+ messages in thread
From: David Ahern @ 2021-07-07 14:39 UTC (permalink / raw)
To: Rocco Yue
Cc: David S . Miller, Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski,
Matthias Brugger, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek, wsd_upstream, rocco.yue, chao.song, kuohong.wang,
zhuoliang.zhang
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-07-07 14:39 ` David Ahern
0 siblings, 0 replies; 45+ messages in thread
From: David Ahern @ 2021-07-07 14:39 UTC (permalink / raw)
To: Rocco Yue
Cc: David S . Miller, Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski,
Matthias Brugger, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek, wsd_upstream, rocco.yue, chao.song, kuohong.wang,
zhuoliang.zhang
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
2021-07-07 14:39 ` David Ahern
(?)
@ 2021-07-13 1:49 ` Rocco Yue
-1 siblings, 0 replies; 45+ messages in thread
From: Rocco Yue @ 2021-07-13 1:49 UTC (permalink / raw)
To: David Ahern
Cc: David S . Miller, Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski,
Matthias Brugger, maze, lorenzo, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, kuohong.wang, zhuoliang.zhang, 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-07-13 1:49 ` Rocco Yue
0 siblings, 0 replies; 45+ messages in thread
From: Rocco Yue @ 2021-07-13 1:49 UTC (permalink / raw)
To: David Ahern
Cc: David S . Miller, Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski,
Matthias Brugger, maze, lorenzo, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, kuohong.wang, zhuoliang.zhang, 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-07-13 1:49 ` Rocco Yue
0 siblings, 0 replies; 45+ messages in thread
From: Rocco Yue @ 2021-07-13 1:49 UTC (permalink / raw)
To: David Ahern
Cc: David S . Miller, Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski,
Matthias Brugger, maze, lorenzo, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, kuohong.wang, zhuoliang.zhang, 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
2021-07-05 16:35 ` David Ahern
(?)
@ 2021-09-09 6:20 ` Lorenzo Colitti
-1 siblings, 0 replies; 45+ messages in thread
From: Lorenzo Colitti @ 2021-09-09 6:20 UTC (permalink / raw)
To: David Ahern
Cc: Rocco Yue, David S . Miller, Hideaki YOSHIFUJI, David Ahern,
Jakub Kicinski, Matthias Brugger, Linux NetDev, lkml,
linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-09-09 6:20 ` Lorenzo Colitti
0 siblings, 0 replies; 45+ messages in thread
From: Lorenzo Colitti @ 2021-09-09 6:20 UTC (permalink / raw)
To: David Ahern
Cc: Rocco Yue, David S . Miller, Hideaki YOSHIFUJI, David Ahern,
Jakub Kicinski, Matthias Brugger, Linux NetDev, lkml,
linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-09-09 6:20 ` Lorenzo Colitti
0 siblings, 0 replies; 45+ messages in thread
From: Lorenzo Colitti @ 2021-09-09 6:20 UTC (permalink / raw)
To: David Ahern
Cc: Rocco Yue, David S . Miller, Hideaki YOSHIFUJI, David Ahern,
Jakub Kicinski, Matthias Brugger, Linux NetDev, lkml,
linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
2021-09-09 6:20 ` Lorenzo Colitti
(?)
@ 2021-09-09 19:12 ` David Ahern
-1 siblings, 0 replies; 45+ messages in thread
From: David Ahern @ 2021-09-09 19:12 UTC (permalink / raw)
To: Lorenzo Colitti
Cc: Rocco Yue, David S . Miller, Hideaki YOSHIFUJI, David Ahern,
Jakub Kicinski, Matthias Brugger, Linux NetDev, lkml,
linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-09-09 19:12 ` David Ahern
0 siblings, 0 replies; 45+ messages in thread
From: David Ahern @ 2021-09-09 19:12 UTC (permalink / raw)
To: Lorenzo Colitti
Cc: Rocco Yue, David S . Miller, Hideaki YOSHIFUJI, David Ahern,
Jakub Kicinski, Matthias Brugger, Linux NetDev, lkml,
linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-09-09 19:12 ` David Ahern
0 siblings, 0 replies; 45+ messages in thread
From: David Ahern @ 2021-09-09 19:12 UTC (permalink / raw)
To: Lorenzo Colitti
Cc: Rocco Yue, David S . Miller, Hideaki YOSHIFUJI, David Ahern,
Jakub Kicinski, Matthias Brugger, Linux NetDev, lkml,
linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
2021-09-09 19:12 ` David Ahern
(?)
@ 2021-09-12 15:47 ` Mark Smith
-1 siblings, 0 replies; 45+ messages in thread
From: Mark Smith @ 2021-09-12 15:47 UTC (permalink / raw)
To: David Ahern
Cc: Lorenzo Colitti, Rocco Yue, David S . Miller, Hideaki YOSHIFUJI,
David Ahern, Jakub Kicinski, Matthias Brugger, Linux NetDev,
lkml, linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-09-12 15:47 ` Mark Smith
0 siblings, 0 replies; 45+ messages in thread
From: Mark Smith @ 2021-09-12 15:47 UTC (permalink / raw)
To: David Ahern
Cc: Lorenzo Colitti, Rocco Yue, David S . Miller, Hideaki YOSHIFUJI,
David Ahern, Jakub Kicinski, Matthias Brugger, Linux NetDev,
lkml, linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-09-12 15:47 ` Mark Smith
0 siblings, 0 replies; 45+ messages in thread
From: Mark Smith @ 2021-09-12 15:47 UTC (permalink / raw)
To: David Ahern
Cc: Lorenzo Colitti, Rocco Yue, David S . Miller, Hideaki YOSHIFUJI,
David Ahern, Jakub Kicinski, Matthias Brugger, Linux NetDev,
lkml, linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
2021-09-12 15:47 ` Mark Smith
(?)
@ 2021-09-13 9:38 ` Lorenzo Colitti
-1 siblings, 0 replies; 45+ messages in thread
From: Lorenzo Colitti @ 2021-09-13 9:38 UTC (permalink / raw)
To: Mark Smith
Cc: David Ahern, Rocco Yue, David S . Miller, Hideaki YOSHIFUJI,
David Ahern, Jakub Kicinski, Matthias Brugger, Linux NetDev,
lkml, linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-09-13 9:38 ` Lorenzo Colitti
0 siblings, 0 replies; 45+ messages in thread
From: Lorenzo Colitti @ 2021-09-13 9:38 UTC (permalink / raw)
To: Mark Smith
Cc: David Ahern, Rocco Yue, David S . Miller, Hideaki YOSHIFUJI,
David Ahern, Jakub Kicinski, Matthias Brugger, Linux NetDev,
lkml, linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-09-13 9:38 ` Lorenzo Colitti
0 siblings, 0 replies; 45+ messages in thread
From: Lorenzo Colitti @ 2021-09-13 9:38 UTC (permalink / raw)
To: Mark Smith
Cc: David Ahern, Rocco Yue, David S . Miller, Hideaki YOSHIFUJI,
David Ahern, Jakub Kicinski, Matthias Brugger, Linux NetDev,
lkml, linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
2021-09-13 9:38 ` Lorenzo Colitti
(?)
@ 2021-09-13 15:22 ` Mark Smith
-1 siblings, 0 replies; 45+ messages in thread
From: Mark Smith @ 2021-09-13 15:22 UTC (permalink / raw)
To: Lorenzo Colitti
Cc: David Ahern, Rocco Yue, David S . Miller, Hideaki YOSHIFUJI,
David Ahern, Jakub Kicinski, Matthias Brugger, Linux NetDev,
lkml, linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-09-13 15:22 ` Mark Smith
0 siblings, 0 replies; 45+ messages in thread
From: Mark Smith @ 2021-09-13 15:22 UTC (permalink / raw)
To: Lorenzo Colitti
Cc: David Ahern, Rocco Yue, David S . Miller, Hideaki YOSHIFUJI,
David Ahern, Jakub Kicinski, Matthias Brugger, Linux NetDev,
lkml, linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode
@ 2021-09-13 15:22 ` Mark Smith
0 siblings, 0 replies; 45+ messages in thread
From: Mark Smith @ 2021-09-13 15:22 UTC (permalink / raw)
To: Lorenzo Colitti
Cc: David Ahern, Rocco Yue, David S . Miller, Hideaki YOSHIFUJI,
David Ahern, Jakub Kicinski, Matthias Brugger, Linux NetDev,
lkml, linux-arm-kernel, linux-mediatek, wsd_upstream, rocco.yue,
chao.song, Kuohong Wang (王國鴻),
Zhuoliang Zhang (张卓亮)
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
^ permalink raw reply [flat|nested] 45+ messages in thread