IPv6 tethering

[Mygod]

Currently AOSP only has support for IPv6 tethering when using mobile networks under supported carriers since Android 7.0.

It's unclear how to do this for IPv6-capable VPN or even Wi-Fi. The main issue is configuring a valid IPv6 address for clients. This is further complicated by the fact that sometimes dnsmasq (actually I'm not 100% sure yet) will configure another valid IPv6 address using Router Advertisement.

Update: It might be possible to create a bridge. [1, 2]

[githuborer]

Looks like a prob here too. My Xiaomi Mi6 has mobile IPv6 support. If I connect to IPv6 vpn-server my Android has the new default v6 route through tunnel. But all clients have an IPv6 leak even if "Disable IPv6 tethering" option is enabled. I 'll show all routes / routing tables if I 've more time.

[Mygod]

@githuborer That would certainly be helpful. You should check if your clients have an IPv6 address after checking "Disable IPv6 tethering". If you want to do a follow-up, feel free to open another issue as this one is reserved for handling IPv6 tethering better.

[githuborer]

You should check if your clients have an IPv6 address after checking "Disable IPv6 tethering".

Yes that's the point. Real IPv6 is leaking to connected clients. "Disable IPv6 tethering" option does nothing for my phone.

[glennbutler]

Hey I have a OnePlus6 on TMobile which prefers IPv6 by default. I noticed some interesting things recently:

1. I always used Disable IPv6 and if you do whatismyip.com -- laptop only detects IPv4
2. USB DNS has issue when Is this app unable to transfer udp? #1 is turned on, so I turned it off and USB Tethering works.
3. With a VPN (I sometimes use my home/vacation home using OpenVPN and have NordVPN -- both IPv4), if Disable IPv6 is turned off, turning on the VPN does nothing (causes all traffic to go around the VPN), whereas if Disable IPv6 is turned on, all traffic goes through the VPN. You can turn the VPN on and off and traffic will switch to going over the VPN or native at will. So on my phone, re-enabling the IPv6 totally defeats VPN's purpose -- all traffic goes around the VPN.

I am using rooted OnePlus Oxygen, but I think it is pretty close to vanilla Android -- the phone was bought unlocked...the TMobile version may have different tethering system.

I could contribute and look into fixing this -- assume most of this is implemented through iptables and ip6tables, right? Would also love to add a TTL (IPv4) hop limit (IPv6) option to help people using the app to get around tethering restrictions...

[Mygod]

@glennbutler It would be great if you can look into this! I think this might be more than messing with ip6tables as for some VPNs, a simple IPv6 forwarding rule may be enough, but for others some kind of IPv6 NAT might be required (I'm not sure if Android kernel supports this).

[Mygod]

I took an additional look at this and here are my thoughts.

For now, I do not plan to support any kind of IPv6 NAT (because I think IPv4-only NAT should cover all the use cases). However, using a neighbor discovery proxy might be useful for local-only interfaces (portier might be useful but still in development) for advantages of IPv6 networks.

No plan on implementing this any time soon yet.

[qwe7002]

I turned off the disable IPv6 tethering function, but I can't get an available IPv6 connection (I don't need IPv6 to connect through VPN), I know that disabling IPv6 can avoid VPN leakage. But sometimes I need to connect to the IPv6 network(Direct connection without VPN) through a relay, without ipv6 will cause problems to use. I don't know if this is a bug.

[qwe7002]

I tried to configure the default gateway of the client device to the IPV6 address used by the P2P interface. This address can be pinged normally. But unable to access other URLs, suggesting no route

[worstperson]

Seems like my kernel is not built with ipv6 nat support, so even running a transparent proxy is out of the question. Still have hope bridging might work. VPN clients can be configured to offer a local subnet rather than just a single local ip, or a least I know the Android WireGuard client can, so that might actually be a workable solution.

How far were you able to get in experimenting with this, Mygod?

[Mygod]

I did not try very hard to get this going because honestly the benefits are minimal. Feel free to submit a PR if you get it going though. ;)

[worstperson]

Quickly found that bridging is also not possible, not without compiling tap support into the kernel and using native clients.

