How to use shell to derive an IPv6 address from a MAC address

On Fedora 25 Workstation, NetworkManager (NM) configures all network interfaces, by default. That means also the wired ones. And the NetworkManager doesn't create EUI-64 derived IPv6 addresses. Instead it generates so called 'stable-privacy' ones. Apparently to not disclose the MAC address to each IPv6 destination.

This can be changed for a given interface $i via changing the IPV6_ADDR_GEN_MODE key in the /etc/sysconfig/network-scripts/ifcfg-$i configuration file. For example via:

sed -i 's/^IPV6_ADDR_GEN_MODE=stable-privacy/IPV6_ADDR_GEN_MODE=eui64/' \
  /etc/sysconfig/network-scripts/ifcfg-$i

The change is effective after NetworkManager rereads its configuration and after a reconnect:

nmcli con reload
nmcli con down $i
nmcli con up $i

Notes

• this option isn't exposed via the NM settings GUI
• the interface configuration files under /etc/sysconfig/network-scripts read by NM are Fedora/Redhat specific, but the configuration key is not - i.e. on other distributions NM just reads the interface configurations from different locations/configuration files

Fedora also comes with systemd-networkd which doesn't disable EUI64 generation, by default. Thus, a simpler way to get stable IPv6 addresses under Fedora is just to remove NetworkManager and configure/enable systemd-networkd, instead.

Or one can set the interface in question to unmanaged in NetworkManager and then configure it in systemd-networkd.

In any case, the networkd config is pretty minimal then, e.g.:

cat /etc/systemd/network/20-wired.network
[Match]
# manage all matching interfaces
#Name=en*
# just manage one:
Name=eno1
    
[Network]
DHCP=ipv4

After some experimentation I found the following command can be used:

ip monitor

It will display a list of what's happening. Run it in one terminal, restart the network interface in another, and you'll see a line printed as each IP address is removed and then re-added.

It still doesn't explain exactly where the IP is coming from, but it did tell me it was an ra (Router Advertisement) which allowed me to go looking at my router config.

In my case I was advertising the same fdaa::/64 prefix as I had assigned as a static IP (assuming a static IP in this subnet would prevent a dynamic one from being assigned) but instead I ended up with both a static and a dynamic IP in the same subnet, which caused the problems. I'm still in two minds as to whether this is a bug.

After a lot of thought I changed the router to advertise a different prefix (actually a different subnet in the same ULA /48, so fdaa:0:0:1/64) because this way both subnets fit in the same ULA assignment but being different subnets they don't cause a machine to reply from the wrong IP when it has IPs belonging to both subnets.