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 207.155.253.5).
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
No comments:
Post a Comment