Good videos, with context.
T-Mobile's journey to IPv6

T-Mobile's journey to IPv6

NANOG
0 HN recommenders · discussed 2022–2026
Open YouTube ↗

About this video

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.

Why it appears in the archive

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

AI-generated summary and labels from the source dataset; verify important details against the video. Source & credits.

From the Hacker News discussion

throw0101a · 2022-06 · reference

> Anyone running v6 only and bridging to v4 on the edge? If you are on T-Mobile USA you are IPv6-only on your mobile device: * [VIDEO] * [LINK] Lots of folks are probably IPv6-only without realizing it.

Read original comment ↗
throw0101c · 2022-12 · reference

> All mobile clients are behind CG-NAT. Demonstrably false. T-Mobile US mobile clients are IPv6-only and connect via IPv6 to IPv6 sites: * [VIDEO] * [LINK] NAT is only used to connect to IPv4-only hosts via DNS64 (with or without 464XLAT). As of 2022Q2, T-Mobile US has 110 million customers: * [LINK] One-third of the US population is connecting via IPv6-only on a day-to-day, hour-to-hour basis every time their smartphone reaches out over the radio.

Read original comment ↗
throw0101b · 2023-04 · reference

> T-Mobile and Verizon both use CGNAT (but do issue individual ipv6 addresses to end user devices). More specifically, T-Mobile US only assigns IPv6 addresses to devices, and to reach the IPv4 world you have to go through a translation mechanism. Presentations from T-Mobile at NANOG and Rocky Mountain IPv6 Taskforce: * [VIDEO] * [LINK]

Read original comment ↗
throw0101a · 2025-11 · reference

> Isn’t essentially the entire US on CG-NAT for IPv4 on mobile data? T-Mobile, for one, has had their handsets IPv6-only for a few years, so if your Android/iOS does a DNS lookup and gets an AAAA record back, it will skip CG-NAT. T-Mobile presenting at NANOG in 2018 on IPv6: * [VIDEO] And Rocky Mountain IPv6 Taskforce in 2017: * [LINK] Further data: > Chances are if you use the Internet on your smartphone, you are connecting via IPv6. According to the Internet Society’s 2018 State of IPv6 Deployment,[1] 80% of smartphones in the US on the major cellular network operators use IPv6 and major mobile networks are driving IPv6 adoption with Verizon Wireless at 84%, Sprint at 70%, T-Mobile USA at 93%, and AT&T Wireless at 57%. Plus, some mobile networks are taking the step to run IPv6-only to simplify network operations and reduce costs. * [LINK] Though some folks aren't happy with the implementation: > But from my own experience, neither T-Mobile nor AT&T allows inbound traffic to the phone's IPv6 address. This negates some of the advantages of having a globally routable IPv6 address. * [LINK]

Read original comment ↗
throw0101c · 2025-12 · reference

> This is the only real reason in my opinion, why IPv6 is doomed to be second-grade citizen for (probably) a few more decades. Except if you're using a mobile phone, in which case many telcos hand out only IPv6 addresses to handsets. 2018 NANOG presentation "T-Mobile's journey to IPv6": * [VIDEO] From 2014, "Case Study: T-Mobile US Goes IPv6-only Using 464XLAT": * [LINK] But who cares about mobile phones, right? They're only second-grade devices.

Read original comment ↗
throw0101c · 2026-04 · reference

> 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): * [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.

Read original comment ↗
throw0101d · 2026-04 · reference

> 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: * [VIDEO] But sure, be IPv4-only and add latency by forcing traffic through an extra translation box.

Read original comment ↗
throw0101d · 2026-04 · reference

> 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: * [VIDEO]

Read original comment ↗