34

How can I permanently disable autoconfiguration of IPv6 in Linux? When I try to manually delete an address from an interface with:

ip -6 addr del 2001:0db8:85a3:0000:0000:8a2e:0370:7334/64 dev eth1

It will reappear a few seconds later, I want it to be gone permanently, but without disabling IPv6 all together.

7 Answers 7

26

Auto configuration can be disabled temporary for eth1 with:

sudo sysctl -w net.ipv6.conf.eth1.autoconf=0
sudo sysctl -w net.ipv6.conf.eth1.accept_ra=0

or for all interfaces with:

sudo sysctl -w net.ipv6.conf.all.autoconf=0
sudo sysctl -w net.ipv6.conf.all.accept_ra=0

Reenabling works by using 1 instead of 0 in the call.

Disabling it permanently can be done with an entry to /etc/sysctl.conf. On Debian Etch (probably on newer too), without setting the accept_ra, the system will autoconfigure using the Link local adress (fe80..)

As Gart mentioned below, automatic address configuration and router discovery will be disabled if the host itself is a router and accept_ra is not 2, i.e

net.ipv6.conf.<iface|all|default>.forwarding=1

and

net.ipv6.conf.<iface|all|default>.accept_ra=0 or net.ipv6.conf.<iface|all|default>.accept_ra=1.

where iface is your interface

2
  • 4
    Also, automatic address configuration and router discovery will be disabled if the host itself is a router, i.e net.ipv6.conf.all.forwarding=1 is set.
    – Gart
    Sep 18, 2011 at 13:25
  • if e.g. net.ipv6.conf.all.autoconf and net.ipv6.conf.eth0.autoconf are set differently, what wins?
    – milkpirate
    Mar 6, 2023 at 10:24
14

The sysctl solution did not work for us on Ubuntu 18.04 Bionic. We solved it by:

Editing /etc/netplan/01-netcfg.yaml, configure:

network:
  ...
  ethernets:
    eth0:
      ...
      dhcp6: no
      accept-ra: no

You may need to use your interface name instead of eth0. After you save the file execute:

netplan apply or reboot

If you already have received an IPv6 IP from autoconfiguration and you want to remove it without rebooting, you can execute:

ip -6 addr del 1111:2222:1:0:aaaa:bbbb:cccc:dddd/64 dev eth0 

Of course you need to replace the IP and device in this command.

3
  • this has just made my day been scratching my head on this for a few months :D Sep 19, 2018 at 12:48
  • 2
    I usually just scratch Google till I find it. Sep 19, 2018 at 13:09
  • 2
    This worked when I tried it, but the problem is turning accept-ra off is quite dangerous, as mentioned by Mark S - it appears to work but later you may find you're missing packets because they hit a fragmentation point or a failover router is used. Also it breaks pings. The reason I was trying to do this was to reliably match my SPF record in outgoing mail but then I realised I should have been using a netmask in the record instead because in IPv6 a range of addresses effectively belongs to a machine, not a single address. Oct 26, 2018 at 4:08
10

net.ipv6.conf.all.accept_ra=0 above should not be done, as RAs are necessary for indication of on-link and off-link for the prefix (as per RFC5942), as well as automated configuration of a number of other parameters, such as MTU, Neighbor Discovery timeouts etc.

If you want to disable autoconfiguration, either set the autoconf sysctl off as above, or switch off the A (autoconfiguration bit) in the Prefix Information Option (PIO) in the RA.

6
sudo sysctl -w net.ipv6.conf.all.autoconf=0

This didn't work for me on Debian Wheezy. After examining /etc/sysctl.conf I needed to use

sudo sysctl -w net.ipv6.conf.default.autoconf=0
1
3

The problem with Ubuntu 18 and ipv6 is that systemd-networkd controls kernel parameters, so though one might disable ipv6 with sysctl, networkd will be more than happy switching them on for you, if the configuration does not state otherwise.

My solution to disable ipv6 is to configure link-local in netplan to an empty scalar (provided you have no link-local ipv4 IPs)

network:
     version: 2
     renderer: networkd
     ethernets:
     eth0:
        ..
        link-local: [ ]

The configuration will compile configuration for networkd that will be posted in /run/systemd/network/10-netplan-eth0.network and that will convince networkd not to put up ipv6 for eth0

If you may want to disable ipv6 also on the loopback, it is easily achieved by setting the kernel parameter net.ipv6.conf.all.disable_ipv6 to 1. networkd does not seem to control loopback.

sysctl -w net.ipv6.conf.all.disable_ipv6=1
1
  • I really like your very clean solution. As we don't use link-local addresses adding the empty scalar the perfect solution. After this, we had to reboot the server as netplan apply kept the already assigned IPv6 addresses on both of our ethernet interfaces. But after reboot, everything works just like you said. I don't think there is a reason to bother with disabling IPv6 on the loopback interface, so I just skipped the sysctl part. Thanks!
    – Zoltan
    May 6, 2019 at 15:51
2

I just ran into an odd issue with this. Normally, I disable autoconf by setting autoconf=0 for all pertinent interfaces in sysctl.conf, like so:

net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.bond0.autoconf = 0
net.ipv6.conf.bond1.autoconf = 0

Normally, that's enough. However, I just ran into some servers (Rocky 8.6 and 8.7) where this is not working consistently. bond0 would come up with a SLAAC address on boot-up, but it would eventually age out and expire. But on reboot, it would be back. bond1, oddly enough, would have no such problem. After fighting with it for a while, the thing that seemed to fix it was adding this to sysctl:

net.ipv6.conf.default.accept_ra_pinfo = 0
net.ipv6.conf.all.accept_ra_pinfo = 0
net.ipv6.conf.bond0.accept_ra_pinfo = 0
net.ipv6.conf.bond1.accept_ra_pinfo = 0

This tells it to ignore the prefix info sent in the RADV.

Feels something like a kernel bug to me. Disabling 'autoconf' parameters in sysctl should, in fact, be enough to actually disable autoconf (otherwise, WTF is the purpose of that parameter?). Also disabling "other things" just to make this work as expected just seems wrong. At any rate, this worked for me, and seems like a safer option that disabling accept_ra entirely.

1

You need to pay attention to tags in the address

inet6 xxxx:ffc8:1:20:ec4:7aff:fe0f:77e5/64 scope global dynamic mngtmpaddr noprefixroute

mngtmpaddr is created by IPv6 Privacy Extensions standard (RFC 4941) hence it will be necessary to disable the autoconf and tempaddr

sysctl -w net.ipv6.conf.all.autoconf=0 
sysctl -w net.ipv6.conf.default.autoconf=0
sysctl -w net.ipv6.conf.default.use_tempaddr=0
sysctl -w net.ipv6.conf.all.use_tempaddr=0
sysctl -w net.ipv6.conf.eth0.use_tempaddr=0

also, you should check if the current flag is false with

/proc/sys/net/ipv6/conf/*/use_tempaddr
/proc/sys/net/ipv6/conf/*/autoconfg

to make changes persistent to reboot, add to the /etc/sysctl.conf net.ipv6.conf.all.autoconf=0 net.ipv6.conf.default.autoconf=0 net.ipv6.conf.default.use_tempaddr=0 net.ipv6.conf.all.use_tempaddr=0 net.ipv6.conf.eth0.use_tempaddr=0

also by last, if you are using netplan, seems that it may override it all. only solution I found was to disable RA, by adding the flag to /etc/netplan/xxx.yaml

accept-ra: false
7
  • I am seeing mngtmpaddr as a flag despite use_tempaddr=0. And the address is created from the EUI64, so it is definitely not a privacy address. Jan 29, 2021 at 15:35
  • Please be careful with disabling router advertisements, so don't use accept-ra: false! RA is needed for some other network configuration besides the addresses, as @Mark S has explained above: superuser.com/a/635251 Jan 29, 2021 at 15:37
  • @MarcelWaldvogel indeed it is not the best, unfortunately I was unable to achieve the goal with that enabled Jan 29, 2021 at 17:31
  • I also gave up. However, the additional SLAAC address did only cause real problems for one application (exposing a UDP port through Docker). I changed the client (in this case Docker) to only listen on the specific additional address. Jan 30, 2021 at 13:33
  • Exactly my point, Linux has weak networking, hence you cannot control the outbount IP unless it is a single IP per namespace/vm; in our aplication, as the peer will accept check if the packet came from the define IP in the software level, a second IP just mess up things... Jan 30, 2021 at 20:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .