[ipv6hackers] NetworkManager and privacy in the IPv6 internet
fgont at si6networks.com
Sun Dec 6 22:02:02 CET 2015
On 12/06/2015 05:08 PM, Matej Gregr wrote:
>>> If I use the same hw and OS, but I switch from network manager to
>>> dhcpcd, the privacy address will be different. If I change a
>>> software used for address configuration, it is also a different
>>> end-node for you?
>> Could you provide a sample case for which you'd want to do that?
> I don't want to do that. It can just happen. Last year, Linux kernel was
> responsible for IPv6 address configuration on my system. Regular system
> update updated my version of dhcpcd and dhcpcd overrode the in-kernel
> IPv6 autoconfiguration.
Just curious: Distro? -- and... dhcpd is doing RFC7217 by default?
> Right now, the user space app is responsible for
> ipv6 address config. The point is, that changes in address configuration
> can happen without an user intervention. My system remains the same.
> So a sample case is, that your favorite Linux distribution switches to a
> different network-conf package. I will probably see it again, when my
> distribution switches from openrc to systemd.
What I would expect in that case is that as part of the process of
updating, the "updater" takes the same secret that was used in the
previous package, and employs it for the new one.
Yes, I'm not sure to what extent that's doable. And, at the same time,
you could argue that, in theory, they each package could e.g. use a
different hash function, or use the hash parameters in different order,
etc. (thus leading to a different IID).
In all these cases, I'd blame the update process. You're essentially
changing the secret, or changing the algorithm implementation. In that
case, it should be the OS update the one making things happen
>> I can only/mostly think of text-only console vs. full GUI. At which
>> point yes, I consider that a different system.
>> Besides, if you change that you're more of sys admin than a user.
> I don't think you have to be a sysadmin. It can be just a regular update.
I see the case you were thinking about. But please se my note above.
>> As far as I understand: node=software+hardware.
>> If you reinstall the OS, and the OS doesn't care to e.g. keep the
>> secret, than that's a different system.
>> The software for address generation is part of the OS. For instance,
>> much of what network manager does is part of the OS, rather than an "app".
> Currently, Linux's in-kernel address configuration is overridden by an
> "app" in several distributions. Every app uses a different secret. The
> secret is not part of the Linux OS.
Well, the OS is not just the kernel, but the whole thing.
I believe that if the OS decides to reorganize things differently, that
shouldn't break, where possible, your configuration.
e.g., and if they decide not to make this happen automagically, then I
guess this "update" should actually be part of an upgrade to a new
relase, rather than just a regular update.
>>> Don't get mi wrong, I don't have anything against RFC 7217. I am
>>> using it on my systems. However, I had an impression from initial
>>> design goals that the RFC will help me to simplify address accounting
>>> in my network. It didn't happen. That's all.
>> It does simplify address accounting. However, RFC7217 is not about
>> preventing users from changing the OS (if you allow your users to do
>> that, then that's your fault. Or, if they do that, having been notified
>> not to do so, then it's your fault if you don't fire them).
> I don't have a control over users system and users software. I cannot
> forbid them to reinstall or update their OS. However, I have to provide
> them an access to a network and have a reasonable way how to account
> them. I though that RFC 7217 will simplify our system for address
> accounting, but it will not. Apparently because of a different
> understanding on what is and what is not stable IID.
Please see my note above regarding OS updates. Besides that, if you
don't control the OS, at the end of the day the user can manually
configure an address and make your life miserable in that respect.
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
More information about the Ipv6hackers