Another year and another heralding of IPv6 – 2013, the year where IPv4 addresses finally ran out and IPv6 becomes mainstream - perhaps. Despite the skepticism, there are genuine reasons why this year could see your new shiny smartphone on an IPv6 network and for mobile operators at least, for the next few years migration from IPv4 is more pressing than deploying SDN.
It comes down to a twist on the original reason we were supposed to move to IPv6 – the lack of new IPv4 addresses to handout to newly minted smartphones.
By the time mobile operators came around to enabling IP networking for mobile devices, most public IPv4 addresses had been gobbled-up by the fixed-line world. But instead of jumping into the brave new world of IPv6, mobile operators punted - instead issuing “private” IPv4 addresses to customers. That is, addresses that can only be used on internal networks and are not valid on the global Internet. This worked because mobile operators then purchased Carrier-grade network address translation (NAT) gateways from the likes of Cisco and Juniper, which mapped many individual private IPv4 addresses to one public IPv4 address, just like the Wi-Fi/ADSL router in your home, but for millions of devices. In this way, the scarce public IPv4 address space has been used efficiently and the industry has been saved from making the IPv6 leap.
Sweetening the deal, an unintended security benefit came to pass. By deploying NAT in the carrier network, it’s as if your smartphone doesn’t really exist on the public Internet unless the smartphone itself makes a connection. So unlike your fixed line connection with a public IPv4 address, where anyone at anytime can reach your device and attempt to break-in, your smartphone is inherently secure from unsolicited traffic. Don’t get me wrong, you might still catch viruses from email, install rouge applications and the like, but your phone is shielded from the daily exposure of having a device on the internet.
So did procrastinating on IPv6 work or is there a sting in the tail?
It turns out there are limits to the number of private IP addresses that can exist on the same private network. That number is shy of 22 million addresses (which includes an additional 4 million, added for carrier-grade-NAT applications in 2012). There is a growing club of mobile operators who have way more than 22 million “always on” IP subscribers and they face some pretty stark choices: They can break-up the network into areas, reusing the same address space by city or region; they can unofficially “borrow” IPv4 addresses not currently being deployed in the real world, run them on their private network and hope they never show-up on the public internet (at least one major US operator has been doing this); or they can migrate to IPv6. Pick your poison.
The “break-up your network into regions and reuse the same address space” solution has been gaining the most traction, with operators pooling users into groups of 4 million. So, in a network of 40 million customers, this means that 10 customers will share the exact same IP address at the same time. This creates headaches for wiretap requirements, back-end analytics systems and cross network traffic routing between subscribers (how many NAT hops is too many?). Further, as smartphone users today have more active applications running on their smartphone (talk+map+messaging+game) and enable them as hotspots, this places extra processing burdens (read financial costs) on scaling NAT.
Cynically perhaps, the end game for IPv4 was only ever going to come when we simply ran out of runway, when staying with IPv4 became too painful, making IPv6 deployment the only way forward. Writing one more check for yet more NAT gateway equipment has become like buying another “final” bottle of Jack for your deadbeat Uncle – we all know that an intervention is the only way forward but are waiting for something dramatic to go wrong first.
It is not as if the industry hasn’t been working behind the scenes to get ready – most RFPs, most equipment specifications have required IPv6 native support for years now. However, it was expected that our devices would run both IPv4 and IPv6 in “dual-stack” mode that would ease the path to an IPv6-only world. The Mac on which I type this is busy searching (in vain) for an IPv6 network, as it communicates in IPv4.
The implications for hitting the NAT wall are startling though – you really can’t hand out another IPv4 address, private or public. The switch to IPv6, at least for new customers and new devices must be absolute. No IPv4 address for your new smartphone. For many operators reaching these IPv4 scaling limits, the transition point to IPv6 is likely to be alongside LTE and/or VoLTE deployment, as these technologies represent a natural transition and technology shift in the network. This will also ensure plenty of time for testing.
So can you deploy an IPv6-only mobile network and will users notice? Well yes and no. The challenge is to make the network transparent to applications and services and there are two critical locations in the network where this will play out. First, those Carrier grade NAT gateways now have to translate between the IPv6 world of your network to the public IPv4 world – you’ve solved the scaling challenge but the rest of the world needs to catch-up and until it does, this forms the connection to any public website or service not operating in IPv6.
Second, and something of a larger challenge is that the handset/smartphone itself needs to provide the appearance of having IPv4 when it doesn't or alternatively force all applications on the handset to be IPv4/IPv6 agnostic. Operators sometimes forget that while they can mandate handset manufacturers and equipment vendors to comply with their specifications, application vendors live outside this realm. A popular app that breaks on an IPv6 only network will cause support complications and user frustration.
A way around this is to bring NAT inside the phone itself and for any application that needs to think it is on an IPv4 network to provide a private address that is translated to IPv6 in the phone. Such a method exists – at least in draft in draft-mawatari-v6ops-464xlat. Example code has already been written for Android and inclusion in new smartphones would go a long way in smoothing the IPv6 transition. Notwithstanding, application vendors, with a little prodding from the likes of Apple and Google must be encouraged not to hardcode IP addresses into their software but to use domain names (so www.kirinsolutions.com, not 184.108.40.206). As a consequence, the first operators that make the IPv6 only transition are likely to go through a few application challenges in the first 3-6 months of operations as consumers.
Finally, let’s go back to the security benefit of all the NAT currently going on in the IPv4 world. When you smartphone shows up with a public IPv6 address, it becomes accessible to the outside world, just as your ADSL gateway is at home on IPv4. Your ADSL gateway likely has a firewall and it’s own NAT functionality to protect your PCs and wireless LAN connected devices from the big bad Internet. Handset manufacturers and operators are going to have to think carefully about what level of exposure this represents. Operators may well need to provide a firewall service in the network to afford the same level of protection, now delivered through NAT.
For an example of 464xlat on a phone see: https://sites.google.com/site/tmoipv6/464xlat