How to Fix an IPv6 dadfailed Address on a Linux Server

If ip -6 address shows your server’s IPv6 address as tentative dadfailed, another device on the same network segment answered for that address during duplicate address detection (DAD), so Linux refuses to use it. On a dedicated or colocated server, a common culprit is the server’s own baseboard management controller (BMC), the IPMI out-of-band management chip. The BMC is a separate network device with its own MAC address, even when it shares the server’s network port, and it may have been configured with the same IPv6 address. This guide shows you how to confirm which device holds the address, give each device its own address and keep DAD switched on.

It applies to Linux on physical servers, with examples for Debian and Ubuntu. A VPS has no BMC, but steps 1 and 2 still identify any other device that claims your address.

Last reviewed: 13 October 2026, against the current Linux kernel, iproute2 and ipmitool documentation. This guide is written for Noiz hosting and is kept current against those tools. It complements, and does not replace, the official documentation linked below.

Official Documentation Reference

• Linux kernel IP sysctl settings: accept_dad, dad_transmits and enhanced_dad.
• ip-address manual (Debian): the tentative, dadfailed and nodad address flags.
• RFC 4862, IPv6 Stateless Address Autoconfiguration: how duplicate address detection works.
• ipmitool manual (Debian): local access to the BMC through the OpenIPMI interface.
• ipmitool upstream project: source for the lan6 subcommand, which the manual page does not describe.

Prerequisites

• An access route that does not depend on the affected IPv6 address: SSH over IPv4, or the server’s console.
• Root access on the server.
• Your IPv6 allocation: the record from your network provider (or from Noiz) of which prefix and addresses are yours to use and which address is the gateway. Having a whole prefix configured on Linux does not mean every address in it is free to use. Never give the gateway’s address to the server or the BMC.
• For the BMC checks: the ipmitool package and the kernel IPMI driver (sudo modprobe ipmi_si ipmi_devintf, after which /dev/ipmi0 should exist). If it does not appear, use the BMC’s web interface or your provider’s management portal instead.
• Saved copies of your network configuration, routes and BMC settings before you change anything.

The examples use the documentation prefix 2001:db8:100::/64 and interface eth0. Replace them with your own verified values. Find your interface name with ip link.

1. Confirm the Address Has Failed DAD

Start with read-only checks:

ip -6 address show dev eth0
ip -6 route show
ip -6 neighbour show dev eth0
sysctl net.ipv6.conf.all.accept_dad net.ipv6.conf.eth0.accept_dad \
  net.ipv6.conf.eth0.dad_transmits

A failed address shows both tentative and dadfailed. tentative alone means detection has not finished yet. Linux uses the higher of the all and per-interface accept_dad values, so all set to 0 does not switch DAD off on an interface set to 1.

If dad_transmits is 0, or the address was added with the nodad option, Linux skips detection entirely (RFC 4862 section 5.1). In that case, the absence of dadfailed does not prove the address is unique.

Compare the running state with the configuration in the network manager the server already uses (for example /etc/network/interfaces with ifupdown, or Netplan on Ubuntu). Do not introduce another network manager while diagnosing.

A gateway that answers from its link-local fe80:: address does not prove global IPv6 works. A timeout from outside can also mean a routing, firewall or service problem.

2. Find the Device Holding the Address

The kernel logs the conflicting device’s MAC address when DAD fails:

sudo journalctl -k --grep 'duplicate address'

The line looks like this:

eth0: IPv6 duplicate address 2001:db8:100::20 used by 02:00:00:00:00:10 detected!

The MAC after used by is the device that answered for your address. The message is rate-limited and can be rotated out of the journal. If you find nothing, capture neighbour discovery traffic while you retry DAD:

sudo timeout 30 tcpdump -ni eth0 -e -vv 'icmp6 and (ip6[40] == 135 or ip6[40] == 136)'

That filter shows only neighbour solicitations and advertisements. The capture includes Ethernet addresses, so treat it as private.

To make Linux try DAD again, remove and re-add only the address that has already failed, in a second session while the capture runs. The address is unusable anyway, so this does not interrupt working traffic:

sudo ip -6 address del 2001:db8:100::20/64 dev eth0
sudo ip -6 address add 2001:db8:100::20/64 dev eth0

