Technical White Paper for

IPv6 Evolution Policies

Contents

1 IPv6 Evolution Policies........................................... 2

2 IPv4/IPv6 Transition Technology............................. 10

2.1 Basic Transition Techniques..................................................... 13

2.2 Evolution Trends ..................................................................... 18

2.3 Optional Evolution Scenarios and Applications of Transition

Technologies ................................................................................ 19

2.4 Summary .............................................................................. 25

3 Acronyms and Abbreviations................................... 27

4 Reference ............................................................... 28

Technical White Paper for IPv6 Evolution Policies

KeywordsIPv4, IPv6, Coexistence, Transition, Dual Stack, Tunnel, Translator, NAT

Abstract: This document describes typical IPv6 transition technologies and application scenarios and lists the analysis and comparison of the technologies and network status used in the transition solutions from several aspects. Owing to the variety of technologies and different situations of provider networks, each provider will certainly select a conservative, reposeful, or aggressive transition technology that is the most suitable for its own network.

In terms of evolution to IPv6, provider networks and customer networks differ in the pace. This can be decoupled through CPEs. No matter providers deploy single stack or dual stacks on their networks, the networks must provide both IPv4 and IPv6 services for users.

Huawei high-end metro router of series provide a complete IPv4-IPv6 solution, which can meet the requirements of transition to IPv6 in all the evolution scenarios previously described.

1

2

1 IPv6 Evolution Policies

IPv4 addresses will be used up by 2011. IPv4 address exhaustion has been a practical problem that providers must face. Existing solutions such as IPv4 readdressing and address reuse fail to solve this problem substantially. The reserved addresses of providers will be exhausted in the near future, which may retard the long-term development of services.

IPv6 is regarded as a complete and thorough solution to IPv4 address exhaustion. The introduction of IPv6, however, is progressing slowly because IPv6 has not brought new business opportunities yet but serves only as a solution to address deficiency. Currently, the address exhaustion issue can be temporarily settled through substitutionary solutions. Therefore, the driving force for adopting IPv6 is insufficient. The IPv6 industry chain (end user — network — service) is not developing in a balanced manner at present. This makes IPv6 not appealing enough to compel any role involved with this chain to independently give an impetus to the development of IPv6. For now, terminal and service are the shortest boards of the IPv6 development. They are the core links, however, which are accepted by users. In terms of network providers and service systems, who introduces IPv6 first will take charge of the IPv4 environment transition and assume the costs due to the immaturity of the IPv6 industry chain. From another point of view, however, the later IPv6 deployment is begun, the higher costs the evolution to IPv6 will require for IPv4 reengineering and transition. Therefore, all the concerned are keeping up with the development of IPv6 and they all have had the technical storage and accumulation for developing and supporting IPv6 in a short time. To break the ice of real IPv6 deployment needs a trigger point.

With regard to investment, IPv6 is lacking in application currently. That is, no application is implemented technically only based on IPv6. Hence, evolution to IPv6 cannot strike a chord with the links in the Industry chain. On the side of end users, attractive services and competitive prices are driving factors for them to use IPv6. On the side of application and service providers, a large-scale IPv6 network and a stable and large IPv6 user group are the fundamental driving force for evolving to IPv6. While users are waiting for IPv6 services, application and service providers are also waiting for the naissance of

3

an IPv6 user group. The situation causes a chicken and egg problem. Although the external force from the government can speed up the establishment of IPv6 industry chain, the acting force for solving the problem lies in the intermediate link, providers. As a link connecting users and services, providers should take the initiative in constructing and developing a basic IPv6 network, providing IPv6 with more service access capabilities, and actively creating an IPv6 environment. This is the key to the deadlock.

Network address translation (NAT) acts as a temporary solution to IPv4 address exhaustion. NAT, however, is not apt to mass deployment due to various innate problems such as:

NAT breaks end-to-end (E2E) connectivity, not complying with the requirement of future network development.NAT traversal is too complex for application software.Stateful NAT cannot be deployed on the core layer because the core layer has multi-pathing and multi-homing requirements.The IPv4 space for private network addresses is limited, holding up to 16,000,000 private network addresses. In a scenario where the upper limit is exceeded, the multi-level NAT is needed. This increases the complexity of service access.

The use of NAT is necessary, however, since providers cannot solve the problem of the transition to IPv6. The evolution to IPv6 is bound to be a long-term project. The 4-4 interoperability remains a service access mode that must be provided in the transition period. After IPv4 addresses are used up, the NAT44 technology will still be a mature and viable solution. In addition, contents may not be in IPv6 format even if IPv6 has been introduced. In this case, mutual access between different protocols still needs the NAT64. The NAT44 or NAT64 is an address translation mechanism. In one word, the NAT mechanism will still be widely used in the evolution of IPv6, and it will exist for a long time.

Currently, the mass deployment of IPv6 is generally handled with discretion in the whole industry. Except that NTT of Japan carried out IPv6 commercialization in an earlier time, most of the worldwide providers are just in the research and experiment phase. When IPv4 address exhaustion is approaching, major providers have set about substantive planning for the real commercial deployment of IPv6. Along with the transformation, the IPv6 industry standards are also developing towards commercialization, deployment, and management.

