DS-Lite CGN Drives the Smooth Evolution to IPv6

Although industry and governments have worked for more than a decade to transition into IPv6, this transition is still nowhere near complete. The long-predicted doomsday for IPv4 is quickly approaching. The Internet Assigned Numbers Authority (IANA) will run out of unallocated IP addresses in August 2011 and the Regional Internet Registries (RIR) will run out of unallocated IP addresses in May 2012. It is therefore imperative that IPv4 be transitioned to IPv6.

Why Slow Transition to IPv6?

   IPv6 has many advantages over IPv4, including larger address space, better header format, plug and play, higher security, end-to-end QoS, and better IP mobility. Despite the limitations of IPv4 and the impending IPv4 address exhaustion, operators are still behind in their IPv6 migration plans.  

  The basic reason for slow deployment of IPv6 is unbalanced development of the industry chain.  IPv6 migration involves network equipment, terminals, IT systems, service systems, and applications. Although IPv6 has grown into a mature technology that is commercially available on network equipment and IT systems, most terminals (excluding PCs), service systems and applications have not been made IPv6 ready. This is due to the “bucket effect” in the industry chain. Few service types are supported on IPv6 networks, and operators have adopted a wait-and-see attitude towards IPv6 migration because there is no obvious ROI. The unbalanced development of the industry chain hampers IPv6 deployment.

   Another reason for the slow deployment of IPv6 is that there is no complete solution for evolving to IPv6. A solution for the backbone network is available and meets current service demands, but there is no solution for the MAN that is mature enough for large-scale commercial deployment. There are two IPv6 solutions for user access.

  Native IPv6 access: Subscribers obtain IPv6 configuration information from BNG and access an IPv6 network through PPPoEv6 or IPoEv6. Native IPv6 access solves the problem of IPv4 address depletion but does not allow for feature-rich services because most current applications do not run smoothly on an IPv6-only host. Therefore, native IPv6 cannot adapt to network features at the present stage but will be applied in the final stage of network evolution.

  Dual-stack access: Subscribers obtain IPv4/IPv6 configuration information and access dual-stack networks through a single PPP session for both IPv4 and IPv6 or IPoEv4/IPoEv6. The dual-stack access solution ensures feature-rich services but cannot be deployed on a large scale because it uses public IPv4 addresses.

DS-Lite

    Because of application and terminal constraints, a large-scale upgrade to IPv6 cannot be completed within a short time. Most ICPs have no intention of deploying IPv6, and IPv4-IPv4 traffic will still be prevalent on the network in years to come. Dual Stack Lite (DS-Lite) has thus been put forward to drive IPv6 deployment and ensure IPv4 service continuity.

   DS-Lite combines IPv4-in-IPv6 tunnels and IPv4 NAT. It is collaboratively implemented by the address family translation router (AFTR) and basic bridging broadband element (B4). The DS-Lite model is shown in Fig. 1.

    B4 (or home gateway) enables the DHCPv4 server function to allocate private IPv4 addresses to internal terminals. If B4 is a terminal, it assigns a fixed private IPv4 address by itself. The operator network advertises AFTR address information (IPv6 addresses) through static configuration or DHCPv6. B4 initiates a request to create an IPv4-in-IPv6 tunnel (known as softwire) to AFTR and encapsulates or decapsulates outgoing IPv4 or incoming IPv6 traffic (the destination address is IPv6 address of B4 WAN interface).

   AFTR creates an IPv4-in-IPv6 tunnel (softwire) to B4 and uses the NAT function to decapsulate/encapsulate outgoing IPv6 or incoming IPv4 traffic as well as IPv4-IPv4 NAT. Since IPv4 addresses are allocated by users on their own, different users may have the same IPv4 address. To avoid address conflict, NAT table entries maintained by AFTR are different from common IPv4 NAT table entries, and the IPv6 address of B4 WAN interface is added to  differentiate users.

   The DS-Lite model supports IPv6 deployment. AFTR and B4 perform native forwarding of IPv6 traffic.

DS-Lite CGN Solution

   To push IPv6 deployment, DS-Lite carrier-grade NAT (DS-Lite CGN) is currently being researched  in this dustry. DS-Lite CGN falls into two types: standalone CGN and embedded CGN. Standalone CGN implements DS-Lite AFTR through hardware. Embedded CGN developed on the BNG (BRAS) platform has a dedicated card for DS-Lite and provides PPPoEv6/IPoEv6+DS-Lite for user access and DS-Lite AFTR. ZTE’s ZXR10 M6000 can be deployed as either a standalone CGN or an embedded CGN. 

   Standalone CGN can be centrally deployed or distributed. In centralized deployment (Fig. 2), subscribers obtain IPv6 configuration information from BNG over PPPoEv6/IPoEv6, and a softwire to CGN is created. CGNs dual-homed to MAN core routers provide DS-Lite AFTR for MAN subscribers. They are deployed in pairs to enable DS-Lite hot backup and load sharing. This improves network availability.

    In distributed deployment (Fig. 3), CGNs connected to IPv6 BNG—the control device at the edge of MAN—provide DS-Lite AFTR for subscribers covered by IPv6 BNG.

   As for the embedded CGN, BNGs provide IPv6 access and DS-Lite AFTR through PPPoEv6/IPoEv6+DS-Lite for subscribers covered by BNGs. Because some BNGs cannot be upgraded, the existing IPv4 BNG serves as LAC, and IPv6 BNG integrates the functions of LNS and CGN. An L2TP tunnel is set up between the IPv4 BNG (LAC) and IPv6 BNG (LNS), and a softwire is set up between the home gateway (B4) and IPv6 BNG. In this way, IPv6 access can be provided for subscribers.

    Standalone CGN and embedded CGN have their own advantages and disadvantages, as listed in Table 1.

   Embedded CGN has not yet matured. It causes service interruption, it is not reliable, it has poor scalability and complicated O&M. However, standalone CGN is highly reliable, has good scalability, easy O&M, and is simple to upgrade with little impact on existing services. France Telecom has chosen to deploy standalone CGN for its initial network evolution.

   Centralized deployment of standalone CGN is cost efficient, although the user base is subject to CGN constraints. The processing capability of a CGN card is much higher than that of BNG (about five times). As native IPv6 or dual-stack access is gradually implemented for networks and services, DS-Lite is applied less and is only needed in the initial and development phases of network evolution. Centralized deployment of standalone CGN is therefore considered the best choice for operators to evolve their networks to IPv6, and distributed deployment of standalone CGN can be adopted in large MAN scenarios as a supplement for wide area coverage. The DS-Lite CGN solution allows for smooth network evolution, protects operator profits, and promotes IPv6 deployment.