Sky’s IPv6 project launched internally in early 2013 as part of a broader program investigating the use and future of IP within the Sky broadband network. Alongside the IPv6 project, the program also included projects to investigate Carrier Grade NAT444, an automated management tool to more efficiently allocate subscriber DHCPv4 pools, and the acquisition of additional IPv4 space from the open market.

Figure 1: Sky UK IPv6 capability as of 2016 (APNIC Labs).

IPv4 address exhaustion was the main driver of the program, but the activation of the final /8 policy by the RIPE NCC on 14 September 2012 provided the catalyst.

Within the program, Sky’s IPv6 project was itself split into several parallel work streams, covering the various functional areas that required development to support IPv6. These streams focused on the:

• Network
• Customer premises equipment
• Information systems
• Business process

Even with the parallelization of these work streams, the project plan still forecasted a three-year project development life cycle, which largely proved to be accurate — do not underestimate the work required to enable IPv6, and do not leave it to the last minute to begin the journey.

Figure 2: Sky UK IPv6 deployment three-year project plan

Network

The network workstream was responsible for readying the MPLS core with 6PE, dual-stacking the peering and transit interconnects, upgrading the DDoS mitigation platform, and ensuring all of the on-net CDN caches were dual-stacked and capable of serving content over IPv6.

Route and performance parity with IPv4 is essential for a successful IPv6 deployment; customer experience is paramount for a residential ISP, and the introduction of a new Internet protocol that performs worse would not be acceptable.

Customer Premises Equipment (CPE)

At the time, the majority of Sky’s customer base was using two models of CPEs that were both developed in-house, however, there were also an additional five legacy models still in use.

The CPE work stream involved the substantial task of developing and deploying IPv6-ready firmware for both the current models and three of the five legacy models. This included a variety of configurations of ADSL2+, VDSL2 and Ethernet, using both PPPoE and IPoE, all with their own unique nuances and issues that required thorough testing.

Information Systems (IS)

The IS work stream was responsible for organizing all of the backend systems and functions. This included not only functional development on the provisioning, logging and compliance systems, but also the capacity upgrade of the anycast platforms to handle twice the load of the additional RADIUS records and DNS queries that are introduced when IPv6 is enabled.

Business readiness

In addition to the technical work streams, a business readiness work stream was tasked with updating business processes and the ultimate enablement of IPv6 once the other work streams were complete.

This work stream had to update the customer journey through the call centre, upskilling call centre agents, providing them with sufficient resources to manage IPv6-related tasks, and enabling them to correctly identify and raise any IPv6-specific issues.

IPv6 enablement was then done in blocks of subscribers based on the combination of CPE model and service type. Subscribers using the latest CPE model on the PPPoE service were enabled first, IPoE services were next due to extra complexity in the authentication process, and the legacy CPE models were done last once firmware development had been completed.

This per-subscriber enablement was controlled by the introduction of a new RADIUS attribute at authentication time and was managed by a custom in-house tool that allowed for the scheduling of individual or batch enabling (and disabling).

Once all services and CPE models were IPv6 ready, the ‘default on’ switch was flicked for all new customers to be IPv6 enabled at provisioning time. Only top tier support staff retain the capability to toggle IPv6 for individual subscribers, to avoid unnecessary disabling.

The future

The overall program also developed and tested a NAT444 CGN solution with the intention of deploying it dual-stack alongside IPv6. The NAT444 solution went to large-scale staff trial in production but was never rolled out to customers due to the acquisition of additional IPv4 space. This IPv4 space, from the Department of Work and Pensions’ 51.0.0.0/8, was purchased from the UK government during 2016.

Alongside an increasingly saturated broadband market with slowing growth, the program has extended Sky’s IPv4 depletion forecasted date substantially. When the time does come to deploy CGN, Sky’s extensive IPv6 deployment puts us in good shape, allowing for offloading of as much traffic as possible from expensive CGN hardware.

Extending this internal exhaustion date out further also allows for the investigation and maturation of newer stateless technologies such as MAP-T, which promises to be a more cost-effective solution compared to traditional stateful NAT444.

This article was originally published on the APNIC blog.