Just going to post my test script that I used to manually configure tethering, I couldn't find this elsewhere. Took an embarrassing amount of iteration to get this to work.

#!/system/bin/sh

#netID = 99 0x63
setprop sys.usb.config 'rndis,adb'
ndc interface setcfg rndis0 192.168.42.129 24 up
ndc ipfwd enable tethering
ndc network interface add 99 rndis0
ndc network route add 99 rndis0 192.168.42.0/24
ndc network route add 99 rndis0 fe80::/64
ndc tether interface add rndis0
ndc tether dns set 99 8.8.4.4 8.8.8.8
ndc nat enable rndis0 tun0 99
ndc ipfwd add rndis0 tun0
ndc tether start 192.168.42.10 192.168.42.99

[Mygod]

I have not looked into this extensively but I am not sure why you say it is impossible. I think Android supports IPv6 tethering natively? Do they use something else?

[worstperson]

It supports IPV6 tethering the correct way, each tethered device receives a unique address from the provider. This is clearly undesirable as any traffic through those addresses is defacto tethering and will be treated as such by the provider.

Tethering through a VPN gets around this, but to be possible, it needs a layer 2 TAP interface to use with bridging(similar to how it works with the provider) or support natting(to simply route traffic rather than hide topology). These features are not at all standard in Android, even with custom kernels/roms, so it doesn't make sense to support them here IMO.

[worstperson]

Think I answered poorly. AFAICT public ipv6 addresses for tethered clients are configured via slaac server on the provider side, not anything on the client side. Guess this would be testable by blocking icmp6 between rndis0 and the ipv6 mobile interface and reconnecting.

I had some recent success getting tethering with ipv6 working. I grabbed Lineage sources for my phone and rebuilt my kernel with CONFIG_NF_NAT_IPV6 and CONFIG_IP6_NF_TARGET_MASQUERADE enabled. Also cross-compiled radvd for ipv6 provisioning. radvd.conf defines interface rndis0, prefix fd00::/64, and ipv6 dns servers.

#!/system/bin/sh

#netID = 99 0x63
setprop sys.usb.config 'rndis,adb'
ndc interface setcfg rndis0 192.168.42.129 24 up
ip -6 addr add fd00::1/64 dev rndis0 scope global
ip -6 route add fd00::/64 dev rndis0 proto kernel src fd00::1
ndc ipfwd enable tethering
ndc network interface add 99 rndis0
ndc network route add 99 rndis0 192.168.42.0/24
ndc network route add 99 rndis0 fd00::/64
ndc network route add 99 rndis0 fe80::/64
ndc nat enable rndis0 tun0 99
ndc ipfwd add rndis0 tun0

ip6tables -t nat -N tetherctrl_nat_POSTROUTING
ip6tables -t nat -A POSTROUTING -j tetherctrl_nat_POSTROUTING
ip6tables -t nat -A tetherctrl_nat_POSTROUTING -o tun0 -j MASQUERADE
ip6tables -t filter -D tetherctrl_FORWARD -g tetherctrl_counters
ip6tables -t filter -A tetherctrl_FORWARD -i tun0 -o rndis0 -m state --state RELATED,ESTABLISHED -g tetherctrl_counters	
ip6tables -t filter -A tetherctrl_FORWARD -i rndis0 -o tun0 -m state --state INVALID -j DROP	
ip6tables -t filter -A tetherctrl_FORWARD -i rndis0 -o tun0 -g tetherctrl_counters	
ip6tables -t filter -A tetherctrl_FORWARD -j DROP

# These commands as written are blocking
dnsmasq --keep-in-foreground --no-resolv --no-poll --dhcp-authoritative --dhcp-range=192.168.42.10,192.168.42.99,1h --dhcp-option=6,8.8.8.8,8.8.4.4 --dhcp-leasefile=/sdcard/dnsmasq.leases --dhcp-option-force=43,ANDROID_METERED --pid-file=/sdcard/dnsmasq.pid --listen-mark 0xf0063

radvd -n

