IPv6 on Linux: Router Advertisements, SLAAC Lifetimes, and Neighbor State

An IPv6 interface can have several addresses and routes at once, each with a different origin and lifetime. A global address may come from Stateless Address Autoconfiguration (SLAAC), DHCPv6, static configuration, or a combination of mechanisms. A default route may be learned from a Router Advertisement (RA) independently of address configuration. A link-local address exists for on-link control traffic even when no router is available. Debugging only /etc/resolv.conf or only ip addr misses this division of responsibility.

Linux implements the IPv6 host stack, while NetworkManager, systemd-networkd, or another manager may own the interface policy. Router Advertisements carry router lifetime and prefix information; prefix flags determine whether a prefix is on-link and/or usable for autonomous address configuration. Hosts perform Duplicate Address Detection before using newly formed addresses. Those controls are distinct, and a correct diagnosis needs addresses, routes, neighbor cache, RA settings, and manager logs.

Neighbor Discovery is more than address resolution

IPv6 Neighbor Discovery (ND) replaces several IPv4-era mechanisms. It discovers routers, resolves next-hop link-layer addresses, maintains reachability state, detects duplicate addresses, and supports redirects and parameter discovery. Router Solicitation and Advertisement messages help a host find routers; Neighbor Solicitation and Advertisement messages are used for address resolution and reachability functions. These are ICMPv6 control messages, not optional application pings.

An RA can advertise a default-router lifetime, one or more Prefix Information Options, and other parameters. The Router Lifetime controls whether the advertising router is installed as a default router. It is independent from the lifetime of addresses created from a prefix. A router can advertise an autonomous prefix while choosing not to be a default router, and a host can have an address without a usable default route.

The prefix option’s L flag describes on-link determination; the A flag permits SLAAC address configuration for that prefix. A host should not infer that every configured address is on-link or that every on-link prefix can be used to form a global address. This is especially important in multi-prefix or routed enterprise networks, where the prefix used for address formation may not be the complete on-link route policy.

SLAAC address lifecycle and lifetimes

With SLAAC, a host combines an advertised prefix and an interface identifier to create an address, then performs Duplicate Address Detection (DAD) before treating it as assigned. The exact interface-identifier strategy can vary by kernel and userspace policy. Modern systems may use stable opaque or temporary privacy addresses rather than exposing a hardware-derived identifier. Do not assume a MAC-based suffix when constructing monitoring rules or firewall exceptions.

The Preferred Lifetime and Valid Lifetime are separate timers. When an address’s preferred lifetime expires, it becomes deprecated: it remains valid for existing communication but should not be selected for new source connections when a suitable preferred source exists. When the valid lifetime expires, the address is removed. Renumbering therefore often involves overlap: the new address becomes preferred while old connections drain on a deprecated address.

SLAAC and DHCPv6 can be used simultaneously. An RA’s Managed and Other Configuration flags are hints that influence host behavior; they do not themselves assign a DHCPv6 address. Host policy, DHCPv6 client availability, and network-manager settings determine how those hints are acted upon. A missing DHCPv6 lease does not prove SLAAC failed, and a working SLAAC address does not prove DNS information was learned from the source you expect.

Read the kernel’s effective state first

These commands report the addresses, routes, and neighbor entries visible in the current network namespace:

ip -6 addr show dev "$IFACE"
ip -6 route show table all
ip -6 neigh show dev "$IFACE"

For each address, inspect whether it is tentative, dadfailed, deprecated, or has a preferred/valid lifetime. Routes may show protocol tags such as ra, but exact formatting depends on iproute2 and kernel versions. The neighbor table has states including INCOMPLETE, REACHABLE, STALE, DELAY, and FAILED; STALE alone is not a fault because reachability is refreshed when the entry is used.

