Internet Engineering Task Force G. Yang Internet-Draft C. Huang Intended status: Informational Y. Wu Expires: November 24, 2011 China Telecom May 23, 2011 The analysis of tools selection for broadband ISP draft-yang-v6ops-fast6-tools-selection-00 Abstract NAT444, DS-LITE, 6RD and other transition technologies have been well done, the ISP should select the most suitable tool to meet the requirements of a typical broadband access network in the real world regarding its network architecture, operation situation and transition goals, etc. According to the mainstream broadband access network, this draft focuses on analyzing the problems that may be encountered when using various transitional technologies during the transition and finally introduces a more systematic and operational proposal. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on November 24, 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 Yang, et al. Expires November 24, 2011 [Page 1] Internet-Draft FAST6-tools selection May 2011 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Brief Description of ISP's Broadband Network . . . . . . . . . 3 5. Transition Principles . . . . . . . . . . . . . . . . . . . . 4 6. Technologies Selection . . . . . . . . . . . . . . . . . . . . 4 6.1. Goal Consistency . . . . . . . . . . . . . . . . . . . . . 5 6.2. Application Continuity . . . . . . . . . . . . . . . . . . 5 6.3. User Habit . . . . . . . . . . . . . . . . . . . . . . . . 5 6.4. Network Scalability . . . . . . . . . . . . . . . . . . . 6 7. DS-lite & NAT444 . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Deployment differences . . . . . . . . . . . . . . . . . . 6 7.2. CPE diversity . . . . . . . . . . . . . . . . . . . . . . 7 7.3. Cost Difference . . . . . . . . . . . . . . . . . . . . . 7 7.4. O&M Diversity . . . . . . . . . . . . . . . . . . . . . . 7 7.5. Supporting system Differences . . . . . . . . . . . . . . 8 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Yang, et al. Expires November 24, 2011 [Page 2] Internet-Draft FAST6-tools selection May 2011 1. Introduction Various transition tools have been proposed and well optimized.The ISP should select most suitable tools to meet the requirements of a mainstream broadband access network in the real world regarding its network architecture, operation situation and transition goals, etc. To satisfy the typical broadband access network, which provides subscribers internet service through PPPOE via L2 access network, this draft filters numbers of transition technologies basing on specific principles. Then, a detailed comparison is made between native dual-stack and tunnels, represented by NAT444 and DS-lite respectively. It is concluded that native dual-stack is more appropriate than tunnels for this specific network. At last, this draft points out some problems that NAT444 are not designed to solve during each period of transition and refers to a more systematic and operational proposal. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Terminologies To be continued. 4. Brief Description of ISP's Broadband Network At the present stage, there are two major service models: PPPoE and IPoE for operators to provide broadband access service to the subscriber. In some scenes, PPPoE offers better security and control functions for the home user than IPoE, and relatively more suitable for broadband service. But IPoE is more appropriate for multicast services. For broadband access network, it's reasonable to believe that PPPoE is much more popular than the other one. So, it is urgent to do some research on this typical broadband access model. Broadband access network which uses PPPoE technology also has following characteristics: o L2 access network; o Bridged mode or routed mode CPE are both permitted for users; Yang, et al. Expires November 24, 2011 [Page 3] Internet-Draft FAST6-tools selection May 2011 o Large number of existing users, it grows rapidly and IPv4 address depletion has a direct impact on services; o Due to large network, there is enormous number of network devices and part of them cannot support IPv6 in the future. Although this kind of equipment will be replaced partially , this situation will last for a long period. That means in current network, there will be a number of equipments that are unable to be updated to support IPv6. The new ISP can achieve the goal in one leap through building a new network. However, for some old brand ISPs with heavy load on transition for their large number of subscribers and diverse situation of the legacy devices, choosing an appropriate transition strategy is a key point for development, and has a great impact in the future. 5. Transition Principles The ISP requirement for IPv6 transition is depend on ISP's role. As a company, making profit is the most important goal of ISP. Therefore, for example, when the network is transiting to IPv6, a more mature and stable technology is more applicable to be chosen than a newer, more creative and greener one. ISP is also different from equipment manufacturers for they pursuit a balance between user experience and investment. For instance, when make an IPv6 transition route, a conservative one maybe more popular than an aggressive one. From the perspective of an ISP, principles of network migration are concluded as follows: o Ensure user experience.; o Save cost; o Reduce technical risks; o Convenient operation and maintenance. o Security supervision. 6. Technologies Selection Now there are two solutions for IPv4 address depletion: using private IPv4 (RFC1918) and IPv6. For private IPv4, there are two transition Yang, et al. Expires November 24, 2011 [Page 4] Internet-Draft FAST6-tools selection May 2011 technologies: A+P and NAT. For IPv6, there are two types of transition mechanisms, the first type is dual-stack, including 6RD, NAT444, DS-LITE, etc., and the second type is native IPv6, including PNAT, 1:N IVI, NAT64, etc,. This chapter would describe the transitional problems related to the existing transitional technologies, under the principles of technical choice, and considering the current situation of broadband access network. 6.1. Goal Consistency In the short term, to permit the network to continue to grow, a series of tools are developed. These tools include more efficient use of the IPv4 address resource, conservation, and the sharing of IPv4 addresses through the use of NAT. While these provide partial mitigation for IPv4 exhaustion, they are not a long-term solution, increase network costs, and merely postpone some of the consequences of address exhaustion without solving the underlying problem. Some of these fixes break end-to-end connectivity, impairing innovation and hampering applications, degrading network performance, and resulting in an inferior version of the Internet. Network operators will be confronted with increased costs to offer potentially inferior service. The short term solution is problematic. The "solution to the solution" is to complete the transition to the native IPv6 network. So, using NAT and A+P can obstruct the development of IPv6, and it's inconsistent with the goal of the Next Generation Internet. 6.2. Application Continuity There are lots of applications that don't support IPv6, and many are not workable in native IPv6 network. Some other applications, such as VoIP, IM, P2P, etc,couldn't traverse through NAT64 or 1:N IVI. Besides, at the beginning of transition, there are still lots of IPv4 resources, which don't support IPv6 yet. Using a native IPv6 solution will have a great impact on the customers, so it can only be used in a specific scenario or in the later transitional period. Therefore, the terminal can't directly be pure IPv6, unless it is a special set-top box or mobile phone. In other words, the pure IPv6 solution is not suitable for the continuity of existing applications. 6.3. User Habit ISP should not force customers to install application in their terminals. First of all, users reject installing software mandatorily. In addition, there is no clear management boundary for Yang, et al. Expires November 24, 2011 [Page 5] Internet-Draft FAST6-tools selection May 2011 mandatory software installation. ISP has the right to manage user software or not is questionable. So the terminal software for PNAT, DS-LITE is not suitable. 6.4. Network Scalability With the continually increasing number of subscribers, the network scale will correspondingly expand. 6RD cannot meet the requirements of the network when their trends are native IPv6 or dual-stack, since it is only applicable in native IPv4 network. In summary, considering the fitness of the long term goal of Internet, the continuity of applications, end user application habits and network scalability, and according to this specific broadband network scenario, the native IPv4, native IPv6 and part of the dual- stack transition skills are not proper to be deployed. It seems like that NAT444 and DS-lite are more applicable to choose. 7. DS-lite & NAT444 Both DS-lite and NAT444 are belonging to dual-stack tools and they are different in technology maturity, equipment maturity and applicable scenarios. NAT444 is composed of mature tools while DS- lite is a green technology and has a long way to be a standard. In addition, NAT has existed for many years in firewall while DS-lite is only on its way of trial with no large-scale commercial deployment cases. NAT444 and DS-lite are the same in consuming IPv4 address number, and they are all supported by current mainstream Internet applications. Which is more suitable for this typical broadband network? The detailed analysis is as below: 7.1. Deployment differences The difficulties of switchover and deployment for NAT444 and DS-LITE are basically the same. However, NAT444 is much more flexible in deployment for it can be allocated either in distributed way or centralized way. In comparison, DS-lite prefers centralized deployment because the distributed way is meaningless for the specific scenario. The reason is that if AFTR is distributed besides the BNG, there is no native IPv6 network for DS-lite to show its advantages, since in this typical broadband network scenario, the access network is composed of L2 equipments which are unaware of IPv6. In addition, at present, the native IPv6 network has not been tested for a long time enough, there is a considerably high risk for the operators to carry the most important service traffic over it. Yang, et al. Expires November 24, 2011 [Page 6] Internet-Draft FAST6-tools selection May 2011 In conclusion, in the initial period of transition, it is not proper to use DS-lite for the large quantity of IPv4 traffic. 7.2. CPE diversity Currently, most CPEs are in bridged-mode and they have already supported NAT444. The newly developed CPEs are baring dual-stack and consequently support NAT444. When the legacy CPE are used to deploy NAT444, the running IPv4 services will not be impacted. However, if the CPE is transformed to support DS-lite, despite the NAT444 function, the tunnel function should also be incorporated. The CPEs can not access the current IPv4 services if they are not replaced with an updated one when DS-lite is deployed. In conclusion, NAT444 can not only continue the existing terminal strategies but also keep the existing service model unchanged when using routed or bridged CPE to support PPPOE accessing. In contrast, DS-lite cannot easily be socialized for its customized routed-model CPE. 7.3. Cost Difference Considering the network cost aspect, NAT444 has very little difference from DS-lite. From the perspective of terminal, DS-lite costs slightly higher than NAT444GBP"because it should support DS-lite despite of dual- stackGBP(C)for the new subscribers. For the legacy ones, if they use NAT444, they have no need to replace the bridged-mode CPE and the routed-mode CPE only need to support IPv6. It is very easy for NAT444 to socialize and lower the operation cost. In contrast, the DS-lite technology is not mature,it will impact existing IPv4 service once they are running abnormally and consequently cause the lost of customers. DS-lite has larger risk in cost. In terms of operation, NAT444 can follow the traditional operation method with low cost while DS-lite has high risk on cost for changing the original operation way. 7.4. O&M Diversity From trouble shooting aspect, NAT444 can easily locate the errors happen in IPv4 and IPv6 separately. In contrast, it is difficult to detect the troubles of IPv4 since IPv4 is encapsulated in IPv6 tunnel in DS-lite. In terms of reliability, logically speaking, IPv6 and IPv4 are ships Yang, et al. Expires November 24, 2011 [Page 7] Internet-Draft FAST6-tools selection May 2011 in the night and IPv6 error won't influence the stability of IPv4 directly in NAT444. Otherwise, the troubles happened in IPv6 will affect the IPv4 running in DS-lite. As for the aspect of forwarding efficiency, enabling IPv6 has little influence in NAT444. However, in DS-lite, all this traffic must be tunneled,encapsulated and decapsulated, so it will cut down the forwarding efficiency. Considering from the operational staff training aspect, it is not very difficult to train the NAT skilled staff to operate NAT444 and people have enough time to be familiar with NAT444. In contrast, the training on DS-lite should be finished before the deployment. The time is too short for the people to be fully trained. 7.5. Supporting system Differences In the term of DNS, NAT444 and DS-lite are almost the same. Considering the accounting, the workload of NAT444 is twice as the DS-lite and the accounting logic is much more complicated than DS- lite. Both of them ask for much higher performance requirement for NAT444 DNS. But basically they have the same customer management and tracing system which need to trace IPv6 and IPv4 separately and to save the record of address translation respectively. Since NAT444 and DS-lite have different requirements for support system, it is not proper to deploy both of these two transition tools in the same time and in the same region. The comparisons of NAT444 and Ds-lite are summarized as follows: Regarding the impact on customers, both of them can support IPv4 Internet application and have tiny influences to the user' IPv4 application. From the point of cost controlling, the DS-lite costs a little higher than NAT444 for a single terminal. However, when DS-lite is deployed in large-scale, the cost of terminals will be highly raised. Speaking of technique risk, the NAT444 is much mature than DS-lite and won't impact the IPv4 service. DS-lite is a new tool for transition and its future trend is not very clear, so operator will take higher risk in the early stage of transition. Meanwhile, using tunnel makes DS-lite increase the difficulties of operation and maintenance, leading performance bottleneck in the initial period which will decline the network performance and customer experience and correspondingly heighten the deployment risk. Yang, et al. Expires November 24, 2011 [Page 8] Internet-Draft FAST6-tools selection May 2011 Technically speaking, NAT444 and DS-LITE are no matter which is better and which is worse, they are simply different from the period of deploying, network scenarios and service model. And because of the different requirements for network,support system and terminals, it is not recommended to use both of these two transition tools in the same time and the same region. As we analyzed in the above paragraph, NAT444 is more suitable to be used in the whole transition period while DS-lite is proper for the latter period of transition with small number of IPv4 subscribers. 8. Conclusion For the mainstream ISP, native dual stack is more appropriate compared to dual stack tunnel. Although NAT444 makes a balance between guaranteeing the customer experience and promoting the development of IPv6. However, it is not a comprehensive solution for broadband network. For example, how to provide the IPv6 service to legacy subscribers, if their default network gateway(BNG) cannot be upgraded to support IPv6 and consequently unable to allocate IPv6 address to the customers, is not mentioned in NAT444. In addition, the emergence of mixed routes (private and public IPv4 route) may bring operators great difficulties to manage the routes, how to solve this problem is not taken account in NAT444. Above there are just two exampled problems that NAT444 doesn't design to solve. In conclusion, as a transition technology, NAT444 has the weakness of one-sided consideration about the transition scenarios and doesn't give a complete solution for each period of IPv6 migration. To meet the ISP's requirement, which needs a more systematic and operational technologies, FAST6, a comprehensive solution based on native dual stack is proposed and its detail is described in I.D:draft-yang-v6ops-fast6-pppoe-00. 9. Acknowledgements The authors would like to acknowledge the discussions on this topic with Yangchun Li, Youming Wu, Jinhua Tan, Jinyan Lin, Qi Chen. 10. IANA Considerations This memo includes no request to IANA. Yang, et al. Expires November 24, 2011 [Page 9] Internet-Draft FAST6-tools selection May 2011 11. Security Considerations TBD. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 12.2. Informative References [I-D.arkko-ipv6-transition-guidelines] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", draft-arkko-ipv6-transition-guidelines-14 (work in progress), December 2010. [I-D.ietf-behave-lsn-requirements] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for IP address sharing schemes", draft-ietf-behave-lsn-requirements-01 (work in progress), March 2011. [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-10 (work in progress), May 2011. [I-D.kuarsingh-lsn-deployment] Kuarsingh, V. and J. Cianfarani, "NAT44/LSN Deployment Options and Experiences", draft-kuarsingh-lsn-deployment-01 (work in progress), January 2011. [I-D.shirasaki-nat444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work in progress), January 2011. [I-D.shirasaki-nat444-isp-shared-addr] Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444 addressing models", Yang, et al. Expires November 24, 2011 [Page 10] Internet-Draft FAST6-tools selection May 2011 draft-shirasaki-nat444-isp-shared-addr-05 (work in progress), January 2011. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4241] Shirasaki, Y., Miyakawa, S., Yamasaki, T., and A. Takenouchi, "A Model of IPv6/IPv4 Dual Stack Internet Access Service", RFC 4241, December 2005. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, October 2010. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. Yang, et al. Expires November 24, 2011 [Page 11] Internet-Draft FAST6-tools selection May 2011 Authors' Addresses GuoLiang Yang China Telecom 109, Zhongshan Ave. West, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: yanggl@gsta.com CanCan Huang China Telecom 109, Zhongshan Ave. West, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: huangcc@gsta.com YouMing China Telecom 109, Zhongshan Ave. West, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: Wuym@gsta.com Yang, et al. Expires November 24, 2011 [Page 12]