GNOME Bugzilla – Bug 765464
RFC7217 stable-privacy addr-gen-mode does not work with auto-created default-wired-connection
Last modified: 2016-04-26 11:06:03 UTC
When NetworkManager auto-activates a device that does not have an explicit connection profile, the generated IPv6 IIDs will change between reboots/re-activations. That defeats the whole point of RFC7217 IIDs. After saving the connection profile, the IIDs become stable. The issue presumably occurs because NM will include the connection's UUID when generating the final secret key. An auto-activated connections is assigned an ephemeral UUIDs, which in turn makes the outcome of the algorithm equally ephemeral. I think that simply excluding the UUID when generating secret keys for auto-activated connections should suffice to fix this issue. The below console session demonstrate the issue. (I'm starting out without a connection profile covering the enp0s25 interface, so NM auto-generates one.) [root@envy ~]# systemctl stop NetworkManager; ip a f dev enp0s25; ip r f dev enp0s25; systemctl start NetworkManager; sleep 3; ip -6 a l dev enp0s25 | grep inet6 inet6 fd2f:c379:e112:5c:b2dc:95fe:53dd:baa/64 scope global noprefixroute dynamic inet6 2a02:fe0:c420:fd44:eba5:8282:3f80:a0d6/64 scope global tentative noprefixroute dynamic inet6 fe80::b957:bd30:3f87:f2d1/64 scope link [root@envy ~]# systemctl stop NetworkManager; ip a f dev enp0s25; ip r f dev enp0s25; systemctl start NetworkManager; sleep 3; ip -6 a l dev enp0s25 | grep inet6 inet6 fd2f:c379:e112:5c:f321:e372:4fa0:e289/64 scope global tentative noprefixroute dynamic inet6 2a02:fe0:c420:fd44:d107:428f:2c32:b57a/64 scope global noprefixroute dynamic inet6 fe80::544f:1985:6772:1477/64 scope link [root@envy ~]# systemctl stop NetworkManager; ip a f dev enp0s25; ip r f dev enp0s25; systemctl start NetworkManager; sleep 3; ip -6 a l dev enp0s25 | grep inet6 inet6 fd2f:c379:e112:5c:a9b:ae84:9fa9:db2b/64 scope global tentative noprefixroute dynamic inet6 2a02:fe0:c420:fd44:7502:a440:5af9:55df/64 scope global tentative noprefixroute dynamic inet6 fe80::245b:9af9:753c:6f52/64 scope link [root@envy ~]# nmcli con edit "Wired connection 1" ===| nmcli interactive connection editor |=== Editing existing '802-3-ethernet' connection: 'Wired connection 1' Type 'help' or '?' for available commands. Type 'describe [<setting>.<prop>]' for detailed property description. You may edit the following settings: connection, 802-3-ethernet (ethernet), 802-1x, dcb, ipv4, ipv6 nmcli> save Connection 'Wired connection 1' (d64763ce-fd4a-4ac3-b681-93863db532d9) successfully updated. nmcli> quit [root@envy ~]# systemctl stop NetworkManager; ip a f dev enp0s25; ip r f dev enp0s25; systemctl start NetworkManager; sleep 3; ip -6 a l dev enp0s25 | grep inet6 inet6 fd2f:c379:e112:5c:a9b:ae84:9fa9:db2b/64 scope global tentative noprefixroute dynamic inet6 2a02:fe0:c420:fd44:7502:a440:5af9:55df/64 scope global tentative noprefixroute dynamic inet6 fe80::245b:9af9:753c:6f52/64 scope link [root@envy ~]# systemctl stop NetworkManager; ip a f dev enp0s25; ip r f dev enp0s25; systemctl start NetworkManager; sleep 3; ip -6 a l dev enp0s25 | grep inet6 inet6 fd2f:c379:e112:5c:a9b:ae84:9fa9:db2b/64 scope global tentative noprefixroute dynamic inet6 2a02:fe0:c420:fd44:7502:a440:5af9:55df/64 scope global tentative noprefixroute dynamic inet6 fe80::245b:9af9:753c:6f52/64 scope link [root@envy ~]# systemctl stop NetworkManager; ip a f dev enp0s25; ip r f dev enp0s25; systemctl start NetworkManager; sleep 3; ip -6 a l dev enp0s25 | grep inet6 inet6 fd2f:c379:e112:5c:a9b:ae84:9fa9:db2b/64 scope global tentative noprefixroute dynamic inet6 2a02:fe0:c420:fd44:7502:a440:5af9:55df/64 scope global tentative noprefixroute dynamic inet6 fe80::245b:9af9:753c:6f52/64 scope link
This autogenerated connection is the so called "default-wired-connection". Which gets created if: - for ethernet only - there exists no matching connection for the device - /var/lib/NetworkManager/no-auto-default.state doesn't indicate that a default-connection was created for this device earlier - you don't configure: [main] no-auto-default=* The use of this default-wired-connection is mostly that you can start on a system without configuration and NM will generate one for your ethernet. Not very useful afterwards, and users are adviced to persist that connection (simply by modifying it). One solution here is to disable private-stable addresses for the default-wired-connection.
(In reply to Thomas Haller from comment #1) > The use of this default-wired-connection is mostly that you can start on a > system without configuration and NM will generate one for your ethernet. Not > very useful afterwards, and users are adviced to persist that connection > (simply by modifying it). I don't think I've ever seen that advise. After installing a distro like Fedora or Ubuntu on a wired workstation, it will have connected to the network and everything will be working out of the box, and it will continue to do so after reboots - so the way I see it, it continues to be very useful. Nowhere have I seen a warning or suggestion to persist the connection. For the record, I didn't find this issue myself, it was a guy who wondered on a mailing list why, after upgrading to Ubuntu 16.04, none of his addresses were stable across reboots: http://lists.cluenet.de/pipermail/ipv6-ops/2016-April/010781.html > One solution here is to disable private-stable addresses for the > default-wired-connection. I don't like this solution at all, because it brings back all the privacy implications RFC7217 purports to solve (MAC address leakage and tracking). I suggest using the MAC address instead of the UUID. I realise this will ascertain that the addresses are not stable across hardware replacements, but IMHO that's acceptable. In most situations the stable addresses won't survive hardware replacement anyway, because: 1) NM appears to include the ifname when generating the stable secret. That's very hardware-dependent these days thanks to udev and /lib/udev/rename_device. If the ifname changes then the RFC7217 IID changes as well. 2) When you persist/save the connection profile, the current MAC address is stored. So even if you're changing the Ethernet card and the new one gets the same ifname as the previous one, the persisted "Wired connection 1" profile won't be used because the current MAC address no longer match the stored one. That probably means you get a brand-new default-wired-connection ("Wired connection 2") with a brand-new UUID, and thus, brand-new RFC7217 IIDs too. It's certainly possible to update the connection profile manually to avoid #2, but even so...I think "hardware replacement" is the wrong use case to optimise for. I mean, how often do people replace their Ethernet cards and expect their address to remain unchanged, anyway? Can't be very often, at least not compared to how often users will simply continue forever to use the default out-of-the-box setup without persisting any connection profile.
Hi, I am the original poster on the mailing list linked above. My expectation after upgrading from 14.04 to 16.04 was not that my IPv6 address would change. When it did, I could have handled that, if I could just have had a persistent address across reboots. My expectation would have been that the EUI64+privacy extension based addresses based behaviour would have continued (keep existing behaviour across upgrades), but I would have been given a new option to get the new RFC7217 based one as an option in NM. This would have been fine. If this is deemed to be not possible, then at least my expectation is that a connection profile is created so that my address is persistent across reboots, without me having to do anything. This should be default behaviour. The current behaviour is just not user friendly. Asking the user to edit the profile (even without doing any changes) in order to persist the address, is in my opinion not a good thing for the user. I don't think this is what most people want.
(In reply to Mikael Abrahamsson from comment #3) > Hi, > > I am the original poster on the mailing list linked above. > > My expectation after upgrading from 14.04 to 16.04 was not that my IPv6 > address would change. When it did, I could have handled that, if I could > just have had a persistent address across reboots. > > My expectation would have been that the EUI64+privacy extension based > addresses based behaviour would have continued (keep existing behaviour > across upgrades), but I would have been given a new option to get the new > RFC7217 based one as an option in NM. This would have been fine. If you have an old connection stored to disk (that doesn't yet know about ipv6.addr-gen-mode), then on upgrade this would be treated as addr-gen-mode=eui64. Thus, you would not experience a change in this case. What changed, is the default for ~new connections~. > If this is deemed to be not possible, then at least my expectation is that a > connection profile is created so that my address is persistent across > reboots, without me having to do anything. This should be default behaviour. > > The current behaviour is just not user friendly. Asking the user to edit the > profile (even without doing any changes) in order to persist the address, It's not in order to persist the address, but to persist the automatically generated connection. Otherwise, on every boot a new connection will be created, which has ipv6.addr-gen-mode=stable-privacy. It also means, that the connection UUID changes on every boot, and the UUID is used when creating the stable-privacy address -- resulting in different addresses. > is > in my opinion not a good thing for the user. I don't think this is what most > people want. There are different ways to solve that: - require users to persist their default-wired-connection if they expect stable private addresses across reboot. - have the default-wired-connection be addr-gen-mode=eui64. - generate the default-wired-connection with a UUID based on the interface name. That way, the UUID is stable, as are the addresses. - solution 3 (below). > I suggest using the MAC address instead of the UUID. I realise this will > ascertain that the addresses are not stable across hardware replacements, but > IMHO that's acceptable. In most situations the stable addresses won't survive > hardware replacement anyway, because: NM hashes the interface name and the connection UUID: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/nm-core-utils.c?id=8280ab69f10b21c999f242b985db0ef81d49776f#n2714 Solution 3 (this is IMO preferred): Maybe we should add a new property ipv6.addr-gen-mode-privacy-token. When set, NM would not hash ifname nor the UUID, but instead use that token. The advantage is that users could configure the same tokens on different connections/interfaces, and they all generate identical addresses. Note, that the secret-key would still be per-machine. Thus, when copying such a connection to another machine, it would still generate a different sequence of addresses. And for default-wired-connection, we would solve the problem by setting the token to (for example) "default-wired:$IFNAME".
In response to the "only applies to new connections": I have had this machine running Ubuntu 14.04 since around when 14.04 was released. It has an ethernet cable onto its physical RJ45 connector. Since the default settings were fine for me, I never edited the connection profile, which from what I read above, means after every reboot, eth0 is treated as a "new connection" (with the same name as before), thus I get a new IPv6 address now with the new RFC7217 behaviour. If 'Wired connection 1' would just have been automatically saved when it was first automatically created, this behaviour wouldn't have been a problem. The only thing that was needed for me to get stable addresses across reboots was to go into nmcli and save: $ nmcli con edit 'Wired connection 1' # the name might be localised nmcli> save This is all that was needed. Why isn't this done automatically?
(In reply to Mikael Abrahamsson from comment #5) > In response to the "only applies to new connections": > > I have had this machine running Ubuntu 14.04 since around when 14.04 was > released. It has an ethernet cable onto its physical RJ45 connector. Since > the default settings were fine for me, I never edited the connection > profile, which from what I read above, means after every reboot, eth0 is > treated as a "new connection" (with the same name as before), thus I get a > new IPv6 address now with the new RFC7217 behaviour. If you don't find that connection stored on disk (e.g. in /etc/NetworkManager/system-connections), it is in-memory only. On D-Bus, you would also see that the connection is "Unsaved=True". But yeah, if you never modified that connection, it was never stored to disk. That works as implemented and intended. Which obviously is not as expected in this case. > If 'Wired connection 1' would just have been automatically saved when it was > first automatically created, this behaviour wouldn't have been a problem. > The only thing that was needed for me to get stable addresses across reboots > was to go into nmcli and save: > > $ nmcli con edit 'Wired connection 1' # the name might be localised > nmcli> save Yes, or just touch any property `nmcli connection modify "Wired connection 1" connection.autoconnect yes` > This is all that was needed. Why isn't this done automatically? Maybe the default-wired-connection should be stored. But it isn't, because it is expected that users who care will modify it. There is even a setting to disable creation of those connections altogether (main.no-auto-default).
as the connection UUID serves as Network_ID for the stable-privacy algorithm, one way to solve this is to generate a stable UUID. This anyway should be done, because it looks nice that whenever the user starts, the UUID of the "Wired connection 1" does not change. th/default-wired-connection-stable-uuid-bgo765464 (this does not preclude any of the other solutions as well, as they might be useful in their own right).
(In reply to Thomas Haller from comment #7) > as the connection UUID serves as Network_ID for the stable-privacy > algorithm, one way to solve this is to generate a stable UUID. > This anyway should be done, because it looks nice that whenever the user > starts, the UUID of the "Wired connection 1" does not change. > > th/default-wired-connection-stable-uuid-bgo765464 merged: master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c17b4ba6c750c375e80ae37759d9a4c9caa5bf08 nm-1-2: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=1e1d5b24fd9b61e74b89680d036c72b907a79aee There are many ways to fix this bug at hand, and this change will fix it. Therefore I am closing this bug. Other solutions might still be useful and be implemented independently.