T-Mobile's journey to IPv6

What people said

throw0101a · 2026-06 · Reference

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

Read the original HN comment ↗

throw0101a · 2026-06 · Reference

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

Read the original HN 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 the original HN comment ↗