I found a very strange problem: After reboot the openwrt, LAN devices can not obtain ipv6 address.
My network is a little bit different: I have 2 different ipv6 subnets: a /64 subnet and a /56 subnet, I can use both of them. And there is no DHCPv6 or RA service in upstream network.
I decide to assign a static ipv6 address to wan6 interface, pick up form the /64 subnet. And I use the /56 subnet as ipv6-pd, also config manually.
After that, the br-lan has the ipv6 address, and all things goes right, the devices in LAN network can get ipv6 address and reach the internet.
However once I reboot the router, ipv4 still works, but the ipv6 not. The br-lan still has ipv6 address, but there is only a fe80 ipv6 address in lan devices.
BTW, I found restart br-lan interface or restart odhcpd service will fix this issue temporary.
Here is my config:
There has to be a huge conceptual misunderstanding here.
If your OpenWrt device acts as a router; and has static prefix delegation; and its properly configured/uses default settings (besides the static prefix set on wan); then there is no such thing as "only one mac per network". And all end-devies on a network, get router advertisments with a prefix where they can pick addresses, and if they can reach the Internet via a default gateway... ndp proxy is an ugly hack for broken network setups.
Thank you for your reply! I know, in normal situation, we do not use ndp proxy, and relay mode is like a hack of ISP network.
However, in my situation, this is a network in server racks. for security reasons, there is a strict mac address rule in upstream network. the whole block of ipv6 address only allowed one mac address.
This rule made me headache. It makes the whole ipv6 address block only available on one instance. So I decide to use openwrt as a router in front of these VMs to deal with this rule.
I am sure I can use these two blocks of ipv6 address. these address is for the servers. Maybe this is not the right config in openwrt.
I'm in the same boat - and I noticed the same behavior. As I didn't want to reboot the OpenWrt VM again, I just left it as-is and considered it a temporary problem.
Edit: Thanks to your post, I did a couple of restarts to debug this issue. With "loglevel" set to "7" for odhcp, I receive the following in my log after rebooting:
Wed Feb 19 14:22:13 2025 daemon.debug odhcpd[1964]: Enabling services with lo running
Wed Feb 19 14:22:13 2025 daemon.debug odhcpd[1964]: Enabling services with eth1 running
Wed Feb 19 14:22:13 2025 daemon.debug odhcpd[1964]: Enabling services with WireGuard running
Wed Feb 19 14:22:13 2025 daemon.debug odhcpd[1964]: Enabling services with eth1 running
As you can see, br-lan is missing. And indeed, odhcp is working fine over Wireguard. Upon restarting odhcp, the output looks like this:
Wed Feb 19 14:23:36 2025 daemon.debug odhcpd[1964]: Enabling services with WireGuard running
Wed Feb 19 14:23:36 2025 daemon.debug odhcpd[1964]: Enabling services with br-lan running
Wed Feb 19 14:23:36 2025 daemon.debug odhcpd[1964]: Enabling services with lo running
Wed Feb 19 14:23:36 2025 daemon.debug odhcpd[1964]: Enabling services with eth1 running
So for whatever reason (a race condition?) it doesn't detect br-lan during startup.
Btw, I could disable NDP proxying for my environment.
For the time being, the following work around "fixes" this issue for me:
Add to /etc/rc.local:
sleep 5
/etc/init.d/odhcpd restart
It doesn't work without the sleep. I will report this to the issue tracker.
So yes, a service restart is a good first test, the see if you find any race conditions.
(andy, Please do not feel directly addressed by the following)
Of course. NDP proxy is only needed to relay NDP and RA messesges between interfaces, which SHOULD NEVER BE NECESSARY AT ALL. A router is a router is a router. It routes. Especially if you have a proper prefix on wan, and a delegated prefix. Then there is no sane reason EVERY to use a NDP proxy. Period.
I have a little knowledge about ipv6. I was misunderstand the usage of NDP proxy.
I had considered to add delay and restart odhcpd service. but this may not a "good" solution. If you report this to issue tracker, please leave the link of the issue, thank you!
The log Enabling services with xxx running is output by the void reload_services(struct interface *iface); function. maybe we need add more debug info and recompile odhcpd to findout the reason.
I tried with dnsmasq-full: While it solves this issue, it does not allow me to retrieve a prefix over Wireguard. I did not investigate this further as I have a functioning workaround for the time being.