Yeah, I started with v6 probably around 2011, and it was obvious that no one was listening to recommended subnet sizes shortly thereafter. I love ATT's fiber service in terms of its speed and such, but I'd drop it in a heartbeat for a fiber connection that didn't require their device and would give a /56
I hear ya. I must gone through six service providers since the beginning of IPv6. The best one was Unwired Ltd. for me. It was WiMAX from a roof dish. Not the greatest down/up at all, but I hated Comcast so much, it was my only option. It was the best for me because I was their first ever subscriber to ask for IPv6, so I got a static config with a /48 while we both had to twiddle with our settings until we got the magic. Just for me 
They gave me the RA on a /126 because they somehow felt v6 needed a broadcast addy. Naww, GW and end-point, good to go!
Not much. I gave up until today. The only way I found to get larger than a /64 in one request was to ignore native v6 and use 6rd to AT&T's border relay for a /60. But the hurdle was I needed to use a static ip from the AT&T RG as their "IP passthru" mode doesn't forward protocol 41.
Spend the extra $12 per month for 5 extra usable IPv4 addresses so I could use IPv6 more correctly? Hell to the NO!
So I've been looking at using an EAP proxy (peapod is probably the best one) and putting the WRT box in front of the broken AT&T RG and forwarding the 802.1X (radius) authentication for true bridge-mode. What dawns on me looking at the code is that this might/could be be done completely in ipchains.
I'm curious if you can make any progress with that. I just got ATT fiber and the only option they offered me was the bgw320 which has the ONT built-in. I'm out of luck for any sort of bypass method at this point, I believe.
I honestly have no gripes with passthrough at the moment other than the IPv6 situation that others are also fighting through. I might end up following @dlakelan's lead and go to a full-blown linux distro on my x86 box for wide-dhcpv6 and other goodies, but I'm trying to stick with OpenWrt as much as possible because of my love for the community here.
FWIW, I did try to strike up some interest in getting wide-dhcpv6 built again for OpenWrt here: WIDE DHCPv6 Build Help Needed
Ooh, I wonder if we could do that entirely within nftables...
yes, you'd be out of luck for a bypass method with the ONT built-in since you need to man-in-the-middle between the ONT and the "gateway"
Yup... sigh I did ask about getting a standard ONT + Arris 210, but the Humax 320 is all they would offer me 
I would be shocked if it was not possible. Here's an example I found where the ATT gateway is plugged into eth2 in this scenario:
ebtables -t filter -A FORWARD -i eth2 -p 802_1Q --vlan-encap 0x888e -j ACCEPT
ebtables -t filter -A FORWARD -i eth2 -p 802_1Q -j DROP
ebtables -t filter -A FORWARD -o eth2 -p 802_1Q --vlan-encap 0x888e -j ACCEPT
ebtables -t filter -A FORWARD -o eth2 -p 802_1Q -j DROP
Obviously that's ebtables, but the trick is apparently to only allow the 0x888e traffic to the ATT gateway.
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?
1 Like
You folks are AWESOME! So many ideas. I need coffee 
2 Likes
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:
config interface 'loopback'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
option device 'lo'
config globals 'globals'
option packet_steering '1'
config interface 'lan'
option proto 'static'
option netmask '255.255.255.0'
option ipaddr '192.168.10.1'
option ip6ifaceid '::1'
option device 'eth1'
list ip6class 'WAN6LAN'
option ip6assign '64'
config interface 'WAN'
option proto 'dhcp'
option peerdns '0'
option device 'eth0'
option hostname '*'
config interface 'WAN6'
option proto 'dhcpv6'
option peerdns '0'
option device 'eth0'
option delegate '0'
option reqaddress 'try'
option reqprefix 'no'
config interface 'GUEST'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '64'
option ipaddr '192.168.9.1'
option ip6ifaceid '::1'
option device 'eth1.9'
list ip6class 'WAN6GUEST'
config interface 'IOT'
option proto 'static'
option netmask '255.255.255.0'
option ipaddr '192.168.99.1'
option ip6assign '64'
option ip6ifaceid '::1'
option device 'eth1.99'
list ip6class 'WAN6IOT'
config device 'vwan1'
option name 'vwan1'
option type 'macvlan'
option ifname 'eth0'
config device 'vwan2'
option name 'vwan2'
option type 'macvlan'
option ifname 'eth0'
config device 'vwan3'
option name 'vwan3'
option type 'macvlan'
option ifname 'eth0'
config interface 'WAN6LAN'
option proto 'dhcpv6'
option peerdns '0'
option device 'vwan1'
option reqprefix '64'
option reqaddress 'none'
config interface 'WAN6GUEST'
option proto 'dhcpv6'
option device 'vwan2'
option reqprefix '64'
option peerdns '0'
option reqaddress 'none'
config interface 'WAN6IOT'
option proto 'dhcpv6'
option device 'vwan3'
option reqaddress 'none'
option reqprefix '64'
option peerdns '0'
Just make sure that the RA mode on each of the internal interfaces is set to 'server' mode and RA flags are set to "other config":
e.g.
config dhcp 'lan'
option interface 'lan'
...
option ra 'server'
list ra_flags 'other-config'
@vgaetera Is it possible to get this written up for AT&T fiber users in the wiki here? https://openwrt.org/docs/guide-user/network/ipv6/start
3 Likes
You could just add a new section to the bottom of that page. Make it "AT&T fiber IPv6 Config Example"
Or you wanting a page like IPv6 with Hurricane Electric but just for AT&T?
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