Here I set the ipv6 address and route, mark traffic for the global ipv6 subnet, and add the missing ip6tables rules to match. Found I needed to call dnsmasq directly as ndc tether seemed to interfere.

[Mygod]

While I definitely applaud the efforts, I do not think we can implement anything close to recompiling the kernel within the app though. 😅

I think the worst we can do is to do everything in user space, which might not be super efficient. I currently do not have the luxury to investigate personally but please do keep me posted. 👍

[worstperson]

Ideally rom and kernel maintainers will pick up on this use case and start building with these options. At the very least it could save advanced users a bunch of time. I imagine two device setups will ultimately be more popular since it's easier and doesn't require root(ex. run a transparent proxy like squid on the phone and configure a router to redirect all outgoing traffic to it).

Do tell if you can think of an entry point for a software solution. The obvious place to look is tunnels, which are widely supported, but only the layer 3 variants that are not useful here. This would also be a herculean task to implement.

[worstperson]

Finally stumbled on how this can be done, I feel really dumb for not landing on this sooner. Turns out we can use TPROXY mangle rules to capture and redirect outbound IPv6 traffic to a local transparent proxy. transocks-wong and microsocks (for example) would be enough for TCP support, but I'm unsure about UDP atm.

The kernel module to achieve this is very widely supported on Android:
CONFIG_NETFILTER_XT_TARGET_TPROXY

[Mygod]

Sounds great. Did you get it working?

[snetsplit]

Could you set up a broute to accomplish this?

I use this command on my router to enable ipv6 on my network from a tethered phone. wan (the android phone to router connection) and lan is local network

ebtables -t broute -A BROUTING -i wan -p ! ipv6 -j DROP && brctl addif lan wan

Could you bridge the vpn connection for IPv6 and then do normal NAT tethering for IPv4? The biggest issue I can think of is kernel module support.

[snetsplit]

Nevermind. I just tried ebtables on my phone. Command not found. Leaving that failed idea up for the next person's info.

[Poorav165]

does disabling ipv6 tethering slow speed?
what are the pros and cons?

[Mygod]

@Poorav165 IPv6 tethering will not be routed through VPNs. You should disable that if you want everything to go through VPN.

[PallavRastogi]

Ok ,thx. But what if I am not using vpn? Will turning ipv6 on improve speed?

[f1vefour]

Finally stumbled on how this can be done, I feel really dumb for not landing on this sooner. Turns out we can use TPROXY mangle rules to capture and redirect outbound IPv6 traffic to a local transparent proxy. transocks-wong and microsocks (for example) would be enough for TCP support, but I'm unsure about UDP atm.

The kernel module to achieve this is very widely supported on Android: CONFIG_NETFILTER_XT_TARGET_TPROXY

This is supported on the Pixel 4 XL stock source, how did you get it to work though?

[worstperson]

Sorry for the extremely late reply.
https://github.com/heiher/hev-socks5-server
https://github.com/heiher/hev-socks5-tproxy

The last line in Android.mk for hev-socks5-tproxy is set to 'BUILD_SHARED_LIBRARY', change to 'BUILD_EXECUTABLE'.

Both projects crash on localtime calls for me, so I disabled logging in hev-socks5-logger.c and hev-logger.c, example:

int
hev_socks5_logger_init (HevSocks5LoggerLevel level, const char *path)
{
    req_level = level;

    /*if (0 == strcmp (path, "stdout"))
        fd = dup (1);
    else if (0 == strcmp (path, "stderr"))
        fd = dup (2);
    else
        fd = open (path, O_WRONLY | O_APPEND | O_CREAT, 0640);

    if (fd < 0)
        return -1;*/

    return 0;
}

Then build. Configs are located under conf/main.yml. Enable the auth block for hev-socks5-server and set the username/password. Then run them(from /data/local/tmp):

./hev-socks5-server socks.yml
./hev-socks5-tproxy tprox.yml

And the iptables rules I used:

