My telco in Singapore (M1) was providing IPv6 service on their cellular dataplan if you knew how to configure your phone. The trick on Android was to change your service type to “LTE/3G/2G” and set the APN protocol to “IPv4/IPv6.” On iPhone no special settings were required – it just worked. In the United States, my service from AT&T includes IPv4 and IPv6 with no configuration required – it just works out of the box. They allocate a /64 block for every phone. My phone currently has block 2600:380:b0d0:f919::/64 allocated. Note that with AT&T I can see both Wi-Fi and dataplan IPv6 addresses at the same time.
It is a bit tricky to find your mobile IP addresses on iOS – get the HE.NET app from the App Store (shown in the following). In Android the Network Info II app allows you to see IPv6 addresses. I will show examples of this later.
Android
The IPv6 address 2401:7400:6000:93d9:1:1:9366:9705 is configured on my phone, along with the private IPv4 address 10.194.78.202. The external public IPv4 address is 246.106.56.119. Note that on Android, if the Wi-Fi configures an IPv6 address, no additional IPv6 addresses are configured on the dataplan. This screenshot required disabling the Wi-Fi. Note that on my ISP, if the phone goes to sleep, it will keep the same /64 prefix when it wakes back up. If I reboot, I get a new /64 prefix. Your mileage may differ.
A screenshot of a mobile depicts the network I P address. It has 3 parts. One gives network info, and the other 2 parts give the interface, device, wifi, B T, and location information of the phone.
Network IP address allocation on Android
A screenshot of a mobile phone depicts the result of i p v 6 test of android phone. It has 2 parts. One is for I P v 4 connectivity and the other is for I P v 6 connectivity.
IPv6test.com test of IPv6 on Android
iPhone
An image of a mobile screen depicts its interface information. It depicts the information about A P 1, A W D L 0, E N 0, E N 1, and E N 2.
IP address allocation on iPhone 7 using HE network application
A photo of a mobile screen depicts its interface information. It depicts the information about I P S E C 1, I P S E C 2, L O 0, P D P I P 0, and P D P I P 1.
Rest of IP allocation info on iPhone 7
On the Wi-Fi interface, a link-local IPv6 address and two global IPv6 addresses have automatically configured.
On the dataplan (cellular data), another link-local IPv6 address and two more global IPv6 addresses have automatically configured.
A screenshot of a mobile phone depicts the result of i p v 6 test of i phones. It has 2 parts. One is for I P v 4 connectivity and the other is for I P v 6 connectivity.
Ipv6-test.com site on iPhone 7
On Android, if there is an IPv6 address on Wi-Fi, any IPv6 address on the dataplan is ignored. On iOS, it will configure IPv6 from both Wi-Fi and dataplan, but if there is an IPv6 Wi-Fi address available, connections will use it rather than the dataplan address.
What Are the Implications of This?
For the first time ever since Internet access has been available on mobile devices, there are finally public IP addresses for mobile devices. That is a major game changer. Up until now, all IP addresses on mobile devices have been private (RFC 1918) addresses, behind NAT (in some cases, behind multiple layers of NAT, with CGN). That means you can only make outgoing connections from your mobile device to nodes with public addresses, typically servers at telcos, ISPs, large content providers, etc. There is no way for external nodes to make connections to your phone. So the only apps you can get or run on your phone are clients.
Now, with IPv6 on mobile devices, you have public IP addresses (accessible only by IPv6 users, but definitely public addresses). These addresses can not only be used for outgoing connections; they will also accept incoming connections, from any IPv6 node in the world (unless the ports involved are blocked somewhere along the way). You can now run servers (FTP, web, email, LDAP, etc.) on your mobile device. If you publish this address in DNS, anyone you allow can connect to those servers.
This also opens up the possibility of end-to-end direct connections: straight from my node to yours, with no intermediary server between us. The Second Internet (using IPv4 with NAT) forces us to use intermediary servers running on nodes with public addresses. If I want to chat with you, with IPv4 I cannot make a connection directly to your node; we both have to make outgoing connections to some intermediary server (XMPP and so on). That server then relays messages back and forth between our two outgoing connections. If the connections are secured by TLS, the messages will be in plain text on that intermediary server. Most snooping takes place on intermediary servers, not in transit between end users and the server. You can achieve end-to-end privacy and sender-to-recipient authentication with S/MIME, but that requires all parties to have mutually trusted client certificates and a PKI to manage them. S/MIME is primarily for email, although I have made it work over FTP as well. I don’t know of any chat protocol that supports S/MIME currently, although in theory it could be done (not with XMPP).
With end-to-end direct messaging, there is only one link involved and no intermediary server(s). In this case, TLS is actually end to end. If both ends use a client cert, this approach achieves strong mutual authentication (we both know for certain who the other party is) and end-to-end privacy. I call this PeerTLS. Messages are encrypted in my node and decrypted in yours. Most people are not aware that TLS can work with a client cert at both ends, but I have verified that it works great. When I message you, I am not really interested in verifying your nodename; I want to know your identity (in other words the information in your client cert, not in a server cert). Note that this will work over IPv4 but only within a private Internet (e.g., your company LAN) – it cannot cross a NAT gateway. With IPv6, there are no NAT gateways, so assuming port 4605 is open from my node to yours, my node can connect directly to yours, regardless of where we are in the world.
Note that decentralized messaging uses existing protocols, just implemented in an end-to-end model, using PeerTLS. This has been tested with chat, email (SMTP), file transfer (FTP), and VoIP (SIP/RTP). With this model, every user has both a client and a (personal) server running on their node (even on a phone). There is no need for a centralized intermediary server (or an account from an ISP or telco). Anyone can exchange messages directly with any other user (assuming both have IPv6). This provides true end-to-end encryption (only one link is involved) and mutual strong authentication (both parties know for certain who they are communicating with). This may be one of the biggest wins of the migration to IPv6.
This is 5G-style decentralized messaging, not possible on the Second Internet because of NAT.
Decentralized Messaging
As long as there is network connectivity between our nodes, it doesn’t matter if our connection to the Internet is up or not. For comparison, even when I'm chatting with the person next to me on Skype, if the ISP connection goes down, the chat stops.
The speed of the connection is limited only by the bandwidth on the shortest network path between us.
Traffic never leaves the shortest network path between us, although that could involve going to our ISP if the other party is not local.
PeerTLS with both ends using a client cert provides strong mutual authentication in addition to end-to-end encryption.
You are not dependent on any intermediary servers being up and running or having an account on them (you will need an IRP account if you want to publish and obtain IP addresses and/or client certs for other parties, but the messaging traffic does not go through this path).
No one but the parties communicating have any control over the message content.
It is very difficult for anyone to snoop on decentralized connections, especially if they are encrypted end to end – there can be no man-in-the-middle attack if there is no “middle.”
Summary
IPv6 deployment is very far along with mobile service providers, as there are major and obvious benefits over trying to splice together many IPv4 10.x.x.x subnets. The largest IPv4 subnet is only a /8, which provides some 16 million private IP addresses. Most mobile service providers have many more than 16M subscribers. With IPv6, a single subnet can provide /64 blocks for every subscriber with no problem.
If you check on your phone today (and you may need to download an application, like Network Info II on Android or HE.NET on iPhones), you can see the IPv6 addresses on your phone. Even without those applications, if you surf to https://ipv6-test.com , you can see whether you have IPv6 today. Most of the people reading this probably already do have it. For mobile device users, the future has already arrived.
If your Wi-Fi supports IPv6, both Android and iOS phones can get IPv6 over Wi-Fi, in addition to over your dataplan. If your service provider is not currently providing IPv6 for some reason, but you have IPv6 running in your local subnet, you can still connect to nodes in the Third Internet via Wi-Fi.
This is one of the most exciting areas of IPv6 deployment. For the first time since phones were given access to the Internet, they now can get public IP addresses. I’m already pioneering several aspects of this, including direct end-to-end connections and PeerTLS.