idnits 2.17.1 draft-chen-v6ops-ipv6-bearer-network-trials-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 4, 2011) is 4678 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2545' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'RFC3032' is defined on line 555, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Chen 3 Internet-Draft T. Yang 4 Intended status: Informational L. Li 5 Expires: January 5, 2012 H. Deng 6 China Mobile 7 July 4, 2011 9 IPv6 Practices on China Mobile IP Bearer Network 10 draft-chen-v6ops-ipv6-bearer-network-trials-00 12 Abstract 14 This memo has introduced IPv6 practices on China Mobile IP bearer 15 network, in which IP backbone network and broadband access routers 16 have been covered. In the practice, IPv6 protocol conformance and 17 data packages forwarding capabiliteis have been tested in multi- 18 vendors environments. Several IPv6 transition schemes have been 19 deployed to validate interoperabilities. Based on concrete testing 20 data, IPv6-enable deployment experiencies have been learned to share 21 with community. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 5, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. IPv6 trial on IP backbone network . . . . . . . . . . . . . . 4 71 2.1. IP Backbone Topology for Trials . . . . . . . . . . . . . 4 72 2.2. IPv6-only Routing Protocol Testing . . . . . . . . . . . . 6 73 2.3. Dual-stack Routing Protocol Testing . . . . . . . . . . . 7 74 2.4. 6PE/6vPE Protocol Testing . . . . . . . . . . . . . . . . 7 75 2.5. Tunnel Protocol Interoperabilities . . . . . . . . . . . . 7 76 2.6. IPv6 ACL and Policy Routing Configuration . . . . . . . . 8 77 2.7. Summary for IPv6 Trial on IP Backbone Network . . . . . . 8 78 3. IPv6 Testing on BRAS . . . . . . . . . . . . . . . . . . . . . 9 79 3.1. Test Topology . . . . . . . . . . . . . . . . . . . . . . 9 80 3.2. Test Cases- Basic IPv6 protocols . . . . . . . . . . . . . 12 81 3.3. Test Cases- DUT in Network Test . . . . . . . . . . . . . 12 82 3.4. Test Cases- Performance in IPv6 environment . . . . . . . 13 83 3.5. Summary for BRAS Testing . . . . . . . . . . . . . . . . . 13 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 6. Normative References . . . . . . . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 With fast development of global Internet, the demands for IP address 92 are rapidly increasing at present. This year, IANA announced that 93 the global free pool of IPv4 depleted on 3 February. IPv6 is only 94 way to satisfy demands of Internet development. Operators have to 95 accelerate the process of deploying IPv6 networks in order to address 96 IP address strains. 98 With significant demands of service development, China Mobile has 99 officially kicked off first IPv6 pre-commercial trials on IP bearer 100 network on June 2011 after several standalone tests of IP equipment 101 in labs. The trials have taken place on major IP backbone network 102 and broadband access equipments. In order to verify IPv6 feasibility 103 and applicability,IPv6 protocol conformance and data packages 104 forwarding capabiliteis have been tested in multi-vendors 105 environments. Several IPv6 transition schemes, i.e. dual-stack, 106 6PE[RFC4789], 6vPE[RFC4659], have been deployed to validate 107 interoperabilities. Based on the IPv6 trials, concrete testing data 108 have been generated and analysed to provide informative assessment to 109 facilitate IPv6 deployment in next steps. 111 This memo has described detailed testing topology, cases and process 112 both on IP backbone network and BRAS. The testing results have been 113 summarized and analyzed to provide explicit conclusions for further 114 deployment. 116 2. IPv6 trial on IP backbone network 118 This section will describe IPv6 trial on IP backbone network in 119 details. It includes testing topoloy, testing cases. Based on 120 collected testing data, we have summarized testing results. 122 2.1. IP Backbone Topology for Trials 124 Figure 1 depicts the overall topology for IP backbone trials, which 125 is constituted by hierarchical IPv6 enable routers. The same level 126 would deploy double-routers due to redundancy considerations. The 127 top-level is national IP backbone network to connect provincial level 128 networks. The middle level is provincial IP backbone to connect 129 metropolitan area networks. The bottom level stands for core IP 130 routers to connect local area networks. The trials have been taken 131 place on these three levels. In order to simulate user-generated 132 data, two router testers have been positioned to access metropolitan 133 core routers. They have resposibilities to propagate routing 134 information into the network under testing. 136 / / 137 / / 138 O------|--------------|---------O 139 | +-------+ +-------+ | 140 | |Router | |Router | | top-level 141 | +-------+ +-------+ | 142 O------|--------------|---------O 143 ________/\___ ______/\__________ 144 _________/ _________\__/________ \____ 145 / / \ \ 146 O-----|--------------|-------O O------|--------------|------O 147 | +-------+ +-------+ | | +-------+ +-------+ | 148 | |Router |----- |Router | | | |Router |------|Router | | 149 | +-------+ +-------+ | | +-------+ +-------+ | 150 O------|--------------|------O O------|--------------|------O 151 \___ _____/ middle-level \___ _____/ 152 \ / \ / 153 \/ \/ 154 +-------+ +-------+ 155 |Router | bottom-level |Router | 156 +-------+ +-------+ 157 | | 158 +-------+ +-------+ 159 |Tester | |Tester | 160 +-------+ +-------+ 162 Figure 1: IP Backbone Topology for Trials 164 The test cases mainly are composed by several parts: 166 o IPv6-only routing protocol interoperabilities: the test case would 167 shutdown IPv4 stack on tested routers. Only IPv6 stack is running 168 to process IPv6 EGP(i.e. BGP4+[RFC2545]) and IGP routing 169 protocol(i.e. OSPFv3[RFC2740] and ISIS[RFC5308]). It will 170 validate IPv6 routing protocol conformance in multi-vendor 171 environments. 173 o Dual-stack routing protocol interoperabilities: the tested router 174 would run both IPv4 and IPv6 IGP and EGP protocol simutanously. 175 It will verify if remote peers could totally learn spreaded IPv4/ 176 IPv6 routing information. 178 o 6PE/6vPE protocol interoperabilities: the test case would require 179 PE routers to be upgraded to support 6PE/6vPE functionalities and 180 remain MPLS core network staying IPv4-enable. It will testify MP- 181 BGP routing learning and package forwarding capabilities. 183 o Tunnel protocol interoperabilities: the test case would configure 184 PE routers as 6over4 tunnel end-point. After configured 6over4 185 tunnel is established, the encapsulated package would be forwarded 186 throught MPLS network. 188 o IPv6 ACL and policy routing capabilities: the target of this test 189 case aiming at IPv6 traffic restrainability. A pair PE would be 190 configured with a paticular policy to constrain data forwarding 191 for specific IPv6 traffic. The verification will help to enhance 192 network security. 194 The following sub-sections would state testing results and related 195 observations. 197 2.2. IPv6-only Routing Protocol Testing 199 The testing is going to validate IPv6 routing protocol 200 interconnection between multi-vendor routers. OSPFv3 and ISIS have 201 been deployed as Interior Gateway Protocol. Based on IGP, BGP4+ has 202 been configured as EGP to commnunicate routing informaiton. 204 In the case of OSPFv3 deployment, routers on the top-level and 205 middle-level have been schemed as area 0, which takes responsibility 206 of backbone area. And, routers on the bottom-level has been 207 configured as area 100 and area 200 accessing to backbone area. The 208 testers inject IPv6 routing information to see whether propagated 209 IPv6 routing information can be learned by remote routers located on 210 the other side of bottom-level. The teting is finalized that routers 211 on bottom-level still remain Exstar/Exchange states. OSPFv3 can't 212 creates adjacencies between neighboring routers for the purpose of 213 exchanging routing information. After troubleshooting, IPv6 MTU 214 between neighboring routers is inconsistent, which causes it failed 215 to establish adjacencies. It is fixed by adjusting IPv6 MTU as 216 identical. It's recommedded that IPv6 MTU should be configured as 217 unified benchmark. 219 In the case of ISIS deployment, routers on the top-level and middle- 220 level have been schemed as level 2, which takes responsibility of 221 backbone area. And, routers on the bottom-level has been configured 222 as level 1. The testers inject IPv6 routing information to see 223 whether propagated IPv6 routing information can be learned by routers 224 located on level 1. The teting has found out that Multi Topology 225 (MT) Routing[RFC5120] in IS-IS would easily cause disorders in ISIS 226 routing area. It's recommedded that MT Routing in IS-IS should be 227 enable or disable simultaneously. 229 In the case of BGP4+ deployment, one of routers on top-level has been 230 selected as reflectors. The router on others level will establish 231 neighboring relationship with the router based on running ISIS route 232 protocol. The testing has shown BGP4+ is running well on IPv6-enable 233 network. 235 2.3. Dual-stack Routing Protocol Testing 237 Dual-stack routing testing runs IPv4 and IPv6 protocols simutanously. 238 The routing area planning is similiar with IPv6-only routing protocol 239 testing. for IPv4 routing protocol, OSPF and ISIS have been taken as 240 IGP and BGP has been taken as EGP. Testing has shown that routing 241 path have been computed by IPv4 and IPv6 routing algorithm 242 independently. The IPv4/IPv6 routing information learning and data 243 forwarding are conformed with testing expectation. 245 2.4. 6PE/6vPE Protocol Testing 247 6PE and 6vPE could shift network to provide IPv6 access depending on 248 existing Multiprotocol Label Switching (MPLS) [RFC3032]core network. 249 Operators could deploy IPv6 network without modifying IPv4 enable 250 MPLS cloud. In the testing, the routers on bottom-level take 251 responsibility of PE and routers tester simulate CE to inject IPv6 252 routing information and package flows. The routers on the top-level 253 and middle-level would still remain IPv4 enable situation. MPLS 254 protocol has been configured on these routers. During the testing, 255 tester would serve for CE to inject routing information. In the case 256 of 6PE, the tester will propagate normal IPv6 IGP routing information 257 to the PE. In the case of 6vPE, the tester would generate IPv6 VPN 258 routing information to communicate with remote peer through MP-BGP. 259 The testing shown remote peers could learn total IPv6 routing 260 information through MPLS enable cloud. The basic funcationalities of 261 6PE/6vPE are going well in the testing network. The caution has been 262 raised by forwarding big data packages. The intermedia routers would 263 like to drop big packages surpassing network MTU since they can't 264 fragment big package in the middle of the forwording path. The data 265 fragmentation functionalities are taken by initiated router. 266 Therefore, it's recommedded that the package size do not exceed 267 network MTU by configuring maximum MTU on initiated router or 268 enabling Path MTU Discovery on initiated router. 270 2.5. Tunnel Protocol Interoperabilities 272 Tunnel protocol requires dedicated board to support. The testing is 273 focusing on configured 6over4 tunnel. In order to coordinate with 274 existing deployed MPLS cloud. The tunnel end-point has been located 275 on PE routers. In this case, IPv6 package is expected encapsulated 276 in IPv4 package going through MPLS network, in which additional MPLS 277 header with lable would route 6over4 packages into remote peer. 278 Therefore, the transmitted IPv6 data packages are not only 279 encapulated in native IPv4 package, but headed into MPLS tunnel. 280 Double tunneling is requested in this situation. According to the 281 testing results, router are failed to support such encapsulation 282 manner. The tunnel board can't forward data packages carrying both 283 tunnel id and MPLS lable. However, MPLS encapsulation supporting is 284 essential for IP bearer network since MPLS is widely deployed. 286 2.6. IPv6 ACL and Policy Routing Configuration 288 IPv6 ACL(Access Control List) will help to reduce potential risks of 289 harmful invasion by preventing IPv6 traffic from a specific source 290 address or network to a specified destination network. In the test 291 scenario, the routers have been configured as IPv6-enable. Routers 292 on bottle-level have configured with ACL deny policies which have 293 applied for both outbound and inbound IPv6 traffics. Testers would 294 inject IPv6 traffic to the routers to validate if the ACL takes 295 effect. The results shown that only outbound ACL deny policies is 296 valid. And inbound policies are failed to constrain IPv6 traffic due 297 to the lacking of supports from the router board. 299 Another testing is taken place at policy routing redistribution 300 through BGP4+. An restricted routing policy would be added into 301 BGP4+ UPDATE message to propagate into the remote peer. After the 302 testing, the remote peer could suceessfully learn the redistributed 303 routing policies and take effect to limite paticular IPv6 traffic . 305 2.7. Summary for IPv6 Trial on IP Backbone Network 307 In general, the tests on several aspects indicate that IPv6-enable 308 backbone network has already qualified for carrying IPv6 data 309 packages in IPv6-only or dual-stack conditions. The IPv6 routing 310 protocol has mature supporting in current routers. It also shows 311 high-interoperabilities in multi-vendor environments. According to 312 testing results, two points needed to be highlighted for next step in 313 IPv6 deployment: 315 o MTU configuration needs to be carefully configured and checked up. 316 The inappropriate MTU configuration will cause failures of IGP 317 neighboring establishement and packages dropping. The unified 318 maxmum MTU configuration is recommended. 320 o Multi Topology (MT) Routing in IS-IS should be configured in 321 unified manner to avoid routing disorders in ISIS area. 323 o Compared to other tunneling technologies, 6PE and 6vPE are 324 recommended to be deployed on IP bearer network, in which MPLS is 325 widely enable. 327 3. IPv6 Testing on BRAS 329 BRAS is the key equipment in MAN, it distributes IP addressess to the 330 subscribers through DHCP protocols, authorize the subscribers to log 331 on, and calculate their online time for billing. It is the "central 332 control node" in MAN. 334 In the past several years, BRAS helped ISPs to control and record the 335 subscribers' bahaviors in IPv4 networks. Along with IPv6 approaching 336 day by day, several BRAS manufacturers announce their equipments 337 could support IPv6 functions. In order to checkout that, we carried 338 on testing five types of BRAS produced by four manufacturers. 340 Test results show that BRAS's IPv6 functions and capabilities are not 341 optimistic. The following subsections describe the specific results 342 of the tests. 344 3.1. Test Topology 346 We tested BRAS in four network scenarios in our labotory. The first 347 scenario checks out the basic IPv6 protocols in stand-alone 348 environment, the following two mostly test the DUTs' communicating 349 ability in networks, and the last simplest configuration verifies the 350 BRAS performance in IPv6 environment. 352 +------+ 353 | IPv4 +--+ 354 | host | | +-----+ 355 +------+ +--+ CPE +--+ ----- 356 +------+ | +-----+ | / \ 357 | IPv4/+--+ | | IPv4 | 358 | IPv6 | | + Network + 359 | host | | / \ / \ 360 +------+ | +-------+ +---+ ----- +-----+ 361 Meter Simulation------>| Test +---+DUT| |Test | 362 | | Meter | | | |Meter| 363 | |(v4/v6)| | | | | 364 +-------+ +-----+ | +-------+ +---+ ----- +-----+ 365 |Client +----+DSLAM+--+ \ / \ / 366 | node | | | | + IPv6 + 367 +-------+ +-----+ | | Network | 368 | \ / 369 +-------+ +-----+ | ----- 370 |Client +----+ AP +--+ 371 | node | | | 372 +-------+ +-----+ 374 Figure 2: Test Topology 1 (stand-lone test) 376 +-------+ 377 | Test | 378 | Meter | 379 |(v4/v6)+---+ 380 +-------+ | 381 +------+ | 382 | IPv4 +--+ | +--------+ 383 | host | | | ---- | Riadus | 384 +------+ | +---+ +---------+ / \ | Server | 385 +---+CPE+---+ BRAS +---+ +--+--------+ 386 +------+ | +---+ | (IPv4) | | | +--------+ 387 | IPv4/+--+ +---|--|--+ | | | | 388 | IPv6 | | | | | +--+ DHCP | 389 | host | | | | | | | Server | 390 +------+ | | | | | +--------+ 391 | | | | | 392 +------+ +-----+ | | | | +--+--------+ 393 +Client+---+DSLAM+---+ | | | | | Portal | 394 +------+ +-----+ | | | | | | 395 | | | IPv4/ | +--------+ ---- 396 L2TP Tunnel-->| | | IPv6 | / \ 397 | | |Network | | IPv4 | 398 +-------+ | | | | +Internet| 399 | Test | | | | | | | 400 | Meter | | | | | / \ / 401 |(v4/v6)+---+ | | | | +--------+ ---- 402 +-------+ | | | | | | Test | 403 +------+ | | | |6PE/6VPE| | Meter | 404 | IPv4 +--+ | | | | | | +---+----+ ---- 405 | host | | | | | | | | | \ / \ 406 +------+ | +---+ +---|--|--+ | V | +---+--+ + IPv6 | 407 +---+CPE+---+ DUT ----------------- M320 | |Internet| 408 +------+ | +---+ |(IPv4/v6)----------------- | \ / 409 | IPv4/+--+ +---------+---+ | +------+ ---- 410 | IPv6 | | + + 411 | host | | | | 412 +------+ | \ / 413 | ---- 414 +------+ +-----+ | 415 |Client+---+DSLAM+---+ 416 +------+ +-----+ 418 Figure 3: Test Topology 2 (DUT in networks) 419 ----- 420 / \ 421 + IPv4 + 422 | Network | 423 + +---+ 424 / \ / | 425 +-------+ +-----------+ +-----+ ----- +----+---------+ 426 | Test | |Aggregation| | | | Test | 427 | Meter +---+ Switch +----+ DUT | | Meter | 428 |(v4/v6)| | | | | | (v4/v6) | 429 +-------+ +-----------+ +-----+ ----- +----+---------+ 430 \ / \ | 431 + IPv6 +---+ 432 | Network | 433 + + 434 \ / 435 ----- 437 Figure 4: Test Topology 3 (DUT in networks) 439 ---------- 440 / \ 441 + IPv4 + 442 | Network | 443 + +-----+ 444 / \ / | 445 +-------+ +--------+ ---------- +-----+-----------+ 446 | Test | | | | Test | 447 | Meter +-------+ DUT | | Meter | 448 |(v4/v6)| | | | (v4/v6) | 449 +-------+ +--------+ ---------- +-----+-----------+ 450 \ / \ | 451 + IPv6 +-----+ 452 | Network | 453 + + 454 \ / 455 ---------- 457 Figure 5: Test Topology 4 (performance Test) 459 3.2. Test Cases- Basic IPv6 protocols 461 Along with devices transiting from IPv4 to IPv6, BRAS's IP-based 462 protocol stack will undergo a major change. Some new protocols will 463 come into being, and some existenced protocols' features will be 464 changed, such as NDP, MLD,ICMPv6, DHCPv6, etc. We tested the BRAS 465 equipments' new features particularly. At the same time, we also did 466 some experiments on L2 or L4 protocols, such as TCP, UDP, PPP, to 467 verify whether they can work well in IPv6 environment. 469 Testing conclusions show that all the equipments made by four 470 manufacturers can support the basic IPv6, ICMPv6, TCP, UDP, PPP, and 471 IPv6 routing protocols, but just two devices can pass most of the 472 access functions test cases. 474 The most serious problem is that two DUTs do not support DHCP server 475 functions in IPv6, which causes a negative impact when the BRAS 476 distributes IPv6 addresses to the subscrtibers or even does DHCP-PD, 477 because there are not local IPv6 address pool in the devices. ISPs 478 must purchase IPv6 DHCP servers additionally. 480 The second trouble is about multicast. One DUT does not only support 481 MLD protocols but PIM-SM which has noting to do with IPv6 or IPv4. 482 Another two cannot duplicate multicast stream for each subscrtiber 483 neither in PPPoE nor IPoE. considering this problem, ISPs can hardly 484 carry out trible-play, such as IPTV, by deploying these devices. 486 At last, only one DUT does not support local PPPoEv6 authentication. 488 3.3. Test Cases- DUT in Network Test 490 In order to achieve the gradual transition from IPv4 to IPv6, and to 491 protect the investment of the deployed devices in the current 492 networks, IPv6 BRAS must have the ability to set L2TP tunnel with 493 IPv4 BRAS, and should support IPv6 over IPv4 tunnel with IPv6 router. 494 We did the experiment in topology 2 and 3 in our lab. 496 One of the problems is about L2TP tunnel. In scenario 2, IPv6 client 497 initiates a PPPoE access request to the IPv4 BRAS, which sets up an 498 L2TP tunnel with the DUT (IPv6 BRAS) after it get the client's IPv6 499 attribute form the Radius server. But unfortunately, the IPv6 client 500 can not get an IPv6 address or prefix. This situation has taken 501 placed on three manufacturers' DUTs because of their IPv6CP function. 503 BRAS must record subscribers' online time and traffic information, 504 which is a basic function in IPv4. We test that in topology 2, all 505 the DUTs can make a record, but three of them cannot distinguish IPv6 506 and IPv4 for a dual-stack client. That means ISPs could not charge 507 separately according to the tradffic is IPv4 or IPv6, which is very 508 important for developing IPv6 if ISPs want to charge IPv6 traffic 509 cheaper than IPv4 in the early of the IPv4-IPv6 transition years. 511 3.4. Test Cases- Performance in IPv6 environment 513 We also tested the BRAS capability in IPv6 environment in topology 4. 514 The test cases inclued FIB capacity, ACL quantity, QoS queue 515 quantity, and line card IPv6 throughput. 517 Performance test conclusions demonstrate that the DUTs' capability do 518 not drop so much in IPv6 networks than in IPv4. The main problems 519 are listed below. 521 One DUT's IPv6 FIB capacity is only 10% of its IPv4 FIB capacity 522 because the related resouces, such as Memory, are designed separately 523 but not shared. But we do not consider that is a serious problem, 524 because the design will certainly be changed if IPv6 traffic 525 increasing over IPv4 traffic in current networks. 527 One DUT's line card throughput is much less than the nominal value 528 when the packet length shorter than 128B no matter it is IPv4 or 529 IPv6. 531 3.5. Summary for BRAS Testing 533 The specific testing results show that only one DUT's IPv6 functions 534 can basicly meet the requirement of current networks experiment or 535 commercial trial. The IPv6 device industy need to be pay more 536 attention by all the ISPs and manufacturers. 538 4. IANA Considerations 540 This document has no IANA actions. 542 5. Security Considerations 544 TBD 546 6. Normative References 548 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 549 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 550 March 1999. 552 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 553 RFC 2740, December 1999. 555 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 556 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 557 Encoding", RFC 3032, January 2001. 559 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 560 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 561 IPv6 VPN", RFC 4659, September 2006. 563 [RFC4789] Schoenwaelder, J. and T. Jeffree, "Simple Network 564 Management Protocol (SNMP) over IEEE 802 Networks", 565 RFC 4789, November 2006. 567 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 568 Topology (MT) Routing in Intermediate System to 569 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 571 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 572 October 2008. 574 Authors' Addresses 576 Gang Chen 577 China Mobile 578 53A,Xibianmennei Ave., 579 Xuanwu District, 580 Beijing 100053 581 China 583 Email: chengang@chinamobile.com 585 Tianle Yang 586 China Mobile 587 53A,Xibianmennei Ave., 588 Xuanwu District, 589 Beijing 100053 590 China 592 Email: yangtianle@chinamobile.com 593 Lianyuan Li 594 China Mobile 595 53A,Xibianmennei Ave. 596 Beijing 100053 597 P.R.China 599 Phone: +86-13910750201 600 Email: lilianyuan@chinamobile.com 602 Hui Deng 603 China Mobile 604 53A,Xibianmennei Ave. 605 Beijing 100053 606 P.R.China 608 Phone: +86-13910750201 609 Email: denghui02@gmail.com