Saudi Arabia IPv6 Task Force

By: Wim Henderickx, Director of Network Consulting Engineering for IP Division, Alcatel-Lucent

Source: http://www2.alcatel-lucent.com/blogs/techzine/2011/making-the-move-to-ipv6/?s_cid=smm_tmc0253_bl
 

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.

Highlights

• IPv4 address exhaustion forces service providers to transition to IPv6
• IPv6 is technically incompatible with IPv4, which introduces several new concepts that change the present operation of broadband networks
• Multiple scenarios support the mixed IPv4/IPv6 operational model, and operators must understand the implications of each as they establish a strategy for the transition

 

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:

• PPPoX IPv6 Control Protocol (CP) for LLA assignment
• DHCPv6 Prefix Delegation (IA-PD – Identity Association for Prefix Delegation) is used to obtain a prefix for LAN address assignment
• Stateless DHCPv6 is used to obtain additional configuration parameters
• When the numbered RG model is deployed, stateful DHCPv6 (IA-NA – Identity Association for Non-temporary Addresses) is used to obtain an RG management IPv6 address; in case of an unnumbered RG model, this is not required
• Route advertisements are required to assign the default Gateway (GW) assignment

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:

• PPPoX IPv6CP for LLA assignment
• SLAAC used for the host to obtain a Global-Unicast IPv6 address
• Stateless DHCP to obtain additional configuration parameters
• Route advertisements to assign the default GW assignment

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
In this scenario, only native IPv6 connectivity is provided to the end. End-to-end IPv6 connectivity is provided natively between end-hosts/web sites. To provide communication from IPv6 to an IPv4 host/web site, a NAT64/DNS64 (Network Address Translation/Domain Name System) service needs to be deployed in the network.

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
There are three potential options in an IPv4/IPv6 dual-stack deployment scenario, depending on the service provider’s network and objectives.

Scenario 2A: Tunneling IPv6 over IPv4 using 6RD (anycast)
In this scenario, the end devices are supplied with dual-stack addressing. Both an IPv4 and an IPv6 address are provided to the customer local area network (LAN). IPv4 connectivity in this model is provided as usual, that is, using private or public IPv4 addressing. IPv6 connectivity is provided using 6to4 tunneling (RFC 3056).

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
This scenario supports both native IPv4 and native IPv6 to the end customer. IPv4 is supported using the current mode of operation with optional deployment of Carrier Grade – Network Address Translation (CG-NAT), depending on the available Public IPv4 address space. IPv6 is provided using one of the methods described in chapter 2 of the IPv6 Transition in Fixed and Mobile Environments White Paper.

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
Scenario 2C provides native IPv6 connectivity while IPv4 connectivity is provided using IPv4inIPv6 tunneling. In this model, the B4 element (Basic Broadband Bridging) is introduced in the CPE/RG, which provides IPv4inIPv6 tunneling capabilities.

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:

• Network connectivity must be initiated from the inside toward the outside, unless static port-forwarding rules are configured on the CG-NAT device. Universal Plug and Play (UPnP) and NAT Port Mapping Protocol (NAT-PMP) will no longer work with CG-NAT, and potentially a portal needs to be deployed to enable customers to use pinholes in the CG-NAT service.
• The private IP address space has a limited size which must be factored in design decisions.
• Application Level Gateways (ALGs) must be supported to allow certain applications (FTP/RTSP/SIP/etc.) to operate across CG-NAT.
• Lawful Intercept (LI) should be integrated in the CG-NAT device to ensure public IP communication is presented to the LI mediation device.
• Certain Internet services, which operate based on IP-only information, will no longer be able to identify a host based on IP address and need to be enhanced with the port information allocated to a certain host.
• Take into account the throughput, NAT binding translation rates, and binding scalability support of the deployed CG-NAT device.
• Select a solution that can be deployed in both a centralized or distributed manner, since NAT requirements might change over time.

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.