4

Effects on the IPv6 evolution must be considered from the angle of the entire industry. Based on the current experience in network development, at least the following core factors should be taken into account.

User

IPv6 is a new generation of the network layer protocol that is not compatible with IPv4 at all. After the introduction of IPv6, the impacts on the existing network should be minimized so that users cannot even perceive them. IPv6 evolution should be implemented in a way similar to PSTN reconstruction, that is, changes to the core do not require changes to the services or to use habits of users. In this case, IPv6 evolution is acceptable for users and thus can be promoted easily. In addition, it should be ensured that original IPv4 services are still accessible to new IPv6 users and service experience is retained to the greatest extent and even improved relying on some business preferential, In such an environment, more IPv4 users will be willing to accept the transition to IPv6. In this regard, NTT of Japan has successful experience in IPv6 evolution. NTT developed a brand new IPv6 service brand by combining the improvement on all-sided service experience closely with IPv6. After that, NTT provided a new package for the concept of next generation network (NGN), which formed a new concept of next generation new service experience over IPv6 for end users. Thus, NTT successfully carried the large-scale application of IPv6 forward.

Service

IPv6 is not compatible with IPv4 at all. This is a key problem that should be considered about the deployment of IPv6. To avoid adverse effects resulting from the incompatibility, the initial deployment of IPv6 should be started with a closed-type service, for example, Internet Protocol television (IPTV). Closed-type services do not have high requirements on interoperability, nor have a requirement on an interaction with the existing IPv4 system. They help simplify and accelerate the deployment of IPv6 at an early stage.

5

Network

The network deployment of IPv6 must be implemented end to end. The networking and devices of different layers on the network differ greatly in many aspects such as the network architecture, technology selection, device capability, vendor composition, and capability to support IPv6. The IPv6 evolution solution should be considered in a comprehensive manner. On the premise that the costs are acceptable, a new private network or dedicated devices can be used in the early deployment to reduce the effects on the existing network. For example, a separate IPv6 gateway is used for connections from IPv6 users. This method brings these benefits: avoiding impacts on the existing services because of potential problems in the early deployment of IPv6, upgrading existing network devices gradually to support IPv6 and thus avoiding cost skyrocketing in a short period, and assigning separate maintenance engineers for the new network and new devices to avoid IPv6 engineer deficiency in the early stage of IPv6 introduction.

Cost

The introduction of IPv6 is a long-term system project. The occasion and pace of introduction must be considered with discretion. This requires weighing and considering the combined costs of reconstruction and upgrade. If a provider begins IPv6 deployment too early, the provider must assume the costs for interworking with the surrounding networks. If a provider begins IPv6 deployment too late, the total costs on network swap increase. Therefore, network providers are not advised to reconstruct their networks and replace devices with those supporting IPv6 in a short period. Networks that cannot provide IPv6 services should be reconstructed so that network providers can accumulate experience in IPv6 network commercialization. The pace of introducing IPv6 must be set from the cost factor.

The evolution of IPv6 is doomed to a long-term process. The process is estimated to include three stages.

6

Early stage: Pilot Stage of the IPv6 Network, Lasting Two to Three Years

Characteristics of network transition:

IPv6 is deployed on small-sized networks. The pilot metropolitan area networks (MANs) are basically provided with the IPv6 service access capability. The pilot backbone networks are deployed partially, enabled with the IPv6 plane. During the initial commercial use, closed-type IPv6 services are deployed so that the impacts on the existing services can be minimized. Meanwhile, a pilot project is launched for open-type IPv6 services so that the MANs can preliminarily handle access to IPv6 services. In this way, network providers can accumulate experience in the design, operation, and maintenance of the IPv6 network. In addition, the original IPv4 services can still be available during the initial commercial use of IPv6.

Intermediate Stage: Mass Deployment Stage of the IPv6 Network, Lasting Three to Five Years

Characteristics of network transition:

IPv6 networks step into a mass deployment phase. The attempt to constructing new IPv4 networks (providing IPv4 services only) should be called off. The backbone networks roundly support two logical planes: IPv4 and IPv6. New MAN devices mainly use dual stack or IPv6 (for ASPs) to ensure the dynamic coexistence of IPv6 and IPv4 services. In terms of services, IPv6 users can be provided with the same service experience as IPv4 users and authorized to access IPv4 network resources. In addition, it is ensured that the transition to IPv6 will not cause any loss of IPv4 users in using original services.

7

Later Stage: Gradual Withdrawal of the IPv4 Network, Lasting Five to Ten Years

Characteristics of network transition:

IPv6 services are becoming popular. Providers’ operation policies shift to IPv6 and push end users and service systems towards IPv6 networks. Majority of new users are IPv6 users and new services are mainly developed based on IPv6. IPv6 is adopted for all the new closed-type services such as IPTV. Open-type services are pushed to evolve to IPv6. The services and applications on IPv4 networks are gradually transitioned to the IPv6 network, including the Internet data center (IDC), service system, and operation and maintenance (O&M) system. IPv6 is becoming the main stream. New IPv4 service development is gradually being scaled down and finally put to an end. The network is oriented to services. IPv4 users are gradually decreased until IPv4 completely exits.

