dslreports logo
 story category
T-Mobile Goes IPv6 Only on Android 4.4 Devices

T-Mobile and MetroPCS users with Android 4.4 KitKat will default to IPv6 only for connecting to the mobile network. The changes are present in Android code commit 4b3880d which changed the default access point name (APN) protocol to IPv6. IPv4 connectivity will be provided by a transition mechanism known as 464XLAT.

Click for full size
T-Mobile's transition to IPv6 started in 2010 when they launched a IPv6 friendly user trial (beta). The friendly user trial used a technology called DNS64/NAT64 which provided access to IPv4.

However, DNS64 does not work with IPv4 literals. The friendly user trial revealed lots of breakage with popular apps such as Skype and Netflix which use IPv4 literals in their applications.

To address the IPv4 literal problem with DNS64 and NAT64, T-Mobile’s Cameron Byrne co-authored a new standard known as 464XLAT. 464XLAT calls for a CLAT daemon to provide local IPv4 connectivity to the smartphone.

In Android 4.3 464XLAT was added, enabling T-Mobile to go IPv6 only in Android 4.4.
view:
topics flat nest 

Napsterbater
Meh
MVM
join:2002-12-28
Milledgeville, GA

Napsterbater

MVM

Nice

Nice to see some progress on IPv6. If only I lived in an area better served by T-Mobile.

fuziwuzi
Not born yesterday
Premium Member
join:2005-07-01
Palm Springs, CA

fuziwuzi

Premium Member

Re: Nice

It's also interesting since T-Mobile has a buttload of customers with phones that T-Mobile has neglected to update beyond ICS or even Gingerbread. Millions of devices stuck on generations-old Android versions thanks to T-Mobile.

Napsterbater
Meh
MVM
join:2002-12-28
Milledgeville, GA

Napsterbater

MVM

Re: Nice

Sadly that seems to be about par for the course with a lot of carriers, not just T-Mo.
cramer
Premium Member
join:2007-04-10
Raleigh, NC
Westell 6100
Cisco PIX 501

cramer

Premium Member

Re: Nice

Do you know how many different kinds of Android phones there are? If you want them all to run 4.4, you go make the thousands of builds. Which, btw, will involved a great deal of code tweaking to even come close to a runable image. Then answer the millions of complaints of how INSANELY SLOW it is -- if it'll run at all in such small RAM.

(I say this as one with an old Droid Eris running 2.3. It is completely unusable for anything real. I use it as an alarm clock.)

fuziwuzi
Not born yesterday
Premium Member
join:2005-07-01
Palm Springs, CA

fuziwuzi

Premium Member

Re: Nice

I'm referring to numerous models of phones that the manufacturer and other carriers did upgrade, but T-Mobile chose NOT to upgrade. There were many HTC phones that fell into the T-Mobile abyss. So don't go blaming Android.
MaynardKrebs
We did it. We heaved Steve. Yipee.
Premium Member
join:2009-06-17

MaynardKrebs

Premium Member

What happens if you roam on T-Mobile?

Example: Nexus 5 not bought through T-Mobile (say Wind Canada instead).
Does the Nexus 5 Kit Kat come with the IPv6 code change for ALL versions of the Nexus 5 for all markets?

whfsdude
Premium Member
join:2003-04-05
Washington, DC

whfsdude

Premium Member

Re: What happens if you roam on T-Mobile?

said by MaynardKrebs:

Example: Nexus 5 not bought through T-Mobile (say Wind Canada instead).
Does the Nexus 5 Kit Kat come with the IPv6 code change for ALL versions of the Nexus 5 for all markets?

The APN list is for the Android AOSP version. Unless a carrier were to rip out the default APN list, it's there as a default.

scheming
@verizon.net

scheming

Anon

Re: What happens if you roam on T-Mobile?

Incorrect. Although there are default APNs, carriers typically use APNs provided over the air to the SIM card to set up the device's Internet bearer. Like the title states, "**T-Mobile** Goes IPv6 Only on Android 4.4 Devices"

beluga
@viagenie.ca

