I'm just updating this thread after some time since I realized I never followed up on it. I was working on some optimization of this and thought I would detail in case someone else came looking.
The problem has to do specifically with using the wpa_supplicant configuration to bypass the AT&T fiber BGW device. If this is not what you are doing, then likely this particular problem doesn't apply to you. This might work for other people on other ISPs trying to remove their ISP's router, but no guarantees.
When you are using AT&T's device, what happens is that their device is handed a single (/128) IPv6 address over DHCPv6-NA in the [2001:] range. It is also assigned DHCPv-6 address, for example [2600:1700:] with a /60 bit mask. So, if you configure your ASUS in place of the BGW using IPv6 Native mode you will see something like this at the top of your routes:
Code:
keymaster@router-asus:/tmp/home/root# ip -6 route show
2001:506:XXXX:XXXX::1 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
2600:XXXX:XXXX:XXXX::/60 dev br0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
This will hand out the [2600:] range to your clients which will route through br0. But the [2001:] address is not routable outside of AT&T's network.
In the above configuration while your clients will be able to access the Internet over IPv6, your router will not.
To get the proper configuration you basically need to examine what your Asus gets when configured in "Native IPv6" mode when it is *behind* the BGW (operating in "bridge" mode).
When we do this we see that the Asus gets a routable address with a /64 mask.
The problem is that you cannot add any additional routes manually to correct this on the Asus because the PD prefix length cannot be changed from /60 (i.e. you can't solicit for a /64, it will only provide a /60).
The solution is to configure the Asus in "Static IPv6" mode. You would use as your "WAN IPv6 Address" whatever your BGW would have normally passed you in "Bridge mode", for example:
2600:XXXX:XXXX:bfe0::48
And for your "WAN IPv6 Gateway" you would use whatever your BGW reports as its "Default IPv6 Gateway Address" when configured in bridge more. This should be a local link address like:
fe80::XXXX:XXXX:XXXX:45XX
Be sure to set the prefix length to 64.
Then, for your "LAN IPv6 Address" you simply choose any address in any other valid subnet from your /64 range. So, using the [2600:XXXX:XXXX:bfe0::48]/64 range that was set for the WAN above, you could use the following address for your LAN:
[2600:XXXX:XXXX:bfe1::1]/64
(incrementing the network from bfe0 to bfe1 and using ::1 as the unique address on that network)
Then choose "Stateless configuration" (stateful has its own raft of issues, especially with Android clients). Turn Router Announcements on:
This is now the range that will be sent to your clients when they solicit IPv6 addresses.
At this point, nothing will work. Since we configured our IP addresses as Static, there is no DHCPv6 client running to request DHCPv6-NA or PD from AT&T's delegating router. Without requesting these ranges (and renewing the leases) they will not be apportioned for your use. So, the secret sauce here is to manually run the odhcp6c client. You have to manually run it since the router is set to "Static IPv6".
While the router is running in "Native IPv6" you can see odhcp6c running like this:
Code:
root@router-asus:/tmp/home/root# ps | grep odhcp6c
15246 keymaste 4728 S grep odhcp6c
28270 keymaste 760 S odhcp6c -df -R -s /tmp/dhcp6c -N try -c 00030001f8XXXXXYYYYY -FP 0:YYYYY eth0
You basically want to copy this odhcp6c command down from your Native mode config and then run it manually when in static mode. This will request the IPv6 ranges from AT&T and they they will become active.
BTW: you should probably have already configured the "MAC Address" under WAN settings to be a clone of your BGW address. If you have then that first long string of numbers (following -c) should be ending with that MAC address. The "YYYYY" are the last 5 characters of that address. In reality, it appears to not matter what is added here, but this information is reported in the DHCP requests to AT&T and so it is probably beneficial to make it appear to be the BGW in case they ever decide to audit/filter on that information.
At this point your clients should start getting proper IPv6 information and all clients (and the router) should be able to communicate to external IPv6 addresses.
At this point, you will probably want to script odhcp6c to run on every boot (and possibly some error handling in case the network gets reloaded). I found creating an init.d script is the easiest way to handle this.
I'm sure there is a very small subset of people that this will help out, but at the very least I have it for my reference!
that a Google DNS related ping6 issue, was not actually the case for me.
