In the last post we have looked at the rapid depletion rate of IPv4 addresses and how that is manifesting itself as another capacity crunch for mobile networks.
In this post, I’d like to go into further detail on various IPv6 transition strategies, their applicability for mobile networks and the most likely paths. Few operators such as Verizon, T-Mobile and Tus Mobile have indicated their preferences for different models. 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. I’d recommend to download and read the latest version. A final version will come out as part of release 10.
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:
- 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.
- 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.
- 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).
- 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.
- 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.
- 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. Network scale has grown about 1 Million times since 1983. Best thing we can do is to start acting on it. Time is now!