Currently, most providers are still in the early stage of IPv6 evolution and a few have begun to enter the intermediate stage. Different network providers may select different IPv6 evolution technologies and different evolution routes because of the differences in network or service. These technologies and routes, however, have similarities in terms of the concept. The following parts offer suggestions on evolution routes and solutions from four aspects: backbone network, MAN, mobile network, and network management.

Backbone Network: Two Logical Planes and Adjustable Resources

IPv6 backbone networks mainly use the dual-stack mode. Pure IP networks use the dual-stack mode while multi-protocol label switching (MPLS) networks use the IPv6 provider edge (6PE) routers or 6vPE technology.

The logical planes are formed in the deployment of pure IP backbone networks. Certain logical planes are upgraded to support IPv6 only or both IPv6 and IPv4. Generally, core nodes and core convergence nodes are connected through multiple links for redundancy purpose.

8

This connection mode is called cross-connect mode. On IPv6 backbone networks, the cross-connect mode is changed to the upper-lower parallel mode. The upper-lower parallel mode not only ensures the reliability by means of link redundancy, and it but also makes the network structure and traffic policy easy to be understood. Flows in the same direction form a logical plane. When there are multiple redundant logical directions, multiple logical planes are formed between core nodes and core convergence nodes. A logical plane consists of upper and lower interconnected devices or ports. Thus, multiple mutually redundant logical networks are formed on the entire network. If some logical networks are upgraded to support IPv6 only or both IPv6 and IPv4, risks accompanied with the introduction of a new protocol are minimized when the backbone networks are upgraded to support IPv6.

Access node

A1 A2

Core node B

Convergence node

Logic 1 Logic 2 Logic 3 Logic 4

Core node A

C1 C2 C3 C4 C1 C2 C3 C4

D1 D2 D3 D4

9

In the deployment of MPLS backbone networks, IPv4 MPLS is available for devices and two logical planes of IPv4 and IPv6 are formed for services. IPv6-based virtual private networks (VPNs) use the 6vPE over IPv4 MPLS. The PE is upgraded to support 6vPE. IPv6 VPN routes are introduced. The IPv6-based Internet service uses the 6PE over IPv4 MPLS. The PE is upgraded to support 6PE. IPv6 public network routes are introduced.

For the network devices that support dual stacks, the device resources must be dynamically shared and adjusted between different protocol stacks. In different stages of network evolution, the network resource application can be properly adjusted according to the traffic flow usage of different protocols.

MANs: Coexistence of Multiple Access Modes and Protocol Interoperation

First centralized and then distributed: In the early stage of IPv6 introduction, there are few IPv6 users and they are distributed sparsely. IPv6 gateway devices can be deployed in a centralized manner to provide the unified access for IPv6 users. Thus, little changes to an IPv4 network and small investment can enable the network to provide IPv6 services. The upgrade for IPv6 support over the entire network can be implemented later so that the network can provide IPv6 services in fully distributed mode. The transition technologies such as the Layer 2 Tunneling Protocol (L2TP) and 6rd can serve as IPv6 MAN solutions in the early stage.

First core and then edge: A MAN is generally divided into the core layer 3 network and the edge layer 2 access network. To enable a network to provide basic IPv6 services, providers can upgrade first layer 3 devices such as core and edge routers of MANs to support IPv6. For layer-2 devices of layer 2 access switches and digital subscriber line access multiplexers (DSLAMs), the requirements on security and multicast capabilities over IPv6 are lower in the early stage. The layer 2 devices are gradually upgraded and supplanted in the future development of IPv6 services. For example, the early IPv6 multicast service requires layer 3 routers to support the layer 3 multicast protocol but does not require layer 2 network devices to have the layer 2 multicast replication capability. That is, multicast packets are replicated by users on the edge of layer 3 network. IPv6

10

deployment has a lower requirement for layer 2 network devices in the early stage. In the future, the IPv6 multicast replication capability is gradually introduced to layer 2 network devices to improve the service performance and security of the network.

First closed and then open: With respect to closed-type services such as the IPTV service, the network and the service system are relatively independent. This type of services does not require interworking with external networks. There is no compatibility requirement for this service. The relevant network management and maintenance engineers are also independent. Upgrading such a service network to IPv6 can minimize the impacts on other services of the existing network. Therefore, the services of this type are easily introduced. In addition, when a user uses a closed-type service, the user does not care about the network address protocol and so the user does not perceive any change of the network layer protocol. The difficulty in introducing closed-type services is lower. Therefore, closed-type services such as the IPTV service should be first deployed in the early stage of IPv6 transition. IPv6 operation experience can be gathered through the early commercial use of IPv6. Open-type services can be gradually introduced in the following future.

