So you set up a linux bridge br-wan between say eth1 and eth2. eth1 is plugged to the ONT, and eth2 is plugged to the ATT gateway. You disallow forwarding anything coming from the ATT GW other than responses to the 802_1Q queries, but you allow forwarding anything from eth1... fine... But then how do you have the router itself use the same MAC as the ATT gateway and do the DHCPv4 and DHCPv6 work?
maybe you add a veth pair? so the br-wan is eth1,eth2,veth0, and then call veth1 your WAN and set the MAC equal to the ATT GW MAC?
I managed to get this working with AT&T's dumb IPv6 setup in IP passthrough mode without needing any additional scripts or wide-dhcpv6.
This is based on pieces from:
Basically, you install kmod-macvlan and set up a macvlan type device (tied to the physical WAN interface) for each prefix you wish to pull from the AT&T gateway's /60 PD. Then you set up an additional interface for each of the macvlan devices you added. Each additional interface is a proto 'dhcpv6' type of /64 size. Finally, your internal interfaces which will receive the IPv6 PDs need to be set to hand out IPv6 addresses only from the corresponding interface you set up for the given PD. This is where the list ip6class ... setting comes into play. See below...
Here's an example of my working /etc/config/network file:
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.
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
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
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:
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)...