HackerTube

T-Mobile's journey to IPv6

NANOGCited 10× on HN, 2022–2026
YouTube
talk · advanced · 2022–2026 on HN

Stephan Lagerholm of T-Mobile explains at NANOG how T-Mobile turned off IPv4 for over 10 million handsets using DNS64 and related technologies. He shares advice on finding and handling broken applications.

Cited as the primary source for T-Mobile US running IPv6-only mobile clients in IPv6 adoption debates.

10 comments from Hacker News

@throw0101a2026-06 · in “Google Hits 50% IPv6”

> Meanwhile T-Mobile/Odido in the Netherlands is still not supporting IPv6 despite promising to have been working on it for years. While T-Mobile US has been IPv6-only since ~2018: * ▶ this video

@throw0101a2026-06 · in “Google Hits 50% IPv6”

> NAT / CGNAT has been doing the heavy lifting extending the life of the Internet; ipv6 has done jack shit. Given they made the transition to IPv6 on handsets, T-Mobile US, which has 140 million subscribers, would disagree: * ▶ this video > As for telco addressing handsets, they could use any addressing scheme to be honest. When people talk about averting address exhaustion, they're not talking about internal addressing of networks, different problem altogether. I'm sure if T-Mobile US thought they could, they would have: > T-Mobile in the United States was running out of IPv4 addresses and needed an IPv6 transition strategy. Their solution was 464XLAT and IPv6-only. * link Similarly Comcast rolled out IPv6 because they ran out of addresses for managing their CPE modems using TR-069: they were using 10/8 multiple times over , and it was too much of a hassle so they went to IPv6 (both internally and to their customers).

@throw0101c2026-04 · in “Why IPv6 is the only way forward”

> IPv6 feels like we just can't admit to ourselves that it has been a failed transition. What would it take to come up with IPv7 which takes in the lessons of IPv6 and produces something better that we can all agree is worth transitioning to over IPv4. Per Google, quite a few countries (including the US) are at >50%: * link Every handset on T-Mobile US's network gets IPv6 (and they're not the only carrier like that): * ▶ this video So I'm not quite sure where "failed" enters the equation. And what exactly would be different with IPv7? Anything that needs more address bits would have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A7" address (for "IPv7" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.) You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.

@throw0101d2026-04 · in “IPv6 Traffic Crosses the 50% Mark for the First Time”

> Outdated beliefs probably. When I talk about v6 support in our b2b saas, PM laughs and says nobody uses that shit. Nobody except the 140M subscribers on T-Mobile US's network: * ▶ this video But sure, be IPv4-only and add latency by forcing traffic through an extra translation box.

@throw0101d2026-04 · in “IPv6 Traffic Crosses the 50% Mark for the First Time”

> They've been requiring that iOS apps work on IPv6-only networks for close to 10 years now This was at the behest of mobile network. E.g., T-Mobile US has 140M subscribers, and moved to IPv6-only many years ago: * ▶ this video