First NAT44 and then NAT64: The root cause for introducing IPv6 is to solve the problem of IPv4 address exhaustion. The introduction of IPv6 is a long-term system project. It is impossible that IPv4 will be totally supplanted by IPv6 on one day. Therefore, IPv4 and IPv6 will still coexist for a long time. To alleviate the IPv4 address exhaustion, it is bound to use private IPv4 addresses. That is, NAT44 must be used in large scale first. In the following future, with gradual introduction of IPv6, NAT64 should be used to solve the service problem that users need to access IPv4 services over IPv6.

11

Mobile Network: Priority Is Given to Data Plane Rather Than Bearer Plane

First service and then bearer: IPv4 address exhaustion affects mainly end users. Users directly face the IPv6 of services. Because the demand on addresses between relevant network devices is fewer, the IP addresses between devices are sufficient. Therefore, the IPv4 of the bearer plane can remain unchanged for a long time. The IPv6 of services should be first solved and then the bearer plane over IPv4 can be used for solving the bearer problem of the IPv6 service plane. For example, tunneling technologies such as the IPv6 over IPv4 GRE can be used.

Core network first and then access network: Priority is given to the IPv6 of core network elements (NEs) related directly to services. The IPv6 of the RAN devices used for service bearer can be implemented gradually in the following future.

Network Management: Unified Operation and Maintenance

First IPv4 management channel and then IPv6 management channel: IPv6 management information can be managed through IPv4 management channels. IPv6 management channels can be gradually introduced in the following future. Thus, the effect of the IPv6 of management channels on service development can be reduced.

Physical plane first and then service plane: In terms of service management, priority is given to the dual-stack resource management and isolation on the physical plane of devices. With gradual penetration and elaboration of service management, the logical service plane is gradually considered, including the logical topology management and the management and isolation of intra-VPN logical dual-stack resources.

12

2 IPv4/IPv6 Transition Technology

As early as in the early 1990s, the Internet Engineering Task Force (IETF) has begun a research on the IPv6-related protocol and attempted to supplant IPv4. After the development of more than a decade, the basic protocol of IPv6 has become mature enough to supplant IPv4. Because IPv4 packet headers are not compatible with IPv6 packet headers, network devices and host devices must be upgraded to support IPv6. On the existing IPv4 network, there are a large number of devices. Upgrade and replacement of these devices requires tremendous investment. Moreover, it is impossible to interrupt the existing services for upgrade. Therefore, IPv4 cannot be completely revoked in a short time.

The transition and evolution to IPv6 can be roughly completed in three stages:

In the early stage, the deployment of IPv6 is prepared and begun on the IPv4-based network.In the intermediate stage, IPv4 and IPv6 coexist.In the later stage, IPv6 plays a leading role on the network and the IPv4 network is gradually withdrawing from the market.

Meanwhile, researchers put forward many transition mechanisms for different network infrastructures and different evolution stages.

The deployment of IPv6, however, is still far below expectation. The causes include:

Certain technologies such as NAT alleviate the IPv4 address exhaustion.There is no IPv6-based killer application yet.The costs for network upgrade are huge.In view of the facts, it is generally accepted in the Industry that the IPv6 evolution process has changed from the IPv4/IPv6 transition into the long-term IPv4-IPv6 coexistence.

13

Actually, the delayed deployment of IPv6 makes the IPv4/IPv6 transition more complex. According to the related statistics, the IPv4 allocation pool will be depleted around 2012. By then, no IPv4 address will be available for any new user. The originally most ideal dual-stack mode is facing a new problem, how to maintain IPv4 services in the case of IPv4 address shortage. In addition, having the technology complexity and O&M problems, the original transition technologies need to be optimized and improved.

The following parts respectively describe the basic transition technologies and the comprehensive appl icat ion of these technologies. According to different network infrastructures, users can choose a proper approach to overcome the difficulties in the transition period. It helps users to implement a smooth transition from the IPv4-based network to IPv6.

2.1 Basic Transition Techniques

The transition mechanisms can be divided into three types: dual stack, tunneling, and translation. Among the three types of basic transition techniques, dual stack is the simplest and easiest to accept, and tunneling and translation are necessary for specific occasions.

Dual Stack

Specified in RFC 4213, dual stack refers to the technique for providing message interworking between terminal devices/network nodes and IPv4/IPv6 nodes by installing both IPv4 and IPv6 protocol stacks on terminal devices and network nodes, as shown in a) of Figure 1. Routers supporting IPv4/IPv6 dual-stack enable the network to act as two parallel logical networks and enable a smooth transition to IPv6. With good interoperability, the dual stack mechanism is the most direct mode to make IPv6 nodes compatible with IPv4 nodes. Moreover, it is easy to understand. The use of dual stack, however, increases the occupancy of system resources and decreases the performance of devices, but cannot solve the problem of address shortage. In addition, this mechanism is bound to increase the network complexity and costs since it needs double resources. Dual stack is divided into two layers: network and terminal.

14

Figure 1 Basic evolution techniques

a. Dual Stack b. Tunneling c. Translation

Application layer

Link layer IPv 4

IPv 4

IPv 6v4 protocol

stackv6 protocol

stack

IPv 6

IPv 4

Tunneling

Tunneling is used to implement the interconnection between the isolated IPv6 networks distributed in an IPv4 network or the isolated IPv4 islands distributed in an IPv6 network, as shown in b) of Figure 1. Requiring only border nodes to implement dual stack, the tunneling technique enables data of an address family to traverse the network of another address family through a tunnel.

In the early stage of IPv6 development, tunneling facilitates the implementation of the interworking between IPv6 islands and the incremental deployment of IPv6 without upgrading the entire network. In this way, the implementation scope of IPv6 is gradually enlarged. Therefore, tunneling is a technique the easiest to use in the early stage of a transition. Similarly, in the later stage of a transition, scattered IPv4 islands can also be connected through tunnels.

Tunneling has the following disadvantages:

Double IP headers increase network overheads.Extra scalability and reliability are required for tunnel ends.Problems about the maximum transmission unit (MTU) may occur.

Table 1 describes common tunnel features and scenarios.

15

Table 1 Comparison of common tunneling techniques

Tunnel Type. Technical Feature Applicable Scenario

Manual tunnel I P - i n - I P o r gene r i c rou t ing encapsulation (GRE) is used for encapsulation.

Tunnels of this type are configured manually. They are easy to implement and widely supported by network devices. However, they are not suitable for large-scale deployment.

A u t o m a t i c tunnel

The IPv6-in-IP mode is used. Sta te le s s au tomat i c tunne l encapsulation is implemented through IPv6 addresses with embedded I P v4 add re s se s . 6to4 addresses use the well-known prefix, 2002:IPv4-globe-Addr:Suffix.

The feature of an Intra-S i te Automatic Tunnel Addressing Protocol ( ISATAP) address is Prefix:0:5EFE:IPv4-Addr.

Automatic tunnels are used as IPv6-in-IPv4 tunnels only. They are implemented through embedded IPv4 addresses. Relying on the IPv4 topology, automatic tunnels are applicable to the early stage of IPv6 transition. Supported by common operating systems, they are suitable for hosts. 6to4 needs public IPv4 addresses for interconnection between IPv6 islands. 6to4 relay routers are used for communication with native IPv6 hosts.

The ISATAP does not have any restriction on IPv4 addresses. It is more applicable to enterprise networks.

MPLS tunnel 6PE/6VPE, IPv6-in-MPLS Multi-protocol label switching (MPLS) tunnels have good forwarding performance. They are applicable to the network cores. MPLS infrastructures are required.

In addition, 6rd continues to use the 6to4 stateless tunneling mode. 6rd uses provider prefixes instead of the well-known prefix 2002/16 used in 6to4. Thus, IPv6 prefixes can be released on the native IPv6 network. The problem of routing through which the native IP network accesses 6to4 islands is solved.

Microsoft puts forward and implements Teredo in Windows Vista. Teredo solves the problem that ISATAP traffic cannot traverse NATs. Owing to its complex process, however, Teredo is difficult to be popularized.

Different from 6PE, Softwire implements the tunnel control function in the scenarios of Mesh and Hub&Spoke in a pure IP environment. It can be IPv6-in-IPv4 or IPv4-in-IPv6. Softwire focuses on how the nodes on both ends of a tunnel discover each other's addresses, negotiate configuration parameters, and complete automatic tunnel configuration.

16

Translation

Translation is used for interworking between IPv6-only networks and IPv4-only networks, as shown in c) of Figure 1. Translation devices are located on the border of two networks. They need to forcibly translate corresponding fields of the IP header and translate the IP address carried in the packet body. The device translating IP addresses in packets is called an application level gateway (ALG).

There are many types of translation techniques. Table 2 describes the characteristics and application scenarios of the major translation mechanisms.

Table 2 Comparison of common translation techniques

Layer Technique Technical Feature Applicable Scenario

Network layer

SIIT SI IT def ines the address translat ion implemented t h ro u g h t h e f o l l o w i n g specific address formats: IPv4 mapping address 0::ffff:a.b.c.d and IPv4 translation address 0::ffff:0:a.b.c.d.

SIIT is stateless translation. It faces the problem of IPv4 address shortage. Therefore, it is applicable only to the occasion from an IPv6 network to the IPv4 Internet.

NAT-PT The mapping between IPv4 addresses/ports and IPv6 addresses is implemented through NAT.

NATPT is stateful translation. It is built in a router or firewall. It has higher efficiency than the techniques used in the application layer.

BIS Network address translation-protocol translator (NAT-PT) implemented in hosts

This technique is applicable to single-stack hosts.

Transport layer TRT Translation in the transport layer

This technique is applicable to routers.

A p p l i c a t i o n layer

SOCKS64 The SOCKS p ro toco l i s used. Address translation is implemented through the SOCKS proxy server.

The host software must be upgraded and a special SOCKS server must be deployed. This technique is applicable to specific application scenarios.

BIA SOCKS64 implemented in hosts

It is a host translation technique, applicable to the traditional application programs of dual-stack hosts.

ALG Address translation in the application layer

The ALG has a lower performance. It usually works with the translation techniques of the network layer for the translation of packet contents.

17

Owing to the problems existing in the translation techniques themselves, however, only NAT-PT has related products and can be deployed currently. Translation techniques above the network layer have low performance due to several layers to be processed. The network layer translation faces the problem about the ALG. The packet bodies of certain protocols contain IP addresses. To implement the ALG, translation devices must identify the specific application layer protocol. An obstacle to new applications may be formed consequently.

The IETF has noticed the issues about translation techniques, and described the issues in RFC 4966, including application layer gateway for domain name server (DNS-ALG) issues, NAT issues, ALG issues, and scalability concerns. On that basis, the Behavior Engineering for Hindrance Avoidance (BEHAVE) working group of the IETF has re-thought translation techniques and made the following improvements:Stateful translation uses NAT64+DNS64 to simplify and supplant NAT-PT. NAT64 allows only the IPv6 side to initiate connections. Furthermore, NAT64 does not implement NAT-ALG functions, which are done by a separate DNS64 server.

Stateless translation absorbs the notions of SIIT and IVI and uses provider prefixes. IPv6 addresses are embedded with IP and can be self-mapped. Thus, addresses are easier to manage.

The mapping between IPv4 and IPv6 header translation and the address translation formats are re-defined.

The NAT behavior mode that is helpful for service interworking during IPv4/IPv6 translation is specified.

18

2.2 Evolution Trends

IPv6 transition technologies have been enriched and developed in the past few years. Table 3 lists the recent changes of different transition technologies. The evolution trends of IPv4/IPv6 transition technologies are summarized as follows:

1. New transition technologies have begun to pay attention to how to assure service continuity in the case of IPv4 address exhaustion. In new transition technologies, NAT or carrier-grade NAT (CGN) is integrated to increase the number of IPv4 addresses in the transition period.

2. The deployment of transition technologies is simplified through automatic configuration so that end users can use the technologies more easily.

3. NAT-PT is simplified. ALG issues in the basic network protocol are separated from the NAT.

4. provider prefixes are used to supplant the well-known prefix so that address management is facilitated and the occurrence of a problem about router scalability can be avoided.

One more important trend of transition technologies is that the vital role acted by home gateways in an IPv6 transition is emphasized in the network. Home gateways decouple home networks from provider networks. Thus, the IPv6 evolution processes of home networks and provider networks are implemented separately. Currently, providers' services are penetrating slowly into home networks. IPv6 transition is a trigger point for replacing home gateways. Providers can seize the opportunity to bind home users.

Table 3 Evolution trends of transition technologies

Original Technique

6to4Configured tunneling

ISATAP SIIT NAT-PT Dual-Stack

Improved Technique

6rd Softwire Teredo IVI NAT64/DNS64 DS-lite

19

2.3 Optional Evolution Scenarios and Applications of Transition Technologies

In terms of the host system, all the current mainstream operating systems support dual stack. Considering preferences of different users, providers must provide users with both IPv4 and IPv6 services. Dual stack, however, is not required for networks. According to different evolution stages or different infrastructures of operation networks, providers can use different evolution solutions and network models to implement a smooth evolution from IPv4 networks to IPv6 networks.

Incremental IPv6 Deployment Based on the IPv4 Network

In the early stage of network evolution, the network infrastructure is constructed based on IPv4. Many old access network devices cannot be upgraded to IPv6. Owing to sparse distribution of few IPv6 users, the costs for an overall upgrade to IPv6 are huge and the input-output ratio is low. If the network is not upgraded, however, IPv6 users will choose the network of another provider. In that case, tunneling can enable rapid traversal of IPv4 network and fast service provisioning for IPv6 users.

Method 1: Layer 2 Tunneling Protocol (L2TP) tunnel shared by multiple users, as shown in a) of Figure 2. If users access the network over Point-to-Point Protocol (PPP) and the broadband remote access server (BRAS) supports the L2TP or GRE, this method is feasible. To provide IPv6 or dual-stack services, providers just need to add a dual-stack BRAS on the border of the IPv6 and IPv4 networks, without changing other network nodes. The original IPV4 users remain unchanged. When an IPv6 or dual-stack user uses PPP for dial-up access, the IPv4 BRAS identifies the user ID and forwards this PPP session through an L2TP tunnel to the dual-stack BRAS according to the user policy. Then the user accesses the IPv6 network and IPv4 Internet through the highly-equipped dual-stack BRAS. Dual-stack users can be allocated with private IPv4 addresses.

Method 2: one tunnel per IPv6 user, as shown in b) of Figure 2. For more details about this method, see the RFC 5569 and draft-v6ops-incremental-cgn. The customer premises equipment (CPE) is upgraded for the users who are willing to use IPv6. Providers just need to deploy

20

an IPv6 gateway on the border of the IPv6 and IPv4 networks. Other nodes continue using IPv4. IPv6 data is transferred to the IPv6 Internet through an IPv6-in-IPv4 tunnel established between the CPE and IPv6 gateway, which is illustrated by 6rd tunnels in Figure 2. In the case of IPv4 address shortage, CGN (NAT44) can be deployed to allocate private addresses to users and ports at the IPv4 side of the IPv6 gateway. Compared with method 1, method 2 does not have any restriction on the access type and tunnel type but more user tunnels are managed.

The incremental IPv4-based deployment of IPv6 has the following advantages:

The new dual-stack BRAS processes IPv6 services in a centralized manner.The existing network does not need consolidation or upgrade.The investment is the smallest.The deployment is simple and rapid.

Figure 2 Incremental deployment of IPv6 on an IPv4 network

a) L2TP tunnel shared by multiple users

Internet v4 Internet v6

BRAS (IPv4) BRAS (IPv4)

NAT44

IPv4

CPE CPE

Public IPv4 IPv6 IPv6

L2TPL2TP

BRAS (dual-stack)

Private IPv4/IPv6

21

b) One tunnel per IPv6 user

With the development of IPv6 networks, a new IPv6 BRAS or gateway is gradually moved down until it overlaps the existing IPv4 BRAS. The network becomes dual stack or even IPv6-only.

Deployment of IPv4-IPv6 Dual-Stack Networks

Deploying IPv4-IPv6 dual-stack networks is another evolution approach. Dual-stack networks are applicable to two scenarios:

In the medium term of evolution, both IPv4 and IPv6 traffic is heavy. Direct forwarding is more proper than tunneling.

Newer network devices that have the IPv6 capabilities need only to be enabled with IPv6 functions.

Internet v4 Internet v6

BRAS (IPv4) BRAS (IPv4)IPv4

CPECPE

IPv6IPv4/IPv6 IPv4

6RD TUNNEL 6RD TUNNEL

6RD GatewayNAT44

22

As previously mentioned, dual stack cannot solve the problem of IPv4 address shortage. NAT44 must be introduced, which is also called large scale NAT (LSN), as shown in Figure 3. An LSN is a NAT deployed in the provider network. It is easier to traverse than traditional NATs. In addition, it can support more private network users. LSN deployment does not affect IPv6 message flows.

Figure 3 Using dual stack and LSN to deal with IPv4 address shortage

Internet v4 Internet v6

CPECPE

Private IPv4/IPv6

IPv4/IPv6

IPv6

PELSN/NAT44

Dual-stack BRAS

Dual-stack BRAS

23

Direct Deployment of IPv6

Dual stack requires concurrent maintenance on the IPv4 and IPv6 networks. Certain new ISPs expect to directly deploy pure IPv6 to simplify network management and O&M, and solve the problem of access to the IPv4 network through IPv4-in-IPv6 tunnels. Dual-stack lite (DS-lite) has emerged to meet this demand.

As shown in a) of Figure 4, DS-lite consists of dual-stack hosts and IPv6 networks. In a DS-lite network, only CPEs and CGNs use dual stack while other network nodes support IPv6 only. CGNs must also support the IPv4-in-IPv6 tunnel and NAT44 functions. Home users can obtain both IPv6 and private IPv4 addresses. Hence, IPv6 packets can directly traverse CPEs into the IPv6 Internet. IPv4 packets reach a CGN through an IPv4-in-IPv6 tunnel between a CPE and the CGN. Then the CGN implements a tunnel decapsulation, converts private IPv4 addresses into pubic network addresses, and sends the addresses to the IPv4 Internet.

When DS-lite is used, many tunnels must be maintained. Port network address translation (PNAT) is a substitutionary solution for the following scenarios:

Certain networks cannot support a large number of tunnels. For example, radio networks lay more stress on transmission efficiency whereas tunnels increase overheads.

Providers do not want to maintain a large number of tunnels.

In PNAT, pure IPv6 networks are also deployed but translated into traditional IPv4 applications over a protocol for providing services. PNAT includes two translation points, as shown in b) of Figure 4:

NAT46 is implemented on the host or CPE for the traditional host to access the IPv6 network.NAT64 is implemented on the PANT-GW for access to IPv4 services from the IPv6 network.

24

Figure 4 Incremental deployment of IPv6 on an IPv4 network

a) DS-lite

Internet v4 Internet v6

BRAS (IPv6) BRAS (IPv6)

IPv6

CPE CPE

IPv6Private IPv4/IPv6

PE

4in6 tunnel

CGN

Stateless translation is applicable to direct IPv6 deployment in the case of IPv4 address shortage. Original IPv4 users can also access IPv6 resources. In this case, ISP allocates an independent IPv4 address and an IPv6 prefix to the IPv6 content server. The IPv6 prefix is released to the IPv4 network through the stateless translation gateway. The traffic in which IPv4 users access IPv6 services is transferred to the translation gateway for stateless translation and necessary ALG processing.

DS-lite, PNAT, and IVI require the deployment of pure IPv6 networks. They are applicable to new networks or the later stage of IPv6 evolution when IPv6 traffic prevails in the network.

25

Internet v4 Internet v6

BRAS (IPv6)

IPv6

CPE

IPv4/IPv6 UEIPv4 IPv6

The terminal implements a

4to6 translation

The CPE implements a

6to4 translation

PNAT-GW PE

b) PNAT

2.4 Summary

For a smooth evolution to IPv6, every aspect of the network must be considered from end to end. Moreover, other factors such as users, services, networks, and costs must also be considered. After proper planning, the evolution must be carried out step by step.

This document describes typical IPv6 transition technologies and application scenarios. Table 4 lists the analysis and comparison of the technologies and network status used in the transition solutions from several aspects. Owing to the variety of technologies and different situations of provider networks, each provider will certainly select a conservative, reposeful, or aggressive transition technology that is the most suitable for its own network.

26

Table 4 Comparison between different evolution solutions

Solution User Address Network Tunnel NAT/NAT-PT

IPv6 service provisioning based on the IPv4 network

Each user obtains a private IPv4 address. Users who are willing to use IPv6 can be allocated with IPv6 addresses.

R e t a i n i n g IPv4 6-o-4 NAT44

LSN + dual stackEach user is allocated with a private IPv4 address and an IPv6 address.

Upgraded to dual stack - NAT44

DS-Lite

Each user is provided with an IPv6 address. Users who are willing to use IPv4 can be provided with private IPv4 addresses.

New IPv6 networks 4-o-6 NAT44

Stateless translation

New IPv6 users are provided with IPv6 addresses. Original IPv4 users can access IPv6 resources.

New IPv6 networks - IVI

PNAT Each user is provided with an IPv6 address.

New IPv6 networks - NAT46/NAT64

In terms of evolution to IPv6, provider networks and customer networks differ in the pace. This can be decoupled through CPEs. No matter providers deploy single stack or dual stacks on their networks, the networks must provide both IPv4 and IPv6 services for users.

Huawei high-end metro router of series provide a complete IPv4-IPv6 solution, which can meet the requirements of transition to IPv6 in all the evolution scenarios previously described.

27

3 Acronyms and Abbreviations

Table 5 List of acronyms and abbreviations

Abbreviation/Acronym Full Spelling

IPv6 Internet Protocol Version 6

6PE IPv6 Provider Edge Routers

6VPE BGP-MPLS IP Virtual Private Network Extension for IPv6 VPN

6rd IPv6 Rapid Deployment

ALG Application Layer Gateway

BIA Bump-in-API

BIS Bump-in-the-stack

CGN Carrier-Grade NAT

GRE Generic Routing Encapsulation

DS Dual stack

ISATAP Intra-Site Automatic Tunnel Addressing Protocol

LSN Large Scale NAT

NAT-PT Network Address Translation-Protocol Translator

PNAT Prefix NAT

SIIT Stateless IP ICMP Translation Algorithm

TRT Transport Layer Translation

28

4 Reference

[1] Nordmark, E. and Gilligan, R. ”Basic Transition Mechanisms for IPv6 Hosts and Routers”, RFC4213. Oct. 2005

[2] Carpenter B, et al. Connection of IPv6 Domains via IPv4 Clouds[S ]. RFC 3056.

[3] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007

[4] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.

[5] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures (6rd)", RFC5569, July 2009.

[6] S. Jiang, D. Guo, and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition" draft-jiang-v6ops-incremental-cgn, work in progress, May 2009

29

[7] A. Durand, R. Droms, B. Haberman, and J. Woodyatt, "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-00, work in progress, March 2009

[8] X. Li, S. Dawkins, D. Ward, and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007

[9] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-bagnulo-behave-nat64-03 (work in progress), March 2009

[10] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64-00 (work in progress), July 2009

[11] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.

[12] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The CERNET IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", draft-xli-behave-ivi, (work in progress), January 2010.

[13] Templin F, Gleeson T, Thaler D. Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). RFC 5214 March 2008

30

[14] Huitema C. Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs), RFC 4380, February 2006

[15] Nordmark E. Stateless IP ICMP Translation Algorithm (SIIT ) [S ]. RFC2765, February 2000.

[16] Huang, B, Deng, H., .Prefix NAT: Host based IPv6 translation draft-huang-behave-pnat-01, (work in progress), February 2010.

[17] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.

[18] De Clercq, J., Ooms, D., Prevost, S., Le Faucheur, F., Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE), RFC4798, September 2006

31

32

Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518219People's Republic of China

Website: http://www.huawei.comEmail: support@huawei.com

Copyright © 2010 Huawei Technologies Co., Ltd. All rights reserved.No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions and other Huawei trademarks are the property of Huawei Technologies Co., Ltd.All other trademarks and trade names mentioned in this document are the property of their respective holders.

NoticeThe product, service, or feature that you purchase should be restricted by the Huawei commercial contract and the clauses in the contract. All or a part of products, services, or features described in this document may not be purchased or used. Every effort has been made in the preparation of this document to ensure the accuracy of the contents, but the statements, information, and recommendations in this document do not constitute a warranty of any kind, expressed or implied.The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure the accuracy of the contents, but the statements, information, and recommendations in this document do not constitute a warranty of any kind, expressed or implied.