SK Telecom (SKT) provides mobile services to over half the population of South Korea — that’s 30 million of the economy’s 50 million people. Unsurprisingly, SKT has felt the pinch of IPv4 depletion, particularly when LTE (with 23 million subscribers) and 5G terminals can consume two or more IP addresses.
With such a demand for IP addresses, and a suite of new services being released, including 5G, IPTV, OTT, music, and IoT, making the move to IPv6 was imperative.
Speaking at APRICOT 2019, Hanwoong Lim of SK Telecom gave an in-depth presentation of SK Telecom’s IPv6 deployment. He discussed the company’s rationale for rolling out v6, their architecture, and the challenges that such a large deployment presented.
Figure 1 — SK Telecom LTE subscribers and ICT portfolio.
Hanwoong says that for SKT, scalability and future preparedness are very important, especially since SKT anticipates that 5G will enable the future expansion of IoT and edge computing.
The state of IPv6 at SKT
SKT are now using IPv6 for all LTE subscribers, and approximately 60% of the traffic on their network is IPv6. This is the highest rate in South Korea, and ranks them highly among networks globally.
Figure 2 — APNIC IPv6 statistics for South Korea, grouped by ASN, ordered by IPv6 Capable.
Figure 3 — IPv6 users per provider. Source: Internet Society.
Architecture and challenges
The SKT LTE network consists of access and core layers, where the Packet Gateway (PGW) resides. PGW assigns IPv6 addresses to User Equipment (UE) in the mobile network, enabling pure IPv6 communication with the outside Internet.
Hanwoong adds that, “in reality, Internet services and some content providers don’t offer IPv6. So, we use standards-based technology, RFC 6877 464XLAT, to ensure 100% service even in such situations.”
Figure 4 — SK Telecom’s LTE and 464XLAT architecture.
The basic concept of 464XLAT is that it will communicate with a device using IPv4 or IPv6 depending on the destination address. For this, it uses CLAT (customer-side translator) technology on the user’s device, with DNS64 and NAT64 as a PLAT (provider-side translator).
Hanwoong says that, “this IPv6 network structure has scalability to service massive numbers of mobile users”, adding that SK Telecom’s EPC (Evolved Packet Core) plus XLAT structure could be distributed over any number of sites.
This kind of growth, however, can often expose the limitations of an architecture, and Hanwoong says that, “since PGW is the mobile anchor point and NAT must manage the session to support TCP-based Internet characteristics, packets will be dropped if traffic enters a device that has no session. So PGW and NAT should work in dedicated pairs. Not all NATs and firewalls support this architecture, so additional standby back-up is also needed. In this structure, we can use up to 100% of our resources for services — resources being dedicated, not flexible.”
While some of their devices are able to handle more traffic, they are currently limited by this bottleneck. “Of course, depending on the network structure, some problems can be solved, but we think it’s a trade-off between reliability and efficiency,” Hanwoong says.
Watch Hanwoong Lim’s presentation at APRICOT 2019.
Another challenge Hanwoong identified was managing complexity. Some of SKT’s inline and middlebox devices require static settings, and so some static and policy-based routing is required to manage their IP pool. Errors in these configurations would cause national-scale failures, so this work must be handled in a very sensitive manner. SKT is currently working on SDN and automation solutions in these areas, but they are not yet ready to handle the complexity of the required jobs.
IP transition process
SKT describes its mobile network as consisting of four factors to enable IPv6: user devices, telco systems, network and Internet services. The network and telco system have been made by SKT themselves. Devices and Internet service verifications were made through cooperation with device manufacturers and service providers.
Figure 5 — Four factors that make IPv6 possible in the SK Telecom network.
The first device that SKT supported on IPv6 was the Samsung Galaxy Note Edge 4 in 2015. This Android device supported pure IPv6, with hardcoded IPv4 apps supported through CLAT. Before launching, the device had been verified to provide the same level of service as IPv4. Now, devices released by SKT support IPv6 only, which is supported by cooperation arrangements with vendors.
For the telco system, the LTE EPS system required development of each IPv6 function, so SKT developed about 40 system functions to provide LTE IPv6 service. Hanwoong says the most difficult thing was “that each system is multi-vendor, so systems needed to be developed separately. This took a long amount of time and IPv6 service performance was also an issue that had to be addressed.”
Figure 6 — SK Telecom developed 40 system functions to provide IPv6 LTE service.
Having already introduced 464XLAT to their LTE core, SKT then introduced dual-stack to their backbone network. Since most big box routers don’t have a problem with this, the process was straightforward.
The next step was to establish IPv6 peering with tier 1 ISPs. SK Telecom is now also connected with 14 content providers offering IPv6 services, such as Facebook and Google.
The final step was to offer internal services over IPv6, such as SKT’s App Store, IoT and LBS services.
Once all this was up and running, SKT verified over 1,500 different apps in the Google Play Store, ensuring that errors in the verification process had been corrected before they launched IPv6 for their customers. This work continued after the launch to maintain an optimal service experience.
Pure IPv6 and the challenges ahead
SKT’s mobile network is now pure IPv6, which means they provide end-to-end service (both voice and data) only using IPv6. “From a network perspective, pure IPv6 truly resolved the problem of IPv4 depletion. A dual-stack network, as deployed for typical broadband services, did not solve our problems,” Hanwoong says.
While SKT has developed collaborative relationships with many providers and vendors to keep service levels high, some challenges still remain. For example, IPv6 can be too heavy for thin clients, like some IoT devices, and some CPE vendor support for IPv6 is uninspiring or non-existent.
Hanwoong concluded by saying, “our efforts in switching to IPv6 were motivated by looking at the worst case, knowing that we couldn’t hide from the problem forever. We realized it was the best choice for the company, so we did it.”
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
This is great progress and very interesting coverage of it. Thanks for posting it.