IPV6 setup behind TMOBILE Home Internet router

Hi, I am curious if someone can explain my success at setting up IPV6 behind a TMOBILE Home internet router ... and then perhaps offer a simpler solution.

I have a TMOBILE Home Internet router (the Arcadyan KVD21) and then Openwrt behind it (EdgeRouter X, with two Access Points). IPV4 has always worked. Just for fun, I tried to set up IPV6 on the LAN. However, I quickly ran into the problem that TMOBILE only delivers one /128 and one /64 address to the EdgeRouter and does not offer prefixes via DHCPV6-PD (etc).

The first step in getting around this problem was to set up an IPV6 relay (https://openwrt.org/docs/guide-user/network/ipv6/configuration#ipv6_relay) and let NDP do most of the work. However, Android devices are not happy because SLAAC is not enabled when doing a relay this way. So, I solved that problem by allowing RA messages to come from one of the access points and enabling SLAAC from the AP. It does not matter whether the ra-flags are set to 'other', 'managed config', or 'none'. None works just fine. (To be precise, the IPV6 settings for the LAN interface on the AP are ra-service => hybrid, DHCPv6-service => relay, NDP-Proxy => relay; with SLAAC enabled and ra_flags none.)

I believe this works because there are no router advertisements being sent over the LAN from any source (TMOBILE or OpenWRT) until they are enabled on the AP and then the AP sends the router advertisement over the LAN with the flag set to enable SLAAC.

I have tried to simplify these IPV6 settings by having the edge router be the IPV6 relay AND serve the RA messages (i.e. not coming from an AP) ... but this doesn't work. Enabling RA messages in any form from the edgerouter seems to disrupt ipv6 on the APs and/or further downstream.

I am curious if an IPV6 expert can suggest an edgerouter configuration that enables IPV6 on all devices (including SLAAC for Android) that doesn't involve unique settings on one AP.

Windows, Mac, Linux etc are all operational with a RA only network, so there is less confusion if you disable DHCPv6 entirely in the typical home.

OpenWrt can definitely handle this as the only router in the network, so turn off DHCP and RA servers in the dumb APs.

When Android connects to the network it will send an RA Solicit which should be answered immediately with an RA from the router. The "hybrid" option is simply an attempt to automatically select server or relay, and it may not work. Set RA service to relay directly. Also make sure that ra_dns is set, which is supposed to be the default.

1 Like

Hi Mike, Thanks for your thoughtful comments. I have tried many combinations and I have only found one working solution. I have not, however, investigated disabling DHCPv6 and/or NDP services as thoroughly as I should and so at your suggestion I have tried the following things:

Basic setup: EdgeRouter WAN6 and LAN interfaces (RA_service, DHCPv6-Service, and NDP Service) all in relay mode. Dumb APs LAN6 and LAN interfaces (RA_service, DHCPv6-service, and NDP service) all in relay mode. In this basic setup, android devices and Raspberry Pis are not happy. I can turn on hybrid mode for the RA_service on one of the Dumb APs with ra_flags 'none' (as mentioned above) and everything works.

Other configurations:

Disable DHCPv6-service and disable NDP service on the LAN interface for the edge router (everything else the same). This does not work.

Edge router in relay mode (all interfaces, all services), but disable DHCPv6-service and NDP service on the Dumb APs. This almost works. Raspberry pi is happy, newest Pixel phones are happy, but Lenovo Smart Display (circa 2019 Android) is not happy and fails miserably.

My working hypothesis continues to be that there is no RA service when all interfaces are in relay mode or disabled ... but I would be delighted to hear a different idea.

NDP relaying in the router is essential for relay mode to work. Do not turn that off. Dumb APs are layer 2 bridges, so NDP and RA packets always pass through them transparently.

I suggest tcpdump the RA packets to make sure the /64 prefix, next hop, and DNS are being properly advertised.

If only one device is not working, check the network status on that device.