1 recommendation

beluga

Anon

Re: What happens if you roam on T-Mobile?

because only Android 4.4 devices have the updated APN list in the configuration folder. Android does not support Over The Air configuration by the carrier for APNs.

tshirt
Premium Member
join:2004-07-11
Snohomish, WA

tshirt

Premium Member

This is terrible!!!

I understand it's a limited cpu, ram , and network stack, but dropping v4 (ie NOT native dual stack) is sure to cause outages/PANIC under some circumstances.
There is some time before ONLY v6 is a good idea.

whfsdude
Premium Member
join:2003-04-05
Washington, DC

1 recommendation

whfsdude

Premium Member

Re: This is terrible!!!

The big issue is T-Mobile can't get the IPv4 address space needed. Unlike the other big three, they have no large legacy IP address blocks to use. They are using squat space in their v4 network currently and multiple layers of NAT. That'll be problematic shortly when the squat space is allocated.

Edit: Just to clarify, the end-host will have access to v4 resources via a transition mechanism. Still a very bold move.
mdpeterman
join:2010-10-10
Pflugerville, TX

mdpeterman

Member

Re: This is terrible!!!

T-Mobile just got a /10 allocation from ARIN last year. I'd think those 4 million addresses would be enough for traditional NAT use on their network. Lets say 25% of those are used for NAT purposes they still should be able to get well over 100 million devices on a network with that many public IPs.
34764170 (banned)
join:2007-09-06
Etobicoke, ON

34764170 (banned)

Member

Re: This is terrible!!!

said by mdpeterman:

T-Mobile just got a /10 allocation from ARIN last year. I'd think those 4 million addresses would be enough for traditional NAT use on their network. Lets say 25% of those are used for NAT purposes they still should be able to get well over 100 million devices on a network with that many public IPs.

It's not as if old phones are going to go away. They will still need "traditional NAT" for those devices. But it's about time they move forward and make further progress for v6 roll out. What they've done is the ultimate end game. If you have an Android 4.3/4.4 device or anything else supporting 464XLAT/RFC 6877 they might as well push users in that direction. The end users won't notice the difference.

j1349705
Premium Member
join:2006-04-15
Holly Springs, NC

1 recommendation

j1349705 to tshirt

Premium Member

to tshirt
I'm pretty sure you can still add a dual stack or IPv4 only APN manually if still needed.

However, if the transition mechanisms they have in place really work properly, IPv6 only should be OK for most people. T-Mobile customers are already behind NAT for IPv4 so its not like customers are suddenly losing public IPv4 addresses (actually VZW also uses NAT when connected to LTE... not sure about the others).

I tried T-Mobile's IPv6 only DNS64/NAT64 network a year ago... it mostly worked, except for the mentioned IPv4 literal issue. If that is fixed, there's no reason for the average customer to worry about having a dual stack configuration.

Personally, I'm glad to see more aggressive IPv6 deployments. Somebody has to make aggressive moves or the transition will never happen. Many popular web sites now are accessible over IPv6, but there is still a long ways to go.
34764170 (banned)
join:2007-09-06
Etobicoke, ON

34764170 (banned) to tshirt

Member

to tshirt
said by tshirt:

I understand it's a limited cpu, ram , and network stack, but dropping v4 (ie NOT native dual stack) is sure to cause outages/PANIC under some circumstances.
There is some time before ONLY v6 is a good idea.

Try understanding what has been said in the post. Support for accessing v4 only sites has not been dropped.

tshirt
Premium Member
join:2004-07-11
Snohomish, WA

tshirt

Premium Member

Re: This is terrible!!!

Yes, I read that, and that consumers trying to reach v4 addresses will have to rely on a v6 to v4 DNS redirection translator.
All good if it works perfectly, is secure, and T-mo finds no reason to "adjust" the DNS results.
would you be as trusting if it were AT&T, or verizon "HELPING" you?
Being forced into it, because your provider failed to secure enough v4 addresses or because the existing DNS64 fails, is different then CHOOSING to embrace a new methodology.

evilphi
@comcast.net

