When I boot with "System Rescue" USB stick, I get the proper addresses, so the problem is definitely with openSUSE.  Windows 10 also gets the correct addresses. On 2020-01-30 03:06 PM, James Knott wrote:

Further on this.  I see that not only does the link local address not have a suffix based on the MAC, there is no global address that has the same suffix.  Also, I am seeing an address with a different prefix and a /128 mask, which you'd normally see in a router.

On 2020-01-30 02:11 PM, James Knott wrote:

...

Forgot to mention, this is on both Ethernet and WiFi connections.

On 2020-01-30 01:32 PM, James Knott wrote:

...

I've been running IPv6 on my notebook computer for years, using NetworkManager to configure the networking.  The consistent IPv6 address had long been based on the MAC address, but now it's a random number.  How did this happen and what do  I do to go back to the MAC based address? As always, the temporary privacy addresses are random.

tnx jk

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-01-30 06:20 PM, Hans-Peter Jansen wrote:

Dear James,

Am Donnerstag, 30. Januar 2020, 19:32:32 CET schrieb James Knott:

...

I've been running IPv6 on my notebook computer for years, using NetworkManager to configure the networking. The consistent IPv6 address had long been based on the MAC address, but now it's a random number. How did this happen and what do I do to go back to the MAC based address? As always, the temporary privacy addresses are random. I'm not on a NM based system ATM, but you might get started with:

nmcli c

to show the connections, and

nmcli c show uuid | less

to browse their settings. Search for mac, cloned and ipv6.

You can modify values with

nmcli c modify uuid key value

I'm struggling with a pathological behavior, where NM swaps the WIFI MAC address with eth0 (during operation many 100th times a day). arpwatch generates two mails for each swap (back and forth)... MUCH fun.

While not solved, it might provide some insights for you, too:

https://bugzilla.suse.com/show_bug.cgi?id=1161231

I think you have a different issue.  My problem is that I'm getting a random number, instead of the MAC based IPv6 addresses.  That nmcli c command doesn't tell me anything useful. Some people are worried about MAC addresses being used in IPv6 addresses, in that someone could identify a particular computer by the IPv6 address.  For that reason, "privacy addresses" are used for outgoing connections, with a random number in place of the MAC based address.  However, that isn't an issue for incoming connections, where you'd have a DNS record pointing to a consistent address. Some have taken that privacy issue to far, by using the random number for incoming connections too.  If you worry about those privacy issues, I don't think it would be a concern if, for example, you took a computer to a coffee shop etc., as that MAC based address will never be used, unless you deliberately intend it to be. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-01-30 07:49 PM, Neil Rickert wrote:

Simple solution -- switch to "wicked".

I have several connections, so that's really not an option.

If you want to continue using NetworkManager, then find the appropriate file for this connection in "/etc/NetworkManager/system-connections"

Edit that file. Look for the section "[ipv6]".

Look for the line

addr-gen-mode=

