idnits 2.17.1 draft-sunq-v6ops-ivi-sp-02.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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 6, 2011) is 4790 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-behave-address-format' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-behave-dns64' is defined on line 661, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-behave-v6v4-framework' is defined on line 666, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-12 -- Duplicate reference: draft-ietf-behave-v6v4-xlate, mentioned in 'I-D.ietf-behave-v6v4-xlate-stateful', was also mentioned in 'I-D.ietf-behave-v6v4-xlate'. == Outdated reference: A later version (-08) exists of draft-xli-behave-divi-01 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Qiong Sun 2 Internet Draft Chongfeng Xie 3 Intended status: Informational China Telecom 4 Expires: April 24, 2011 Xing Li 5 CongXiao Bao 6 CERNET Center/Tsinghua University 7 Ming Feng 8 China Telecom 9 March 6, 2011 11 Considerations for Stateless Translation (IVI/dIVI) in Large SP 12 Network 13 draft-sunq-v6ops-ivi-sp-02.txt 15 Abstract 17 With the approaching exhaustion of IPv4 address space, large-scale 18 SPs are now faced with the only real option to deploy IPv6 in a 19 timely manner. In order to achieve smooth transition to IPv6, 20 migration tools should be introduced for different deployment models. 21 Among different IPv6 transition mechanisms, dIVI is a prefix-specific 22 and stateless address mapping method which can directly translate 23 IPv4 packet to IPv6 packet. This document describes the challenges 24 and requirements for large SP to deploy IPv6 in operational network, 25 the experimental results of dIVI in our laboratory and the 26 considerations for dIVI deployment in large SP operational network. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. Internet-Drafts are working 32 documents of the Internet Engineering Task Force (IETF), its areas, 33 and its working groups. Note that other groups may also distribute 34 working documents as Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on September 6,2011. 48 Copyright Notice 50 Copyright (c) 2011 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents carefully, 57 as they describe your rights and restrictions with respect to this 58 document. Code Components extracted from this document must include 59 Simplified BSD License text as described in Section 4.e of the Trust 60 Legal Provisions and are provided without warranty as described in 61 the Simplified BSD License. 63 Table of Contents 65 1. Introduction ................................................ 3 66 2. Terminologies ............................................... 3 67 3. Problem Statement ........................................... 3 68 4. Laboratory experiment........................................ 5 69 4.1. Experiment environment.................................. 6 70 4.2. Experiment configuration................................ 7 71 4.3. Experiment results...................................... 7 72 5. dIVI Deployment Scenario..................................... 9 73 5.1. Network Architecture for Large SP Network............... 9 74 5.2. dIVI Deployment Scenario in Operational Network.........11 75 6. Considerations for dIVI deployment.......................... 12 76 6.1. Addressing ............................................ 12 77 6.2. Routing ............................................... 13 78 6.3. DNS ................................................... 13 79 6.4. AAA and User Management................................ 13 80 6.5. Network management..................................... 14 81 6.6. dIVI CPE Requirements and Configuration ................14 82 6.7. dIVI Xlate Placement in Large SP Network ...............14 83 6.8. ALG consideration ......................................15 84 7. Security Considerations..................................... 15 85 8. IANA Considerations ........................................ 15 86 9. References ................................................. 15 87 9.1. Normative References................................... 15 88 10. Acknowledgments ........................................... 16 90 1. Introduction 92 The dramatic growth of the Internet is accelerating the exhaustion of 93 available IPv4 addressing pool. It is widely accepted that IPv6 is 94 the only real option on the table for the continued growth of the 95 Internet. However, IPv6 deployment is a huge systematic project and a 96 lot of challenges will arise especially in large SP operational 97 network. 99 In order to achieve smooth transition to IPv6, migration tools should 100 be introduced for different deployment models, among which dIVI is a 101 stateless translation mechanism with good scalability. This document 102 describes the challenges and requirements for large SPs in IPv6 103 transition period. Then, we introduce dIVI experimental results in 104 our laboratory. And finally, the considerations for designing and 105 deploying dIVI in operational network are discussed in terms of 106 addressing and routing, DNS deployment requirement, AAA support and 107 user management, network management, CPE requirement and Xlate 108 placement. 110 2. Terminologies 112 This document uses the terminologies defined in [I-D.ietf-behave- 113 v6v4-framework], [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave- 114 address-format], [I-D.ietf-behave-v6v4-xlate-stateful], and [I-D.xli- 115 behave-ivi]. 117 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 118 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 119 document, are to be interpreted as described in [RFC2119]. 121 3. Problem Statement 123 It is well known that the pool of public IPv4 addressing is nearing 124 its exhaustion. The '/8' IANA blocks for Regional Internet Registries 125 (RIRs) are projected to 'run-out' towards the end of 2011. Credible 126 estimates based on past behavior suggest that the RIRs will exhaust 127 their remaining address space by early 2012, apart from the 128 development of a market in IPv4 address space. Thus, it will become 129 much more difficult to get available public IPv4 addresses. In the 130 same time, a lot of emerging applications, e.g. Apple's iPad, 131 Motion's BlackBerry, etc. will quickly deplete the available 132 addresses. This has led to a hightened awareness among the providers 133 to consider introducing IPv6 to keep the Internet operational. 135 It has been widely accepted that the end goal of IPv6 transition is 136 to achieve an end-to-end IPv6-only network, and IPv4 can eventually 137 be turned off. However, since it will have impact on almost the 138 entire world, it will take a considerable period of time to reach the 139 ultimate goal. As a result, IPv4 and IPv6 need to coexist during the 140 whole transition period. In this document, we mainly focus on IPv6 141 migration issues from large ISP's point of view. In order to 142 facilitate smooth IPv6 migration, some factors need to be taken into 143 consideration especially for large SPs. There are ten major 144 requirements: 146 1. It should deploy in an incremental fashion and the overall 147 transition process should be stable and operational. 149 2. It should largely reduce IPv4 public address consumption. 151 3. It should accelerate the deployment of IPv6, rather than just 152 prolonging the lifecycle of IPv4 by introducing multiple layers of 153 NAT. 155 4. There should be no perceived degradation of customer experience. 156 As a result, IPv6 transition mechanisms should provide IPv4 157 service continuity. 159 5. It should achieve scalability, simplicity and high availability, 160 especially for large-scale SPs. 162 6. It should have user management and network management ability. 164 7. It should support user authentication, authorization and 165 accounting as an essential part of operational network. 167 8. Most ISPs need some kind of mechanisms to trace the origin of 168 traffic in their networks. This should also be available for IPv6 169 traffic. 171 9. It should have good throughput performance and massive concurrent 172 session support. 174 10.It should maintain the deployment concepts and business models 175 which have been proven and used with existing revenue generating 176 IPv4 services. 178 All existing IPv6 transition mechanisms can be widely divided into 179 three categories: dual-stack solution, translation-based solution and 180 tunnel-based solution. In this document, we mainly concentrate on 181 stateless translation mechanism: dIVI. The original stateless 182 IPv4/IPv6 translation (stateless 1:1 IVI) is scalable, [I-D.ietf- 183 behave-v6v4-framework], [I-D.ietf-behave-v6v4-xlate], [I-D.ietf- 184 behave-address-format],[I-D.xli-behave-ivi]. But it cannot use the 185 IPv4 addresses effectively. The stateless dIVI[I-D.xli-behave-divi] 186 is a double translation mechanism which includes a 1:N stateless 187 translator and a 1:1 Hgw translator. The 1:N stateless translator is 188 implemented in the border between the IPv6 network and the IPv4 189 Internet. It translates the packets between IPv4 and IPv6 with the 190 1:N stateless address mapping. The 1:1 Hgw translator is implemented 191 between an IPv6 network and user's end system. It translates the 192 packets between IPv4 and IPv6 with 1:1 stateless address mapping. In 193 addition, the home gateway translator maps random source port numbers 194 to restricted port number based on the extended IPv4-translatable 195 address format and keeps the mapping table in database for the port 196 number mapping of the retuning packets and all the packets in the 197 same session. 199 dIVI support bidirectional communication initiated from IPv4 and IPv6. 200 It can be deployed in an IPv6-only access network, in which 201 operational and maintenance cost can be reduced. It has very good 202 scalability and can largely reduce IPv4 address consumption. 204 In this document, we firstly demonstrate the laboratory experimental 205 results of dIVI in section 4. We can see that dIVI can support most 206 of the current IPv4 applications in IPv6-only access network, while 207 largely reducing IPv4 address consumption. And then dIVI deployment 208 model and considerations in large operational network are proposed in 209 section 5 and section 6 respectively. Some important factors need to 210 be taken into account when introducing dIVI. Since most challenges in 211 dIVI have no big difference compared to an IPv6-only environment, we 212 strongly recommend that related network elements should take the 213 corresponding modifications in order to guarantee the IPv6 transition 214 process to be operational and manageable. 216 4. Laboratory experiment 218 We have tested dIVI using the prototype in our laboratory. The major 219 objective listed in the following is to verify the functionality and 220 performance of dIVI: 222 O Verify how to deploy dIVI in practical network. 224 O Verify what applications can be used in dIVI. 226 O Verify what Operating Systems can be supported in dIVI. 228 O Verify the effect of user experience with limited ports. 230 O Verify the performance of dIVI. 232 4.1. Experiment environment 234 We have tested dIVI in our laboratory. The network topology is 235 depicted in Figure 1. 237 +-----+ +-----+ 238 |Host1+--+Hgw1 +------+ ------ 239 +-----+ +-----+ | //// \\\\ 240 /-+--\ +----------+ // \\ 241 // \\ | | | | 242 +-----+ +-----+ | IPv6 | | IVI Xlate| | IPv4 Internet | 243 |Host2+--+Hgw2 +-+ Network +---| +--+ | 244 +-----+ +-----+ \\ // | | \\ // 245 |---+/ +----------+ \\\\ //// 246 | | ------ 247 +-----+ +-----+ | | 248 |Host3+--+Hgw3 +----+ | 249 +-----+ +-----+ | ------ 250 | //// \\\\\ 251 | |/ | 252 +----------------------+ IPv6 Internet | 253 | | 254 |\ / 255 \\\\ ///// 256 ------ 258 Figure 1 dIVI topology in the test 260 There are three key components in the test: 262 o The Hosts are dual-stack customers, who could run IPv4 application, 263 IPv6 application or dual stack application. 265 o The Home Gateways (Hgw) are dIVI translator in user side. It 266 translates the packets between IPv4 and IPv6 with 1:1 stateless 267 address mapping, and maps random source port numbers to restricted 268 port number. 270 o The Xlate translates the packets between IPv4 and IPv6 with the 271 1:N stateless address mapping. 273 The network between Hgw and Xlate is IPv6-only, and the network 274 behind Hgw is dual-stack. Thus, the hosts behind Hgw can communicate 275 with both IPv4 Internet and IPv6 Internet. 277 4.2. Experiment configuration 279 For address configuration, each host will use two IPv6 addresses: one 280 is IVI6 address which is synthesized in Hgw with the IVI4 address and 281 port-related information, and the other is non-IVI IPv6 address which 282 is used for native IPv6 communication. We should notice that only 283 non-IVI IPv6 address needs be allocated to end users. Besides, each 284 user will get an IVI4 address from Hgw. 286 For routing configuration, both IVI address and non-IVI address need 287 to be imported into the IPv6-only network. 289 For port configuration, since there are 65536 TCP/UDP ports for each 290 IP address, and in fact one can use hundreds only for normal 291 applications, so one IPv4 address can be shared by multiple customers. 292 In our experiment, we selected ratio to be 128. That is to say, one 293 IPv4 address is shared by 128 users, and there are 512 available 294 ports per user. 296 For DNS configuration, there is no need to have additional DNS64 for 297 dIVI. Only an IPv6 DNS server with A/AAAA records is needed and the 298 DNS address is manually configured in Hgw. Besides, Hgw has 299 implemented DNS Proxy and it will convert an IPv4 DNS 300 request/response to IPv6 DNS request/response. 302 For ALG configuration, there is no need to deploy specific ALG for 303 IPv4 applications in dIVI. 305 4.3. Experiment results 307 In our laboratory, we mainly have taken the following tests: 309 o Application test: The applications we have tested include web, 310 email, Instant Message, ftp, telnet, SSH, video, Video Camera, P2P, 311 online game, Voip, VPN and so on. 313 o Operating System test: The OS we have tested includes Win7, VISTA, 314 windows XP. 316 o Performance test: We have measured the parameters of concurrent 317 session number, throughput performance. 319 The experimental results are listed as follows: 321 |----------------------|-------------------------------------------| 322 | Type | Experiment Result | 323 |----------------------|-------------------------------------------| 324 | Application test | dIVI hosts can support web, email, im, ftp| 325 | | , telnet, SSH, video, Video Camera, P2P, | 326 | | online game, voip, and so on. | 327 |----------------------|-------------------------------------------| 328 | Operating System test| dIVI can widely support Win7, VISTA, | 329 | | windows XP. | 330 |----------------------|-------------------------------------------| 331 | | The performance test for dIVI Xlate is | 332 | | carried out on a normal PC. | 333 | Performance test | Due to limitation of the PC hardware, the | 334 | | overall throughput is not quite good. | 335 | | However, it can still support more than | 336 | | one hundred million concurrent sessions. | 337 |----------------------|-------------------------------------------| 338 Figure 2 dIVI test result 340 From the experiment, we can have the following conclusions: 342 1. dIVI can have good scalability. Xlate does not need to maintain 343 any session state, and only limited session states have to been 344 maintained in Hgw for its customer. 346 2. dIVI can be deployed in an incremental way. The most complicated 347 part of dIVI is addressing and routing. The configuration for DNS 348 and ALG is very simple. 350 3. dIVI can support a majority of current IPv4 applications. 352 4. dIVI can support a variety of Operating Systems. 354 5. With the ratio of 128 (512 maximum concurrent sessions), there is 355 no perceived degradation of customer experience. 357 However, in the current status of equipment, e.g. BRAS, end system, 358 etc., the support for IPv6-only function has not been fully 359 accomplished. Therefore, there are still some limitations which would 360 be improved in the next version of dIVI development when deploying 361 dIVI prototype in practical operational network: 363 1. Address assignment process have not been integrated with existing 364 address allocation system. 366 2. Currently, IVI routing entries are configured manually. 368 3. Hgw has not integrated PPPoE functionality with dIVI functionality. 370 4. AAA system has not supported IVI-related (or IPv6-only) functions. 372 With regard to the listed IPv6 transition requirements in section 3, 373 most of them can be satisfied by dIVI, except for the requirement of 374 network management and user management. These two points should be 375 paid special attention for large SPs, which will be further discussed 376 in section 6. 378 5. dIVI Deployment Scenario 380 In order to investigate the ways to deploy dIVI in operational 381 network, we firstly briefly discuss network architecture for large SP 382 network. Then dIVI deployment model is introduced. 384 5.1. Network Architecture for Large SP Network 386 In large SPs, the generic network topology can be divided into four 387 main parts (as depicted in Figure3): the Customer Premises Network 388 (CPN), the Access Network (AN), the Metro Area Network (MAN), and the 389 Backbone Network. 391 ----- ------ 392 // \\ // \\ ------ ---------- 393 / \ / \\ // \\ // CPN 394 | +------+ +----+ \ / ---------- 395 | | | Metro +BRAS| |-----|--- End System 396 | Backbone|Core | Area |/SR | Access | | ---------- 397 | Network |Route | Network +----+ Network | CPE | ---------- 398 | | | |AAA | |-----|--- End System 399 | +------+ +----+ / \ ---------- 400 \ / \ / \\ // \\ 401 \\ // \\ // ------ ---------- 402 ---- ------ 404 Figure 3 Network Architecture for Large SP Network 406 1. CPN is the part of the network by a customer when connecting to an 407 ISP's network which includes the CPE and the last hop link. 409 2. In Access Network, a very wide variety of access technologies can 410 be used, including ADSL, Ethernet, PON, ATM, WIFI, etc. 412 3. MAN is the aggregated network for customers in one single metro, 413 with the vast range of size. In most metro networks, BRAS is 414 connected to Core Router directly, while for a small portion of 415 large metro networks, BRAS is connected to Core Routers via 416 aggregated routers. 418 4. Backbone network is to offer transit service between MANs and 419 other ISPs. 421 There are typically two network models for fixed broadband access 422 service: one is to access using PPPoE/PPPoA authentication method 423 while the other is to use IPoE. The first one is usually applied to 424 Residential network and SOHO networks. Subscribers in CPNs can access 425 broadband network by PPP dial-up authentication. BRAS is the key 426 network element which takes full responsibility of IP address 427 assignment, user authentication, traffic aggregation, PPP session 428 termination, etc. Then IP traffic is forwarded to Core Routers 429 through Metro Area Network, and finally transited to external 430 Internet via Backbone network. 432 The second network scenario is usually applied to large enterprise 433 networks. Subscribers in CPNs can access broadband network by IPoE 434 authentication. IP address is normally assigned by DHCP server, or 435 static configuration. 437 5.2. dIVI Deployment Scenario in Operational Network 439 The deployment model of dIVI in operational network is depicted in 440 Figure4. 442 ---- ----- 443 // \\ // \\ --------- -------- 444 / \ / \ // \\ // CPN 445 | +-----+ +----+ \ / -------- 446 | | | Metro |BRAS| |-----|--End System 447 | Backbone|Core | Area |/SR | Access | | -------- 448 | Network |Route| Network +----+ Network | CPE | -------- 449 | | | |AAA | |-----|--End System 450 | +-----+ +----+ / | \ -------- 451 \ / \ / \\ // | \\ 452 \\ // \\ // -------- | --------- 453 ---- ----|-- | 454 | | 455 -----------------| | |----------------| | |---------| 456 \ | / \ | / | 457 \---|--- / \--|--/ | 458 IPv6/IPv4 | dIVI | IPv6-only | Hgw | IPv6/IPv4 | 459 Internet | Xlate | Network |(CPE)| Network | 460 / ------- \ / ----- \ | 461 / \ / \ | 462 ----------------| |----------------| |--------| 463 Figure 4 dIVI Deployment in Operational Network 465 In stateless dIVI, the network between Hgw and Xlate is an IPv6-only 466 network, in which the operational and maintenance cost can be greatly 467 reduced. The access network behind Hgw can either be IPv4-only or 468 dual-stack. Thus, IPv4-only system and dual-stack system can 469 communication with IPv4 Internet using shared IPv4 address by dIVI 470 and the dual-stack system can also communicate with IPv6 Internet 471 directly. 473 In operational network, Hgw can usually be integrated with CPE, while 474 Xlate can be in someplace of MAN or Backbone Network. Subscribers can 475 get IPv6 address from BRAS/SR after user authentication stage. Then, 476 IVI-related route should be imported into the IPv6-only network 477 between Xlate and Hgw. The detailed considerations for dIVI 478 deployment will be discussed in section 6. 480 6. Considerations for dIVI deployment 482 This section describes the considerations for dIVI deployment in 483 large operational network. 485 The major differences between dIVI deployment in laboratory and 486 operational network lie in: 488 1. Operational network is a commercial network with strict user 489 management requirement, while in laboratory it is simple and 490 straightforward. 492 2. Operational network has different kinds of network equipments, e.g. 493 BRAS/SR, CPE, Radius, etc. It would be more difficult to take 494 modifications on all of these equipments. 496 3. Operational network has a large number of customers. Thus, it 497 would be impossible to take manual configuration for all customers. 499 In this section, we try to outline considerations for dIVI deployment 500 on large SP network. Some of the features are not specific to dIVI, 501 but rather to a general requirement on all IPv6 transition techniques. 503 6.1. Addressing 505 In dIVI, there is no need to allocate IVI6 address explicitly to end 506 users. Thus, the process of IPv6 address assignment can be integrated 507 with existing IPv6 address allocation process. Only CPE will need to 508 get IVI4 address, reallocate it to end user, do port-mapping and 509 traffic translation with port-related information. Here are some 510 basic considerations in dIVI addressing: 512 o Determine IVI6 prefix for each Xlate. Operators should use its own 513 prefix as an IVI6 prefix, i.e. pref=2001:db8:a4a6::/48, in order 514 to perform stateless translation. Address allocation process in 515 BRAS/SR should be consistent with Xlate. 517 o Determine the embedded IVI4 address and port multx ratio. 518 Operators should estimate the scale of subscribers in a certain 519 region, evaluate the number of remaining IPv4 address, and analyze 520 the number of concurrent ports. It is a tradeoff between multx 521 ratio and concurrent port numbers. The bigger the multx ratio is, 522 the more an IPv4 address can be shared by multiple subscribers and 523 the less concurrent port number can be used per subscriber. From 524 the above test in our laboratory, we choose multx ratio to be 128 525 and it is enough for current usage. 527 o Determine the ways to distribute the configuration profile 528 including IVI4 address and port multx ratio to Hgw automatically, 529 either by extended DHCP option, or other protocols. 531 6.2. Routing 533 In dIVI, IVI4(i) and IVI6(i) will be aggregated to ISP's IPv4 address 534 and ISP's IPv6 address. They will not affect the global IPv4 and IPv6 535 routing tables 537 In dIVI deployment model, Hgws are normally configured with a default 538 route that points to the BRAS/SR. The routers between BRAS/SR and 539 Xlate run IPv6 dynamic routing protocols (IGP or BGP), and routers in 540 the upper level of Xlate run IPv4 dynamic routing protocols. 541 Therefore, the aggregated IVI6 routing directing to the upper routers 542 will be learned/inserted by in IPv6-only domain. And the IVI6 route 543 directing to Hgws should also be configured in BRAS/SR. 545 6.3. DNS 547 In dIVI, there is no DNS64/DNS46 needed anymore. An IPv6 DNS server 548 is needed to process IPv6 DNS request/response, and the address of 549 IPv6 DNS server should be passed to Hgw. 551 Since there is no IPv4 DNS server in IPv6-only network, it is 552 recommended that Hgw should implement IPv4-to-IPv6 DNS Proxy to 553 convert an IPv4 DNS request/response to IPv6 DNS request/response 554 accordingly. 556 6.4. AAA and User Management 558 User authentication can be used to control who can have the dIVI 559 connectivity service. This is not always required when a customer of 560 IPv4 service automatically can have access to the dIVI service. 561 However, it is highly recommended that IPv6-only customers should be 562 authenticated separately. It is good for security, trouble shooting, 563 user accounting, etc. There are some major points that AAA systems 564 need to be taken into consideration: 566 o User authentication function needs to be extended to support the 567 identification of IPv6-only subscriber, with additional dIVI- 568 related profile for subscribers, e.g. IVI6 address, IVI4 address, 569 non-IVI address, etc. 571 o User accounting and management function needs to be extended to 572 identify dIVI user (or IPv6-only user) separately. 574 In summary, the major challenge of dIVI for the AAA and User 575 Management is no big difference compared to an IPv6-only environment. 577 6.5. Network management 579 There are two issues to manage dIVI in operational network: 581 o Manage IPv6-only network. Operators should be able to manage IPv6- 582 only network, including IPv6 MIB modules, Netflow Records, log 583 information, etc. 585 o Manage the translation process. There are some exceptions that the 586 MIB modules need to add dIVI related features, e.g. dIVI device 587 management, dIVI traffic monitoring, etc. 589 6.6. dIVI CPE Requirements and Configuration 591 In dIVI, CPE is an important network element. It should perform DHCP 592 server, integrated user authentication function, traffic translation 593 and port mapping, DNS proxy, etc. The major operations in dIVI CPE 594 include: 596 o Address assignment: dIVI CPE should support IVI4 address 597 assignment by DHCP process to end users. It should also support 598 IPv6 address assignment, either by stateful DHCP or stateless 599 auto-configuration. 601 o Integrated user authentication function: dIVI CPE should integrate 602 with existing user authentication function, e.g. PPPoE/PPPoA, etc. 604 o DNS: CPE should enable RFC 5006, well-known addresses, and DHCPv6 605 in order to maximize the likelihood of dIVI Hgw being able to use 606 DNS without manual configuration. Besides, dIVI CPE should also 607 support IPv4-to-IPv6 DNS proxy. 609 6.7. dIVI Xlate Placement in Large SP Network 611 Normally, dIVI Xlate can be deployed in "centralized model" and 612 "distributed model". 614 In "centralized model", dIVI Xlate could be deployed in the place of 615 Core Router, or even in the entrance of ICP. Since dIVI is a 616 stateless method with better scalability than stateful ones, it can 617 handle numerous concurrent sessions. 619 In "distributed model", dIVI Xlate is usually be integrated with 620 BRAS/SR. So each Xlate should be configured with its own IVI6 prefix 621 and is responsible for translating the traffic of its own region. The 622 number of subscribers is normally limited, so does the number of IVI 623 routing entries. However, the network infrastructure should still be 624 upgraded to dual-stack support in MAN and backbone network, and so 625 the decreased operational cost is rather limited. Besides, since the 626 newly emerging customers might be distributed in the whole Metro area, 627 we have to deploy Xlate on all BRAS/SRs. This will cost a lot in the 628 initial phase of IPv6 transition period. 630 In summary, we strongly recommend adopting "centralized model" for 631 dIVI. It is a cost-effective way and easy to manage. 633 6.8. ALG consideration 635 dIVI does not require ALG, this is a very important feature in the 636 initial development phase of IPv6. 638 7. Security Considerations 640 There are no security considerations in this document. 642 8. IANA Considerations 644 This memo adds no new IANA considerations. 646 Note to RFC Editor: This section will have served its purpose if it 647 correctly tells IANA that no new assignments or registries are 648 required, or if those assignments or registries are created during 649 the RFC publication process. From the author's perspective, it may 650 therefore be removed upon publication as an RFC at the RFC Editor's 651 discretion. 652 9. References 654 9.1. Normative References 656 [I-D.ietf-behave-address-format] C., Bao, Huitema, C., Bagnulo, M., 657 Boucadair, M., and X.Li, "IPv6 Addressing of IPv4/IPv6 658 Translators", draft-ietf-behave-address-format-10 (work in 659 progress), August 2009. 661 [I-D.ietf-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., and 662 I. Beijnum, "DNS64: DNS extensions for Network Address 663 Translation from IPv6 Clients to IPv4 Servers", draft-ietf- 664 behave-dns64-11 (work in progress),October 2009. 666 [I-D.ietf-behave-v6v4-framework] Baker, F., Li, X., Bao, C., and K. 667 Yin, "Framework for IPv4/IPv6 Translation", draft-ietf- 668 behave-v6v4-framework-10 (work in progress), October 2009. 670 [I-D.ietf-behave-v6v4-xlate] Li, X., Bao, C., and F. Baker, "IP/ICMP 671 Translation Algorithm", draft-ietf-behave-v6v4-xlate-23 672 (work in progress), October 2009. 674 [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., I. 675 Beijnum, "IP/ICMP Translation Algorithm", draft-ietf- 676 behave-v6v4-xlate-12 (work in progress), October 2009. 678 [I-D.xli-behave-divi] Li,X., Bao, C., and Zhang, H., "Address-sharing 679 stateless double IVI", draft-xli-behave-divi-01, April 29, 680 2010. 682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 683 Requirement Levels", BCP 14, RFC 2119, March 1997. 685 10. Acknowledgments 687 The authors would like to thank to Fred Baker for his continuous 688 suggestion around this topic over the years. Thanks to Qian Wang, Jie 689 Hu and Fan Shi for useful feedback. 691 Authors' Addresses 693 Qiong SUN 694 China Telecom Beijing Research Institute 695 Room 708 No.118, Xizhimenneidajie, xicheng District Beijing 100035 696 China 698 Phone: <86 10 58552636> 699 Email: sunqiong@ctbri.com.cn 701 Chongfeng Xie 702 China Telecom Beijing Research Institute 703 Room 708 No.118, Xizhimenneidajie, xicheng District Beijing 100035 704 China 706 Phone: <86 10 58552116> 707 Email: xiechf@ctbri.com.cn 709 Xing Li 710 CERNET Center/Tsinghua University 711 Room 225, Main Building, Tsinghua University 713 Phone: <86 10 62785983> 714 Email: xing@cernet.edu.cn 716 Congxiao Bao 717 CERNET Center/Tsinghua University 718 Room 225, Main Building, Tsinghua University 720 Phone: <86 10 62785983> 721 Email: congxiao@cernet.edu.cn > 723 Ming Feng 724 China Telecom 725 No.31, Jinrong Ave,Xicheng District,100032 727 Phone: <86 10 58501428> 728 Email: fengm@chinatelecom.com.cn