IPv6 not honoring sysctl

So, for some reason I can’t divine, my Rocky Linux 8.9 VM simply will not permit me to disable ipv6 on the loopback interface. I have what I believe are the correct flags in /etc/sysctl.conf, and they are being loaded when I run sysctl -a. Yet, stubbornly, when I run netstat -tan, there my processes are, attaching to an ipv6 address which should not exist:

[root@aarons_host:~]# cat /etc/sysctl.conf
# sysctl settings are defined through files in
# /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.
#
# Vendors settings live in /usr/lib/sysctl.d/.
# To override a whole file, create a new file with the same in
# /etc/sysctl.d/ and put new settings there. To override
# only specific settings, add a file with a lexically later
# name in /etc/sysctl.d/ and put new settings there.
#
# For more information, see sysctl.conf(5) and sysctl.d(5).

# Disable ipv6
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
[root@aarons_host:~]# sysctl -a | egrep disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.enp1s0.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
[root@aarons_host:~]# netstat -tan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN
tcp        0      0 10.16.4.12:53           0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:5666            0.0.0.0:*               LISTEN
tcp        0    180 10.16.4.12:22           10.16.4.106:54494       ESTABLISHED
tcp        0      0 10.16.4.12:51846        10.16.4.101:9997        TIME_WAIT
tcp        0      0 10.16.4.12:59732        10.16.4.101:9997        ESTABLISHED
tcp        0      0 10.16.4.12:46910        10.16.4.101:9997        TIME_WAIT
tcp6       0      0 :::111                  :::*                    LISTEN
tcp6       0      0 :::53                   :::*                    LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN
tcp6       0      0 :::5666                 :::*                    LISTEN
[root@aarons_host:~]# cat /etc/redhat-release
Rocky Linux release 8.9 (Green Obsidian)

Any ideas? Am I huffing paint? What’s going on?

Thanks.

The sysctl options you’ve set tell the OS to not assign an IPv6 address to the network interfaces. You can check this with ip -6 a

The IPv6 network module is still loaded, so applications can bind to :::22 (for example) but the result is that it will only be reachable on IPv4.

1 Like

Thank you for your response. It still seems very strange to me that the kernel will let a process bind to an address which doesn’t actually exist in the network stack. If I use the grub method, I assume the module wouldln’t be loaded?

GRUB_CMDLINE_LINUX_DEFAULT=”ipv6. disable=1″

I would recommend against completely disabling ipv6 through grub. Doing so may cripple certain software or packages in the base repositories that we ship.

1 Like

Understood. I will live with the confounding errors in my log.

-Aaron

Well, 0.0.0.0 (INADDR_ANY) and :: (IN6ADDR_ANY) are “special”; they don’t bind to any specific address on the machine, they just listen for the port. So it doesn’t matter if there’s no interface with an address configured, the service still listens.

This turns out to be important and useful behaviour; e.g. now you don’t have an interface with IPv6 but in 5 minutes time you might add one; that listening service will work on the new address without needing restarting.

If you want to stop a service listening on :: and only on 0.0.0.0 then you probably need to change the service config; eg for sshd you can set AddessFamily inet in sshd_config and now it will only listen on IPv4. You’d need to do this for all the services (rpcbind, named, nagios?) you want to stop.

1 Like

Yes, that is what I wound up doing, I found this in the process of setting up bind 9 on a couple of systems (new DNS servers), and I was getting errors in the log which reported ‘named[2075]: couldn’t add command channel ::1#953: address not available’, which is what started me down this rabbit-hole. I was able to make the error go away by commenting out ’ listen-on-v6 port 53 { any; };’ in my named.conf.