odhcpd NDP relay does not proxy SLAAC-only addresses

Describe the bug

When ImmortalWrt is configured as a secondary router with IPv6 relay mode (NDP relay), odhcpd fails to register NDP proxy entries for devices that obtain IPv6 addresses via pure SLAAC. Devices that use DHCPv6 are correctly proxied, but SLAAC-only devices (e.g., Linux machines using default kernel SLAAC) are missing from the NDP proxy table, resulting in no IPv6 connectivity for those devices.

ImmortalWrt version

r37854-4b24da3b4c5c

ImmortalWrt release

25.12.0

ImmortalWrt target/subtarget

x86/64

Device

QEMU Standard PC (Q35 + ICH9, 2009)

Image kind

Official downloaded image

Steps to reproduce

Configuration

/etc/config/dhcp:

dhcp.lan=dhcp
dhcp.lan.interface='lan'
dhcp.lan.ra='relay'
dhcp.lan.dhcpv6='relay'
dhcp.lan.ndp='relay'

dhcp.wan6=dhcp
dhcp.wan6.interface='wan6'
dhcp.wan6.ra='relay'
dhcp.wan6.dhcpv6='relay'
dhcp.wan6.ndp='relay'
dhcp.wan6.master='1'

IPv6 forwarding is enabled:

# cat /proc/sys/net/ipv6/conf/all/forwarding
1

Actual behaviour

odhcpd NDP relay only registers proxy entries for devices that obtain addresses via DHCPv6. SLAAC-only devices are missing from the proxy table, resulting in broken IPv6 connectivity for those devices.

Devices that DON'T have IPv6 connectivity

Devices that obtain addresses via pure SLAAC (e.g., Linux with default kernel SLAAC, accept_ra=1) receive a valid global IPv6 address but are missing from the NDP proxy table:

# ip -6 neigh show proxy
# (no entry for the SLAAC-only device)

The SLAAC device has a valid global address:

inet6 240e:b8f:961d:ef00:be24:11ff:fe07:8b7c/64 scope global dynamic mngtmpaddr noprefixroute

But cannot reach the internet:

$ ping6 -c 3 2001:4860:4860::8888
6 packets transmitted, 0 received, 100% packet loss

Expected behaviour

odhcpd NDP relay should snoop all downstream IPv6 addresses, including those obtained via SLAAC, and automatically register NDP proxy entries on the WAN interface for each address. The NDP relay snooping logic should not rely solely on DHCPv6 to discover downstream addresses.

Devices that DO have IPv6 connectivity

Devices that request addresses via DHCPv6 (e.g., Huawei AX3 router) are correctly registered in the NDP proxy table:

# ip -6 neigh show proxy
240e:b8f:961d:ef00:2681:c7ff:fec2:7c0a dev eth0 proxy

These devices can access IPv6 internet without issues.

Additional info

Analysis

tcpdump on ImmortalWrt WAN interface (eth0)

When the SLAAC-only device sends ICMPv6 echo requests, the packets are correctly forwarded by ImmortalWrt to the WAN interface:

23:43:22 IP6 240e:b8f:961d:ef00:be24:11ff:fe07:8b7c > 2001:4860:4860::8888: ICMP6, echo request
23:43:23 IP6 240e:b8f:961d:ef00:be24:11ff:fe07:8b7c > 2001:4860:4860::8888: ICMP6, echo request
23:43:24 IP6 240e:b8f:961d:ef00:be24:11ff:fe07:8b7c > 2001:4860:4860::8888: ICMP6, echo request

However, no echo replies are received. The upstream router never sends a Neighbor Solicitation for the SLAAC device's address, because ImmortalWrt never registered an NDP proxy entry for it.

In contrast, for the DHCPv6 device (Huawei AX3), the upstream router sends NS and ImmortalWrt correctly responds with NA:

23:43:52 IP6 fe80::1 > 240e:b8f:961d:ef00:2681:c7ff:fec2:7c0a: ICMP6, neighbor solicitation
23:43:52 IP6 fe80::be24:11ff:fef6:e259 > fe80::1: ICMP6, neighbor advertisement, tgt is 240e:b8f:961d:ef00:2681:c7ff:fec2:7c0a

Manual workaround

Manually adding the NDP proxy entry restores connectivity immediately:

ip -6 neigh add proxy 240e:b8f:961d:ef00:be24:11ff:fe07:8b7c dev eth0

After this, the SLAAC device can ping IPv6 internet:

$ ping6 -c 3 2001:4860:4860::8888
3 packets transmitted, 3 received, 0% packet loss

Workaround

Manually add NDP proxy entries:

ip -6 neigh add proxy <slaac-device-ipv6-address> dev eth0

This is not sustainable because:

1. SLAAC addresses can change (especially with privacy extensions enabled)
2. Must be re-added after every OpenWrt reboot or network restart
3. Does not scale for networks with many SLAAC-only devices

Diffconfig

Terms

• I am reporting an issue for ImmortalWrt, not an unsupported fork.