15.3 KDE network manager -- no persistent IPv6 address
I run OpenSUSE 15.3 on a notebook computer, with network manager for configuring IP. One thing I've noticed is there do not appear to be any persistent IPv6 addresses. Normally, with SLAAC, there is 1 persistent address, based on either the MAC address or a random number. There can then be up to 7 privacy addresses, depending on how long the computer has been running. Without a persistent address, DNS can't be used to reach it. Is it possible to enable a persistent address with the network manager? tnx jk
On 09.05.2022 03:06, James Knott wrote:
I run OpenSUSE 15.3 on a notebook computer, with network manager for configuring IP. One thing I've noticed is there do not appear to be any persistent IPv6 addresses. Normally, with SLAAC, there is 1 persistent address, based on either the MAC address or a random number. There can then be up to 7 privacy addresses, depending on how long the computer has been running. Without a persistent address, DNS can't be used to reach it. Is it possible to enable a persistent address with the network manager?
tnx jk
This is ipv6.ip6-privacy connection property. If it is not set explicitly, it defaults to whatever kernel configuration is (.../use_tempaddr). This may or may not be exposed by frontend and different frontends may default to different values. I am not familiar with current KDE code, but briefly looking in plasma-nm-applet git, this setting is exposed and default is to use default (pun unintended), i.e. kernel setting.
On 2022-05-09 2:43 a.m., Andrei Borzenkov wrote:
This is ipv6.ip6-privacy connection property. If it is not set explicitly, it defaults to whatever kernel configuration is (.../use_tempaddr). This may or may not be exposed by frontend and different frontends may default to different values. I am not familiar with current KDE code, but briefly looking in plasma-nm-applet git, this setting is exposed and default is to use default (pun unintended), i.e. kernel setting.
Is it possible to change it? All I see in kernel settings is a check box to enable SysReq keys.
James Knott wrote:
On 2022-05-09 2:43 a.m., Andrei Borzenkov wrote:
This is ipv6.ip6-privacy connection property. If it is not set explicitly, it defaults to whatever kernel configuration is (.../use_tempaddr). This may or may not be exposed by frontend and different frontends may default to different values. I am not familiar with current KDE code, but briefly looking in plasma-nm-applet git, this setting is exposed and default is to use default (pun unintended), i.e. kernel setting.
Is it possible to change it? All I see in kernel settings is a check box to enable SysReq keys.
Look for the "use_tempaddr" in /proc/sys/net -- Per Jessen, Zürich (21.9°C)
On 2022-05-09 9:17 a.m., Per Jessen wrote:
Is it possible to change it? All I see in kernel settings is a check box to enable SysReq keys. Look for the "use_tempaddr" in /proc/sys/net
I don't think that's the setting. It's "1" on both my ThinkPad and desktop systems and SLAAC works properly on my desktop. That setting allows privacy addresses to be used, in addition to a persistent address. I don't think it prevents the persistent address from working. On my desktop, also 15.3 but with network configured with Wicked, I get 1 persistent address and up to 7 privacy addresses, with a new one each day.
On 09.05.2022 17:03, James Knott wrote:
On 2022-05-09 9:17 a.m., Per Jessen wrote:
Is it possible to change it? All I see in kernel settings is a check box to enable SysReq keys. Look for the "use_tempaddr" in /proc/sys/net
I don't think that's the setting.
You provided vague description of your problem and got vague suggestion. Start with showing actual facts like "ip -6 a" and marking what is wrong.
It's "1" on both my ThinkPad and desktop systems and SLAAC works properly on my desktop. That setting allows privacy addresses to be used, in addition to a persistent address. I don't think it prevents the persistent address from working. On my desktop, also 15.3 but with network configured with Wicked, I get 1 persistent address and up to 7 privacy addresses, with a new one each day.
On 2022-05-09 10:10 a.m., Andrei Borzenkov wrote:
You provided vague description of your problem and got vague suggestion. Start with showing actual facts like "ip -6 a" and marking what is wrong.
I already stated that I only get dynamic addresses and no persistent address. wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 fd48:1a37:2160:0:314d:2cb6:9ec9:c4c1/64 scope global temporary dynamic valid_lft 85611sec preferred_lft 13611sec inet6 fd48:1a37:2160:0:71f0:e1b4:77ce:12e4/64 scope global dynamic mngtmpaddr noprefixroute <--- ??? valid_lft 85611sec preferred_lft 13611sec inet6 2607:fea8:4c82:5900:314d:2cb6:9ec9:c4c1/64 scope global temporary dynamic valid_lft 85611sec preferred_lft 13611sec inet6 2607:fea8:4c82:5900:8d63:e1de:7def:14a8/64 scope global dynamic mngtmpaddr noprefixroute <--- ??? valid_lft 85611sec preferred_lft 13611sec inet6 fe80::2579:66fb:acb:bda0/64 scope link noprefixroute valid_lft forever preferred_lft forever On the desktop system, I have this line, where the address is based on the MAC: inet6 fd48:1a37:2160:0:76d4:35ff:fe5b:f5fa/64 scope global dynamic mngtmpaddr This address is persistent and has survived for years, through even replacing my firewall computer and cable modem and updating openSUSE. Also, the least significant 64 bits have remained through different prefixes, as they're based on the MAC. On my ThinkPad, I can't even get an address that survives a reboot.
On 09.05.2022 17:42, James Knott wrote:
On 2022-05-09 10:10 a.m., Andrei Borzenkov wrote:
You provided vague description of your problem and got vague suggestion. Start with showing actual facts like "ip -6 a" and marking what is wrong.
I already stated that I only get dynamic addresses and no persistent address.
wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 fd48:1a37:2160:0:314d:2cb6:9ec9:c4c1/64 scope global temporary dynamic valid_lft 85611sec preferred_lft 13611sec inet6 fd48:1a37:2160:0:71f0:e1b4:77ce:12e4/64 scope global dynamic mngtmpaddr noprefixroute <--- ??? valid_lft 85611sec preferred_lft 13611sec inet6 2607:fea8:4c82:5900:314d:2cb6:9ec9:c4c1/64 scope global temporary dynamic valid_lft 85611sec preferred_lft 13611sec inet6 2607:fea8:4c82:5900:8d63:e1de:7def:14a8/64 scope global dynamic mngtmpaddr noprefixroute <--- ???
This is global non-temporary address.
valid_lft 85611sec preferred_lft 13611sec inet6 fe80::2579:66fb:acb:bda0/64 scope link noprefixroute valid_lft forever preferred_lft forever
On the desktop system, I have this line, where the address is based on the MAC: inet6 fd48:1a37:2160:0:76d4:35ff:fe5b:f5fa/64 scope global dynamic mngtmpaddr
Nothing requires to use MAC for building address. What is the output of cat /proc/sys/net/ipv6/conf/wlan0/addr_gen_mode
This address is persistent and has survived for years, through even replacing my firewall computer and cable modem and updating openSUSE. Also, the least significant 64 bits have remained through different prefixes, as they're based on the MAC. On my ThinkPad, I can't even get an address that survives a reboot.
Well, we have your word for it. Show the same output again again after reboot.
On 2022-05-09 11:18 a.m., Andrei Borzenkov wrote:
wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 fd48:1a37:2160:0:314d:2cb6:9ec9:c4c1/64 scope global temporary dynamic valid_lft 85611sec preferred_lft 13611sec inet6 fd48:1a37:2160:0:71f0:e1b4:77ce:12e4/64 scope global dynamic mngtmpaddr noprefixroute <--- ??? valid_lft 85611sec preferred_lft 13611sec inet6 2607:fea8:4c82:5900:314d:2cb6:9ec9:c4c1/64 scope global temporary dynamic valid_lft 85611sec preferred_lft 13611sec inet6 2607:fea8:4c82:5900:8d63:e1de:7def:14a8/64 scope global dynamic mngtmpaddr noprefixroute <--- ??? This is global non-temporary address.
Well, let's see how long it lasts. It was different addresses yesterday.
valid_lft 85611sec preferred_lft 13611sec inet6 fe80::2579:66fb:acb:bda0/64 scope link noprefixroute valid_lft forever preferred_lft forever
On the desktop system, I have this line, where the address is based on the MAC: inet6 fd48:1a37:2160:0:76d4:35ff:fe5b:f5fa/64 scope global dynamic mngtmpaddr
Nothing requires to use MAC for building address. What is the output of
I never said it required the MAC, only that's what mine uses. The persistent address can be based on the MAC or a random number, but either way it shouldn't change. I prefer to use the MAC, but can live with a random number. On the other hand, the privacy addresses are always based on a random number, with a new one every day.
On 09.05.2022 21:26, James Knott wrote:
On 2022-05-09 11:18 a.m., Andrei Borzenkov wrote:
wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 fd48:1a37:2160:0:314d:2cb6:9ec9:c4c1/64 scope global temporary dynamic valid_lft 85611sec preferred_lft 13611sec inet6 fd48:1a37:2160:0:71f0:e1b4:77ce:12e4/64 scope global dynamic mngtmpaddr noprefixroute <--- ??? valid_lft 85611sec preferred_lft 13611sec inet6 2607:fea8:4c82:5900:314d:2cb6:9ec9:c4c1/64 scope global temporary dynamic valid_lft 85611sec preferred_lft 13611sec inet6 2607:fea8:4c82:5900:8d63:e1de:7def:14a8/64 scope global dynamic mngtmpaddr noprefixroute <--- ??? This is global non-temporary address.
Well, let's see how long it lasts. It was different addresses yesterday.
valid_lft 85611sec preferred_lft 13611sec inet6 fe80::2579:66fb:acb:bda0/64 scope link noprefixroute valid_lft forever preferred_lft forever
On the desktop system, I have this line, where the address is based on the MAC: inet6 fd48:1a37:2160:0:76d4:35ff:fe5b:f5fa/64 scope global dynamic mngtmpaddr
Nothing requires to use MAC for building address. What is the output of
I never said it required the MAC, only that's what mine uses. The persistent address can be based on the MAC or a random number, but either way it shouldn't change. I prefer to use the MAC, but can live with a random number. On the other hand, the privacy addresses are always based on a random number, with a new one every day.
No, they are not. Again, without seeing actual information from your system it is just pure speculation, but NetworkManager builds these addresses based on machine ID, stable secret, connection UUID and interface name. Unless these addresses fail DAD they should remain the same as long as the listed items remain the same. Setting ipv6.addr-gen-mode=0 will change it to EUI64 if you prefer that.
On 2022-05-09 2:51 p.m., Andrei Borzenkov wrote:
No, they are not. Again, without seeing actual information from your system it is just pure speculation, but NetworkManager builds these addresses based on machine ID, stable secret, connection UUID and interface name. Unless these addresses fail DAD they should remain the same as long as the listed items remain the same.
I have been running IPv6, with SLAAC, on my home network for 12 years. Yes, there are new privacy addresses every day. I have seen that many, many times. If I were to boot my desktop system today, I would have 1 persistent and 1 privacy address. Tomorrow I would have 2 privacy addresses and so on for 7 days when the oldest one is deleted.
Setting ipv6.addr-gen-mode=0 will change it to EUI64 if you prefer that.
I have considered that. I'll see what happens and if I get both a persistent and privacy address.
On 09.05.2022 22:29, James Knott wrote:
On 2022-05-09 2:51 p.m., Andrei Borzenkov wrote:
No, they are not. Again, without seeing actual information from your system it is just pure speculation, but NetworkManager builds these addresses based on machine ID, stable secret, connection UUID and interface name. Unless these addresses fail DAD they should remain the same as long as the listed items remain the same.
I have been running IPv6, with SLAAC, on my home network for 12 years. Yes, there are new privacy addresses every day.
Apparently you confuse privacy and temporary addresses.
I have seen that many, many times. If I were to boot my desktop system today, I would have 1 persistent and 1 privacy address. Tomorrow I would have 2 privacy addresses and so on for 7 days when the oldest one is deleted.
Setting ipv6.addr-gen-mode=0 will change it to EUI64 if you prefer that.
I have considered that. I'll see what happens and if I get both a persistent and privacy address.
On 2022-05-11 12:56 a.m., Andrei Borzenkov wrote:
Apparently you confuse privacy and temporary addresses.
No I'm not. From https://labs.ripe.net/author/johanna_ullrich/ipv6-addresses-security-and-pri... IPv6 Privacy Extension The IPv6 Privacy Extension is defined in RFC 4941. It is a format defining temporary addresses that change in regular time intervals; successive addresses appear unrelated to each other for outsiders and are a means of protection against address correlation. Their regular change is independent from the network prefix; this way, they protect against tracking of movement as well as against temporal correlation. Privacy addresses were created because of concerns the MAC based address could be used to track a mobile device. So yes, privacy addresses are temporary and you get a new one every day, up to 7, with the oldest discarded. Perhaps you're thinking of private addresses, which would be RFC1918 on IPv4 and Unique Local Addresses (ULA) on IPv6.
On Wed, May 11, 2022 at 3:41 PM James Knott <james.knott@jknott.net> wrote:
On 2022-05-11 12:56 a.m., Andrei Borzenkov wrote:
Apparently you confuse privacy and temporary addresses.
No I'm not.
You still have not shown any evidence that the address I indicated changes over time.
From https://labs.ripe.net/author/johanna_ullrich/ipv6-addresses-security-and-pri...
IPv6 Privacy Extension
The IPv6 Privacy Extension is defined in RFC 4941. It is a format
Which is not related to addr-gen-mode at all (either in NetworkManager or kernel itself), but you are IPv6 expert, so you must know better.
defining temporary addresses that change in regular time intervals; successive addresses appear unrelated to each other for outsiders and are a means of protection against address correlation. Their regular change is independent from the network prefix; this way, they protect against tracking of movement as well as against temporal correlation.
Privacy addresses were created because of concerns the MAC based address could be used to track a mobile device. So yes, privacy addresses are temporary and you get a new one every day, up to 7, with the oldest discarded.
I have no idea where you got the magic number 7 from, but it is still not relevant to your original question. Your system does have a stable global non-temporary address which does not change as long as you do not change system configuration.
Perhaps you're thinking of private addresses, which would be RFC1918 on IPv4 and Unique Local Addresses (ULA) on IPv6.
On 2022-05-11 9:04 a.m., Andrei Borzenkov wrote:
I have no idea where you got the magic number 7 from, but it is still not relevant to your original question. Your system does have a stable global non-temporary address which does not change as long as you do not change system configuration.
I can count. I have been running IPv6 with SLAAC for 12 years. When I first boot my desktop computer, I get one persistent address, in my case based on the MAC, and 1 privacy address based on a random number. The next day, I'll have 2 privacy addresses, then 3, then 4, then 5, then 6, then 7. The next day I will still have 7 privacy addresses, but what had been the oldest the day before has been discarded. Here are my current ULA addresses, but the same applies to my global addresses:
ifconfig|grep fd48 inet6 fd48:1a37:2160:0:f932:70a1:d12e:9eb2 prefixlen 64 scopeid 0x0<global> inet6 fd48:1a37:2160:0:c95e:fa9:3a87:9fe3 prefixlen 64 scopeid 0x0<global> inet6 fd48:1a37:2160:0:c538:d337:2c53:7d58 prefixlen 64 scopeid 0x0<global> inet6 fd48:1a37:2160:0:6d1a:c696:6f61:f1e7 prefixlen 64 scopeid 0x0<global> inet6 fd48:1a37:2160:0:59d:f82:d976:9ba0 prefixlen 64 scopeid 0x0<global> inet6 fd48:1a37:2160:0:76d4:35ff:fe5b:f5fa prefixlen 64 scopeid 0x0<global> inet6 fd48:1a37:2160:0:f55b:d2e7:78ca:3281 prefixlen 64 scopeid 0x0<global> inet6 fd48:1a37:2160:0:95fe:dc25:c2d7:a2e5 prefixlen 64 scopeid 0x0<global>
Unless I need new glasses, there are 8 listed, one of which is based on the MAC address. Tormorrow, there will still be 8, with one new one and the oldest discarded. This is the way it's been working for 12 years.
participants (4)
-
Andrei Borzenkov -
Bengt Gördén -
James Knott -
Per Jessen