evilphi

Anon

Re: This is terrible!!!

It's more like T-mobile was forced into doing this due to lack of IPv4 addresses. They didn't "fail" to get more IPv4, there simply isn't any more to get. The majority of users get new devices annually, so this will quickly alleviate long-term IPv4 pressure. In other words, this will make it possible for T-mobile to support legacy (IPv4-only and non-464XLAT) devices much longer.
34764170 (banned)
join:2007-09-06
Etobicoke, ON

34764170 (banned) to tshirt

Member

to tshirt
said by tshirt:

Yes, I read that, and that consumers trying to reach v4 addresses will have to rely on a v6 to v4 DNS redirection translator.
All good if it works perfectly, is secure, and T-mo finds no reason to "adjust" the DNS results.
would you be as trusting if it were AT&T, or verizon "HELPING" you?
Being forced into it, because your provider failed to secure enough v4 addresses or because the existing DNS64 fails, is different then CHOOSING to embrace a new methodology.

v4 address space doesn't grow on trees and isn't limitless. A lot of mobile providers are already using NAT which is a shit show. It's time things move forward.

scheming
@verizon.net

scheming

Anon

Meh.. only affects cellular data

This is only going to affect cellular data connections. Your WiFi connections will be what they already are so who cares. More companies should support IPv6
openbox9
Premium Member
join:2004-01-26
71144

1 recommendation

openbox9

Premium Member

Re: Meh.. only affects cellular data

said by scheming :

so who cares.

Consumers using T-Mobile's services? If T-Mobile's translation works correctly, I'd imagine most people won't know, or care. If not done seamlessly, I imagine you'll have T-Mobile customers complaining.
34764170 (banned)
join:2007-09-06
Etobicoke, ON

34764170 (banned) to scheming

Member

to scheming
said by scheming :

This is only going to affect cellular data connections. Your WiFi connections will be what they already are so who cares. More companies should support IPv6

And? You have to start somewhere. It's all kinds of steps from all angles that add up over time to get us to the end goal. Android already supported v6 for Wifi, but one big bug that needs to be fixed is v6 only Wifi connections which pathetic as it is is not an issue for iOS / OS X / Windows / Windows Phone / other Linux based OS's.

Da Geek Kid
join:2003-10-11
::1

Da Geek Kid

Member

VoIP chat.

not sure if my Callcentric would work over LTE. It'd be interesting...
broccoli
join:2007-11-29
Portland, OR
Draytek Vigor2860Vac
EnGenius EAP600
Obihai OBi100

broccoli

Member

NAT64 breaks VPN

I have been using T-Mobile's dual stack setup for about 6 months, and there is one big problem that I cannot live with: when I try to connect to VPN endpoints that do not have IPv6 addresses, T-Mobile's DNS server hands out fake IPv6 addresses that go nowhere. I have to use third-party DNS servers to get around this problem.
34764170 (banned)
join:2007-09-06
Etobicoke, ON

34764170 (banned)

Member

Re: NAT64 breaks VPN

said by broccoli:

I have been using T-Mobile's dual stack setup for about 6 months, and there is one big problem that I cannot live with: when I try to connect to VPN endpoints that do not have IPv6 addresses, T-Mobile's DNS server hands out fake IPv6 addresses that go nowhere. I have to use third-party DNS servers to get around this problem.

They're not fake IPv6 addresses that go nowhere. They're synthesized DNS records provided via DNS64. The traffic sent towards these addresses is translated via NAT64 and sent towards the IPv4 address at the other end.
broccoli
join:2007-11-29
Portland, OR
Draytek Vigor2860Vac
EnGenius EAP600
Obihai OBi100

broccoli

Member

Re: NAT64 breaks VPN

said by 34764170:

They're not fake IPv6 addresses that go nowhere. They're synthesized DNS records provided via DNS64.

A hostname resolves to something other than its official A record or AAAA record. To me that's a fake address.

The end result is the VPN session fails to be established. That's what I mean by 'going nowhere'.
broccoli

broccoli

Member