Do not flush the interface, or remove a healthy address just to generate traffic.

In the capture, look for your address in a neighbour advertisement from another MAC, or in another device’s DAD solicitation sent from the unspecified address ::. Two devices running DAD at the same time can conflict without either sending an advertisement. Ignore your own probes looped back by the network (RFC 4862 section 5.4.3). A silent capture does not prove the address is unique.

Compare the MAC you found with your server’s own interfaces (ip link) and with the BMC’s MAC in step 3. If it matches neither, give your network provider the log line or capture, the timestamps and your allocation before you readdress anything.

3. Check the Server’s BMC

Read the BMC’s LAN settings locally. The LAN channel is usually 1; check it with sudo ipmitool channel info 1 if unsure.

sudo ipmitool -I open lan print 1
sudo ipmitool -I open lan6 print 1

lan6 is not described in the ipmitool manual page; run ipmitool lan6 help for its parameters. Compare the BMC’s MAC address, its static IPv6 address slots (the numbered address entries it can hold), their prefix length and enabled state, and its router settings. Note the BMC’s IPv4 management address and how you reach it.

Treat the BMC as the cause only when the MAC from step 2 and the BMC’s own settings agree on the same enabled address. A matching MAC vendor prefix, or a past network problem on the same range, does not establish the cause on its own. Local readback shows the configuration; it does not prove that you can log in to the BMC remotely.

4. Give Each Device Its Own Address

Decide which device should keep the address, based on what depends on it:

• The BMC does not need IPv6: disable only its IPv6 address slot and keep its private IPv4 management settings.
• The BMC must keep the address: move the operating system to another free address from your allocation. For a server running hosting services, this also affects service bindings and DNS. If you use Plesk, see How to Change a Plesk Server’s IPv6 Address.

An example final allocation looks like this:

Device	Example address
Gateway	2001:db8:100::1
BMC (only if IPv6 management is needed and permitted)	2001:db8:100::10
Linux and its services	2001:db8:100::20

These are illustrations, not a recommendation to expose BMC management to the internet. Keep the BMC on private management access with its access controls.

Change only the address slot you intend to, using the BMC’s supported interface (its web interface, your provider’s portal or ipmitool). Read all the relevant settings back afterwards. Before giving an address to a different device, confirm that the previous holder has released it.

Keep DAD switched on. Disabling it makes the address look usable while two devices still answer for it.

BMC firmware quirks

Check error output, the change’s completion state and a full readback, even when ipmitool exits successfully. Some BMC firmware has been seen to reject the final “commit write” step that applies staged LAN changes, or to clear a stored address when its slot is disabled. Save the complete slot configuration before changing it.

ipmitool lan6 set locks the settings, writes the change and commits it in one go. Its nolock option skips the lock and commit for firmware that rejects them; use it only for a confirmed firmware limitation with a recovery path. ipmitool lan6 discard only marks the change as complete; it does not restore earlier values. Both behaviours are defined in the upstream lan6 source.

5. Verify the Repair

1. Retry DAD on the server’s address as in step 2 and confirm it loses the tentative flag.
2. Confirm the other device no longer answers for that address, and that the original IPv4 routes and BMC management settings are unchanged.
3. Test outbound IPv6 (for example ping -6 to a well-known host), then test inbound IPv6 from a separate IPv6-capable system.
4. Make the change persistent in your network configuration, then test the BMC login and both devices’ settings through a planned restart. Live readback proves neither.

If the server hosts websites, also test the server’s own hostname over IPv6 with certificate validation, and check a few existing sites over IPv4. A site that has never been given an IPv6 address may show the server’s default site over IPv6. That is a hosting configuration task, not a DAD problem. If you use Plesk, see How to Enable IPv6 for a Website in Plesk.

Undoing the Change

Before giving an address back to a previous device, find out who holds it now. Remove it from that device first and confirm it has been released. Restore only the saved settings needed for that ownership, keeping any later configuration changes and the BMC’s private management access. Never recreate the original collision.

For help on a Noiz server, contact Noiz support with the address flags, the interface, the time of the failure and the kernel log line, with MAC addresses redacted if you prefer. Never include BMC passwords or raw management exports in a ticket.