(I don't remember what comes after the "=", but I think it might be something like "StablePrivacy").

Change that line to:

addr-gen-mode=eui64

After reboot, you should revert to address based of MAC.

It is set to addr-gen-mode=stable-privacy.  This means that I'll have to set it for every connection where I use IPv6.  Is there a default value saved somewhere?  It shouldn't be necessary to change each and every one. BTW, the wired one does have that line. tnx -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-01-31 12:40 AM, Neil Rickert wrote:

On 1/30/20 8:22 PM, James Knott wrote:

...

On 2020-01-30 07:49 PM, Neil Rickert wrote:

...

Change that line to:

addr-gen-mode=eui64 It is set to addr-gen-mode=stable-privacy.  This means that I'll have to set it for every connection where I use IPv6.  Is there a default value saved somewhere?  It shouldn't be necessary to change each and every one. I don't think there is any setting.

I only changed for the home connection. If I'm visiting someone, or at a coffee shop, I don't much care. Maybe the privacy address even makes sense there. If I were using the laptop at work, I would change that.

If you really want to change all, it is probably a simple "sed" script to do that.

It's really annoying when they do something like that with no way back.  At least in Windows there's a registry setting you can change and there used to be a config line in SuSE, IIRC. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-01-31 08:01 AM, jdd@dodin.org wrote:

Le 31/01/2020 à 13:01, James Knott a écrit :

...

It's really annoying when they do something like that with no way back. At least in Windows there's a registry setting you can change and there used to be a config line in SuSE, IIRC.

if my memory is good, it's now the rule for android, for privacy reason. A smartphone is aimed to move.

For a laptop, it's not that sure, many have them only for the fact they are small, and never move

I have a Google Pixel 2, with Android 10 and the latest update, as of a few days ago.  It still uses MAC based addresses.  The MAC based address is used only when you want to run a server or have other access to a device.  For that, you'd put the MAC based address in the DNS.  Outgoing connections, such as you'd use in a coffee shop etc., use a privacy address, which is based on a random number.  If the computer is left running long enough, it will get a new privacy address every day, with those more than 7 days old discarded. Also, another thing I've noticed is that the link local, global unique and unique local addresses all have different suffixes, whereas previously they were all the same.  As I mentioned, there is also a /128 address, which is pretty much useless on a computer, though often used on routers.  For example I get a /56 prefix from my ISP.  My WAN address is a /128, which has no relationship with my prefix.  It's not even used for routing.  It's just a public address to use to access the firewall.  Routing is done over link local addresses. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-01-31 09:33 AM, Per Jessen wrote:

James Knott wrote:

...

Also, another thing I've noticed is that the link local, global unique and unique local addresses all have different suffixes, whereas previously they were all the same. When was this 'previously' - pre 15.0 ?

Yes.  I've had IPv6 on my home network for almost 10 years.  My DNS, both local and public, contains MAC based addresses.

...

As I mentioned, there is also a /128 address, which is pretty much useless on a computer, though often used on routers. I don't see one of those: (a 15.1 desktop machine)

This is with 15.0 on my notebook: eth0: mtu 1500 state UP qlen 1000     inet6 2607:f798:804:90:b455:3be6:1e3a:9173/128 scope global noprefixroute dynamic

2: eth0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:21:86:4f:8a:88 brd ff:ff:ff:ff:ff:ff inet 192.168.3.37/21 brd 192.168.7.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a03:7520:1a22:1:ff99::2f53/64 scope global dynamic valid_lft 85349sec preferred_lft 42149sec inet6 2a03:7520:1a22:1:80d3:c3e2:a93f:e098/64 scope global temporary dynamic valid_lft 86295sec preferred_lft 14295sec inet6 2a03:7520:1a22:1:20a5:fcc5:ccfa:3269/64 scope global temporary deprecated dynamic valid_lft 86295sec preferred_lft 0sec inet6 2a03:7520:1a22:1:221:86ff:fe4f:8a88/64 scope global mngtmpaddr dynamic valid_lft 86295sec preferred_lft 14295sec inet6 fe80::221:86ff:fe4f:8a88/64 scope link valid_lft forever preferred_lft forever

According to above, you are using MAC based addresses.  Look at the link/ether line and the bottom  two inet6 lines.  The first is a global address and the 2nd link local. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-02-01 03:19 AM, Per Jessen wrote:

...

This is with 15.0 on my notebook: eth0: mtu 1500 state UP qlen 1000 inet6 2607:f798:804:90:b455:3be6:1e3a:9173/128 scope global noprefixroute dynamic I expect it is your router that hands it out - dunno why.

It's only on the Ethernet connection, configured for DHCP on IPv4 and SLAAC on IPv6. The WiFi interface, connected to the same router, doesn't get it.  I just booted the computer, with the Ethernet cable disconnected and my AP turned off.  It booted up without addresses on either interface.  I then turned on the AP and got addresses on WiFi, but no /128.  I then connected the Ethernet cable and, in addition to the normal addresses, got that /128.  I do not see a /128 on my desktop computer, which is using wicked and connected to the same router.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-02-01 08:39 AM, Per Jessen wrote:

James Knott wrote:

...

On 2020-02-01 03:19 AM, Per Jessen wrote:

...

...

This is with 15.0 on my notebook: eth0: mtu 1500 state UP qlen 1000 inet6 2607:f798:804:90:b455:3be6:1e3a:9173/128 scope global noprefixroute dynamic I expect it is your router that hands it out - dunno why.

It's only on the Ethernet connection, configured for DHCP on IPv4 and SLAAC on IPv6. The WiFi interface, connected to the same router, doesn't get it. Which suggests the router somehow treats those interfaces differently. Weird.

No.  I have a separate access point, so the router would see no difference.

...

I just booted the computer, with the Ethernet cable disconnected and my AP turned off.  It booted up without addresses on either interface.  I then turned on the AP and got addresses on WiFi, but no /128.  I then connected the Ethernet cable and, in addition to the normal addresses, got that /128.  I do not see a /128 on my desktop computer, which is using wicked and connected to the same router.. So somehow it must be NetworkManager doing this. You might be able to spot the difference if you run a tcpdump on both interfaces, at the time they're coming up.

I have a couple of static wired connections set up.  I'll have to see if they also do that.  Also, my firewall/router is pfSense, so I can use its Packet Capture or use Wireshark with port mirroring on my switch.  This might be a bit more reliable than trying tcpdump during connection setup. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

01.02.2020 11:19, Per Jessen пишет:

James Knott wrote:

...

On 2020-01-31 09:33 AM, Per Jessen wrote:

...

James Knott wrote:

...

...

...

As I mentioned, there is also a /128 address, which is pretty much useless on a computer, though often used on routers. I don't see one of those: (a 15.1 desktop machine)

This is with 15.0 on my notebook: eth0: mtu 1500 state UP qlen 1000 inet6 2607:f798:804:90:b455:3be6:1e3a:9173/128 scope global noprefixroute dynamic

I expect it is your router that hands it out - dunno why.

RFC8415 (DHCPv6): IPv6-address An IPv6 address. A client MUST NOT form an implicit prefix with a length other than 128 for this address. A 16-octet field. So prefix 128 on address assigned by DHCPv6 is absolutely correct. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov wrote:

01.02.2020 11:19, Per Jessen пишет:

...

James Knott wrote:

...

On 2020-01-31 09:33 AM, Per Jessen wrote:

...

James Knott wrote:

...

...

...

As I mentioned, there is also a /128 address, which is pretty much useless on a computer, though often used on routers. I don't see one of those: (a 15.1 desktop machine)

This is with 15.0 on my notebook: eth0: mtu 1500 state UP qlen 1000 inet6 2607:f798:804:90:b455:3be6:1e3a:9173/128 scope global noprefixroute dynamic

I expect it is your router that hands it out - dunno why.

RFC8415 (DHCPv6):

IPv6-address An IPv6 address. A client MUST NOT form an implicit prefix with a length other than 128 for this address. A 16-octet field.

So prefix 128 on address assigned by DHCPv6 is absolutely correct.

We use dhcpv6 too, I have never seen any such /128 addresses assigned. I saw some mention of the radvd 'AdvOnLink' option - it is on by default, but when I switched it off and rebooted a machine, I _did_ see such a /128 prefix. There is some relation, I'm just not sure what it is. -- Per Jessen, Zürich (13.9°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

On 2020-02-01 11:55 AM, Per Jessen wrote:

...

...

So prefix 128 on address assigned by DHCPv6 is absolutely correct. We use dhcpv6 too, I have never seen any such /128 addresses assigned.

Is that on your LAN or WAN connection?

That would be LAN - for external connections, we use fixed addresses. -- Per Jessen, Zürich (14.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

01.02.2020 20:26, Per Jessen пишет:

Per Jessen wrote:

...

We use dhcpv6 too, I have never seen any such /128 addresses assigned.

I saw some mention of the radvd 'AdvOnLink' option - it is on by default, but when I switched it off and rebooted a machine, I _did_ see such a /128 prefix. There is some relation, I'm just not sure what it is.

I made this experiment -

modify radvd.conf, in the prefix definition, "AdvLinkOn = off".

rebooted a VM

It came up with a /128 address assigned:

2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 7a:11:a2:11:4b:30 brd ff:ff:ff:ff:ff:ff inet 192.168.4.150/21 brd 192.168.7.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a03:7520:4c68:1:ff99::45e9/128 scope global dynamic valid_lft 82917sec preferred_lft 39717sec

modify radvd.conf, in the prefix definition, "AdvLinkOn = on".

After a little while, maybe some minutes -

2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 7a:11:a2:11:4b:30 brd ff:ff:ff:ff:ff:ff inet 192.168.4.150/21 brd 192.168.7.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a03:7520:4c68:1:ff99::45e9/64 scope global noprefixroute dynamic valid_lft 84605sec preferred_lft 41405sec

And client is using to manage network what exactly?

I'll have to read up on AdvLinkOn.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

01.02.2020 20:34, Per Jessen пишет:

Andrei Borzenkov wrote:

...

01.02.2020 20:26, Per Jessen пишет:

...

Per Jessen wrote:

...

We use dhcpv6 too, I have never seen any such /128 addresses assigned.

I saw some mention of the radvd 'AdvOnLink' option - it is on by default, but when I switched it off and rebooted a machine, I _did_ see such a /128 prefix. There is some relation, I'm just not sure what it is.

I made this experiment -

modify radvd.conf, in the prefix definition, "AdvLinkOn = off".

rebooted a VM

It came up with a /128 address assigned:

2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 7a:11:a2:11:4b:30 brd ff:ff:ff:ff:ff:ff inet 192.168.4.150/21 brd 192.168.7.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a03:7520:4c68:1:ff99::45e9/128 scope global dynamic valid_lft 82917sec preferred_lft 39717sec

modify radvd.conf, in the prefix definition, "AdvLinkOn = on".

After a little while, maybe some minutes -

2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 7a:11:a2:11:4b:30 brd ff:ff:ff:ff:ff:ff inet 192.168.4.150/21 brd 192.168.7.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a03:7520:4c68:1:ff99::45e9/64 scope global noprefixroute dynamic valid_lft 84605sec preferred_lft 41405sec

And client is using to manage network what exactly?

wicked.

Yes, wicked will apply prefix to address received via DHCPv6 if it finds advertised onlink prefix that matches address. It will actually select the longest prefix. It is up to client to follow RFC requirement. wicked is probably non-compliant, but end-effect is the same (network route is added to interface based on prefix), so it is more or less cosmetic except for one possible problem. IPv6 does not use address prefix to decide whether address is on link or not. IPv6 host only considers prefixes marked with on-link flag. Which means it is entirely valid to have *no* IPv6 address that belongs to "local network" and still send packets directly if destination prefix is marked as on-link. Cf. RFC5942: 1. The assignment of an IPv6 address -- whether through IPv6 stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315], or manual configuration -- MUST NOT implicitly cause a prefix derived from that address to be treated as on-link and added to the Prefix List. My understanding is that Linux translates on-link prefixes into "network route" on corresponding device. Like 2a00:xxx::/64 dev wlan0 proto ra metric 600 pref medium If you configure ip6 address that has non-trivial prefix, kernel will automatically add corresponding route unless "noprefixroute" flag is supplied. So what wicked does, it searches matching prefix and configures IPv6 address without "noprefixroute" flag, otherwise it is using 128 prefix. But if IP address does not match any local prefix, it means no network route will be created. Conceptually what should be done is configure routes and addresses separately. It does not matter as long as RA are handled by kernel. But if you turn off accept_ra, I suspect routes will be missing. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-02-01 03:19 AM, Per Jessen wrote:

...

This is with 15.0 on my notebook: eth0: mtu 1500 state UP qlen 1000 inet6 2607:f798:804:90:b455:3be6:1e3a:9173/128 scope global noprefixroute dynamic I expect it is your router that hands it out - dunno why.

I just did a Packet Capture for ICMP6 and the notebook computer's MAC address.  I didn't see anything in the RAs that has anything to do with that /128 address. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

On 2020-02-01 03:19 AM, Per Jessen wrote:

...

...

This is with 15.0 on my notebook: eth0: mtu 1500 state UP qlen 1000 inet6 2607:f798:804:90:b455:3be6:1e3a:9173/128 scope global noprefixroute dynamic I expect it is your router that hands it out - dunno why.

I just did a Packet Capture for ICMP6 and the notebook computer's MAC address.  I didn't see anything in the RAs that has anything to do with that /128 address.

Andrei explained the situation yesterday, although I'll admit I'm not sure I totally understood. (thanks anyway, Andrei). It may be that wicked is in fact slightly non-compliant, whereas NetworkManager is doing the right thing. If you inspect the RAs in detail, maybe check the AdvOnLink bit. -- Per Jessen, Zürich (10.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2020-01-31 10:29 AM, Patrick Shanahan wrote:

while I haven't noticed before, this morning I get a 2600:1700*/128 address on NetworkManager systems but not on wicked systems.

My experience too. Why is such an address even there?  As I mentioned, it's pretty much useless, except on routers. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org