Having issues to split IPv6 in 2 different networks

Greetings all,

I am running a WRT3200ACM with OpenWRT 18.06.2. Everything is working as expected but then I created a different network so I can put all my IoT devices there. IPv4 is working as expected but I decided to also allow those devices to use IPv6 and it's what I've been having problems with.
Some data:

My ISP gives me a /56 so I have a /60 for my LAN (lan) and /64 for that IOT network I created (iot).
This is what I can see on ifstatus wan6:

"ipv6-prefix": [
			"address": "xxxx:xxxx:xxxx:2a00::",
			"mask": 56,
			"preferred": 60290,
			"valid": 74690,
			"class": "wan6",
			"assigned": {
				"lan": {
					"address": "xxxx:xxxx:xxxx:2a00::",
					"mask": 60
				"iot": {
					"address": "xxxx:xxxx:xxxx:2a10::",
					"mask": 64

I tried all sorts of configurations for DHCP on both LANs (server,relay and hybrid), tried to assign both LANs a /64 instead of /60 and /64, fiddled with the firewall and I can't see anything being blocked, tried to set the DHCP to authoritative, etc but I am at a standstill now.
Does anyone have any idea what could be happening?
If any other data is needed, please let me know.


  • Change assingment length to disabled
  • Assign an IPv6 address using a free /64 prefix from your /60 (e.g. xxxx:xxxx:xxxx:2a10::1/64)
  • Assign that same prefix as the IPv6 routed prefix (e.g. xxxx:xxxx:xxxx:2a10::/64)

This works for me:


Thanks for that!

I have tried that but still doesn't work, do you have the same 2 networks, lan and something else? They don't connect to each other.

I have tried to assign different prefixes to each one of them (and also the same) to no avail.

Allow forwarding.

Thanks but I don't want them to, they are completely separate networks but for a test, I did enable forward and it's still the same thing.

I am not sure what the exact problem is - that the ifaces are not being assigned ipv6 addresses or that ipv6 interconnectivity does not work?

The former is working as expected on this node, with the same ula_prefix and different ip6hint per iface

If it is about ipv6 interconnectivity you might experience https://bugs.openwrt.org/index.php?do=details&task_id=2280&order=dateopened&sort=desc

Another potential cause could be bridge filtering/isolation.

Thanks, n8v8R. i believe the problem is with connectivity and it's not the one you mentioned (NO CARRIER issue).
This is what I have on my side:

But no addresses are being given to any network connected to br-iot.
Adding a forward from br-iot to lan doesn't help either.

Edit: For testing purposes I got a device connected to br-iot and set a fixed IP address on the same network (x:x:x:2a10) and it works fine, I have full IPv6 connectivity.
Question remains, how come IPs are not being given automatically?

seems somewhat contradictory to

unless it pertains to dhcp6 connectivity indeed.

Did you check the logs whether odhcpd (unless you use dnsmasq for dhcp6 that is) is receiving any dhcp queries from the iot clients?
You may inspect the issue with a tcpdump on the router to see what happens to dhcp6 traffic.

Sorry about that, you are right so let me rephrase that after I tested manually setting an IP to a node connected to br-iot: Connectivity is actually working well so the problem seems to be no IPs are being handed out automatically on br-iot.
I just did a tcpdump and I saw a client requesting an IP via DHCP on br-iot but it's being ignored.

How is the firewall configured for the iot network?

The curious thing I have been observing something similar with wan6 set to dhcp

I did not get around doing a tcpdump then, but it seems like bug perhaps.

Like mentioned in the other thread, when I let netid automatically span wan (pppoe-wan), wan_6 (pppoe-wan) and wan_6_4 (dslite-wan_6_4) all downstream clients get their ipv6 from upstream but not with wan6 configured to dhcp.

This is very interesting, it's a quite similar setup, I have FTTB/H so I get an ethernet cable going straight from the ISP's media converter on the wall to the WAN port of my router and use DHCP.

It could be a bug, yes. Here's the tcpdump output:

# tcpdump -i br-iot udp port 546 and udp port 547
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-iot, link-type EN10MB (Ethernet), capture size 262144 bytes
10:45:11.235849 IP6 fe80::9a09:cfff:fe5a:5da4.546 > ff02::1:2.547: dhcp6 solicit
10:45:12.334759 IP6 fe80::9a09:cfff:fe5a:5da4.546 > ff02::1:2.547: dhcp6 solicit
10:45:14.495028 IP6 fe80::9a09:cfff:fe5a:5da4.546 > ff02::1:2.547: dhcp6 solicit

Perhaps worth lodging it with the developers unless someone could come up with a way to get it working.

I am just not sure which component such potential bug is with - netifd or odhcpc or odhcpd

Yes, it's what I will probably do after some days.

No idea too.

Not sure if it make a difference (propably not though) - netifd automatically spawns the virtual iface wan_6 whilst for manually setting upstream dhcp the iface name is wan6.

The issue is really peculiar and curious.

@jow I know you are busy with tons of stuff - any chance for you to take a look since we seem to be at the end of our wits?

I don't have that one but I believe it just happens when you use pppoe? I have a 2nd ISP connection that I haven't been using since getting fibre but that one uses pppoe and I can see the wan_6 you are talking about.

You could increase the odhcpd log level (restart odhcpd to take effect), e.g.

config odhcpd 'odhcpd'
	option loglevel '4'

and see if that would reveal the issue perhaps. Queries from iot clients should show up, if not however than they are likely not being received.

Yep, that seems correct. I am not into coding matters and really do not understand why in one case it is wan6 and the other wan_6 or why automatic iface spawning works only for pppoe but not dhcp.
It probably is not likely to cause the issue however.

I tried that but I can only see this changing the log level from 4 to 7.

Wed Jun 19 11:45:11 2019 daemon.debug odhcpd[8266]: Netlink newneigh xxx:xxxx:%br-lan

where xxxx:xxxx is an IPv6 IP.

dhcp6 traffic with clients would show as something like


If that is absent then odhcpd is likely not receiving the queries or silently discarding them. Which seems strange considering

So perhaps, odhcpd is not aware of the ipv6 range received from upstream and thus silently discards the queries from downstream because it thinks there is nothing to give.