# IPv4
iptables -t mangle -A PREROUTING -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A PREROUTING -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A PREROUTING -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A PREROUTING -d 169.254.0.0/16 -j RETURN
iptables -t mangle -A PREROUTING -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A PREROUTING -d 192.0.0.0/24 -j RETURN
iptables -t mangle -A PREROUTING -d 192.0.2.0/24 -j RETURN
iptables -t mangle -A PREROUTING -d 192.88.99.0/24 -j RETURN
iptables -t mangle -A PREROUTING -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A PREROUTING -d 198.18.0.0/15 -j RETURN
iptables -t mangle -A PREROUTING -d 198.51.100.0/24 -j RETURN
iptables -t mangle -A PREROUTING -d 203.0.113.0/24 -j RETURN
iptables -t mangle -A PREROUTING -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A PREROUTING -d 240.0.0.0/4 -j RETURN
iptables -t mangle -A PREROUTING -d 255.255.255.255 -j RETURN
iptables -t mangle -A PREROUTING -p tcp -j TPROXY --on-port 1088 --tproxy-mark 1088
iptables -t mangle -A PREROUTING -p udp -j TPROXY --on-port 1088 --tproxy-mark 1088

ip rule add fwmark 1088 table 100
ip route add local default dev lo table 100

# IPv6
ip6tables -t mangle -A PREROUTING -d :: -j RETURN
ip6tables -t mangle -A PREROUTING -d ::1 -j RETURN
ip6tables -t mangle -A PREROUTING -d ::ffff:0:0:0/96 -j RETURN
ip6tables -t mangle -A PREROUTING -d 64:ff9b::/96 -j RETURN
ip6tables -t mangle -A PREROUTING -d 100::/64 -j RETURN
ip6tables -t mangle -A PREROUTING -d 2001::/32 -j RETURN
ip6tables -t mangle -A PREROUTING -d 2001:20::/28 -j RETURN
ip6tables -t mangle -A PREROUTING -d 2001:db8::/32 -j RETURN
ip6tables -t mangle -A PREROUTING -d 2002::/16 -j RETURN
ip6tables -t mangle -A PREROUTING -d fc00::/7 -j RETURN
ip6tables -t mangle -A PREROUTING -d fe80::/10 -j RETURN
ip6tables -t mangle -A PREROUTING -d ff00::/8 -j RETURN
ip6tables -t mangle -A PREROUTING -d AAAA:BBBB:CCCC:DDDD::/64 -j RETURN
ip6tables -t mangle -A PREROUTING -p tcp -j TPROXY --on-port 1088 --tproxy-mark 1088
ip6tables -t mangle -A PREROUTING -p udp -j TPROXY --on-port 1088 --tproxy-mark 1088
ip -6 rule add fwmark 1088 table 100
ip -6 route add local default dev lo table 100

Replace AAAA:BBBB:CCCC:DDDD with the first half of your public IPv6 address(the one assigned by your carrier). Wireguard in kernel mode breaks this configuration, but other VPNs work fine.

[f1vefour]

That's a lot to have just figured out, very nice and thank you for coming back with the well written instructions.

I'm not setup for compiling NDK binaries currently but I will certainly try this as soon as I can pull down the compiler, I used to write Android apps but lost interest in it several years ago

[mcheng89]

Think I answered poorly. AFAICT public ipv6 addresses for tethered clients are configured via slaac server on the provider side, not anything on the client side. Guess this would be testable by blocking icmp6 between rndis0 and the ipv6 mobile interface and reconnecting.

I had some recent success getting tethering with ipv6 working. I grabbed Lineage sources for my phone and rebuilt my kernel with CONFIG_NF_NAT_IPV6 and CONFIG_IP6_NF_TARGET_MASQUERADE enabled. Also cross-compiled radvd for ipv6 provisioning. radvd.conf defines interface rndis0, prefix fd00::/64, and ipv6 dns servers.

#!/system/bin/sh

#netID = 99 0x63
setprop sys.usb.config 'rndis,adb'
ndc interface setcfg rndis0 192.168.42.129 24 up
ip -6 addr add fd00::1/64 dev rndis0 scope global
ip -6 route add fd00::/64 dev rndis0 proto kernel src fd00::1
ndc ipfwd enable tethering
ndc network interface add 99 rndis0
ndc network route add 99 rndis0 192.168.42.0/24
ndc network route add 99 rndis0 fd00::/64
ndc network route add 99 rndis0 fe80::/64
ndc nat enable rndis0 tun0 99
ndc ipfwd add rndis0 tun0

