By: Wim Henderickx, Director of Network Consulting Engineering for IP Division, Alcatel-Lucent
The adoption of IPv6 is underway, and service providers must navigate multiple technology issues and choices in order to define an optimal strategy for the transition from IPv4.
What you need to know about IPv6
Since the 1980s the telecom industry has predicted the depletion of the pool of available IPv4 address blocks. That point was finally reached in 2011. Now, service providers must make the transition to IPv6 in order to sustain Internet growth and provide customers with proper service — especially with the very rapid adoption of smartphones and machine-to-machine devices.
One of the greatest challenges with the move to IPv6 is how to continue to support IPv4 services in residential broadband environments at the same time as they migrate to a mixed IPv4 and IPv6 operational model. This is especially critical as IPv6 is technically incompatible with IPv4, which forces the introduction of several new concepts that change the present operation of broadband networks and has ramifications on how IPv6 can be offered to residential subscribers.
IPv6 creates multi-dimensional issues (Figure 1), and has requirements over which service providers have little or no control. The implications of some of these elements depend on the network design that is chosen for introducing IPv6, which will vary between telecom, cable and mobile service providers.
The following section highlights the implications of certain scenarios in telco and mobile environments, taking into account the coexistence of IPv4 and IPv6 and with a focus on unicast IPv6 connectivity. For more detailed information on implications for cable environments, please refer to the IPv6 Transition in Fixed and Mobile Environments White Paper.
Implications for IPv6 in combination with PPPoX in telco environments
IPv6 support in telco environments using Point-to-Point Protocol over Ethernet (PPPoX) and/or Asynchronous Transfer Mode (ATM) is defined in TR-187 of the Broadband Forum. The introduction of IPv6 using PPPoX/Layer 2 Tunneling Protocol (L2TP) has no implications on the access and aggregation network elements. PPP session authentication for IPv6 is identical to IPv4, using Password Authentication Protocol/Challenge Handshake Authentication Protocol (PAP/CHAP) or option 82. IPv4 and IPv6 authentication can be done in a single authentication phase to optimize RADIUS transactions. As PPPoX IPv6 Control Protocol (CP) is only defining the Link Local Address (LLA), global IPv6 addresses are typically assigned using Dynamic Host Configuration Protocol (DHCP) or Stateless Address Auto-configuration (SLAAC).
To support an IPv6 routed Residential Gateway (RG) using the PPP termination and aggregation/L2TP Network Server (PTA/LNS) model, the following mechanisms are required between the RG and the Broadband Network Gateway/Broadband Remote Access Server (BNG/BRAS) to ensure IPv6 connectivity:
Figure 2 shows a flow diagram of how to establish IPv6 connectivity using a routed RG PPP model.
Another option to provide IPv6 connectivity with PPPoX is by using the Bridged Residential Gateway which requires:
Therefore, to support IPv6 in a telco environment, PPPoX for IPv6 imposes no different requirements on N:1 Virtual Local Area Network (VLAN) or 1:1 VLAN architectures or on a bridged gateway model compared to IPv4. However, PPPoX for IPv6 will always impact the BNG/BRAS, CPE and home gateway using a routed gateway model.
Implications for IPv6 in combination with IP over Ethernet (IPoE) in telco environments
IPoE is an alternative to the PPP over Ethernet (PPPoE) access model. Broadband Forum specification TR-177 defines support for IPv6 in telco environments based on IPoE. The implications for introducing IPv6 IPoE mainly depend on the VLAN model used (1:1 or N:1) and the operational model of the home gateway (bridged or routed).
The impact of IPv6 support for IPoE in a Bridged Residential Gateway model depends on whether DHCP or SLAAC is used to the end device. When deploying DHCP, the main difference from the Routed RG IPoE model comes from the fact that there is no DHCP PD address required and only an IA address is assigned to the host. Care must be taken to ensure communication between IPv6 devices in the home remains local and is not sent through the BNG.
Implications for IPv6 in mobile environments based on R7 or R8 3GPP
IPv6 connectivity in a mobile environment is defined in 3GPP R7/R8/etc. The main elements involved in the IPv6 connectivity establishment are the User Equipment (UE) and the Gateway GPRS Support Node (GGSN)/PDN Gateway (PGW). See Figure 3.
From R8 onwards, 3GPP has defined a mechanism using Packet Data Protocol (PDP) type (IPv4/IPv6) to assign both an IPv4 address and an IPv6 address using a single PDP/Bearer Context. With this mechanism, no additional PDP Context has to be created.
IPv6 transition scenarios
There are various ways forward when making the transition from IPv4 to IPv6, and it is important to understand the various implications for service providers. Below is a brief overview of multiple scenarios.
Scenario 1: IPv6 single stack
Because mobile UE operating systems (OS) have more and more IPv6 support and because some mobile operators have more control over the OS used in their environment, we believe that adopting this model in a mobile environment is acceptable under these circumstances. The cost for this model includes capital and operational expenses (CAPEX/OPEX) to exchange/upgrade RG/UE, CAPEX/OPEX of the DNS64/NAT64 GW, CAPEX/OPEX of introducing IPv6 in access, aggregation, edge and core, as well as OPEX on the Operation Support Systems (OSS).
Scenario 2: IPv4/IPv6 dual-stack deployment options
Scenario 2A: Tunneling IPv6 over IPv4 using 6RD (anycast)
This scenario is positioned in wireline deployments for rapid IPv6 introduction to support Internet access in cases where the access network is incapable of supporting IPv6. Native IPv6 is not supported in this scenario, thus potentially requiring a second upgrade. The costs are determined by CAPEX/OPEX to change/upgrade RG to support 6RD, CAPEX/OPEX of the 6RD Border Relay (BR) and OPEX on the OSS.
Scenario 2B: Dual stack throughout the network
Scenario 2B is positioned in wireline and wireless network deployments. Service providers can leverage synergies between fixed and mobile if they supply both services. The cost is determined by the CAPEX/OPEX to change/upgrade the RG/UE, the CAPEX/OPEX of the CG-NAT, and the CAPEX/OPEX of introducing IPv6 in access, aggregation, edge and core and OPEX on the OSS.
Scenario 2C: Partial dual-stack deployment in combination with IPv6-only
An Address Family Transition Router (AFTR) is introduced in the aggregation network to encapsulate/de-encapsulate IPv4 traffic in/from IPv6, and provides CG-NAT using the IPv6 source prefix as the subscriber key. More details are described in draft-ietf-softwire-dual-stack-lite.
Scenario 2C is mainly positioned in wireline deployments that need to transition quickly to a native IPv6-only environment in access and aggregation. Implementation costs includes CAPEX/OPEX to exchange/upgrade RG/UE to support B4/IPv6, CAPEX/OPEX of the AFTR, CAPEX/OPEX of introducing IPv6 in access, aggregation, edge and core and OPEX on the OSS.
Carrier grade network address translation (CG-NAT)
Besides approaches to providing IPv6 and IPv4 connectivity, there are other considerations such as CG-NAT and its various implications that determine the IPv6 transition strategy. CG-NAT is a technology that enables multiple users to share a common public IPv4 address on the Internet. Here are some of the considerations to be taken into account:
Many service providers offering public IP services have to face these challenges while minimizing the impact to their customers. Providing native IPv6 will avoid these issues.
A strategy for transition
As there are many options available when developing a strategy to deploy IPv6, the implications for each will vary based on the network design chosen for introducing IPv6. For a more detailed overview into the transition from IPv4 to IPv6 please refer to the IPv6 Transition in Fixed and Mobile Environments White Paper.