Internet Engineering Task Force Q. Ma Internet-Draft R. Gu Intended status: Informational T. Yang Expires: April 21, 2014 China Mobile October 18, 2013 Test for router and BRAS devices on the degree of IPv6 support draft-ma-v6ops-router-test-00 Abstract This document introduces the test for the router and BRAS devices on the degree of IPv6 support. IPv6 functions and performance of the routers and BRAS widely deployed in current networks are included in testing items. It turns out that some specific IPv6 functions and performance are not well-supported by the router and BRAS devices. The test results have been discussed to share with internet community. Status of This Memo This Internet-Draft is submitted to IETF 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 April 21, 2014. Copyright Notice Copyright (c) 2013 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. Ma, et al. Expires April 21, 2014 [Page 1] Internet-Draft TEST-RESULT October 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Test overview . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Test topology . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Results and analysis of router devices testing . . . . . . . 4 4.1. Functionality of QPPB . . . . . . . . . . . . . . . . . . 4 4.2. Functionality of NetFlow . . . . . . . . . . . . . . . . 5 4.3. Performance of IPv6 FIB capacity . . . . . . . . . . . . 5 4.4. Summary for routers testing . . . . . . . . . . . . . . . 5 5. Results and analysis of BRAS devices testing . . . . . . . . 5 5.1. Functionality of PPPoE . . . . . . . . . . . . . . . . . 6 5.2. Functionality of DHCPv6 . . . . . . . . . . . . . . . . . 6 5.3. Summary for BRAS testing . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Every device on the Internet must be assigned an IP address in order to communicate with other devices. With the ever-increasing number of new devices being connected to the Internet, the need arose for more addresses than IPv4 is able to accommodate. IPv6 was developed to deal with the long-anticipated problem of IPv4 address exhaustion and the deployment of IPv6 became imperative to the global Internet service providers (ISPs). In order to deploy IPv6 in current networks, IPv6 support is required in the network equipments. It's necessary to test the existing equipments to verify whether they meet the operational needs of network operators in IPv6 migration. China Mobile processed the IPv6 supporting test to the router and BRAS equipments to ensure that these equipments will meet the requirement of IPv6 function and perform well in the future IPv6 commercial networks. This document has described the detailed test contents such as functionality, performance and other aspects of IPv6 support in router and BRAS devices. The test results have been evaluated and problems of router and BRAS devices in IPv6 support are analyzed. Results show that the functionality of QPPB, NetFlow and the FIB capacity performance of the tested router devices in the current networks do not meet the requirement of IPv6 deployment and the problems in PPPoE and DHCPv6 function of BRAS devices still exist. These problems may lead to the conditions that the multicast-based services may not be well-developed, separate DHCPv6 servers should be built, and the QoS of the IPv6 network may be largely influenced. Ma, et al. Expires April 21, 2014 [Page 2] Internet-Draft TEST-RESULT October 2013 Discussions of the testing results will give technical guidance to ISPs and device manufacturers in the commercial IPv6 deployment. 2. Test overview The IPv6 supporting tests contain IPv6 functionality, performance, and other aspects of router and BRAS devices deployed in the current networks. Throughout the full test, the service providers will be able to understand the technical maturity of the various equipment manufacturers, obtain the crisis data and technical support to the deployment of IPv6. The tests mainly include the following aspects: - functionality test of basic IPv6 protocols including IPv6, ICMPv6, TCP, UDP, PPP, MLD, etc; - functionality test of Dual-Stack routing protocols including router protocol of OSPFv3/ISISv6/BGP4+; - functionality test of QPPB based on source address or destination address of IPv4/IPv6; - functionality test of GR/NSR/NSF, including router protocol of OSPF /ISIS/BGP; - functionality test of ECMP, including router protocol of OSPF/ISIS/ EBGP, MPLS-TE, ECMP max link numbers; - functionality test of Access technology, including QinQ, PPPoEv6, PPP, DHCPv6 relay; - -functionality test of DHCPv6 including DHCPv6 protocol, DHCP-PD, PHCP-PD with PPPoE; - functionality test of Multicast, including multicast replication, managed, and source specified; - functionality test of NetFlow, including IPv4/IPv6 Unicast and Multicast; - functionality test of Radius, including authentication and accounting; - functionality test of 6PE/6vPE protocol; - performance test of IPv4/IPv6 FIB capacity; Ma, et al. Expires April 21, 2014 [Page 3] Internet-Draft TEST-RESULT October 2013 - performance test of IPv4/IPv6 ACL quantity; - performance test of QoS queue quantity; - performance test of the max concurrent sessions and established link numbers of PPPoE/IPoE; - performance test of data package forwarding capabilities of IPv6 including throughput and delay; 3. Test topology |--------| |------------| |-----------| |--------| | Tester |-----|Aggregation |---|ROUTER/BRAS|----| Tester | | | | Device | | | | | |--------| |------------| |-----------| |--------| Figure 1: Test topology 4. Results and analysis of router devices testing Router devices play the roles of a traffic director on the Internet. A data packet is typically forwarded from one router to another through the networks that constitute the internetwork until it reaches its destination node. Router devices should support various IPv6 functionality and IPv6 transition technology in order to perform smoothly in the transition from IPv4 to IPv6. All the tested router devices can support basic IPv4 and IPv6 protocol stacks such as OSPFv3 [RFC2740], ISISv6 [RFC5308] and BGP4+ [RFC2545] and have the functionality of 6PE/6vPE. The performance of IPv4/IPv6 ACL quantity, QoS queue quantity and the data package forwarding capabilities can meet the requirement of commercial IPv6 deployment. But some specific IPv6 functions are not supported by the router devices currently adopted in the networks. 4.1. Functionality of QPPB QoS Policy Propagation via BGP (QPPB) is a mechanism that allows propagation of quality of service policy and classification by the sending party based on access lists, community lists and autonomous system paths in the BGP. In testing the QPPB functionality, we found out that QPPB based on source address or destination address in IPv6 is not supported in Ma, et al. Expires April 21, 2014 [Page 4] Internet-Draft TEST-RESULT October 2013 some current routers, because the design of router devices adopted in early networks does not take IPv6 into consideration. In the recent router version, IPv4 and IPv6 are both considered, which means some routers in current networks should be upgraded. 4.2. Functionality of NetFlow NetFlow is a network protocol developed for collecting IP traffic information, which is used in traffic monitoring and supported on various platforms. While in multicast NetFlow test, it turns out that the function of IPv6 multicast NetFlow is not supportive among several router devices. Even the IPv4 multicast NetFlow is not supported in some router devices. The result shows that the functionality of NetFlow in IPv4/IPv6 traffic should be noted in the transition from IPv4 to IPv6. 4.3. Performance of IPv6 FIB capacity Forwarding information base (FIB), also known as a forwarding table, is most commonly used to find the proper interface to which the input interface should forward a packet in routing networks. However, the IPv6 FIB of most router devices does not meet the requirement in IPv6 scenario for the reasons such as memory and software designed in the equipments, which should be taken into consideration in the IPv6 network infrastructures. 4.4. Summary for routers testing The specific test gives out a result that the router devices deployed in the current networks are partly supported in the IPv6 deployment except in the functionality of QPPB, NetFlow and the Performance of FIB capacity. Thus the multicast-based services may be influenced and QoS may not satisfy the carriers and users in the commercial IPv6 scenario, which should be noticed by ISPs and device manufacturers. 5. Results and analysis of BRAS devices testing Broadband Remote Access Server (BRAS), is the aggregation point for the subscriber traffic. It provides aggregation capabilities between the Access Network and the Metropolitan Area Network. Besides, it is also the injection point for access authentication, policy management and QoS. BRAS is the PPP session termination point at ISP edge. BRAS should support various IPv6 access technologies, be able to authenticate and manage IPv6 subscribers, and support IPv6 transition technology, such as 6PE [RFC4789], 6vPE [RFC4659] and Dual-Stack Lite technology in the smooth IPv6 transition. Ma, et al. Expires April 21, 2014 [Page 5] Internet-Draft TEST-RESULT October 2013 IPv4 and IPv6 protocol stacks are supported by all tested BRAS devices. Most BRAS devices can support basic PPPoEv6 and DHCPv6 protocols and functions, which allow subscribers to dial-up to establish a PPP session [RFC5072] from host or routed CPE to BRAS for the IPv4 and IPv6 traffic, and can assign 128-bit IPv6 address to subscribers in the DHCPv6 IA_PD option , or assign 64-bit IPv6 prefix to subscribers through Stateless address auto configuration (SLAAC) scheme. Most BRAS support the function of AFTR, and can be deployed as AFTR device in the DS-Lite architecture. But some specific IPv6 functions are not completed by the BRAS devices currently adopted in the networks. 5.1. Functionality of PPPoE PPPoE is widely used in large scale broadband ISPs as a broadband connecting method. For certain tested BRAS devices, some PPPoE functions for IPv6 are not well-supported. Some BRAS devices do not support multicast for IPv6 PPPoE session. Thus the multicast-based services are hardly developed without the functionality of multicast for IPv6 PPPoE session. Multilink PPP (MLP) is a variant of PPP used to aggregate multiple WAN links into one logical channel for the traffic transportation. It enables the traffic load-balance from different links and allows some levels of redundancy in case of a line failure on a single link. Several tested BRAS devices do not support Multilink PPPoE for IPv6. When accessing IPv6 Internet via PPPoE, the Win7 operating system cannot work with the 128-bit address, which is assigned to the Win7 OS in IA-NA option and the low order 64-bit is different from the EUI-64. The low order 64-bit of the address must be the EUI-64 interface ID generated from a EUI-48 MAC address. In other words, when connecting the IPv6 PPPoE access, Win7 operating system can only be assigned a 64-bit IPv6 prefix through SLAAC or DHCPv6. The BRAS configuration in actual networks should set the managed address configuration flag to 0, assigning IPv6 prefix through SLAAC, or set the managed address configuration flag to 1, assigning 128-bit IPv6 address with the EUI-64 interface ID through DHCPv6. 5.2. Functionality of DHCPv6 A few BRAS devices do not support DHCPv6 [RFC3315] server, which means they cannot assign IPv6 address to subscriber in the DHCPv6 IA_PD option , and can only assign 64-bit IPv6 prefix to subscribers through Stateless address auto configuration (SLAAC) scheme. Ma, et al. Expires April 21, 2014 [Page 6] Internet-Draft TEST-RESULT October 2013 Some tested BRAS do not support DHCPv6 relay function, which means they cannot listen for the DHCPv6 messages and broadcast and route the messages to a DHCPv6 server on a different subnet. Prefix delegation [RFC3633] is used to assign a network address prefix to a user site, configuring the user's router with the prefix to be used for each LAN. A few BRAS devices do not support prefix delegation, which means they cannot assign IPv6 prefix to the LAN of customer premise equipment (CPE) using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 5.3. Summary for BRAS testing The specific test gives out results that the BRAS devices deployed in the current networks are well supported in IPv4 and IPv6 protocol stacks, and the basic PPPoEv6 and DHCPv6 protocols and functions are partly supported by the tested BRAS devices. The existed problems in PPPoE and DHCPv6 function have an impact on the deployment of IPv6, such as operators have to build separate DHCPv6 servers, multicast- based service cannot be well-developed and the QoS of the IPv6 network may be largely influenced. All these should be noticed by ISPs and device manufacturers. 6. Security Considerations It needs to be further identified. 7. IANA Considerations TBD 8. Normative References [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999. [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. Ma, et al. Expires April 21, 2014 [Page 7] Internet-Draft TEST-RESULT October 2013 [RFC4659] 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. [RFC4789] Schoenwaelder, J. and T. Jeffree, "Simple Network Management Protocol (SNMP) over IEEE 802 Networks", RFC 4789, November 2006. [RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007. [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008. Authors' Addresses Ma Qiongfang China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 01719 China Email: maqiongfang@chinamobile.com Gu Rong China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 01719 China Email: gurong@chinamobile.com Yang Tianle China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 01719 China Email: yangtianle@chinamobile.com Ma, et al. Expires April 21, 2014 [Page 8]