ip6tables -t nat -N tetherctrl_nat_POSTROUTING
ip6tables -t nat -A POSTROUTING -j tetherctrl_nat_POSTROUTING
ip6tables -t nat -A tetherctrl_nat_POSTROUTING -o tun0 -j MASQUERADE
ip6tables -t filter -D tetherctrl_FORWARD -g tetherctrl_counters
ip6tables -t filter -A tetherctrl_FORWARD -i tun0 -o rndis0 -m state --state RELATED,ESTABLISHED -g tetherctrl_counters	
ip6tables -t filter -A tetherctrl_FORWARD -i rndis0 -o tun0 -m state --state INVALID -j DROP	
ip6tables -t filter -A tetherctrl_FORWARD -i rndis0 -o tun0 -g tetherctrl_counters	
ip6tables -t filter -A tetherctrl_FORWARD -j DROP

# These commands as written are blocking
dnsmasq --keep-in-foreground --no-resolv --no-poll --dhcp-authoritative --dhcp-range=192.168.42.10,192.168.42.99,1h --dhcp-option=6,8.8.8.8,8.8.4.4 --dhcp-leasefile=/sdcard/dnsmasq.leases --dhcp-option-force=43,ANDROID_METERED --pid-file=/sdcard/dnsmasq.pid --listen-mark 0xf0063

radvd -n

Here I set the ipv6 address and route, mark traffic for the global ipv6 subnet, and add the missing ip6tables rules to match. Found I needed to call dnsmasq directly as ndc tether seemed to interfere.

Thanks for this! I modified the script to setup a wifi hotspot on my Pixel 6:

/data/data/com.termux/files/usr/bin/iw dev wlan0 interface add wlan2 type __ap
/data/data/com.termux/files/usr/bin/iw dev wlan0 interface add wlan3 type __ap

nohup /vendor/bin/hw/hostapd /data/vendor/wifi/hostapd/hostapd_wlan2.conf & >/dev/null 2>&1
nohup /vendor/bin/hw/hostapd /data/vendor/wifi/hostapd/hostapd_wlan3.conf & >/dev/null 2>&1

ip -6 addr add fd00::1/64 dev ap_br_wlan2 scope global
ndc interface setcfg ap_br_wlan2 192.168.42.129 24 up
ip -6 route add fd00::/64 dev ap_br_wlan2 proto kernel src fd00::1

ndc ipfwd enable tethering
ndc network interface add 99 ap_br_wlan2
ndc network route add 99 ap_br_wlan2 192.168.42.0/24
ndc network route add 99 ap_br_wlan2 fd00::/64
ndc network route add 99 ap_br_wlan2 fe80::/64
ndc nat enable ap_br_wlan2 rmnet0 99
ndc ipfwd add ap_br_wlan2 rmnet0

ip6tables -t nat -N tetherctrl_nat_POSTROUTING
ip6tables -t nat -A POSTROUTING -j tetherctrl_nat_POSTROUTING
ip6tables -t nat -A tetherctrl_nat_POSTROUTING -o ap_br_wlan2 -j MASQUERADE
ip6tables -t nat -A tetherctrl_nat_POSTROUTING -i ap_br_wlan2 -o rmnet0 -j MASQUERADE
ip6tables -t filter -D tetherctrl_FORWARD -g tetherctrl_counters
ip6tables -t filter -A tetherctrl_FORWARD -i rmnet0 -o ap_br_wlan2 -m state --state RELATED,ESTABLISHED -g tetherctrl_counters
ip6tables -t filter -A tetherctrl_FORWARD -i ap_br_wlan2 -o rmnet0 -m state --state INVALID -j DROP
ip6tables -t filter -A tetherctrl_FORWARD -i ap_br_wlan2 -o rmnet0 -g tetherctrl_counters
ip6tables -t filter -A tetherctrl_FORWARD -j DROP