Re: NAT64 breaks VPN

Until now I haven't taken the effort to look into the root cause of my difficulties using VPN under NAT64, but it seems that there is no provision for it to work at all, at least for now.

RFC 6146:

The current specification only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. Multicast packets and other protocols, including the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), and IPsec, are out of the scope of this specification.

(bold emphasis are mine)

IPsec and PPTP use IP protocols (ESP: 50; AH: 51; GRE: 47) that are not covered by NAT64.
34764170 (banned)
join:2007-09-06
Etobicoke, ON

1 edit

1 recommendation

34764170 (banned)

Member

Re: NAT64 breaks VPN

said by broccoli:

)
IPsec and PPTP use IP protocols (ESP: 50; AH: 51; GRE: 47) that are not covered by NAT64.

If you're using IPsec properly it is UDP. Otherwise you're doing things wrong and good luck when using NAT even if its not NAT64. Good luck using these protocols too when ISPs start using CGN.

Frits
@chello.nl

Frits to broccoli

Anon

to broccoli
Broccoli,

You should be aware that the world goes to IPv6-only eventually. So you'd better make sure that your VPN service can be reached over IPv6.
broccoli
join:2007-11-29
Portland, OR
Draytek Vigor2860Vac
EnGenius EAP600
Obihai OBi100

1 edit

broccoli

Member

Re: NAT64 breaks VPN

IPv6 is not the problem. NAT is the problem. Also T-Mobile's existing NAT for IPv4 works OK so I don't see why we need NAT64. At least make it optional (implement using different APNs, for example).

Also, whether a particular VPN is IPv6 capable or not could be out of the user's control. I can't just find another job because my employer's VPN has no IPv6 support.
34764170 (banned)
join:2007-09-06
Etobicoke, ON

34764170 (banned) to broccoli

Member

to broccoli
said by broccoli:

said by 34764170:

They're not fake IPv6 addresses that go nowhere. They're synthesized DNS records provided via DNS64.

A hostname resolves to something other than its official A record or AAAA record. To me that's a fake address.

The end result is the VPN session fails to be established. That's what I mean by 'going nowhere'.

Read up on what DNS64 is. You're just showing ignorance.
broccoli
join:2007-11-29
Portland, OR

broccoli

Member

Re: NAT64 breaks VPN

I know exactly what DNS64/NAT64 trying to do. It's an ugly hack that works, sometimes.
34764170 (banned)
join:2007-09-06
Etobicoke, ON

34764170 (banned)

Member

Re: NAT64 breaks VPN

said by broccoli:

I know exactly what DNS64/NAT64 trying to do. It's an ugly hack that works, sometimes.

Trying to provide v4 in a legacy environment is ugly and it'll just get worse; NAT is ugly. Get used to it.

j1349705
Premium Member
join:2006-04-15
Holly Springs, NC

j1349705 to broccoli

Premium Member

to broccoli
This might not be an issue on Android 4.4 and later. The new 464XLAT mechanism might work around the issues you have been seeing. Unfortunately I don't have an Android 4.4 device yet to test this theory with.

Once the Nexus 4 KitKat update is released, I'll swap my SIM back into it from my Galaxy S4 (purchased for WiFi calling feature) and test a few types of VPNs. I will also be interested to see how well SIP works under this configuration.

More interesting info: »sites.google.com/site/tm ··· /464xlat

Acuity
join:2002-06-22
Londonderry, NH

Acuity

Member

I've Been On KitKat...

I was kind of surprised to see this. I've been on KitKat since the evening of Halloween and I still had an IPv4 address. I went into my APN settings and changed APN protocol from IPv4 to IPv6, rebooted and now I'm IPv6.

TL;DR: When you update you'll probably still be on IPv4 unless you change it manually.

whfsdude
Premium Member
join:2003-04-05
Washington, DC

whfsdude

Premium Member

Re: I've Been On KitKat...

said by Acuity:

TL;DR: When you update you'll probably still be on IPv4 unless you change it manually.

Correct, this is the default APN. Upgrading doesn't reset the APNs to defaults.