Network Working Group Qiong Sun Internet Draft Chongfeng Xie Intended status: Standards Track China Telecom Expires: April 24, 2011 March 7, 2011 LAFT6: Lightweight address family transition for IPv6 draft-sun-v6ops-laft6-00.txt Abstract With the approaching exhaustion of IPv4 address space, large-scale ISPs are now facing the option to deploy IPv6 in a timely manner. However, most existing IPv6 transition solutions have tradeoff between scalability and efficiency. This draft proposes a lightweight address family transition mechanism named LAFT6. It only needs to maintain per-subscriber state entries in core network and there is no specific address format requirement for users' IPv6 address. It is a lightweight solution in terms of state-management, addressing and routing. The experimental results have shown that LAFT6 is scalable and can be rapidly deployed in commercial ISP network. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 7,2011. Sun Expires September 24 2011 [Page 1] Internet-Draft Lightweight address family transition March 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................ 3 2. Terminologies ............................................... 4 3. LAFT6 Overview .............................................. 5 3.1. Features of LAFT6....................................... 5 3.2. Deployment scenario..................................... 6 3.3. LAFT6 solution overview................................. 7 3.4. LAFT6 workflow ......................................... 7 4. LAFT-CGW element ........................................... 10 4.1. Initialization ........................................ 10 4.2. Extended Binding Table................................. 11 4.3. Packet Translation..................................... 11 4.4. Encapsulation/De-encapsulation......................... 12 4.5. Fragmentation and Reassembly........................... 12 4.6. LAFT-NGW discovery..................................... 12 4.7. DNS ................................................... 13 5. LAFT-NGW element ........................................... 13 5.1. Port-range Binding Table............................... 13 5.2. Encapsulation ......................................... 13 5.3. Fragmentation and Reassembly........................... 13 5.4. DNS ................................................... 14 6. Deployment Considerations for Broadband Provider............ 14 6.1. Addressing and Routing................................. 14 6.2. DNS ................................................... 14 6.3. AAA and User Management................................ 14 6.4. Placement in Large SP Network.......................... 15 6.5. ALG consideration...................................... 15 7. Security Considerations .................................... 15 8. IANA Considerations ........................................ 15 9. Appendix A: Experimental Result............................. 15 Sun Expires September 7, 2011 [Page 2] Internet-Draft Lightweight address family transition March 2011 9.1. Experiment environment................................. 16 9.2. Experiment configuration............................... 16 9.3. Experiment results..................................... 17 9.4. Conclusions ........................................... 17 10. References ................................................ 18 11. Acknowledgments ........................................... 19 1. Introduction Global IPv4 address exhaustion is becoming reality. The dramatic growth of the Internet is accelerating the consumption of available IPv4 addresses, which makes the address shortage problem even worse. It is widely accepted that IPv6 is the only answer to solve the address shortage problem and sustain the long-term growth of the Internet. However, IPv6 deployment is a huge systematic project and a lot of challenges will arise especially in large SP operational network. In order to facilitate smooth migration to IPv6-based Internet, many factors need to be taken into consideration, e.g. rapid deployment, scalability, backward compatibility, legal traceability and IPv6 encouragement. Thereinto, high scalability and efficiency are two factors which cannot be easily accomplished in the same time. Currently, most existing IPv6 transition mechanisms can be wildly divided into stateful and stateless solutions. Stateful ones, e.g. DS- Lite[I-D.ietf-softwire-dual-stack-lite], NAT64 [I-D.ietf-behave-v6v4- xlate-stateful], etc., need to keep per-session state in CGN. This will result in severe scalability problem especially for large-scale ISP networks. Moreover, the dynamic feature of session-based states will also bring a great burden on load balancing with state synchronization and legal traceability. While for stateless solutions, it has strict IPv6 address-format restriction in order to achieve algorithm-based translation. It is very scalable, simple and straightforward; however, it would also have impact on existing address allocation systems, CPE prefix delegation models and routing systems. Since these IPv6 addresses with embedded port index are not continuous anymore, existing DHCPv6 server have to introduce additional function to deal with port-range allocation, either by specifying individual IPv6 address for each end subscriber manually in DHCPv6 pool configuration, or taking modifications for automatic configuration. And then, CPE should re-allocate IPv6 address to end-user based on PD prefix, and announce individual IPv6 routing entry to access Sun Expires September 7, 2011 [Page 3] Internet-Draft Lightweight address family transition March 2011 routers. These functionalities have not been fully supported by existing systems. Therefore, existing solutions do not have a good tradeoff between stateful and stateless ones. For large scale operators, it is of vital importance to achieve high scalability and simplicity in core network. It is one of the key principles in the overall development of Internet and it would also be very important in the future. Although it is inevitable to multiplex IPv4 address with port range in IPv4/IPv6 coexistence period when the common problems discussed in [I-D.ietf-intarea-shared-addressing-issues] could not be totally avoided, a lightweight state-management solution is still encouraged. It could simplify the packet processing procedure, state synchronization and traffic logging, etc., compared to session- based stateful solution. Furthermore, it is also very important for network operators to adopt flexible addressing. A solution with no specific addressing requirement can make use of existing IPv6 addressing and routing model as much as possible. As a result, it can be rapidly deployed in operational network when facing pressing IPv4 address shortage problem. Network operators could further define more flexible addressing plans according to different service requirement. In this document, we propose a scalable lightweight solution named LAFT6. It only needs to maintain per-subscriber state entries in core network and there is no specific address format requirement for each IPv6 address. 2. Terminologies LAFT-CGW LAFT Customer-side Gateway LAFT-NGW LAFT Network-side Gateway Addr4-user IPv4 address for end node Addr4-CGW-pub Multiplex Public IPv4 address for LAFT-CGW Addr6-user IPv6 address for end node Addr6-CGW IPv6 address for LAFT-CGW Addr6-NGW IPv6 address for LAFT-CGW Port-range-CGW Port range of LAFT-CGW Sun Expires September 7, 2011 [Page 4] Internet-Draft Lightweight address family transition March 2011 Pref64 Prefix for translation 4to4 table: binding table in LAFT-CGW for IPv4 sources with IPv4 receivers 6to4 table: binding table in LAFT-CGW for IPv6 sources with IPv4 receivers The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 3. LAFT6 Overview 3.1. Features of LAFT6 Instead of relying on a large carrier-grade session-based NAT, LAFT6 solution is built on IPv4-in-IPv6 tunnels to reach a lightweight subscriber-based NAT in the carrier side. Two major features of LAFT6 are lightweight state management and addressing. For lightweight state management, LAFT6-NGW only needs to maintain the mapping pair between IPv4 address (denoted by Addr4-CGW-pub), available port range (denoted by Port-range-CGW) with IPv6 address( denoted by Addr6-CGW)for each subscriber. Thus, it could dramatically reduce the size of state database compared to session-based solutions, e.g. DS-Lite, NAT444, NAT64, etc. There are numbers of benefits to this feature: o The state management in Carrier-grade NAT is largely simplified, including searching, inserting and deleting process, not only due to the fact that the size of state database has been reduced to a great extend, but also the number of dimension for each state has been decreased from 5-dimensional session-based tuple to 3- dimensional subscriber-based tuple (IPv6 address, IPv4 address and port range). Therefore, it can easily support larger amount of subscribers when deployed in the same placement than session-based solutions. Sun Expires September 7, 2011 [Page 5] Internet-Draft Lightweight address family transition March 2011 o It can simplify the complexity in traffic logging system. It only needs to record IPv4 address, available port range, IPv6 address and time stamp for each subscriber. While for session-based solution, logging system needs to record the 6-dimensional tuple including IPv4 source address, IPv4 destination address, source port, destination port, protocol and timestamp, other than solutions taking into account the advice given in [I-D.behave- natx4-log-reduction]. o State synchronization and HA (High Availability) is easier to achieve since the binding state for a specific subscriber is more stable during the whole login process. For lightweight addressing, LAFT6 has no additional requirements on IPv6 address format. In this way, the addressing and routing of the service provider access network is simplified by leveraging existing IPv6 addressing and routing system. And more flexible addressing for different services and applications can be achieved conveniently. As a result, LAFT6 can be deployed rapidly in operational network. 3.2. Deployment scenario The LAFT6 function is implemented in a customer side gateway (LAFT-CGW) and a carried grade gateway (LAFT-NGW) (as depicted in Figure1). +------+ // \\ ------------ / \ / \ +------+ + +----------+ | | IPv4 +-----+ | | LAFT-NGW | IPv4 Internet | | node | | | +----------+ | +------+ | +----------+ IPv6-only | \ / +--+ LAFT-CGW | network | ------------ | | HGW | | | +----------+ | ------------ +------+ | | | / \ | IPv6 | | | +----------+ | | node |-----+ | | CR | IPv6 Internet | +------+ + +----------+ | \ / \ / \\ // ------------ +------+ Figure 1 LAFT6 deployment scenario It is mainly designed for end nodes with a customer gateway in broadband access network. For example, in the future home network, it would be common that there are IPv4-only computers, dual-stack computers, Sun Expires September 7, 2011 [Page 6] Internet-Draft Lightweight address family transition March 2011 IPv6-only sensors located behind the same home gateway. Therefore, LAFT- CGW is designed to accommodate different scenarios gracefully and it is up to LAFT-CGW to determine which scenario it would like to support, while LAFT-NGW is simple and it can deal with different scenarios in the same way. LAFT6 can be applied to both scenarios where IPv4 sources communicate IPv4 receivers (denoted as 4to4) and IPv6 sources communicate with IPv4 receivers (denoted as 6to4). It can also support IPv6 sources communicating with IPv6 receivers in a native way without further treatment. In home Local Area network, which is characterized by the presence of a home gateway, or CPE, provisioned only with IPv6 by the service provider, a LAFT CPE is an IPv6-aware device with a LAFT-CGW Interface implemented in the WAN interface. LAFT-NGW element is implemented in a device which has (at least) two interfaces, an IPv4 interface connected to the IPv4 network, and an IPv6 interface connected to the IPv6 network. It is usually deployed in core network. 3.3. LAFT6 solution overview In the initial phase, the end user and LAFT-CGW(e.g. located in Home gateway) would get their individual IPv6 address (denoted as Addr6-user and Addr6-CGW) through traditional PPPoE, IPoE, etc. Besides, the end user would also get its private IPv4 address (denoted as Addr4-user) which is determined by LAFT-CGW only. After that, LAFT-CGW would be allocated a port range (denoted as Port-range-CGW), a public address (denoted as Addr4-CGW-pub) via PCP protocol [I-D.tsou-pcp-natcoord], and notify LAFT-NGW with its own IPv6 address (Addr6-CGW). LAFT-NGW would keep 3-tuple, which includes Addr4-CGW-pub, Port-range-CGW and Addr6-CGW. In LAFT6, LAFT-CGW can deal with session-based packet translation like traditional NAT, except that it would change the randomly generated source port to a valid port number within the range of Port-range-CGW. At the same time, it will deal with different scenarios accordingly. While in LAFT-NGW, on the other hand, it only needs to do packet encapsulation/ de-encapsulation according to the address mapping table in LAFT-NGW for different scenarios. Although it is a little complicated in LAFT-CGW, there will be not many new functionalities to implement since customer-side NAT is a quite common function for most current CPEs. 3.4. LAFT6 workflow For upstream packets originated from IPv4 sources and destined for a receiver located in the IPv4 network, LAFT-CGW will firstly change the randomly generated source port to a valid port selected from Port-range- Sun Expires September 7, 2011 [Page 7] Internet-Draft Lightweight address family transition March 2011 CGW, then change the private IPv4 address to its Addr4-CGW-pub and encapsulate in IPv6 packet directed to LAFT-NGW. The corresponding mapping table with IPv4 addresses and port number will be maintained in LAFT-CGW. The LAFT-NGW will only need to de-encapsulate the packet and forward them as IPv4 packets through the IPv4 network to the IPv4 receiver. There is no packet translation in LAFT-NGW anymore. For downstream IPv4 packet, LAFT-NGW will extract the IPv4 destination address and destination port from the incoming packet, lookup the mapping table, determine the corresponding IPv6 address and then tunneled to LAFT-CGW. LAFT-CGW will also de-encapsulate the packet, lookup the mapping table for each packet, determine the original port number and private IPv4 address, and translate the packet back again. The workflow of 4to4 communication is depicted in the following Figure 2. +-----------+ Packet Workflow Example | Host | +-----+-----+ +---------------------------+ 192.168.0.2 | |src address: 192.168.0.2| | |src port: 9201 | | +---------------------------+ 192.168.0.1 | +---------|---------+ | | | | Home Gateway | |+--------+--------+| || LAFT-CGW || |+--------+--------+| | |NAT| | | +-+-+ | +--------|||--------+ +---------------------------+ 2001:c68:0:1::1||| |src addr6: 2001:c68:0:1::1| 210.25.112.69||| |src addr4: 210.25.112.69 | IPv4-in-IPv6 Tunnel->>||| |src port: 2001 | ||| +---------------------------+ -------|||------- / ||| \ | ISP core network | \ ||| / -------|||------- +---------------------------+ ||| |src addr4: 210.25.112.69 | 2001:c68:0:2::1||| |src port: 2001 | 210.25.112.69||| +---------------------------+ +--------|||--------+ | LAFT-NGW | | | | Sun Expires September 7, 2011 [Page 8] Internet-Draft Lightweight address family transition March 2011 +---------|---------+ 210.25.112.69| | --------|-------- / | \ | Internet | \ | / --------|-------- | |198.51.100.1 +-----+-----+ | IPv4 Host | +-----------+ Figure 2 Workflow of 4to4 communication For packets generated from IPv6 sources for a receiver located in the IPv4 network, the LAFT-CGW will not only need to change the random source port to a valid port in the Port-range-CGW,and change the IPv6 address to Addr4-CGW-pub, but also translate the IPv6 packet to an IPv4 packet. Then, the traversed IPv4 packet with Addr4-CGW-pub will also be encapsulated in IPv6 packet and then tunneled to LAFT-NGW. In this IPv6 header, the source address is Addr6-CGW, rather than Addr6-user in the original IPv6 packet generated by IPv6 source. LAFT-NGW will take the same procedure as in the 4to4 scenario. The workflow of 6to4 communication is depicted in the following Figure 3. +-----------+ Packet Workflow Example | Host | +-----+-----+ 2001:c68:0:3::2||| +---------------------------+ ||| |src addr6: 2001:c68:0:3::2 | ||| |src port: 9103 | 2001:c68:0:3::1||| +---------------------------+ +---------|---------+ | | | | Home Gateway | |+--------+--------+| || LAFT-CGW || |+--------+--------+| | |NAT| | | +-+-+ | +--------|||--------+ +---------------------------+ 2001:c68:0:1::1||| |src addr6: 2001:c68:0:1::1| 210.25.112.69||| |src addr4: 210.25.112.69 | IPv4-in-IPv6 Tunnel->>||| |src port: 2002 | Sun Expires September 7, 2011 [Page 9] Internet-Draft Lightweight address family transition March 2011 ||| +---------------------------+ -------|||------- / ||| \ | ISP core network | \ ||| / -------|||------- +---------------------------+ ||| |src addr4: 210.25.112.69 | 2001:c68:0:2::1||| |src port: 2002 | 210.25.112.69||| +---------------------------+ +--------|||--------+ | LAFT-NGW | | | | +---------|---------+ 210.25.112.69| | --------|-------- / | \ | Internet | \ | / --------|-------- | |198.51.100.1 +-----+-----+ | IPv4 Host | +-----------+ Figure 3 Workflow of 6to4 communication 4. LAFT-CGW element The LAFT-CGW element is a function implemented on CPE. LAFT-CGW need to perform initialization, build extended binding table, do packet translation, encapsulation, fragmentation and reassembly, and DNS proxy, etc. 4.1. Initialization In the initialization phase, each LAFT-CGW device will get its own IPv6 address by existing user authentication process, and it will also get Addr4-CGW-pub and Port-range-CGW by extended protocols []. Furthermore, it would allocate private IPv4 address to IPv4 or dual- stack end-users. . Sun Expires September 7, 2011 [Page 10] Internet-Draft Lightweight address family transition March 2011 4.2. Extended Binding Table There are two kinds of binding tables in LAFT-CGW element: one is 4to4 scenario (denoted as 4to4 table) and the other is 6to4 scenario (denoted as 6to4 table). There are conceptual dynamic data structures to construct the 4to4 and 6to4 binding table, with TCP, UDP and ICMP respectively. In case of TCP and UCP, each state entry specifies a mapping between the IP address and port number: (X',x) <--> (T,y) where X' is Addr4-user in 4to4 mapping table and is Addr6-user in 6to4 table, T is the Addr4-CGW-address for both 4to4 table and 6to4 table, x is the original random port created by upper-layer application for LAFT- CGW and y is the translated port in Port-range-CGW. A given IPv6 or IPv4 transport address can appear in at most one entry in a binding table since TCP and UDP have separate binding tables because TCP and UDP have different port number space. In the case of the ICMP Query, each ICMP Query binding entry specifies a mapping between an (IP address, ICMP Identifier) pair. (X',i1) <--> (T,i2) where X' and T are the same as in the above table, i1 and i2 are an ICMP Identifiers in 4to4 case and are an ICMPv6 Identifiers in 6to4 case. A given (IPv6 or IPv4 address, ICMPv6 or ICMPv4 Identifier) pair can appear in at most one entry in the ICMP Query. Each upstream packet will construct a binding entry in case there is no existing binding entry in the extended binding table. It will determine the traversed port number for each packet. For downstream packet, LAFT-CGW knows how to re-construct IPv4/IPv6 packet when the packets comes back from by doing a reverse look-up in the extended IPv4 NAT binding table. 4.3. Packet Translation In LAFT-CGW, packet translation includes network-layer header translation and transport-layer header translation. o Network-layer header translation Sun Expires September 7, 2011 [Page 11] Internet-Draft Lightweight address family transition March 2011 For both IPv4 and IPv6 packet, it will change the end user address to Addr4-CGW. For IPv6 packet, it MUST be performed according to SIIT [RFC2765] except the source addresses in the header. o Transport-layer header translation In LAFT-CGW, source port should be changed to the conversed port according to extended binding table. Since the TCP and UDP headers [RFC0793] [RFC0768] consist of check sums which include the IP header, the recalculation and updating of the transport-layer headers MUST be performed. 4.4. Encapsulation/De-encapsulation The tunnel is a multi-point to point IPv4-in-IPv6 tunnel ending on a service provider LAFT-NGW. The upstream IPv4 packet will be encapsulated in IPv6 header and tunneled to LAFT-NGW. In the same way, the downstream IPv6 tunneled packet will be de-encapsulated in LAFT-CGW. 4.5. Fragmentation and Reassembly Fragmentation and Reassembly is the most time-consuming task for LAFT-CGW. Thus, it is better to deal with this problem, either by increasing the MTU size of all the links between the LAFT-CGW element and the LAFT-NGW elements or by limiting the size of packet generated by end users. However, as not all service providers will be able to control the links or the packet size, the LAFT-CGW element MUST perform fragmentation and reassembly if the outgoing link MTU cannot accommodate the packet IPv6 transmission due to the addition of the extra IPv6 header. Fragmentation MUST happen after the encapsulation on the IPv6 packet. Reassembly MUST happen before the de-capsulation of the IPv6 header. The IETF standard for Fragmentation and MTU Handling is defined in [I- D.ietf-behave-v6v4-xlate], which contains updated technical specifications. 4.6. LAFT-NGW discovery In order to configure the IPv4-in-IPv6 tunnel, the LAFT-CGW element needs the IPv6 address of the LAFT-NGW element. In order to guarantee interoperability, a LAFT-CGW element SHOULD implement the DHCPv6 option defined in [I-D.ietf-softwire-ds-lite-tunnel-option]. Sun Expires September 7, 2011 [Page 12] Internet-Draft Lightweight address family transition March 2011 4.7. DNS A LAFT-CGW element is only configured from the service provider with IPv6 address, so it can only learn the address of a DNS recursive server through DHCPv6 (or other similar method over IPv6). As DHCPv6 only defines an option to get the IPv6 address of such a DNS recursive server, the LAFT-CGW element cannot easily discover the IPv4 address of such a recursive DNS server, and as such will have to perform all DNS resolution over IPv6. As a result, the LAFT-CGW element SHOULD implement a DNS proxy, following the recommendations of [RFC5625]. When LAFT6 is applied to 6to4 scenario, it should also perform DNS64 [I-D.ietf-behave-dns64] in case there is no DNS64 server located in the local network. It should be configured with a Pref64 to synthesize IPv6 address. For AAAA request, the DNS64 will query the AAAA response. If there is no response for a certain period, it will reconstruct an A request and synthesize an AAAA response. 5. LAFT-NGW element An LAFT-NGW element is the combination of an IPv4-in-IPv6 tunnel end-point. LAFT-NGW element is a light-weight end-point which only needs to do port-range management, encapsulation, fragmentation and reassembly, etc. 5.1. Port-range Binding Table In LAFT-NGW, there is one Port-range Binding tale for TCP, UDP and ICMP. Each state entry specifies a mapping between the IP address, port range: (X') <--> (T,pr) where X' is the IPv6 address of LAFT-CGW (Addr6-CGW), T is the user's Addr4-CGW, and pr is Port-range-CGW for each user. pr can be continuous, discrete or partial random. This binding table can be used for both 4to4 and 6to4 scenarios. 5.2. Encapsulation The tunnel is a point-to-multipoint IPv4-in-IPv6 tunnel ending at the LAFT-CGW elements. 5.3. Fragmentation and Reassembly Fragmentation and Reassembly will be performed if the underlying link MTU cannot accommodate packet transmission due to addition of the Sun Expires September 7, 2011 [Page 13] Internet-Draft Lightweight address family transition March 2011 extra IPv6 header of the tunnel. Fragmentation MUST happen after the encapsulation on the IPv6 packet. Reassembly MUST happen before the de- capsulation of the IPv6 header. Methods to avoid fragmentation, such as rewriting the TCP MSS option or using technologies such as Subnetwork Encapsulation and Adaptation Layer defined in [I-D.templin-seal] are out of scope for this document. 5.4. DNS As noted previously, LAFT6 node implementing a LAFT-CGW element will perform DNS resolution over IPv6. As such, very few, if any, DNS packets will flow through the LAFT-NGW element. 6. Deployment Considerations for Broadband Provider 6.1. Addressing and Routing In LAFT6, there is no additional addressing and routing requirements. Thus, the process of IPv6 address assignment and routing entry establishment can be integrated with existing IPv6 address allocation process, e.g. using PPPoE or IPoE, etc. 6.2. DNS In LAFT6, since there is no IPv4 DNS server in IPv6-only network, it is recommended that LAFT-CGW should implement IPv4-to-IPv6 DNS Proxy to convert an IPv4 DNS request/response to IPv6 DNS request/response accordingly. When applied to scenarios for IPv6 sources communicating with IPv6 receivers, DNS64 should be deployed. In case there is no DNS64 deployed in IPv6 operational network, it is recommended that DNS64 should be integrated into LAFT-CGW. 6.3. AAA and User Management User authentication can be used to control who can have the LAFT6 connectivity service. In the initial phase of deployment, the maximum number of port number for subscribers can be configured uniformly in LAFT-NGW. But it is still recommended that AAA would define the maximum number of port number for different subscribers to offer better security and differentiated service. Sun Expires September 7, 2011 [Page 14] Internet-Draft Lightweight address family transition March 2011 6.4. Placement in Large SP Network Normally, LAFT-NGW can be deployed in "centralized model" and "distributed model". In "centralized model", LAFT-NGW could be deployed in the place of Core Router. Since LAFT-NGW has good scalability and it can handle numerous concurrent sessions, we strongly recommend adopting "centralized model" for LAFT6 as it is a cost-effective way and easy to manage. In "distributed model", LAFT-NGW is usually be integrated with BRAS/SR. Since the newly emerging customers might be distributed in the whole Metro area, we have to deploy LAFT-NGW on all BRAS/SRs. This will cost a lot in the initial phase of IPv6 transition period. 6.5. ALG consideration Currently, LAFT6 can support most of existing applications, such as HTTP, SSH and Telnet. However, some applications are designed such that IP addresses are used to identify application-layer entities (e.g. FTP). In these cases, application layer gateway (ALG) is unavoidable, and it can be integrated into the LAFT-CGW. Since there is no address and port mapping in LAFT-NGW, there is no ALG needed anymore in carrier side network. 7. Security Considerations There are no security considerations in this document. 8. IANA Considerations This memo adds no new IANA considerations. 9. Appendix A: Experimental Result We have tested LAFT6 using the prototype in our operational network of HuNan province, China. The major objective listed in the following is to verify the functionality and performance of LAFT6: O Verify how to deploy LAFT6 in practical network. O Verify what applications can be used in LAFT6. O Verify the effect of user experience with limited ports. Sun Expires September 7, 2011 [Page 15] Internet-Draft Lightweight address family transition March 2011 O Verify the performance of LAFT6. 9.1. Experiment environment The network topology for this experiment is depicted in Figure 4. +-----+ +-----+ |Host1+--+ CGW +----+ -------- +-----+ +-----+ | /// \\\ | /------\ // \\ | // \\ +-----+ | | +-----+ +-----+ +-+--+ | IPv6 | | | | IPv4 Internet | |Host2+--+ CGW +--+BRAS+--| Network |---| NGW +--+ | +-----+ +-----+ +-+--+ \\ // | | \\ // | \---+--/ +-----+ \\\ /// | | --------- +-----+ +-----+ | | |Host3+--+ CGW +----+ | +-----+ +-----+ | ------ | // \\ | / \ +-------------------+IPv6 Internet + | | \ / \\ // ------- Figure 4 LAFT6 topology in the test There are three key components in the test: o The Hosts are dual-stack or IPv6-only customers, who could run IPv4 application, IPv6 application or dual stack application. o The Home Gateways (Hgw) are LAFT-CGW in user side. It would do packet translation, encapsulation, fragmentation and reassembly, and DNS proxy, etc. o The LAFT-NGW encapsulate/de-encapsulate the packet according to the mapping table in LAFT-NGW. 9.2. Experiment configuration For address configuration, each host will get it IPv6 address through PPPoE process. And there is no explicit routing configuration needed. Sun Expires September 7, 2011 [Page 16] Internet-Draft Lightweight address family transition March 2011 For port configuration, we allocate each user with 2000 maximum available ports in LAFT-NGW. We have not implement AAA system with additional port-number notification. For DNS configuration, since LAFT-CGW has implemented DNS64 itself, there is no DNS64 needed anymore in our operational network. 9.3. Experiment results In our trial, we mainly have taken the following tests: o Application test: The applications we have tested include web, email, Instant Message, ftp, telnet, SSH, video, Video Camera, P2P, online game, Voip, VPN and so on. o Operating System test: The OS we have tested includes Win7, VISTA, windows XP. o Performance test: We have measured the parameters of concurrent session number, throughput performance. The experimental results are listed as follows: |----------------------|-------------------------------------------| | Type | Experiment Result | |----------------------|-------------------------------------------| | Application test | LAFT hosts can support web, email, im, ftp| | | , telnet, SSH, video, Video Camera, P2P, | | | online game, voip, and so on. | |----------------------|-------------------------------------------| | Operating System test| LAFT can widely support Win7, VISTA, | | | windows XP. | |----------------------|-------------------------------------------| | | The performance test for LAFT-NGW is | | | carried out on a normal PC. | | Performance test | Due to limitation of the PC hardware, the | | | overall throughput is not quite good. | | | However, it can still support more than | | | one hundred million concurrent subscribers| |----------------------|-------------------------------------------| Figure 5 LAFT6 test result 9.4. Conclusions From the experiment, we can have the following conclusions: Sun Expires September 7, 2011 [Page 17] Internet-Draft Lightweight address family transition March 2011 o LAFT6 has good scalability. LAFT-NGW is a lightweight solution which only maintains per-subscriber state information. As a result, it can easily support a large amount of concurrent subscribers. o LAFT6 can be deployed rapidly. There is no modification to existing addressing and routing system in our operational network. And it is simple to achieve traffic tracing and logging. o LAFT6 can support a majority of current IPv4 applications and it can support a variety of Operating Systems. 10. References [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack- lite-06 (work in progress), August 2010 [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf- behave-v6v4-xlate-stateful-12 (work in progress), July 2010. [I-D.ietf-intarea-shared-addressing-issues] M. Ford, Ed., M. Boucadair, A. Durand, P. Levis, P. Roberts, "Issues with IP Address Sharing", draft-ietf-intarea-shared-addressing- issues-04 (work in progress), February 2011. [I-D.behave-natx4-log-reduction] T. Tsou, W. Li, T. Taylor, "Port Management To Reduce Logging In Large-Scale NATs", draft- tsou-behave-natx4-log-reduction-02(work in progress), September 2010. [I-D.ietf-softwire-ds-lite-tunnel-option] D. Hankins, T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", draft-ietf-softwire-ds-lite- tunnel-option-08 (work in progress), January 2011 [RFC5625] R. Bellis, "DNS Proxy Implementation Guidelines", RFC5625, August 2009. [I-D.ietf-behave-dns64] Bagnulo, M., "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64-10.txt, July 2010. Sun Expires September 7, 2011 [Page 18] Internet-Draft Lightweight address family transition March 2011 [I-D.tsou-pcp-natcoord] T.Tsou, C.Zhou, Q.Sun, T.Taylor, "Using PCP To Coordinate Between the CGN and Home Gateway Via Port Allocation", draft-tsou-pcp-natcoord-00.txt, March 4, 2011. 11. Acknowledgments The authors would like to thank to Fred Baker and Tony Hain for his continuous suggestion around this topic over the years. Thanks to Qian Wang, Jie Hu and Fan Shi for useful feedback. Authors' Addresses Qiong SUN China Telecom Beijing Research Institute Room 708 No.118, Xizhimenneidajie, xicheng District Beijing 100035 China Phone: <86 10 58552936> Email: sunqiong@ctbri.com.cn Chongfeng Xie China Telecom Beijing Research Institute Room 708 No.118, Xizhimenneidajie, xicheng District Beijing 100035 China Phone: <86 10 58552116> Email: xiechf@ctbri.com.cn Sun Expires September 7, 2011 [Page 19]