nohup dnsmasq --keep-in-foreground --no-resolv --no-poll --dhcp-authoritative --dhcp-range=192.168.42.10,192.168.42.99,1h --dhcp-option=6,8.8.8.8,8.8.4.4 --dhcp-option-force=43,ANDROID_METERED --dhcp-leasefile=/sdcard/Download/Tether/dnsmasq.leases --pid-file=/sdcard/Download/Tether/dnsmasq.pid --listen-mark 0xf0063 & >/dev/null 2>&1

radvd -p /sdcard/Download/tmp/radvd.pid

iptables -t mangle -I POSTROUTING -o rmnet0 -j TTL --ttl-set 64
ip6tables -t mangle -I POSTROUTING -o rmnet0 -j HL --hl-set 64

[Mygod]

@worstperson So it seems like your POC uses ULA? Is there any advantage of doing this compared to simply using a 6to4 tunnel/IPv6 VPN?

(Ideally I would like to support global scope IPv6 tethering.)

[worstperson]

@Mygod It's GUA because it uses the address provided by the upstream provider. Without bypassing android's RA server, the device must connect to an IPv6 network for IPv6 traffic to flow, even if your using a dual stack vpn on the phone.

It would probably make more sense to use ULA in the context of VPNHotspot given that the socks server is limited to TCP/UDP. An interesting novelty to be sure, but I'm less sure it's worth implementing tbh.

[Mygod]

Is it GUA provided by local mobile carrier or by VPN? It sounds like the former, in which case how would it work? Outgoing packets go through the VPN but the incoming packets bypass the VPN?

[worstperson]

The rules take TCP/UDP traffic destined for a public address that would otherwise be forwarded and redirects them through a local transparent proxy. This proxy will use Android's primary internet source, which will be the VPN you have running. Doing this for IPv4 is only good for masking the TTL of traffic without a VPN. I only included it for completeness.

The address is provided by the mobile carrier in this case, controlling addresses Android gives out would have made the POC too complicated. You can use this command to drop RA packets from processes that are not root:
ip6tables -t filter -A OUTPUT -m owner ! --uid-owner 0 -p icmpv6 --icmpv6-type 134 -m hl --hl-eq 255 -j DROP
Then you can run your own dnsmasq or radvd service to provide addressing to clients to any arbitrary range.

The big difference is the POC allows traffic to leak. This allows incoming traffic and raw sockets, while still rewriting TTL for the vast majority of traffic, something of a compromise. To prevent leaking, you can use a rule like this:
ip6tables -t filter -I FORWARD -j DROP

I wrote up a prototype app one weekend to try an work out the details as best I could. The default server configurations bind to all addresses, we need to bind to the tether interface or localhost. I used localhost and that worked well in my tests. If you bind to the tether interface for greater compatibility, you have to be sure to kill the servers after as they do not handle their interface being removed. hev-socks5-tproxy can only be configured to one address at a time currently so I had to run two instances to cover both IPv4 and IPv6.

Replace AAAA:BBBB:CCCC:DDDD with the first half of your public IPv6 address(the one assigned by your carrier).

This was wrong. You actually take the prefix from the non-link-local address assigned to the tether interface.

[Mygod]

Okay that's cool and all, but ideally we want IPv6 addresses from the VPN provider so that things would work properly? 🤔

[worstperson]

It acts exactly like a NAT, the address/range is only needed locally for communication between the phone and clients tethered to it. An address being GUA/ULA only effects which protocol the tethered devices will default to. Once traffic gets redirected to the proxy, the packets get recreated on the phone, so it's like the traffic originated from the phone. You could also configure the proxy to only send outgoing traffic through the desired interface.

I think it would be most useful to use a ULA range so clients default to IPv4. Most traffic will travel as normal, but instead of failing if a client tries to access an IPv6 resource, the connection will instead be made through the proxy. Traffic will still exit through the VPN in both cases.

[Mygod]

Yeah but it sounds like maybe it is probably easier to just use a 6to4 tunnel instead, don't you think? 🤣

(Genuine question: do you have a concrete use case for IPv6 tethering?)

