T-Mobile's journey to IPv6

> 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: * this video * link Lots of folks are probably IPv6-only without realizing it.

> All mobile clients are behind CG-NAT. Demonstrably false. T-Mobile US mobile clients are IPv6-only and connect via IPv6 to IPv6 sites: * this 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.

> 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: * this video * link

> 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: * this 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

> 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": * this 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.

> 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.

> 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.

> 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

> 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

> 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).