idnits 2.17.1 draft-xli-behave-divi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 is 1 instance 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 (October 19, 2009) is 5303 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 537, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-00 == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-00 == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-01 == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-01 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-02 == Outdated reference: A later version (-07) exists of draft-xli-behave-ivi-02 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Li 3 Internet-Draft C. Bao 4 Intended status: Informational H. Zhang 5 Expires: April 22, 2010 CERNET Center/Tsinghua University 6 October 19, 2009 8 Address-sharing stateless double IVI 9 draft-xli-behave-divi-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 22, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document presents the concepts and the implementations of 48 address-sharing stateless IVI (stateless 1:N IVI) and the address- 49 sharing stateless double IVI (stateless 1:N dIVI). 51 The stateless 1:N IVI keeps the features of stateless, end-to-end 52 address transparency and bidirectional-initiated communications of 53 the original stateless 1:1 IVI, while it can utilize the IPv4 54 addresses more effectively. The stateless 1:N dIVI has above 55 features and it does not require the DNS64/DNS46 and ALG supports. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Stateless 1:N IVI . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Address format . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Protocol translation . . . . . . . . . . . . . . . . . . . 7 65 3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.5. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.6. ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.7. The translator behavior and the IPv6 end system 69 requirements . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. Stateless 1:N double IVI . . . . . . . . . . . . . . . . . . . 8 71 4.1. Port number mapping algorithm . . . . . . . . . . . . . . 8 72 4.2. Double IVI . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.3. Protocol translation . . . . . . . . . . . . . . . . . . . 10 74 4.4. Home gateway implementation . . . . . . . . . . . . . . . 10 75 4.5. End system implementation . . . . . . . . . . . . . . . . 10 76 5. Work flow examples . . . . . . . . . . . . . . . . . . . . . . 11 77 5.1. IPv6 initiated communication . . . . . . . . . . . . . . . 11 78 5.2. IPv4 initiated communication . . . . . . . . . . . . . . . 11 79 6. Testing prototype information . . . . . . . . . . . . . . . . 11 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 The experiences for the IPv6 deployment in the past 10 years strongly 91 indicate that for a successful transition, the communication between 92 IPv4 and IPv6 address families should be supported. 94 Recently, the stateless and stateful IPv4/IPv6 translation methods 95 are developed and becoming the IETF standards 96 [I-D.ietf-behave-v6v4-framework], [I-D.ietf-behave-v6v4-xlate], 97 [I-D.ietf-behave-v6v4-xlate-stateful]. The original stateless IPv4/ 98 IPv6 translation (stateless 1:1 IVI) is scalable, maintains the end- 99 to-end address transparency and support both IPv6 initiated and IPv4 100 initiated communications [I-D.ietf-behave-v6v4-framework], 101 [I-D.ietf-behave-v6v4-xlate], [I-D.xli-behave-ivi]. But it can not 102 use the IPv4 addresses effectively. The IPv4 address depletion 103 problem makes the deployment of the 1:1 IVI stateless IVI difficult. 104 The stateful IPv4/IPv6 translation can share the IPv4 addresses among 105 IPv6 hosts, but it only supports IPv6 initiated communication 106 [I-D.ietf-behave-v6v4-framework], 107 [I-D.ietf-behave-v6v4-xlate-stateful]. Rely on session initiated 108 states, the stateful translation cannot support the end-to-end 109 address transparency and costs more compared with the stateless 110 translation. 112 In this document, we present concepts and the implementations of the 113 address-sharing stateless IVI (stateless 1:N IVI) and the address- 114 sharing stateless double IVI (stateless 1:N dIVI). The basic 115 concepts of these techniques are the combination of "Address plus 116 port addressing" (A+P) and the IPv4/IPv6 stateless translation (IVI). 118 The stateless 1:N IVI is the extensions of the stateless 1:1 IVI. It 119 is the solution for the following scenarios 120 [I-D.ietf-behave-v6v4-framework]. 122 o Scenario 1: An IPv6 network to the IPv4 Internet. 124 o Scenario 2: The IPv4 Internet to an IPv6 network. 126 o Scenario 5: An IPv6 network to an IPv4 network. 128 o Scenario 6: An IPv4 network to an IPv6 network. 130 The stateless 1:N IVI and the stateless 1:N dIVI keep all the 131 advantages of stateless 1:1 IVI and can use the IPv4 addresses more 132 effectively. In addition, stateless 1:N dIVI can work without DNS64/ 133 DNS46 and ALG. 135 2. Terminologies 137 This document uses the terminologies defined in 138 [I-D.ietf-behave-v6v4-framework]. 140 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 141 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 142 document, are to be interpreted as described in [RFC2119]. 144 3. Stateless 1:N IVI 146 The stateless 1:N IVI is shown in the following figure. 148 -------- 149 // \\ ----------- 150 / \ // \\ 151 / +----+ \ ------------ 152 | |XLAT| |------ End System 1 153 | The IPv4 +----+ An IPv6 | ------------ 154 | Internet +----+ Network | ------------ 155 | |DNS | (address |------ End System N 156 \ +----+ subset) / ------------ 157 \ / \\ // 158 \\ // ---------- 159 -------- 160 <====> 162 Figure 1: Stateless 1:N IVI 164 Where the XLATE is the IPv4/IPv6 translator perform 1:N translation 165 between IPv4 and IPv6; DNS is the DNS46 and DNS64 for providing the 166 authoritative and resolving services; the End System 1 and End System 167 N, etc are the IPv6-only hosts which can restrict their transport 168 layer port range when communicating with the IPv4 Internet. 170 In order to share the IPv4 address among IPv6 hosts, the port number 171 multiplexing technique is used [I-D.xli-behave-ivi]. The basic idea 172 is similar to the ones used in NAT and A+P. This is to say that a 173 single IPv4 address can be shared for multiple IPv6 hosts under the 174 condition that these individual hosts can only use a subset of the 175 65,536 port numbers when communicating with the IPv4 Internet. For 176 example, if the port multiplexing ratio is 128, each host with IPv4- 177 translatable address can use 512 concurrent port numbers when 178 communicating with IPv4 Internet. Note that there is no port number 179 restriction when these IPv6 hosts communicate with the IPv6 Internet. 181 3.1. Algorithm 183 The stateless 1:N IVI is shown in the following figure. 185 .-------|Host0| A1/(P%N)+0 186 / 187 ------ ----- | 188 / The \ ------ / An \ | 189 | IPv4 |--|1:N |---| IPv6 |------------|Host1| A1/(P%N)+1 190 \Internet/ |XLATE | \Network/ | 191 ------ ------ ----- | 192 |\ 193 | -------|Host2| A1/(P%N)+2 194 | 195 | 196 \ 197 -------|HostK| A1/(P%N)+K 199 Figure 2: Stateless 1:N IVI 201 In the above figure, the Host0, Host1, Host2, ..., HostN are sharing 202 the same IPv4 address A1, but port number range for different hosts 203 are not overlapped. Therefore, when these IPv6 hosts communicate 204 with the IPv4 Internet via the translator, it looks like a single 205 host with IPv4 address A1 communicating with the IPv4 Internet. 207 We use the Modulus Operator to define the port number range. If the 208 multiplexing ratio is N, then: 210 o For host K, the allowed port number (P) are P=j*N + K (j=0, 1, 211 ..., N-1). 213 o For the destination port number (P), the packets will be sent to 214 host K=(P%N) (% is the Modulus Operator). 216 For example: If N=256, then host K=5 is only allowed to use port 217 numbers of 5, 261, 517, 773, ..., 65,285 as the source port, while 218 the packets with these port numbers as the destination port number 219 will be send to host K=5. 221 3.2. Address format 223 In order to perform the stateless translation (IVI) between the IPv4 224 and IPv6, both IPv4-mapped and IPv4-translatable address are required 225 [I-D.ietf-behave-v6v4-framework]. We use the reserved 16-bits to 226 encode the range of the port number [I-D.ietf-behave-address-format]. 228 The IPv4-mapped addresses are used to represent IPv4 addresses in 229 IPv6, as shown in the following figure. 231 | 0 |32 |40 |72 |88 127| 232 ----------------------------------------------------------------- 233 | LIR |FF | IPv4 addr | all 0 | 234 ----------------------------------------------------------------- 236 Figure 3: IPv4-mapped address format 238 Note that we use the address format and the prefix (e.g. 2001:db8: 239 ff00::/40) defined in [I-D.xli-behave-ivi]. There is no port number 240 coding required for the IPv4-mapped address. 242 The IPv4-translatable addresses are used to represent IPv6 addresses 243 in IPv4, we defined the extended IPv4-translatable as shown in the 244 following figure. 246 | 0 |32 |40 |72 |88 127| 247 ----------------------------------------------------------------- 248 | LIR |FF | IPv4 addr |Port Coding| all 0 | 249 ----------------------------------------------------------------- 251 Figure 4: Extended IPv4-translatable address format 253 Where, we use reserved 16-bits to encode the port number range based 254 on the Modulus Operator. 256 The most significant 4 bits define the multiplexing ratio and the 257 least significant 12 bits define the index of the host, as shown in 258 the following figure. 260 (4 bits) | Index Range(12 bits) | Multx ratio | # of Ports 261 ----------------------------------------------------------------- 262 0 000-000 1 65,536 263 1 000-001 2 32,768 264 2 000-003 4 16,384 265 3 000-007 8 8,192 266 4 000-00f 16 4,096 267 5 000-01f 32 2,048 268 6 000-03f 64 1,024 269 7 000-07f 128 512 270 8 000-0ff 256 256 271 9 000-1ff 512 128 272 A 000-3ff 1,024 64 273 B 000-7ff 2,048 32 274 C 000-fff 4,096 16 275 ----------------------------------------------------------------- 277 Figure 5: Transport layer port number coding 279 3.3. Protocol translation 281 The protocol translation is defined in [I-D.ietf-behave-v6v4-xlate]. 283 3.4. Routing 285 The routing follows the general IPv4/IPv6 routing principle, i.e. 286 "more specifics win", same as the original stateless 1:1 IVI. 287 [I-D.xli-behave-ivi]. 289 3.5. DNS 291 The DNS handling is referring to DNS64 [I-D.ietf-behave-dns64] and 292 DNS46 [I-D.xli-behave-ivi]. 294 3.6. ALG 296 The ALG related issue is discussed in 297 [I-D.ietf-behave-v6v4-framework]. 299 3.7. The translator behavior and the IPv6 end system requirements 301 For the stateless 1:N IVI, the IPv6 end systems are required to 302 follow the port number range defined by the extended IPv4- 303 translatable address format when communicating with the IPv4 304 Internet. The behaviors of the stateless 1:N translator are: 306 o If the packets are from the IPv4 Internet to an IPv6 network, the 307 IPv4 source addresses are translated to the IPv4-mapped addresses 308 and the source port numbers are unchanged; the IPv4 destination 309 addresses are translated to the extended IPv4-translatable 310 addresses based on the destination port number and the destination 311 port numbers are unchanged. 313 o If the packets are from an IPv6 network to the IPv4 Internet, the 314 IPv6 source addresses and the source port numbers are checked, if 315 the source port number matches the port number range defined by 316 the extended IPv4-translatable address format, the IPv6 source 317 addresses (which are the IPv4-translatable addresses) are 318 translated to the IPv4 addresses and the source port numbers are 319 unchanged; the destination IPv6 addresses (which are the IPv4- 320 mapped addresses) are translated to the IPv4 destination addresses 321 and the destination port numbers are unchanged. However, if the 322 source port numbers do not match the port number range defined by 323 the extended IPv4-translatable address format, the packets will be 324 dropped. 326 Therefore, the IPv6 end systems must follows the port number range 327 defined by the extended IPv4-translatable addresses. The hehavor of 328 the IPv6 end system when communicating with the IPv4 Internet are: 330 o If the IPv6 end system is used as a server, different well-known 331 ports will be served by different IPv6 hosts. 333 o If the IPv6 end system is used as a client, the end system must 334 generate the source port numbers in the range defined by the 335 extended IPv4-translatable address format. This can be done by 336 modification of the end system, or via a port number mapping 337 device (home gateway). 339 4. Stateless 1:N double IVI 341 In general, it is not good idea to force the modification of the end 342 system in order to meet the IPv6 end system requirements of the 343 stateless 1:N IVI. Alternatively, we can use the home gateway to map 344 the randomly generated source port number to the port number range 345 defined by extended IPv4-translatable address format. 347 4.1. Port number mapping algorithm 349 The port number mapping algorithm is straightforward. The port 350 number mapping device maintains a database of allowed port numbers 351 defined by the extended IPv4-translatable address format. If the 352 packets from the end system contains the source port number which do 353 not match the port number range defined by the extended IPv4- 354 translatable address format, the home gateway will translate the 355 source port number to an allowed one and keep the record in the 356 database for translating back the returning packets and all the 357 packets in the same session. 359 The maintaining of the database can be done via the corresponding 360 trnsport layer flags for TCP or timeout for UDP. 362 4.2. Double IVI 364 If we can use the home gateway for the port number mapping, then we 365 can also use the home gateway (1:1 Xlate) to translate the IPv6 366 packets back to IPv4, as shown in the following figure. 368 ------ ----- 369 / The \ ------ / An \ ----- ---- 370 | IPv4 |--|1:N |---| IPv6 |------|1:1 |---|Host1| 371 \Internet/ |XLATE | \Network/ |XLATE| ---- 372 ------ ------ ----- ----- 374 Figure 6: Double IVI (dIVI) 376 The advantage of double IVI is that the DNS64/DNS46 and ALG are not 377 required. 379 The first IPv4/IPv6 translator (1:N XLATE) is the core network 380 translator, the second IPv4/IPv6 translator (1:1 XLATE) is the home 381 gateway trnaslator. The features of these translators are: 383 Core network translator: The core network translator (1:N XLATE) is 384 implemended in the border between the IPv6 core network and the 385 IPv4 Internet. It translates the packets between IPv4 and IPv6 386 with the 1:N stateless address mapping, same as the one used in 387 the stateless 1:N IVI. 389 Home gateway translator: The home gateway translator (1:1 XLATE) is 390 implemented between an IPv6 network and user's end syatem. It 391 translates the packets between IPv4 and IPv6 with 1:1 stateless 392 address mapping. In addition, the home gateway translator maps 393 the random source port numbers to restricted port number based on 394 the extended translatable address format and keeps the mapping 395 table in database for the port number mapping of the retuning 396 packets and all the packets in the same session. Note that the 397 1:1 XLATE is still stateless for the address mapping. 399 4.3. Protocol translation 401 The protocol translation is referring to 402 [I-D.ietf-behave-v6v4-xlate]. Special MTU and fragmentation actions 403 must be taken, due to the process of double translation (more 404 details). 406 4.4. Home gateway implementation 408 The home gateway implementation is suitable for the ADSL environment, 409 as shown in the following figure. 411 ---- ----- 412 .-|hgw0|---|Host0| A1/(P%N)+0 413 / ---- ----- 414 ------ ----- | 415 / The \ ------ / An \ | ---- ----- 416 | IPv4 |--|1:N |---| IPv6 |------|hgw1|---|Host1| A1/(P%N)+1 417 \Internet/ |XLATE | \Network/ | ---- ----- 418 ------ ------ ----- | 419 |\ ---- ----- 420 | -|hgw2|---|Host2| A1/(P%N)+2 421 | ---- ----- 422 | 423 \ ---- ----- 424 -|hgwK|---|HostK| A1/(P%N)+K 425 ---- ----- 427 Figure 7: dIVI home gateway implementation 429 Where Xlate is the IPv4/IPv6 stateless 1:N IVI translator; hgw0, 430 hgw1, ..., hgwK are the home gateways performing the port number 431 mapping and the 1:1 IPv4/IPv6 translation function; Host0, Host1, 432 ..., HostK are dual-stack hosts who share same IPv4 address (A1), and 433 have different non-IPv4-translatable IPv6 addresses. 435 4.5. End system implementation 437 For the wireless mobile Internet environment, it is not difficult to 438 modify the operating system of the mobile device, therefore it 439 possible to integrate the port number restriction and the IPv4/IPv6 440 translation function in the mobile device, which is an IPv6-only host 441 to the network and has a dual-stack socket API for the applications 442 running on this host. 444 ----------- 445 .-|Host0 (hgw)| A1/(P%N)+0 446 / ----------- 447 ------ ----- | 448 / The \ ------ / An \ | ----------- 449 | IPv4 |--|1:N |---| IPv6 |------|Host1 (hgw)| A1/(P%N)+1 450 \Internet/ |XLATE | \Network/ | ----------- 451 ------ ------ ----- | 452 |\ ----------- 453 | -|Host2 (hgw)| A1/(P%N)+2 454 | ----------- 455 | 456 \ ----------- 457 -|HostK (hgw)| A1/(P%N)+K 458 ----------- 460 Figure 8: dIVI end system implementation 462 5. Work flow examples 464 5.1. IPv6 initiated communication 466 Add details later. 468 5.2. IPv4 initiated communication 470 Add details later. 472 6. Testing prototype information 474 The address-sharing stateless double IVI (dIVI) with 1:N stateless 475 translator, home gateways and the end systems have been coded in Linux 476 and deployed in the [CERNET] (IPv4) and [CNGI-CERNET2] (IPv6). The 477 testing homepage is at [dIVI] 479 7. Security Considerations 481 There are no security considerations in this document. 483 8. IANA Considerations 485 This memo adds no new IANA considerations. 487 Note to RFC Editor: This section will have served its purpose if it 488 correctly tells IANA that no new assignments or registries are 489 required, or if those assignments or registries are created during 490 the RFC publication process. From the author's perspective, it may 491 therefore be removed upon publication as an RFC at the RFC Editor's 492 discretion. 494 9. Acknowledgments 496 The authors would like to acknowledge the following contributors in 497 the different phases of the address-sharing IVI and dIVI development: 498 Maoke Chen, Yu Zhai, Wentao Shang, Weifeng Jiang and Yuncehng Zhu. 500 The authors would like to acknowledge the following contributors who 501 provided helpful inputs: Dan Wing, Fred Baker, Dave Thaler, Randy 502 Bush and Kevin Yin. 504 10. References 506 10.1. Normative References 508 [I-D.ietf-behave-address-format] 509 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 510 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 511 draft-ietf-behave-address-format-00 (work in progress), 512 August 2009. 514 [I-D.ietf-behave-dns64] 515 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 516 "DNS64: DNS extensions for Network Address Translation 517 from IPv6 Clients to IPv4 Servers", 518 draft-ietf-behave-dns64-00 (work in progress), July 2009. 520 [I-D.ietf-behave-v6v4-framework] 521 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 522 IPv4/IPv6 Translation", 523 draft-ietf-behave-v6v4-framework-01 (work in progress), 524 September 2009. 526 [I-D.ietf-behave-v6v4-xlate] 527 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 528 Algorithm", draft-ietf-behave-v6v4-xlate-01 (work in 529 progress), September 2009. 531 [I-D.ietf-behave-v6v4-xlate-stateful] 532 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 533 Address and Protocol Translation from IPv6 Clients to IPv4 534 Servers", draft-ietf-behave-v6v4-xlate-stateful-02 (work 535 in progress), October 2009. 537 [RFC1035] Mockapetris, P., "Domain names - implementation and 538 specification", STD 13, RFC 1035, November 1987. 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, March 1997. 543 10.2. Informative References 545 [CERNET] "CERNET Homepage: 546 http://www.edu.cn/english_1369/index.shtml". 548 [CNGI-CERNET2] 549 "CNGI-CERNET2 Homepage: 550 http://www.cernet2.edu.cn/index_en.htm". 552 [I-D.xli-behave-ivi] 553 Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 554 CERNET IVI Translation Design and Deployment for the IPv4/ 555 IPv6 Coexistence and Transition", draft-xli-behave-ivi-02 556 (work in progress), June 2009. 558 [dIVI] "Test homepage for the dIVI: 559 http://202.38.97.114:8056/test.html". 561 Authors' Addresses 563 Xing Li 564 CERNET Center/Tsinghua University 565 Room 225, Main Building, Tsinghua University 566 Beijing 100084 567 CN 569 Phone: +86 10-62785983 570 Email: xing@cernet.edu.cn 571 Congxiao Bao 572 CERNET Center/Tsinghua University 573 Room 225, Main Building, Tsinghua University 574 Beijing 100084 575 CN 577 Phone: +86 10-62785983 578 Email: congxiao@cernet.edu.cn 580 Hong Zhang 581 CERNET Center/Tsinghua University 582 Room 225, Main Building, Tsinghua University 583 Beijing 100084 584 CN 586 Phone: +86 10-62785983 587 Email: neilzh@gmail.com