IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready message repeating every minute

The repeating IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready message in the kernel log is typically caused by a race condition between NetworkManager and systemd-networkd, or by IPv6 Duplicate Address Detection (DAD) failing to complete. You can resolve this by disabling IPv6 on the interface if it is not needed, configuring stable privacy extensions, or switching to a single network management service.

Understanding the Kernel Message

This log entry originates from the Linux kernel's networking stack rather than a user-space application. The message indicates that the network device, identified as eth0, has detected a change in its physical link state and is attempting to configure an IPv6 address. The repetition suggests that the system believes the link is going down and up repeatedly, or that the IPv6 configuration process is stuck in a loop. In many modern Ubuntu distributions, this behavior is often linked to how network interfaces are managed. If both NetworkManager and systemd-networkd are active, they may conflict over control of the interface. This conflict causes the interface to flap, triggering the kernel to log the event every time the link state changes. Additionally, if IPv6 Duplicate Address Detection (DAD) fails because another device on the local network segment claims the same address, the kernel will retry configuration indefinitely. For a deeper understanding of how these interfaces are handled, you might want to review How do Ubuntu-server network interfaces work?. This resource explains the underlying mechanisms that govern interface states and configuration persistence.

Step 1: Identify Conflicting Network Services

The most common cause for this specific repetitive logging is a conflict between two network management daemons. Ubuntu uses NetworkManager for desktop environments and systemd-networkd for server environments. Running both simultaneously can lead to unpredictable behavior where one service resets the connection just as the other attempts to configure it. To check which services are currently managing your network, run the following command in your terminal:

systemctl status systemd-networkd
systemctl status NetworkManager

If both services show as "active (running)," you likely have a conflict. On a standard Ubuntu Desktop installation, NetworkManager should be the primary manager. On Ubuntu Server, systemd-networkd is preferred. You should disable one of them to prevent interference. For example, to disable systemd-networkd in favor of NetworkManager, use:

sudo systemctl disable --now systemd-networkd
sudo systemctl disable --now systemd-resolved

After disabling the conflicting service, restart NetworkManager and observe if the messages stop appearing in the logs.

Step 2: Disable IPv6 if Not Required

If your network infrastructure does not require IPv6 connectivity, the simplest solution is to disable IPv6 entirely on the affected interface. This prevents the kernel from attempting to perform DAD or autoconfiguration, thereby stopping the associated log spam. You can temporarily disable IPv6 for testing purposes using the sysctl utility. Run the following command, replacing eth0 with your actual interface name if it differs:

sudo sysctl -w net.ipv6.conf.eth0.disable_ipv6=1

Check your system logs immediately after running this command. If the messages cease, the issue was indeed related to IPv6 processing. To make this change permanent across reboots, add the setting to your /etc/sysctl.conf file or create a new configuration file in /etc/sysctl.d/:

net.ipv6.conf.eth0.disable_ipv6 = 1

Then apply the changes with:

sudo sysctl --system

Disabling IPv6 is a valid troubleshooting step, especially in environments where only IPv4 is used. However, if you need IPv6 for external connectivity, refer to Why is my public IPv6 address different from the one listed in Linux? to understand address assignment nuances before making permanent changes.

Step 3: Configure Stable Privacy Extensions

If you must keep IPv6 enabled, the issue might stem from how the system generates temporary addresses. By default, Linux uses Privacy Extensions to generate random temporary IPv6 addresses for outbound connections. In some network environments, particularly those with strict firewalls or specific router advertisements, this constant generation can trigger repeated link change events. You can mitigate this by forcing the use of stable, predictable addresses. Edit the sysctl configuration to set the use_tempaddr parameter to 0:

net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.default.use_tempaddr = 0

Add these lines to /etc/sysctl.conf and apply them. This reduces the frequency of address regeneration and can stabilize the link state reporting.

Step 4: Check for Physical Link Flapping

While less common in virtualized environments, physical link flapping can also cause this message. A loose cable, faulty NIC, or switch port issues can cause the physical layer to drop and reconnect rapidly. Use the dmesg command to look for Ethernet controller errors preceding the IPv6 messages:

dmesg | grep -i eth0

Look for phrases like "link down," "carrier lost," or "reset." If you see frequent hardware-level disconnections, the issue is physical rather than software-related. Replace cables or switch ports as necessary.

Frequently Asked Questions

Does disabling IPv6 break SSH connectivity?

If your SSH server is configured to listen only on IPv4 addresses, disabling IPv6 will not affect your ability to connect. However, if your server listens on both IPv4 and IPv6, clients connecting via IPv6 will lose access. Ensure your SSH daemon (sshd_config) is bound to the correct IP version before making changes.

How can I tell if systemd-networkd is causing the issue?

You can check the journal logs for conflicts by running journalctl -u systemd-networkd. Look for entries indicating that NetworkManager is trying to manage an interface already controlled by systemd. If you see "interface not found" or "state change" errors occurring simultaneously with the IPv6 messages, systemd-networkd is likely the culprit.

What is Duplicate Address Detection (DAD)?

DAD is a process where a device checks if an IPv6 address it intends to use is already in use on the local network segment. If DAD fails, the kernel considers the address invalid and may attempt to acquire a new one, leading to repeated link change events. This is common in environments with multiple routers or misconfigured DHCPv6 servers.

Can I filter these messages in dmesg?

You can suppress these specific messages from the console by adjusting the kernel log level, but this does not fix the underlying issue. It is generally better to resolve the root cause, such as service conflicts or IPv6 configuration errors, rather than hiding the symptoms. Hiding the messages may prevent you from detecting real network failures.

Is this issue specific to Ubuntu?

No, this is a general Linux kernel behavior. Any distribution using the standard Linux networking stack can exhibit this message if there are conflicts between network managers or if IPv6 autoconfiguration fails. The steps provided are applicable to Debian, CentOS, and other RHEL-based systems as well.