Deactivating Arch Linux IPv6 Privacy Extensions
Thursday, July 24. 2014
Something funny happened to my Arch Linux, it changed the IPv6 address rather surprisingly. When I failed to SSH into it, I went to the console.
On none of my machines I have the RFC 4941 privacy extensions enabled. The first thing to do was to confirm, that the IP-address was not based on my Ethernet Address:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:cf:1c:36 brd ff:ff:ff:ff:ff:ff
inet6 2001::e2:349d:bcc6:c9fc/64 scope global noprefixroute dynamic
valid_lft 84267sec preferred_lft 12267sec
There is absolutely no reference to the MAC-address 52:54:00:cf:1c:36 of in the EUI-64 address 00e2:349d:bcc6:c9fc. Given the calculator result of 5054:00ff:fecf:1c36. Apparently something modifies the autoconfiguration address.
First culprit could be Linux kernel:
# cat /proc/sys/net/ipv6/conf/all/use_tempaddr
0
I even iterated all the configurations:
find /proc/sys/net/ipv6/conf/ -name use_tempaddr -print -exec cat {} \;
just to make sure, that privacy is off.
That was puzzling. What the heck is going on in the machine!! After all, it used to work ok before. What could be doing that?
Lot of googling around landed me on Arch Linux ArchWiki IPv6 page. It says: "dhcpcd includes in its default configuration file since version 6.4.0 the option slaac private, which enables "Stable Private IPv6 Addresses instead of hardware based ones", implementing RFC 7217". Hum? I've never heard of RFC 7217, nor "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", but there it was.
I confirmed /etc/dhcpcd.conf and yes, it did contain a:
slaac private
in it. Why?! I didn't ask for it. I simply put a comment (#) in front of the line and did a:
systemctl restart dhcpcd@eth0.service
To refresh the situation. No change. A reboot. Yes change! 
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:cf:1c:36 brd ff:ff:ff:ff:ff:ff
inet6 2001::5054:ff:fecf:1c36/64 scope global noprefixroute dynamic
valid_lft 86399sec preferred_lft 14399sec
Now my IPv6-address was exactly what it used to be. Weird incident, though. There is a perfectly good mechanism for privatizing addressses, if wanted to. But now somebody had created another and some higher power made a choice for me to start using it. Really weird! Well, I'm hoping that my addresses won't change any more.
Comments
Display comments as
(Linear | Threaded)
Just stumbled upon this bullshit and found your post in an attempt to fix it. WTF? Don't mess with my IP address. 
Comment (1)
#1
Bachsau
on
2016-12-06 10:11
(Reply)
Add Comment
Something funny happened to my Arch Linux, it changed the IPv6 address rather surprisingly. When I failed to SSH into it, I went to the console.
On none of my machines I have the RFC 4941 privacy extensions enabled. The first thing to do was to confirm, that the IP-address was not based on my Ethernet Address:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:cf:1c:36 brd ff:ff:ff:ff:ff:ff
inet6 2001::e2:349d:bcc6:c9fc/64 scope global noprefixroute dynamic
valid_lft 84267sec preferred_lft 12267sec
There is absolutely no reference to the MAC-address 52:54:00:cf:1c:36 of in the EUI-64 address 00e2:349d:bcc6:c9fc. Given the calculator result of 5054:00ff:fecf:1c36. Apparently something modifies the autoconfiguration address.
First culprit could be Linux kernel:
# cat /proc/sys/net/ipv6/conf/all/use_tempaddr
0
I even iterated all the configurations:
find /proc/sys/net/ipv6/conf/ -name use_tempaddr -print -exec cat {} \;
just to make sure, that privacy is off.
That was puzzling. What the heck is going on in the machine!! After all, it used to work ok before. What could be doing that?
Lot of googling around landed me on Arch Linux ArchWiki IPv6 page. It says: "dhcpcd includes in its default configuration file since version 6.4.0 the option slaac private, which enables "Stable Private IPv6 Addresses instead of hardware based ones", implementing RFC 7217". Hum? I've never heard of RFC 7217, nor "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", but there it was.
I confirmed /etc/dhcpcd.conf and yes, it did contain a:
slaac private
in it. Why?! I didn't ask for it. I simply put a comment (#) in front of the line and did a:
systemctl restart dhcpcd@eth0.service
To refresh the situation. No change. A reboot. Yes change!
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:cf:1c:36 brd ff:ff:ff:ff:ff:ff
inet6 2001::5054:ff:fecf:1c36/64 scope global noprefixroute dynamic
valid_lft 86399sec preferred_lft 14399sec
Now my IPv6-address was exactly what it used to be. Weird incident, though. There is a perfectly good mechanism for privatizing addressses, if wanted to. But now somebody had created another and some higher power made a choice for me to start using it. Really weird! Well, I'm hoping that my addresses won't change any more.
