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.

Although this thread is a couple months old, I just got T-Mobile home internet and I was struggling to make ipv6 work, and this thread helped. Well, I think I got it working (at least with my Mac and iOS clients) without needing an external RA on my LAN. Here are the pertinent options I'm using in /etc/config/dhcp. I have to admit that I don't fully understand the mechanics.

config dhcp 'lan'
	option interface 'lan'
	option dhcpv6 'relay'
	option ra 'relay'
	option ndp 'relay'
	option ndproxy_slave '1'

config dhcp 'wan6'
	option dhcpv6 'relay'
	option ra 'relay'
	option ndp 'relay'
	option master '1'
	option interface 'wan6'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

If I connect a MacBook (macOS), iPad (iOS) or Linux (Debian) devices directly to the second ethernet port on the TMHI gateway (G4AR, similar to the KVD21), all of them will pass the www.test-ipv6.com test, that means I am getting a valid IPv6 address from T-Mobile Home Internet, now, I need to understand why OpenWrt 23.05.4 is not passing it through.

IPV6 Relay Mode should work for your application with modern Apple and Android devices. Only older devices (pre-2017 ish) fail when placed behind my TMobile KVD21 gateway + Openwrt router. To make these old devices work, I had to go to the trick of setting up SLAAC on a remote (dumb) access point as described in my original post.

I encourage you to start from the default configuration on your OpenWRT device and then make as few changes as necessary to shift it into IPV6 Relay Mode. It is possible that prior attempts to set up IPV6 have left some remnants in your configuration files that are interfering with some of your devices. So I encourage you to start with a fresh config file. Then as seen from the command line interface (CLI) your dhcp, network, and firewall files should be no more complex than shown below:

/etc/config/dhcp

config dhcp 'lan'
  option interface 'lan'
  option start '100'
  option limit '150'
  option leasetime '12h'
  option dhcpv4 'server'
  option dhcpv6 'relay'
  option ra 'relay'
  option ndp 'relay'

config dhcp 'wan'
  option interface 'wan'
  option ignore '1'
  
config dhcp 'wan6'
  option interface 'wan6
  option master '1'
  option ra 'relay'
  option dhcpv6 'relay'
  option ndp 'relay'
  …


/etc/config/network

config interface 'lan'
  option device 'br-lan'
  option proto 'static'
  option ipaddr '192.168.1.1'
  option netmask '255.255.255.0'
  option ip6assign '60'

config interface 'wan'
  option device 'eth0'
  option proto 'dhcp'
  …

config interface 'wan6'
  option device 'eth0'
  option proto 'dhcpv6'
  option reqaddress 'try'
  option reqprefix 'auto'
  …

/etc/config/firewall

config zone
  option name 'lan'
  option input 'ACCEPT'
  option output 'ACCEPT'
  option forward 'ACCEPT'
  list network 'lan'
  list network 'lan6'
  …

Your device names may be different. If you are running Stubby, MWAN3, etc., then there will be additional lines in your configuration files, but the basic ipv6 options shown above should not be different.

[Note added later: there will be other configurations in the /etc/config/dhcp and /etc/network files that are not shown above for the sake of brevity. In this email, only those configs that affect the dhcpv6 settings are shown.]

Thank you for the information, I started from scratch, did the changes you suggested, all the clients get 3 IPv6 addresses with prefix length of 64:

2607:fb90:.....
2607:fb90:....
fd15:4b0c:....

The router gets default gateway address of: fe80:9683:.....

Unfortunately none of them pass the ipv6-test.com, honestly I don't know what else to do

Try test-ipv6.com instead. If you pass this test then you are fine. Ipv6-test.com is different and is overly demanding.

This is the one I am using test-ipv6.com

The 2607: addresses are external addresses while the fdxx: and fexx addresses are internal addresses (internal addresses only work on your LAN segment and won't pass outside to the WAN). Try the openwrt network diagnostics on your router to see if you can ping openwrt.com using both ipv4 and ipv6. You can also try the trace route tool for both ipv4 and ipv6. The ipv6 trace route to openwrt.org will probably fail so use ipv6.google.com instead. If you can't ping and/or trace route using ipv6 then something is wrong with your router setup and it has nothing to do with your devices.

Is your wan6 interface up and running? If it exists and has been booted, then check to see if the the wan6 interface has been set as 'master'. It should say option master '1' in the /etc/config/dhcp file at the same point that you set all the relay options. You can also check this with the Luci interface if you dig a bit.

Agree, it is definitely something related to the openWRT router, if I replace it with my old Asus ax88u configured with ipv6 in passthrough mode, everything ipv6 works.

Yes wan6 is up and running, I can see it in the overview page in LuCI with a valid 2607: ipv6 address assigned to it via dhcp client by TMHI gateway

Keep trying. Check your dhcp, network, and firewall settings carefully. Check your network diagnostics on the LUCI Network => Diagnostics tab. It should work.

Look at the IPv6 Upstream box on the LUCI Status Overview page. You should see one or more external addresses for the DHCPv6 client and perhaps even an internal address too. Most importantly check that you have an internal address (fexx: or fdxx:) for the Gateway. The last four digits of the gateway address should match the last four digits of the MAC address for the TMobile KVD21 box.

I'm not able to access my network at the moment, but as I earlier posted, in addition to the relay options I also had to use option ndproxy_slave '1' and the config odhcp options to make it work with my router.

I'm not sure what the ndproxy_slave option will do so I cannot speak to that.

I would recommend that you try again with the bare bones 'relay' settings including the config odhcp section and all the other default configs. Then check the overview page to see if you have an external address for the DHCPv6 client in the IPv6 upstream box, a local address for the Gateway ending with the last 4 digits of the MAC address for the TMobile Box, and (I forgot to say) the DNS server should have the same ipv6 local address as the Gateway. If you have all these things, then you should be able to make ipv6 ping and trace route work on the Network => Diagnostics page.

I'm assuming that you are talking directly to your router via wifi or a wired interface and NOT through an Access Point. Correct? If you are trying to make ipv6 work through your router and an AP, then there are a few other things you need to do.

My understanding is that ndproxy-slave is used whenthe upstream provider does not support prefix delegation, which I'm pretty sure was the case on my TMHI modem, as I recall the openwrt WAN got a /64 address. From what I understand, ndproxy_slave enables the LAN interface to learn routes from the interface that is marked master.

According to the Openwrt web page for the dhcp default settings, ndpproxy_slave causes the devices to "Ignore neighbor messages on slave enabled (1) interfaces". I still don't know what that means but I honestly don't think you want it or need it. The openwrt default configuration for an ipv6 relay should take care of everything you need to make ipv6 work behind a TMobile router. Prefix delegation will not work because TMobile does not allow it, but you should not have to make any special changes to the default relay settings to get an ipv6 address for the devices on you LAN.

With just the basic relay settings, openwrt and TMobile will allow your devices to use the external tmobile prefix and add a suffix that is based on the MAC address for the device. In other words, each device will have one fixed external address. This is not the ideal situation but that is all that can be done when an ISP does not allow prefix delegation.