Inspect the RA-related sysctls for the specific interface, for example net.ipv6.conf.IFACE.accept_ra, autoconf, and accept_ra_pinfo. The per-interface value can inherit from default at interface creation. Forwarding mode changes RA acceptance behavior unless accept_ra is configured to accept advertisements even while forwarding. Do not write sysctls to “fix IPv6” until you know whether the machine is a host, router, container, or virtual bridge endpoint.

for key in accept_ra autoconf accept_ra_pinfo accept_ra_defrtr forwarding; do
    printf '%s=' "$key"
    cat "/proc/sys/net/ipv6/conf/$IFACE/$key" 2>/dev/null || true
done

Use the actual interface name and compare it with the manager’s configuration. A NetworkManager profile may intentionally ignore RAs or may request DHCPv6-only behavior; editing a sysctl behind the manager can create a persistent split-brain policy. Use the manager’s connection settings and logs when it owns the device.

Capture the control plane, not just the symptom

If an address or route is disappearing, capture ICMPv6 RAs on the affected link and note their source, Router Lifetime, Prefix Information flags, and lifetimes. tcpdump -ni IFACE icmp6 can help, but an on-link capture point may miss traffic on a VLAN, bridge, Wi-Fi interface, or namespace boundary. Confirm that the capture sees the interface where the kernel receives the RA.

Compare timestamps from packet capture, ip monitor address route, manager logs, and kernel logs. The route can expire while the address remains valid. A prefix can remain on-link while the default route changes. A manager restart can reapply a static profile after an RA update. DAD failure can make one address unusable without affecting the rest of the interface.

ip monitor is a useful read-only event stream:

ip -ts monitor address route neigh

Run it in a controlled session and preserve the output with timezone and interface context. For a transient DAD failure, collect the neighbor solicitation/advertisement exchange and check for duplicated static addresses or an L2 domain unexpectedly shared by two sites. Do not disable DAD to hide a conflict; doing so can make duplicate addressing harder to detect.

Host and router behavior differ

A Linux router often enables forwarding. Forwarding changes how RAs are accepted, and router advertisements may be generated by a separate daemon such as radvd or a network appliance. A host should not be configured as a router just to make SLAAC work. For a router, validate both forwarding and advertisement generation, including whether it advertises itself as a default router and whether the PIO’s L and A flags match the intended design.

DHCPv6 does not replace Neighbor Discovery. Even when DHCPv6 supplies addresses or other configuration, the host still uses ND for next-hop resolution and may use RAs for default-router discovery. Conversely, a network with SLAAC-only address assignment can still use DHCPv6 for additional configuration according to its policy. Write the desired division down before debugging.

Router Advertisement filtering must be applied with a clear trust boundary. On managed networks, switch and Wi-Fi controls can restrict unauthorized RAs; endpoint settings are not a substitute for L2 controls. The IPv6 standards have updated guidance over time, so read the current RFC updates when designing router behavior rather than assuming the original 2007 documents answer every modern security question.

Acceptance tests for address changes

Test initial link-up, no-router operation, a valid RA, a prefix with A=0, a prefix with L=0, router lifetime expiry, preferred-lifetime expiry, valid-lifetime expiry, DAD conflict, and simultaneous DHCPv6 plus SLAAC if deployed. Verify the exact source address selection, route, DNS policy, and application reconnection behavior for each case. Keep test prefixes isolated from production and use a lab router or network namespace.

For renumbering, record old and new addresses and their preferred and valid lifetimes over time. Confirm that new connections use the preferred address while existing sessions can continue on a deprecated address when the application permits it. Check that firewall rules, monitoring, service bindings, and allowlists do not hard-code a single temporary address.

An acceptance statement should identify the interface manager, allowed RA sources, expected default route, address-generation policy, and maximum recovery time after link change. It should also state what should happen when there is no RA or DAD fails. “IPv6 ping works” is too weak: validate DNS, route selection, neighbor resolution, application bind behavior, and the observed lifecycle of every address class.

Related:

Sources: