Sounds reasonable to me, but it looks like the wiki is closed to general updates. I think @vgaetera was the last one to make edits to it, so hoping somebody can help us help others. 
you can apply there for a wiki account to do edits.
I have wiki edit if you want a page creating and you can edit it when tmomas sorts you an account?
It works! 
for WAN6, option reqprefix 'no' as we don't need it
2 Likes
I’ll test with that as well. For some reason I was thinking that was still desirable for Openwrt itself to have an ipv6 address with a gateway so it could use ipv6 as well. Thoughts?
Another item of note, the MAC address of a MAC-VLAN device changes each time the network service restarts. I ended up setting option macaddr 'xx:xx:xx:xx:xx:xx' for each of the MAC-VLAN devices. I picked a MAC address to populate into each of those devices and just incremented the last character for uniqueness.
The populated MAC addresses then become the client IDs sent in the DHCPv6 PD request at the AT&T GW.
For me, it is getting a SLAAC in the addressing subnet, but it doesn't need its own /64 as we're bypassing that now. I have my four subnets working properly. I'm so pleased
1 Like
Right on! I just made your suggested change and that's perfect for me! I updated the solution post to include the option reqprefix 'no' for WAN6.
I'm having trouble with the DHCPv6 servers on the subnets. All I'm getting on my main lan are SLACC addresses. here is part of my /etc/config/dhcp
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv4 'server'
option ndp 'hybrid'
option ra 'server'
list ra_flags 'other-config'
option dhcpv6 'server'
it doesn't look wrong. I'm at a loss. the MACVLAN interface owns the PD, though. Is this the problem?
ok, I got it. managed-config was missing
list ra_flags 'managed-config'
list ra_flags 'other-config'
1 Like
Alright, take a look at this that I've added to the OpenWrt wiki and let me know what you think!
2 Likes
I wanted to hold-off until I understood it better, but I'm at a loss. The default gateway being advertised on my lan by the DHCPv6 server is unreachable. I tried a different MAC on the lan interface, but still the same behavior.
davygrvy@puukukui:~$ ip -6 route |grep default
default via fe80::6238:e0ff:feca:e009 dev enp3s0 proto ra metric 20100 pref medium
davygrvy@puukukui:~$ ping fe80::6238:e0ff:feca:e009
PING fe80::6238:e0ff:feca:e009(fe80::6238:e0ff:feca:e009) 56 data bytes
ping: sendmsg: Invalid argument
ping: sendmsg: Invalid argument
ping: sendmsg: Invalid argument
^C
--- fe80::6238:e0ff:feca:e009 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2045ms
Was it working and then stopped or the default gateway has never worked with this configuration?
Hasn't worked at all.
I'm bypassing the bridge and going right to the first port if this makes a difference. In /etc/config/network:
config device
option name 'lan1'
option macaddr '60:38:e0:ca:e0:09'
option acceptlocal '1'
Ah! Okay, so that was happening for me too and I was banging my head on the wall for a while until I realized the firewall (nftables in my case) was blocking certain IPv6 traffic. For instance, I had to allow DHCPv6 from those additional interfaces I created to the AT&T gateway (via my physical WAN iface).
Also, I was seeing the same issue as you until I made sure my client subnets were able to make the nd-router-solicit ICMPv6 call to the WAN6* interfaces. Once router-solicitation (ICMPv6 type 133) was enabled, I was off to the races!
For reference, here are the complete IPv6 rules that fixed my issue:
chain input {
type filter hook input priority 0; policy drop;
...
ip6 nexthdr ipv6-icmp icmpv6 type echo-request limit rate 5/second counter accept comment "IPv6 ICMP"
ip6 nexthdr ipv6-icmp ip6 hoplimit 1 icmpv6 type { nd-neighbor-advert, nd-neighbor-solicit, nd-router-advert, nd-router-solicit } limit rate 10/second counter accept comment "IPv6 ICMP"
ip6 nexthdr ipv6-icmp ip6 hoplimit 255 icmpv6 type { nd-neighbor-advert, nd-neighbor-solicit, nd-router-advert, nd-router-solicit } limit rate 10/second counter accept comment "IPv6 ICMP"
...
}
1 Like
Is this for /etc/config/firewall ?
Unfortunately no... I am doing the firewall4 (nftables) deal on my OpenWrt build, so the syntax I shared above is for nftables. Let me see if I can look up the equivalent for iptables (or specifically /etc/config/firewall)...
thanks. I added my WAN6LAN to the existing lan zone, too, but no luck
Oh! I'm half working now adding WAN6LAN to the lan zone. WTH?
davygrvy@puukukui:~$ ping6 google.com
PING google.com(sfo03s26-in-x0e.1e100.net (2607:f8b0:4005:811::200e)) 56 data bytes
64 bytes from sfo03s26-in-x0e.1e100.net (2607:f8b0:4005:811::200e): icmp_seq=1 ttl=116 time=5.79 ms
64 bytes from sfo03s26-in-x0e.1e100.net (2607:f8b0:4005:811::200e): icmp_seq=2 ttl=116 time=5.60 ms
64 bytes from sfo03s26-in-x0e.1e100.net (2607:f8b0:4005:811::200e): icmp_seq=3 ttl=116 time=5.80 ms
64 bytes from sfo03s26-in-x0e.1e100.net (2607:f8b0:4005:811::200e): icmp_seq=4 ttl=116 time=5.70 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 5.599/5.723/5.802/0.081 ms
davygrvy@puukukui:~$ ping fe80::6238:e0ff:feca:e009
PING fe80::6238:e0ff:feca:e009(fe80::6238:e0ff:feca:e009) 56 data bytes
ping: sendmsg: Invalid argument
ping: sendmsg: Invalid argument
^C
--- fe80::6238:e0ff:feca:e009 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1028ms
Can you consistently ping the IPv6 global address on the OpenWrt interface for that lan subnet?
yes, and now DHCPv6 has stopped working. This is bizarre. I need coffee 
This is excellent. Transmission is now receiving IPv6 traffic 
Transmission doesn't support UPnP pinholes, but I do it manually:
upnpc -6 -A "" 8333 2600:1700::xxxx 51413 udp 30000