2 min read

For reasons I don’t still fully understand, my local backup server decided that it was no longer going to be reachable from the outside world.  Along the way to fixing it, I learnt a little more about IPv6 which might be worth sharing…

By default DHCP will assign you addresses (and automatically set a gateway for your machine) but I was very frustrated by the constantly changing IP (particularly after reboots) my server was receiving “from the DHCP server on my cablemodem/router”.  This was preventing my remote EyeSkills client from reliably being able to reach my backup server.

To cut a long story short, I discovered much later (with kind help from these lovely people) that there is a configuration file at /etc/sysctl.d/10-ipv6-privacy.conf which determines whether privacy extensions for IPv6 are enabled. These were causing my IP to be constantly reassigned while using DHCP. Interestingly, by default, an IPv6 address is partially mapped to your MAC address.  By disabling these global privacy settings (which really ought to be possible from within netplan, but isn’t) I would most likely also have ended up with a reliable IP address, but I am wary of changing such “system wide” settings.

Understanding slowly dawned as I could see there was always a second IP being assigned to my network interface, despite having disabled dhcp6 in netplan.  This was happening because of RA (router assignment) which is an integral part of the IPv6 system.  This was producing the same IP address quite reliably (from the interface’s MAC), and it turns out I probably could trust it not to change, but I really wanted to be sure that I could rely on a given IP.

Disabling RA (accept-ra: no for the given interface in the netplan.yaml file under /etc/netplan/XXX.yaml) comes at a cost: you are then responsible for both explicitly setting your own IP, and also your gateway.  Where my other servers seem to have fe80::1 as their gateway, it turned out not to be the case locally.  As I understand it, fe80::1 is effectively fe80::0000:0000:0000….0001, but this didn’t work for me.

To find the true gateway, I used an RA assigned address and traceroute6 from a remote machine, discovering a full address something like 2a02:810a:0:13:a57f:xxx:xxxx:81c9. I set this as “gateway6” in the netplan yaml file, and suddenly, finally, the static addressing was working again!

Here’s a sample of my /etc/netplan/01-network-manager-all.yaml (under Ubuntu 18.13) file:

  version: 2
  renderer: networkd
      dhcp4: no
      dhcp6: no
      accept-ra: no
      addresses: [XXXX/24, 'XXXX/64']
gateway4: XXXX
gateway6: XXXX
addresses: [,]

Make those changes, run “sudo netplan apply”, take a look all is well with “ip -d address” and/or “ip -6 route” and you’re off!

Would you like to beta test EyeSkills* or just follow what we are doing?


  • While the IPv6 address works for your router, you might be better served using its fe80:: equivalent (probably something like fe80::xxx:xxxx:81c9), if you can figure out what it is (check the config of the router if you can, it definitely should say somewhere).

    FWIW; when we discussed this on #netplan it didn’t sound like you had any DHCPv6 configuration; it just so happens that in netplan (and systemd-networkd), this “dhcp6:” field is used for both SLAAC (the autoconfiguration based only on the contents of the RA (which should be mostly static)) and DHCPv6 (where you’re talking to a real DHCP server which should always get you the same address, or something very predictable).

    The most important part of the issue is definitely the use_tempaddr=2 setting that we ship by default in Ubuntu — that serves to “anonymize” you a bit when you connect to the Internet, especially for when you send out requests, but it /can/ get in the way for requests coming in — and that’s what you want a nice, static address for.

    1. Thank you for this super interesting feedback, although I do need to say that the behavior of dhcp6 : no was NOT the same as when I additionally added accept-ra : yes/no. With dhcp6 to “no” and accept-ra to “yes” I got a reliable ip. With both to “yes” I got an unpredictable address.

      1. As it happens, I had to re-allow accept-ra:yes. After some time being shutdown, the static IP was no longer accessible (I suspect it was some strange cacheing artefact that made it work initially), and at no point could I get an fe80 address to work. So, I’m using the (hopefully static enough) RA assigned address for now.