Internet Engineering Task Force G. Chen Internet-Draft T. Yang Intended status: Informational L. Li Expires: January 5, 2012 H. Deng China Mobile July 4, 2011 IPv6 Practices on China Mobile IP Bearer Network draft-chen-v6ops-ipv6-bearer-network-trials-00 Abstract This memo has introduced IPv6 practices on China Mobile IP bearer network, in which IP backbone network and broadband access routers have been covered. In the practice, IPv6 protocol conformance and data packages forwarding capabiliteis have been tested in multi- vendors environments. Several IPv6 transition schemes have been deployed to validate interoperabilities. Based on concrete testing data, IPv6-enable deployment experiencies have been learned to share with community. 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 January 5, 2012. 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 Chen, et al. Expires January 5, 2012 [Page 1] Internet-Draft IPv6-bearer-network-trials July 2011 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Chen, et al. Expires January 5, 2012 [Page 2] Internet-Draft IPv6-bearer-network-trials July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. IPv6 trial on IP backbone network . . . . . . . . . . . . . . 4 2.1. IP Backbone Topology for Trials . . . . . . . . . . . . . 4 2.2. IPv6-only Routing Protocol Testing . . . . . . . . . . . . 6 2.3. Dual-stack Routing Protocol Testing . . . . . . . . . . . 7 2.4. 6PE/6vPE Protocol Testing . . . . . . . . . . . . . . . . 7 2.5. Tunnel Protocol Interoperabilities . . . . . . . . . . . . 7 2.6. IPv6 ACL and Policy Routing Configuration . . . . . . . . 8 2.7. Summary for IPv6 Trial on IP Backbone Network . . . . . . 8 3. IPv6 Testing on BRAS . . . . . . . . . . . . . . . . . . . . . 9 3.1. Test Topology . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Test Cases- Basic IPv6 protocols . . . . . . . . . . . . . 12 3.3. Test Cases- DUT in Network Test . . . . . . . . . . . . . 12 3.4. Test Cases- Performance in IPv6 environment . . . . . . . 13 3.5. Summary for BRAS Testing . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Chen, et al. Expires January 5, 2012 [Page 3] Internet-Draft IPv6-bearer-network-trials July 2011 1. Introduction With fast development of global Internet, the demands for IP address are rapidly increasing at present. This year, IANA announced that the global free pool of IPv4 depleted on 3 February. IPv6 is only way to satisfy demands of Internet development. Operators have to accelerate the process of deploying IPv6 networks in order to address IP address strains. With significant demands of service development, China Mobile has officially kicked off first IPv6 pre-commercial trials on IP bearer network on June 2011 after several standalone tests of IP equipment in labs. The trials have taken place on major IP backbone network and broadband access equipments. In order to verify IPv6 feasibility and applicability,IPv6 protocol conformance and data packages forwarding capabiliteis have been tested in multi-vendors environments. Several IPv6 transition schemes, i.e. dual-stack, 6PE[RFC4789], 6vPE[RFC4659], have been deployed to validate interoperabilities. Based on the IPv6 trials, concrete testing data have been generated and analysed to provide informative assessment to facilitate IPv6 deployment in next steps. This memo has described detailed testing topology, cases and process both on IP backbone network and BRAS. The testing results have been summarized and analyzed to provide explicit conclusions for further deployment. 2. IPv6 trial on IP backbone network This section will describe IPv6 trial on IP backbone network in details. It includes testing topoloy, testing cases. Based on collected testing data, we have summarized testing results. 2.1. IP Backbone Topology for Trials Figure 1 depicts the overall topology for IP backbone trials, which is constituted by hierarchical IPv6 enable routers. The same level would deploy double-routers due to redundancy considerations. The top-level is national IP backbone network to connect provincial level networks. The middle level is provincial IP backbone to connect metropolitan area networks. The bottom level stands for core IP routers to connect local area networks. The trials have been taken place on these three levels. In order to simulate user-generated data, two router testers have been positioned to access metropolitan core routers. They have resposibilities to propagate routing information into the network under testing. Chen, et al. Expires January 5, 2012 [Page 4] Internet-Draft IPv6-bearer-network-trials July 2011 / / / / O------|--------------|---------O | +-------+ +-------+ | | |Router | |Router | | top-level | +-------+ +-------+ | O------|--------------|---------O ________/\___ ______/\__________ _________/ _________\__/________ \____ / / \ \ O-----|--------------|-------O O------|--------------|------O | +-------+ +-------+ | | +-------+ +-------+ | | |Router |----- |Router | | | |Router |------|Router | | | +-------+ +-------+ | | +-------+ +-------+ | O------|--------------|------O O------|--------------|------O \___ _____/ middle-level \___ _____/ \ / \ / \/ \/ +-------+ +-------+ |Router | bottom-level |Router | +-------+ +-------+ | | +-------+ +-------+ |Tester | |Tester | +-------+ +-------+ Figure 1: IP Backbone Topology for Trials The test cases mainly are composed by several parts: o IPv6-only routing protocol interoperabilities: the test case would shutdown IPv4 stack on tested routers. Only IPv6 stack is running to process IPv6 EGP(i.e. BGP4+[RFC2545]) and IGP routing protocol(i.e. OSPFv3[RFC2740] and ISIS[RFC5308]). It will validate IPv6 routing protocol conformance in multi-vendor environments. o Dual-stack routing protocol interoperabilities: the tested router would run both IPv4 and IPv6 IGP and EGP protocol simutanously. It will verify if remote peers could totally learn spreaded IPv4/ IPv6 routing information. o 6PE/6vPE protocol interoperabilities: the test case would require PE routers to be upgraded to support 6PE/6vPE functionalities and remain MPLS core network staying IPv4-enable. It will testify MP- BGP routing learning and package forwarding capabilities. Chen, et al. Expires January 5, 2012 [Page 5] Internet-Draft IPv6-bearer-network-trials July 2011 o Tunnel protocol interoperabilities: the test case would configure PE routers as 6over4 tunnel end-point. After configured 6over4 tunnel is established, the encapsulated package would be forwarded throught MPLS network. o IPv6 ACL and policy routing capabilities: the target of this test case aiming at IPv6 traffic restrainability. A pair PE would be configured with a paticular policy to constrain data forwarding for specific IPv6 traffic. The verification will help to enhance network security. The following sub-sections would state testing results and related observations. 2.2. IPv6-only Routing Protocol Testing The testing is going to validate IPv6 routing protocol interconnection between multi-vendor routers. OSPFv3 and ISIS have been deployed as Interior Gateway Protocol. Based on IGP, BGP4+ has been configured as EGP to commnunicate routing informaiton. In the case of OSPFv3 deployment, routers on the top-level and middle-level have been schemed as area 0, which takes responsibility of backbone area. And, routers on the bottom-level has been configured as area 100 and area 200 accessing to backbone area. The testers inject IPv6 routing information to see whether propagated IPv6 routing information can be learned by remote routers located on the other side of bottom-level. The teting is finalized that routers on bottom-level still remain Exstar/Exchange states. OSPFv3 can't creates adjacencies between neighboring routers for the purpose of exchanging routing information. After troubleshooting, IPv6 MTU between neighboring routers is inconsistent, which causes it failed to establish adjacencies. It is fixed by adjusting IPv6 MTU as identical. It's recommedded that IPv6 MTU should be configured as unified benchmark. In the case of ISIS deployment, routers on the top-level and middle- level have been schemed as level 2, which takes responsibility of backbone area. And, routers on the bottom-level has been configured as level 1. The testers inject IPv6 routing information to see whether propagated IPv6 routing information can be learned by routers located on level 1. The teting has found out that Multi Topology (MT) Routing[RFC5120] in IS-IS would easily cause disorders in ISIS routing area. It's recommedded that MT Routing in IS-IS should be enable or disable simultaneously. In the case of BGP4+ deployment, one of routers on top-level has been selected as reflectors. The router on others level will establish Chen, et al. Expires January 5, 2012 [Page 6] Internet-Draft IPv6-bearer-network-trials July 2011 neighboring relationship with the router based on running ISIS route protocol. The testing has shown BGP4+ is running well on IPv6-enable network. 2.3. Dual-stack Routing Protocol Testing Dual-stack routing testing runs IPv4 and IPv6 protocols simutanously. The routing area planning is similiar with IPv6-only routing protocol testing. for IPv4 routing protocol, OSPF and ISIS have been taken as IGP and BGP has been taken as EGP. Testing has shown that routing path have been computed by IPv4 and IPv6 routing algorithm independently. The IPv4/IPv6 routing information learning and data forwarding are conformed with testing expectation. 2.4. 6PE/6vPE Protocol Testing 6PE and 6vPE could shift network to provide IPv6 access depending on existing Multiprotocol Label Switching (MPLS) [RFC3032]core network. Operators could deploy IPv6 network without modifying IPv4 enable MPLS cloud. In the testing, the routers on bottom-level take responsibility of PE and routers tester simulate CE to inject IPv6 routing information and package flows. The routers on the top-level and middle-level would still remain IPv4 enable situation. MPLS protocol has been configured on these routers. During the testing, tester would serve for CE to inject routing information. In the case of 6PE, the tester will propagate normal IPv6 IGP routing information to the PE. In the case of 6vPE, the tester would generate IPv6 VPN routing information to communicate with remote peer through MP-BGP. The testing shown remote peers could learn total IPv6 routing information through MPLS enable cloud. The basic funcationalities of 6PE/6vPE are going well in the testing network. The caution has been raised by forwarding big data packages. The intermedia routers would like to drop big packages surpassing network MTU since they can't fragment big package in the middle of the forwording path. The data fragmentation functionalities are taken by initiated router. Therefore, it's recommedded that the package size do not exceed network MTU by configuring maximum MTU on initiated router or enabling Path MTU Discovery on initiated router. 2.5. Tunnel Protocol Interoperabilities Tunnel protocol requires dedicated board to support. The testing is focusing on configured 6over4 tunnel. In order to coordinate with existing deployed MPLS cloud. The tunnel end-point has been located on PE routers. In this case, IPv6 package is expected encapsulated in IPv4 package going through MPLS network, in which additional MPLS header with lable would route 6over4 packages into remote peer. Therefore, the transmitted IPv6 data packages are not only Chen, et al. Expires January 5, 2012 [Page 7] Internet-Draft IPv6-bearer-network-trials July 2011 encapulated in native IPv4 package, but headed into MPLS tunnel. Double tunneling is requested in this situation. According to the testing results, router are failed to support such encapsulation manner. The tunnel board can't forward data packages carrying both tunnel id and MPLS lable. However, MPLS encapsulation supporting is essential for IP bearer network since MPLS is widely deployed. 2.6. IPv6 ACL and Policy Routing Configuration IPv6 ACL(Access Control List) will help to reduce potential risks of harmful invasion by preventing IPv6 traffic from a specific source address or network to a specified destination network. In the test scenario, the routers have been configured as IPv6-enable. Routers on bottle-level have configured with ACL deny policies which have applied for both outbound and inbound IPv6 traffics. Testers would inject IPv6 traffic to the routers to validate if the ACL takes effect. The results shown that only outbound ACL deny policies is valid. And inbound policies are failed to constrain IPv6 traffic due to the lacking of supports from the router board. Another testing is taken place at policy routing redistribution through BGP4+. An restricted routing policy would be added into BGP4+ UPDATE message to propagate into the remote peer. After the testing, the remote peer could suceessfully learn the redistributed routing policies and take effect to limite paticular IPv6 traffic . 2.7. Summary for IPv6 Trial on IP Backbone Network In general, the tests on several aspects indicate that IPv6-enable backbone network has already qualified for carrying IPv6 data packages in IPv6-only or dual-stack conditions. The IPv6 routing protocol has mature supporting in current routers. It also shows high-interoperabilities in multi-vendor environments. According to testing results, two points needed to be highlighted for next step in IPv6 deployment: o MTU configuration needs to be carefully configured and checked up. The inappropriate MTU configuration will cause failures of IGP neighboring establishement and packages dropping. The unified maxmum MTU configuration is recommended. o Multi Topology (MT) Routing in IS-IS should be configured in unified manner to avoid routing disorders in ISIS area. o Compared to other tunneling technologies, 6PE and 6vPE are recommended to be deployed on IP bearer network, in which MPLS is widely enable. Chen, et al. Expires January 5, 2012 [Page 8] Internet-Draft IPv6-bearer-network-trials July 2011 3. IPv6 Testing on BRAS BRAS is the key equipment in MAN, it distributes IP addressess to the subscribers through DHCP protocols, authorize the subscribers to log on, and calculate their online time for billing. It is the "central control node" in MAN. In the past several years, BRAS helped ISPs to control and record the subscribers' bahaviors in IPv4 networks. Along with IPv6 approaching day by day, several BRAS manufacturers announce their equipments could support IPv6 functions. In order to checkout that, we carried on testing five types of BRAS produced by four manufacturers. Test results show that BRAS's IPv6 functions and capabilities are not optimistic. The following subsections describe the specific results of the tests. 3.1. Test Topology We tested BRAS in four network scenarios in our labotory. The first scenario checks out the basic IPv6 protocols in stand-alone environment, the following two mostly test the DUTs' communicating ability in networks, and the last simplest configuration verifies the BRAS performance in IPv6 environment. +------+ | IPv4 +--+ | host | | +-----+ +------+ +--+ CPE +--+ ----- +------+ | +-----+ | / \ | IPv4/+--+ | | IPv4 | | IPv6 | | + Network + | host | | / \ / \ +------+ | +-------+ +---+ ----- +-----+ Meter Simulation------>| Test +---+DUT| |Test | | | Meter | | | |Meter| | |(v4/v6)| | | | | +-------+ +-----+ | +-------+ +---+ ----- +-----+ |Client +----+DSLAM+--+ \ / \ / | node | | | | + IPv6 + +-------+ +-----+ | | Network | | \ / +-------+ +-----+ | ----- |Client +----+ AP +--+ | node | | | +-------+ +-----+ Figure 2: Test Topology 1 (stand-lone test) Chen, et al. Expires January 5, 2012 [Page 9] Internet-Draft IPv6-bearer-network-trials July 2011 +-------+ | Test | | Meter | |(v4/v6)+---+ +-------+ | +------+ | | IPv4 +--+ | +--------+ | host | | | ---- | Riadus | +------+ | +---+ +---------+ / \ | Server | +---+CPE+---+ BRAS +---+ +--+--------+ +------+ | +---+ | (IPv4) | | | +--------+ | IPv4/+--+ +---|--|--+ | | | | | IPv6 | | | | | +--+ DHCP | | host | | | | | | | Server | +------+ | | | | | +--------+ | | | | | +------+ +-----+ | | | | +--+--------+ +Client+---+DSLAM+---+ | | | | | Portal | +------+ +-----+ | | | | | | | | | IPv4/ | +--------+ ---- L2TP Tunnel-->| | | IPv6 | / \ | | |Network | | IPv4 | +-------+ | | | | +Internet| | Test | | | | | | | | Meter | | | | | / \ / |(v4/v6)+---+ | | | | +--------+ ---- +-------+ | | | | | | Test | +------+ | | | |6PE/6VPE| | Meter | | IPv4 +--+ | | | | | | +---+----+ ---- | host | | | | | | | | | \ / \ +------+ | +---+ +---|--|--+ | V | +---+--+ + IPv6 | +---+CPE+---+ DUT ----------------- M320 | |Internet| +------+ | +---+ |(IPv4/v6)----------------- | \ / | IPv4/+--+ +---------+---+ | +------+ ---- | IPv6 | | + + | host | | | | +------+ | \ / | ---- +------+ +-----+ | |Client+---+DSLAM+---+ +------+ +-----+ Figure 3: Test Topology 2 (DUT in networks) Chen, et al. Expires January 5, 2012 [Page 10] Internet-Draft IPv6-bearer-network-trials July 2011 ----- / \ + IPv4 + | Network | + +---+ / \ / | +-------+ +-----------+ +-----+ ----- +----+---------+ | Test | |Aggregation| | | | Test | | Meter +---+ Switch +----+ DUT | | Meter | |(v4/v6)| | | | | | (v4/v6) | +-------+ +-----------+ +-----+ ----- +----+---------+ \ / \ | + IPv6 +---+ | Network | + + \ / ----- Figure 4: Test Topology 3 (DUT in networks) ---------- / \ + IPv4 + | Network | + +-----+ / \ / | +-------+ +--------+ ---------- +-----+-----------+ | Test | | | | Test | | Meter +-------+ DUT | | Meter | |(v4/v6)| | | | (v4/v6) | +-------+ +--------+ ---------- +-----+-----------+ \ / \ | + IPv6 +-----+ | Network | + + \ / ---------- Figure 5: Test Topology 4 (performance Test) Chen, et al. Expires January 5, 2012 [Page 11] Internet-Draft IPv6-bearer-network-trials July 2011 3.2. Test Cases- Basic IPv6 protocols Along with devices transiting from IPv4 to IPv6, BRAS's IP-based protocol stack will undergo a major change. Some new protocols will come into being, and some existenced protocols' features will be changed, such as NDP, MLD,ICMPv6, DHCPv6, etc. We tested the BRAS equipments' new features particularly. At the same time, we also did some experiments on L2 or L4 protocols, such as TCP, UDP, PPP, to verify whether they can work well in IPv6 environment. Testing conclusions show that all the equipments made by four manufacturers can support the basic IPv6, ICMPv6, TCP, UDP, PPP, and IPv6 routing protocols, but just two devices can pass most of the access functions test cases. The most serious problem is that two DUTs do not support DHCP server functions in IPv6, which causes a negative impact when the BRAS distributes IPv6 addresses to the subscrtibers or even does DHCP-PD, because there are not local IPv6 address pool in the devices. ISPs must purchase IPv6 DHCP servers additionally. The second trouble is about multicast. One DUT does not only support MLD protocols but PIM-SM which has noting to do with IPv6 or IPv4. Another two cannot duplicate multicast stream for each subscrtiber neither in PPPoE nor IPoE. considering this problem, ISPs can hardly carry out trible-play, such as IPTV, by deploying these devices. At last, only one DUT does not support local PPPoEv6 authentication. 3.3. Test Cases- DUT in Network Test In order to achieve the gradual transition from IPv4 to IPv6, and to protect the investment of the deployed devices in the current networks, IPv6 BRAS must have the ability to set L2TP tunnel with IPv4 BRAS, and should support IPv6 over IPv4 tunnel with IPv6 router. We did the experiment in topology 2 and 3 in our lab. One of the problems is about L2TP tunnel. In scenario 2, IPv6 client initiates a PPPoE access request to the IPv4 BRAS, which sets up an L2TP tunnel with the DUT (IPv6 BRAS) after it get the client's IPv6 attribute form the Radius server. But unfortunately, the IPv6 client can not get an IPv6 address or prefix. This situation has taken placed on three manufacturers' DUTs because of their IPv6CP function. BRAS must record subscribers' online time and traffic information, which is a basic function in IPv4. We test that in topology 2, all the DUTs can make a record, but three of them cannot distinguish IPv6 and IPv4 for a dual-stack client. That means ISPs could not charge Chen, et al. Expires January 5, 2012 [Page 12] Internet-Draft IPv6-bearer-network-trials July 2011 separately according to the tradffic is IPv4 or IPv6, which is very important for developing IPv6 if ISPs want to charge IPv6 traffic cheaper than IPv4 in the early of the IPv4-IPv6 transition years. 3.4. Test Cases- Performance in IPv6 environment We also tested the BRAS capability in IPv6 environment in topology 4. The test cases inclued FIB capacity, ACL quantity, QoS queue quantity, and line card IPv6 throughput. Performance test conclusions demonstrate that the DUTs' capability do not drop so much in IPv6 networks than in IPv4. The main problems are listed below. One DUT's IPv6 FIB capacity is only 10% of its IPv4 FIB capacity because the related resouces, such as Memory, are designed separately but not shared. But we do not consider that is a serious problem, because the design will certainly be changed if IPv6 traffic increasing over IPv4 traffic in current networks. One DUT's line card throughput is much less than the nominal value when the packet length shorter than 128B no matter it is IPv4 or IPv6. 3.5. Summary for BRAS Testing The specific testing results show that only one DUT's IPv6 functions can basicly meet the requirement of current networks experiment or commercial trial. The IPv6 device industy need to be pay more attention by all the ISPs and manufacturers. 4. IANA Considerations This document has no IANA actions. 5. Security Considerations TBD 6. Normative References [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999. Chen, et al. Expires January 5, 2012 [Page 13] Internet-Draft IPv6-bearer-network-trials July 2011 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [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. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008. [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008. Authors' Addresses Gang Chen China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: chengang@chinamobile.com Tianle Yang China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: yangtianle@chinamobile.com Chen, et al. Expires January 5, 2012 [Page 14] Internet-Draft IPv6-bearer-network-trials July 2011 Lianyuan Li China Mobile 53A,Xibianmennei Ave. Beijing 100053 P.R.China Phone: +86-13910750201 Email: lilianyuan@chinamobile.com Hui Deng China Mobile 53A,Xibianmennei Ave. Beijing 100053 P.R.China Phone: +86-13910750201 Email: denghui02@gmail.com Chen, et al. Expires January 5, 2012 [Page 15]