[worstperson]

I had read that the standard 6in4 tunneling protocol breaks when behind CGNAT and if I were to set it up on a phone IPv6 traffic would not go through the VPN, count as tethered traffic, and have high latency. (As far as I can tell from how brokers work and how that would need to be set up)

It is very rare that'd I find a host that's not dual-stack or IPv4-only, and the vast majority of users will never know or care. I honestly don't know why I'm still bothered by this. I use NAT6 on my devices, and when I do use VPNHotspot, the lack of IPv6 has really not been an issue. I posted this information because another user had requested it. I would have held on to it otherwise, until I could add the feature myself or find a better solution.

[elesbb]

Yeah but it sounds like maybe it is probably easier to just use a 6to4 tunnel instead, don't you think? 🤣

(Genuine question: do you have a concrete use case for IPv6 tethering?)

I'm not the original person this was asked to, but also am looking for IPv6 tethering. Reason why - gaming. I was always under the impression IPv6 has a much lower latency (ping) than IPv4. Especially on networks like T-Mobiles which is natively IPv6. So all IPv4 addresses have an additional step for converting to IPv6 and reverse.

[worstperson]

I'm not the original person this was asked to, but also am looking for IPv6 tethering. Reason why - gaming. I was always under the impression IPv6 has a much lower latency (ping) than IPv4. Especially on networks like T-Mobiles which is natively IPv6. So all IPv4 addresses have an additional step for converting to IPv6 and reverse.

This is sort of true on T-Mobile since they do not CGNAT IPv6. As long as you don't do any sort of NAT6 setup, tethered clients receive an IP and can forward ports and my tests show a bit more throughput and reliability over time versus IPv4.

But it is unlikely to be your issue. Not everyone has IPv6 and the game and platform must support it, so the vast majority of games are played over IPv4. If you were to host a game through that IPv6 connection, you'd probably have trouble enough finding other players that can connect.

What's more likely is that mobile internet just isn't the best, especially for gamers. The best solution I've found is to pipe all traffic though Google One VPN. Google has really good peering with mobile carriers and no other VPN I've tested came close to it's latency and throughput. It had also worked flawlessly with every game, console, and streaming platform I tried. But YMMV.

[elesbb]

I'm not the original person this was asked to, but also am looking for IPv6 tethering. Reason why - gaming. I was always under the impression IPv6 has a much lower latency (ping) than IPv4. Especially on networks like T-Mobiles which is natively IPv6. So all IPv4 addresses have an additional step for converting to IPv6 and reverse.

This is sort of true on T-Mobile since they do not CGNAT IPv6. As long as you don't do any sort of NAT6 setup, tethered clients receive an IP and can forward ports and my tests show a bit more throughput and reliability over time versus IPv4.

But it is unlikely to be your issue. Not everyone has IPv6 and the game and platform must support it, so the vast majority of games are played over IPv4. If you were to host a game through that IPv6 connection, you'd probably have trouble enough finding other players that can connect.

What's more likely is that mobile internet just isn't the best, especially for gamers. The best solution I've found is to pipe all traffic though Google One VPN. Google has really good peering with mobile carriers and no other VPN I've tested came close to it's latency and throughput. It had also worked flawlessly with every game, console, and streaming platform I tried. But YMMV.

Ah. Thanks for the awesome explanation! I did not realize games had to support the IPv6 protocol. I thought that was basically server/router dependent of the ISP.

In the long run, my gaming experience has not been that bad with my mobile hotspot. My ping in most games is 50-100. Rarely getting to the 100ms range. I truly don't physically notice any difference when on hotspot vs friends wifi despite seeing the ping numbers change.

I was more so thinking IPv6 would keep the ping closer to the 50ms region if not lower, but from what you are saying, may not even be the case. I also am unsure of if IPv6 is working when I remove all my mods, when I run a ping from my computer, it does not fetch the IPv6 address of the destination (google).

Thanks again for all the info. This has been a fun learning experience trying to bypass all the bs carriers do. I just don't understand how 40GB of hotspot data is any different than 40GB of cellular data lol