| Message ID | 20210701015940.29726-1-rocco.yue@mediatek.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: ipv6: don't generate link-local address in any addr_gen_mode | expand |
| Context | Check | Description |
|---|---|---|
| netdev/cover_letter | success | Link |
| netdev/fixes_present | success | Link |
| netdev/patch_count | success | Link |
| netdev/tree_selection | success | Guessed tree name to be net-next |
| netdev/subject_prefix | warning | Target tree name not specified in the subject |
| netdev/cc_maintainers | warning | 7 maintainers not CCed: linmiaohe@huawei.com zxu@linkedin.com willemb@google.com rdunlap@infradead.org praveen5582@gmail.com Jason@zx2c4.com edumazet@google.com |
| netdev/source_inline | success | Was 0 now: 0 |
| netdev/verify_signedoff | success | Link |
| netdev/module_param | success | Was 0 now: 0 |
| netdev/build_32bit | success | Errors and warnings before: 2270 this patch: 2270 |
| netdev/kdoc | success | Errors and warnings before: 38 this patch: 38 |
| netdev/verify_fixes | success | Link |
| netdev/checkpatch | warning | WARNING: line length of 84 exceeds 80 columns |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 2358 this patch: 2358 |
| netdev/header_inline | success | Link |
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?
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
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?
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
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
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.
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
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.
>> 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
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
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.
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.
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.
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.
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 */ }
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(+)