Clients receive IPv6 addresses but no default route after enabling DHCPv6-only mode on OpenWrt router

Environment

Edge router: OpenWrt 22.03 on ARM appliance; LAN clients include Ubuntu 22.04 laptops, Android phones, and an Apple TV; upstream prefix delegated via ISP DHCPv6-PD. Router configured to disable DHCPv4 and serve only DHCPv6/SLAAC.

Symptoms

Clients show global IPv6 addresses but cannot reach the internet (timeouts to IPv6-only sites). ping6 to upstream gateway's link-local address succeeds from router but client default route (via RA) is missing or set to fe80::/64 with no route to outside.

Observations

tcpdump on LAN interface shows Router Advertisements with prefix information (IA_PD present) but Router Advertisement flags sometimes omit the 'M' and 'O' bits; RA rate-limited messages appear occasionally; clients' 'ip -6 route' shows no default ::/0 or shows a stale default route pointing to a link-local address that is unreachable; sysctl net.ipv6.conf.all.forwarding = 1 set on router; firewall rules on router include ip6tables FORWARD ACCEPT for established but default policy is DROP for input; router logs show 'radvd: interface eth0: failed to bind to socket' intermittently after reload.

Already attempted

Restarted odhcpd and radvd on router; rebooted multiple clients; toggled IPv6 firewall rules to allow RA; re-enabled DHCPv4 briefly then disabled again; verified prefix delegation on WAN interface with 'odhcpd-state'; captured RA packets to check flags and lifetime values.

Question

Why do clients get IPv6 addresses but no usable default route after switching to DHCPv6-only on the router, and what steps will restore consistent RA/default route behavior without reverting to IPv4?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1d ago• Trouble ID

Most likely causes

RA daemon (odhcpd/radvd) failing to bind/send RAs reliably due to socket errors after configuration reload or file descriptor exhaustion on router, causing clients to lack default route. 80%

Router firewall or ip6tables rules are dropping ICMPv6 RA/RS packets (or NAT-like rules applied to ICMPv6), preventing clients from receiving default route information. 60%

Client-side kernel settings (accept_ra, forwarding) or network-manager settings disable accepting RA-derived default routes; some clients prefer DHCPv6 default-router options not used by current RA configuration. 40%

Summary

Clients acquiring addresses but lacking a default route typically indicates Router Advertisements not advertising a route (R bit) or RA packets being filtered, dropped, or bound to the wrong socket. Root causes include misconfigured or competing RA/odhcpd/radvd processes, incorrect socket binding after interface/file descriptor limits causing RA to fail intermittently, firewall blocking ICMPv6 router advertisements, or kernel forwarding/RA acceptance settings on clients. The observation of radvd bind failures points to a local daemon/socket problem or resource exhaustion. Fix requires checking the RA daemon configuration and ensuring RA is reliably sent and not filtered by the router firewall or host kernel.

Suggested Fixes

Diagnostic step 1

On router, check running RA-related daemons: ps aux | grep -E 'odhcpd|radvd' and inspect dmesg/syslog for 'failed to bind' or EMFILE errors. Increase ulimit/file-descriptor limits if EMFILE shown, then restart odhcpd/radvd.

Diagnostic step 2

Capture RA packets on LAN (tcpdump -i br-lan -s 0 -vv icmp6) and confirm each RA contains the Router Lifetime > 0 and the 'router' flag; verify M/O flags and Prefix Information options are present and have non-zero valid/preferred lifetimes.

Diagnostic step 3

Temporarily set router firewall to permissive for IPv6 (ip6tables -P INPUT ACCEPT; ip6tables -F) and restart odhcpd/radvd to see if clients acquire default routes — if that fixes it, tighten rules to allow ICMPv6 types 133/134/135/136.