Mobile Network Operators (MNOs) serve the largest constituent of connected devices. There are over 4.6B GSM (and its derivatives) subscriptions today. When you add the CDMA family along with technologies with smaller footprints such as WiMax, IDEN to this list, that number tops 5B mark. On the other hand there are only (yes only!) 800M Internet hosts per ISC. Considering such a small percentage of those 5B or so devices are capable of being an Internet host and out of that percentage even a much smaller percentage is connected at a given time, one can understand the sheer potential of explosion in the number of Internet hosts as mobile devices in the next 3-5 years. In a world where Android based smartphones are being marketed for sub $100 already, it is a matter of 2-3 years to reach price figures that will allow almost anyone who wishes to have a phone that can be an Internet host (even permanently). By the way, this doesn’t count the potential of large scale deployments of “Internet of Things”.

These large number of hosts are why MNOs should be among the first to tackle the IPv6 transition. However, so far movement towards IPv6 has been quite nascent within the mobile world. Few operators such as Verizon, T-Mobile and Tus Mobile have indicated their preferences for different transition methods. However, there are more alternatives on the table and it is useful to analyze their relative strengths and weaknesses. 3GPP is developing a detailed Technical Report, TR 23.975 for this purpose.

As of the latest revision (1.1.1) of TR 23.975, there are 6 transition methods specified. Understanding the details of each of these methods will require reading the relevant IETF drafts or RFCs. Nevertheless, we can make an attempt to highlight each considered proposal:

1. A+P architecture: A+P stands for Address+Port. This architecture proposes to extend the IPv4 address space by overloading TCP/UDP port numbers to identify end devices. It allows multiple users to share the same IPv4 address similar to port translation but without the need for a translation operation. This requires restricting the allowed ports per user to a subset such that the same IP address can be shared among multiple users. Using A+P in mobile networks such as GPRS is easier compared to network topologies involving broadcast since end-to-end tunnel between a handset and a GGSN (P-GW) is no visible to any other network element. A+P is orthogonal to IPv6 deployment/transition, instead it is a mechanism to extend the lifespan of PAT while removing its disadvantages.
2. DS-lite: DS-lite stands for Dual Stack Lite. DS-lite is dependent on adoption of IPv6 as the networking technology within an ISP domain and allowing IPv4 traffic between dual stack hosts in customer premises and Carrier Grade NAT (CGN) devices at the ISP boundary over IPv6 tunnels. DS-lite lets IPv6 native traffic to pass unhindered. One of its significant advantages is reducing the need for unique private IPv4 addresses for each customer. Another benefit is the ability to deploy this solution with only over an IPv6 PDP context in a mobile network.
3. Stateless NAT64: Stateless NAT64 is dependent on adoption of IPv6 as the networking technology within an ISP doamin as well. It assumes that IPv6 hosts will communicate with IPv4 servers via a one-to-one translation (NAT) mechanism that is implemented at the ISP boundary, typically in a CGN. It is an update of Stateless IP/ICMP Translation Algorithm. Unfortunately it doesn’t the IPv4 address depletion problem, it suffers from IP address literals and inability to handle application like Skype, AIM, multi-party games that don’t have readily available IPv6 versions. Some of these problems can be solved by using double NATting (NAT46 in the host and NAT64 at the network boundary).
4. Dual stack: This is the original method of IPv6 transition where every host and router were expected to have both IPv4 and IPv6 capability. Unfortunately this sounds much easier said than done. I believe the last 15 years of inaction has been a good indication of the difficulty of this approach. Dual stack requires mobile devices to have both IPv4 and IPv6 PDP contexts, at least until the mobile network starts supporting a dual purpose one. This will be another capacity burden on the network.
5. NAT64 / DNS64: This is a minimalist approach that promotes the use of IPv6 only hosts. Based on this method, host only has an IPv6 stack and it communicates with IPv4 hosts via a NAT64 translation device at the ISP boundary. In order to direct the traffic to be translated, DNS64 is used. It provides a clear break with IPv4 legacy within the host and the ISP. Its major downside is the inability to deal with IP address literals in content and applications that don’t have IPv6 versions yet.
6. BIH: BIH stands for Bump In the Host. BIH can be considered as the double NAT option for NAT64. It resolves the lack of IPv6 versions of applications by performing a NAT46 within the host.

Looking at the IPv6 transition methods for mobile networks, few observations can be made:

• Double-NAT is a more complex solution compared to single-NAT from end-to-end perspective. That rules out BIH and (double) stateless NAT64 methods. Since single stateless NAT64 requires a public IPv4 address assignment for each mobile, it is not a realistic scenario.
• A+P reduces the incentive to migrate to IPv6 while requiring a significant capability upgrade in the user equipment. That substantial change as well as special treatment for ICMP and fragment handling restrict the applicability of A+P.
• DS-lite provides a benefit of needing only an IPv6 PDP context as opposed to dual stack approach. Until release 8 upgrades take place relying on PDP type IPv4v6 is not possible. Other major benefit of DS-lite is the elimination for the private IPv4 address space.
• For mobile devices without any IPv4 protocol stack, NAT64/DNS64 is the most viable option. It allows rapid transition to IPv6 while maintaining connectivity to IPv4 content servers via port-translation.

IPv6 transition is a much bigger beast than selecting a transition method. It requires an enterprise-wide effort. IPv6 transition will touch a lot of different parts of a mobile operator’s network, processes, tools, people. Until now mobile operators couldn’t justify spending money and effort to start offering IPv6 for their customers. This is primarily due to a fundamental lack of advantage (at least from the vantage point of an everyday customer of TCP and UDP applications) of IPv6 over IPv4. Similarly, for the operator cost of having an IPv4 network (even counting all the evils of NAT and renumbering due to limited address spaces, etc.) wasn’t substantially higher compared to operating an IPv6 network. However, with the looming depletion of IPv4 address space within the next 18-24 months, we anticipate there will be a cost differential.

Mobile network operators serving the biggest user community of the Internet must be at the forefront of this transition. Following is a set of recommendations for this transition strategy (excerpt from a white paper I just published. It can be downloaded from www.wirelesse2e.com as well as from scribd):

• For service/UE introduction in 2011-2012 timeframe, rely on dual stack while testing and potentially deploying DS-lite solutions. This will avoid any impacts due to IPv4 only applications or IP address literals in web content.
• For service/UE introduction beyond 2012, rely on single IPv6 stack while working with content and application providers to migrate them to IPv6. This will require deployment of NAT64/DNS64 solution for IPv4 content.
• Develop an IPv6 transition plan that would span 24-36 months. Start with small but quick wins such as building a test network, obtaining an IPv6 prefix, choosing and enabling a tunneling technology in the core IP network, etc. in 4-6 months. Aim for a commercial UE with IPv6 capability in 24 months after project start.
• Limit network changes to essentials. As an example, instead of a dual-stack strategy for handset web portals (which are declining in importance for mobile operator), use a load balancer based translation method to reduce the amount of network and host changes.
• Upgrade packet core network to support release 8 as early as feasible. This will provide option for IPv4v6 PDP context.
• Evangelize change to your roaming partners, back-office, enterprise system owners so that they start taking action.

Networking industry has been talking about IPv6 transition for the last 15 years. Unfortunately we can’t repeat what was done back in January 1st 1983 when Internet was transitioned from NCP to IPv4. At that time there were less than 500 hosts connected to the Internet according to Hobbes’ Internet Timeline. Network scale has grown about 1 Million times since 1983. Best thing we can do is to start acting on this transition. Time is now!