idnits 2.17.1 draft-xli-behave-divi-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 (April 11, 2011) is 4762 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 513, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 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: October 13, 2011 CERNET Center/Tsinghua 6 University 7 April 11, 2011 9 Address-sharing stateless double IVI 10 draft-xli-behave-divi-02 12 Abstract 14 This document presents the concepts and the implementations of 15 address-sharing stateless IVI (stateless 1:N IVI) and the address- 16 sharing stateless double IVI (stateless 1:N dIVI). 18 The stateless 1:N IVI keeps the features of stateless, end-to-end 19 address transparency and bidirectional-initiated communications of 20 the original stateless 1:1 IVI, while it can utilize the IPv4 21 addresses more effectively. The stateless 1:N dIVI has above 22 features and it does not require the DNS64/DNS46 and ALG supports. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 13, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Stateless 1:N IVI . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Address-sharing algorithm . . . . . . . . . . . . . . . . 5 62 3.2. Extended address format . . . . . . . . . . . . . . . . . 5 63 3.3. Protocol translation . . . . . . . . . . . . . . . . . . . 7 64 3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.5. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.6. ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.7. The translator behavior and the IPv6 end system 68 requirements . . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Stateless 1:N double IVI . . . . . . . . . . . . . . . . . . . 8 70 4.1. Port number mapping algorithm . . . . . . . . . . . . . . 8 71 4.2. Double IVI . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.3. Protocol translation . . . . . . . . . . . . . . . . . . . 10 73 4.4. Home gateway implementation . . . . . . . . . . . . . . . 10 74 4.5. End system implementation . . . . . . . . . . . . . . . . 10 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 81 Appendix A. Testing environment and workflow examples . . . . . . 13 82 A.1. The host on the IPv4 Internet initiats communication . . . 14 83 A.2. The address-sharing end system on an IPv6 network 84 initiats communication . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 The experiences for the IPv6 deployment in the past 10 years strongly 90 indicate that for a successful transition, the communication between 91 IPv4 and IPv6 address families should be supported. 93 Recently, the stateless and stateful IPv4/IPv6 translation methods 94 are developed and becoming the IETF standards 95 [I-D.ietf-behave-v6v4-framework], [I-D.ietf-behave-v6v4-xlate], 96 [I-D.ietf-behave-v6v4-xlate-stateful]. The original stateless IPv4/ 97 IPv6 translation (stateless 1:1 IVI) is scalable, maintains the end- 98 to-end address transparency and support both IPv6 initiated and IPv4 99 initiated communications [I-D.ietf-behave-v6v4-framework], 100 [I-D.ietf-behave-v6v4-xlate], [I-D.xli-behave-ivi]. But it can not 101 use the IPv4 addresses effectively. The IPv4 address depletion 102 problem makes the deployment of the 1:1 IVI stateless IVI difficult. 103 The stateful IPv4/IPv6 translation can share the IPv4 addresses among 104 IPv6 hosts, but it only supports IPv6 initiated communication 105 [I-D.ietf-behave-v6v4-framework], 106 [I-D.ietf-behave-v6v4-xlate-stateful]. Rely on session initiated 107 states, the stateful translation cannot support the end-to-end 108 address transparency and costs more compared with the stateless 109 translation. 111 In this document, we present concepts and the implementations of the 112 address-sharing stateless IVI (stateless 1:N IVI) and the address- 113 sharing stateless double IVI (stateless 1:N dIVI). The basic 114 concepts of these techniques are the combination of "Address plus 115 port addressing" (A+P) and the IPv4/IPv6 stateless translation (IVI). 117 The stateless 1:N IVI is the extensions of the stateless 1:1 IVI. It 118 is the solution for the following scenarios 119 [I-D.ietf-behave-v6v4-framework]. 121 o Scenario 1: An IPv6 network to the IPv4 Internet. 123 o Scenario 2: The IPv4 Internet to an IPv6 network. 125 o Scenario 5: An IPv6 network to an IPv4 network. 127 o Scenario 6: An IPv4 network to an IPv6 network. 129 The stateless 1:N IVI and the stateless 1:N dIVI keep all the 130 advantages of stateless 1:1 IVI and can use the IPv4 addresses more 131 effectively. In addition, stateless 1:N dIVI can work without DNS64/ 132 DNS46 and ALG. 134 2. Terminologies 136 This document uses the terminologies defined in 137 [I-D.ietf-behave-v6v4-framework]. 139 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 140 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 141 document, are to be interpreted as described in [RFC2119]. 143 3. Stateless 1:N IVI 145 The stateless 1:N IVI is shown in the following figure. 147 -------- 148 // \\ ----------- 149 / \ // \\ 150 / +----+ \ ------------ 151 | |XLAT| |------ End System 1 152 | The IPv4 +----+ An IPv6 | ------------ 153 | Internet +----+ Network | ------------ 154 | |DNS | (address |------ End System N 155 \ +----+ subset) / ------------ 156 \ / \\ // 157 \\ // ---------- 158 -------- 159 <====> 161 Figure 1: Stateless 1:N IVI 163 Where the XLATE is the IPv4/IPv6 translator perform 1:N translation 164 between IPv4 and IPv6; DNS is the DNS46 and DNS64 for providing the 165 authoritative and resolving services; the End System 1 and End System 166 N, etc are the IPv6-only hosts which can restrict their transport- 167 layer number port range when communicating with the IPv4 Internet. 169 In order to share the IPv4 address among IPv6 hosts, the port number 170 multiplexing technique is used [I-D.xli-behave-ivi]. The basic idea 171 is similar to the ones used in NAT and A+P. This is to say that a 172 single IPv4 address can be shared for multiple IPv6 hosts under the 173 condition that these individual hosts can only use a subset of the 174 65,536 port numbers when communicating with the IPv4 Internet. For 175 example, if the port multiplexing ratio is 128, each host with IPv4- 176 translatable address can use 512 concurrent port numbers when 177 communicating with IPv4 Internet. Note that there is no port number 178 restriction when these IPv6 hosts communicate with the IPv6 Internet. 180 3.1. Address-sharing algorithm 182 The stateless 1:N IVI is shown in the following figure. 184 .-------|Host0| A1/(P%N)+0 185 / 186 ------ ----- | 187 / The \ ------ / An \ | 188 | IPv4 |--|1:N |---| IPv6 |------------|Host1| A1/(P%N)+1 189 \Internet/ |XLATE | \Network/ | 190 ------ ------ ----- | 191 |\ 192 | -------|Host2| A1/(P%N)+2 193 | 194 | 195 \ 196 -------|HostK| A1/(P%N)+K 198 Figure 2: Stateless 1:N IVI 200 In the above figure, the Host0, Host1, Host2, ..., HostK are sharing 201 the same IPv4 address A1, but port number range for different hosts 202 are not overlapped. Therefore, when these IPv6 hosts communicate 203 with the IPv4 Internet via the translator, it looks like a single 204 host with IPv4 address A1 communicating with the IPv4 Internet. 206 We use the Modulus Operator to define the port number range. If the 207 multiplexing ratio is N, then: 209 o For host K, the allowed port number (P) are P=j*N + K-1, where 210 j=0, 1, ..., (65536-N)/N. 212 o For the destination port number (P), the packets will be sent to 213 host K=(P%N) (% is the Modulus Operator). 215 For example: If N=256, then host K=5 is only allowed to use port 216 numbers 5, 261, 517, 773, ..., 65,285 as the source port, while the 217 packets with these port numbers as the destination port number will 218 be send to host K=5. 220 3.2. Extended address format 222 In order to perform the stateless translation (IVI) between the IPv4 223 and IPv6, both IPv4-mapped and IPv4-translatable address are required 224 [I-D.ietf-behave-v6v4-framework]. We use the reserved 16-bits to 225 encode the range of the port number [RFC6052]. 227 The IPv4-mapped addresses are used to represent IPv4 addresses in 228 IPv6, as shown in the following figure. 230 | 0 |32 |40 |72 |88 127| 231 ----------------------------------------------------------------- 232 | LIR |FF | IPv4 addr | all 0 | 233 ----------------------------------------------------------------- 235 Figure 3: IPv4-mapped address format 237 Note that we use the address format and the prefix (e.g. 2001:db8: 238 ff00::/40) defined in [I-D.xli-behave-ivi]. There is no port number 239 coding required for the IPv4-mapped address. 241 The IPv4-translatable addresses are used to represent IPv6 addresses 242 in IPv4, we defined the extended IPv4-translatable as shown in the 243 following figure. 245 | 0 |32 |40 |72 |88 127| 246 ----------------------------------------------------------------- 247 | LIR |FF | IPv4 addr |Port Coding| all 0 | 248 ----------------------------------------------------------------- 250 Figure 4: Extended IPv4-translatable address format 252 Where, we use reserved 16-bits to encode the port number range based 253 on the Modulus Operator. 255 The most significant 4 bits define the multiplexing ratio and the 256 least significant 12 bits define the index of the host, as shown in 257 the following figure. 259 (4 bits) | Index Range(12 bits) | Multx ratio | # of Ports 260 ----------------------------------------------------------------- 261 0 000-000 1 65,536 262 1 000-001 2 32,768 263 2 000-003 4 16,384 264 3 000-007 8 8,192 265 4 000-00f 16 4,096 266 5 000-01f 32 2,048 267 6 000-03f 64 1,024 268 7 000-07f 128 512 269 8 000-0ff 256 256 270 9 000-1ff 512 128 271 A 000-3ff 1,024 64 272 B 000-7ff 2,048 32 273 C 000-fff 4,096 16 274 ----------------------------------------------------------------- 276 Figure 5: Transport layer port number coding 278 3.3. Protocol translation 280 The protocol translation is defined in [I-D.ietf-behave-v6v4-xlate]. 282 3.4. Routing 284 The routing follows the general IPv4/IPv6 routing principle, i.e. 285 "more specifics win", same as the original stateless 1:1 IVI. 286 [I-D.xli-behave-ivi]. 288 3.5. DNS 290 The DNS handling is referring to DNS64 [I-D.ietf-behave-dns64] and 291 DNS46 [I-D.xli-behave-ivi]. 293 3.6. ALG 295 The ALG related issue is discussed in 296 [I-D.ietf-behave-v6v4-framework]. 298 3.7. The translator behavior and the IPv6 end system requirements 300 For the stateless 1:N IVI, the IPv6 end systems are required to 301 follow the port number range defined by the extended IPv4- 302 translatable address format when communicating with the IPv4 303 Internet. The behaviors of the stateless 1:N translator are: 305 o If the packets are from the IPv4 Internet to an IPv6 network, the 306 IPv4 source addresses are translated to the IPv4-mapped addresses 307 and the source port numbers are unchanged; the IPv4 destination 308 addresses are translated to the extended IPv4-translatable 309 addresses based on the destination port number and the destination 310 port numbers are unchanged. 312 o If the packets are from an IPv6 network to the IPv4 Internet, the 313 IPv6 source addresses and the source port numbers are checked, if 314 the source port number matches the port number range defined by 315 the extended IPv4-translatable address format, the IPv6 source 316 addresses (which are the IPv4-translatable addresses) are 317 translated to the IPv4 addresses and the source port numbers are 318 unchanged; the destination IPv6 addresses (which are the IPv4- 319 mapped addresses) are translated to the IPv4 destination addresses 320 and the destination port numbers are unchanged. However, if the 321 source port numbers do not match the port number range defined by 322 the extended IPv4-translatable address format, the packets will be 323 dropped. 325 Therefore, the IPv6 end systems must follow the port number range 326 defined by the extended IPv4-translatable addresses. The behavior of 327 the IPv6 end system when communicating with the IPv4 Internet are: 329 o If the IPv6 end system is used as a server, different well-known 330 ports will be served by different IPv6 hosts. 332 o If the IPv6 end system is used as a client, the end system must 333 generate the source port numbers in the range defined by the 334 extended IPv4-translatable address format. This can be done by 335 modification of the end system, or via a port number mapping 336 device (home gateway). 338 4. Stateless 1:N double IVI 340 In general, it is not a good idea to modify the end system in order 341 to meet the IPv6 end system requirements of the stateless 1:N IVI. 342 Alternatively, we can use the home gateway to map the randomly 343 generated source port number to the port number range defined by 344 extended IPv4-translatable address format. 346 4.1. Port number mapping algorithm 348 The port number mapping algorithm is straightforward. The port 349 number mapping device maintains a database of allowed port numbers 350 defined by the extended IPv4-translatable address format. If the 351 packets from the end system contains the source port number which do 352 not match the port number range defined by the extended IPv4- 353 translatable address format, the home gateway will translate the 354 source port number to an allowed one and keep the record in the 355 database for translating back the returning packets and all the 356 packets in the same session. 358 The port number database can be refreshed via the corresponding 359 transport layer flags for TCP or via timeout for UDP sessions. 361 4.2. Double IVI 363 If we can use the home gateway for the port number mapping, then we 364 can also use the home gateway (1:1 Xlate) to translate the IPv6 365 packets back to IPv4, as shown in the following figure. 367 ------ ----- 368 / The \ ------ / An \ ----- ----- 369 | IPv4 |--|1:N |---| IPv6 |------|1:1 |---|Host1| 370 \Internet/ |XLATE | \Network/ |XLATE| ----- 371 ------ ------ ----- ----- 373 Figure 6: Double IVI (dIVI) 375 The advantage of double IVI is that the DNS64/DNS46 and ALG are not 376 required. 378 The first IPv4/IPv6 translator (1:N XLATE) is the core network 379 translator, the second IPv4/IPv6 translator (1:1 XLATE) is the home 380 gateway translator. The features of these translators are: 382 Core network translator: The core network translator (1:N XLATE) is 383 implemented in the border between the IPv6 core network and the 384 IPv4 Internet. It translates the packets between IPv4 and IPv6 385 with the 1:N stateless address mapping, same as the one used in 386 the stateless 1:N IVI. 388 Home gateway translator: The home gateway translator (1:1 XLATE) is 389 implemented between an IPv6 network and user's end system. It 390 translates the packets between IPv4 and IPv6 with 1:1 stateless 391 address mapping. In addition, the home gateway translator maps 392 random source port numbers to restricted port number based on the 393 extended IPv4-translatable address format and keeps the mapping 394 table in database for the port number mapping of the retuning 395 packets and all the packets in the same session. Note that the 396 1:1 XLATE is still stateless for the address mapping. 398 4.3. Protocol translation 400 The protocol translation is referring to 401 [I-D.ietf-behave-v6v4-xlate]. Special MTU and fragmentation actions 402 must be taken, due to double translation (more details). 404 4.4. Home gateway implementation 406 The home gateway implementation is suitable for the ADSL environment, 407 as shown in the following figure. 409 ---- ----- 410 .-|hgw0|---|Host0| A1/(P%N)+0 411 / ---- ----- 412 ------ ----- | 413 / The \ ------ / An \ | ---- ----- 414 | IPv4 |--|1:N |---| IPv6 |------|hgw1|---|Host1| A1/(P%N)+1 415 \Internet/ |XLATE | \Network/ | ---- ----- 416 ------ ------ ----- | 417 |\ ---- ----- 418 | -|hgw2|---|Host2| A1/(P%N)+2 419 | ---- ----- 420 | 421 \ ---- ----- 422 -|hgwK|---|HostK| A1/(P%N)+K 423 ---- ----- 425 Figure 7: dIVI home gateway implementation 427 Where Xlate is the IPv4/IPv6 stateless 1:N IVI translator; hgw0, 428 hgw1, ..., hgwK are the home gateways performing the port number 429 mapping and the 1:1 IPv4/IPv6 translation function; Host0, Host1, 430 ..., HostK are dual-stack hosts who share same IPv4 address (A1), and 431 have different non-IPv4-translatable IPv6 addresses. 433 4.5. End system implementation 435 For the wireless mobile Internet environment, it is not difficult to 436 modify the operating system of the mobile device, therefore it 437 possible to integrate the port number restriction and the IPv4/IPv6 438 translation function in the mobile device, which is an IPv6-only host 439 to the network and has a dual-stack socket API for the applications 440 running on this host. 442 ----------- 443 .-|Host0 (hgw)| A1/(P%N)+0 444 / ----------- 445 ------ ----- | 446 / The \ ------ / An \ | ----------- 447 | IPv4 |--|1:N |---| IPv6 |------|Host1 (hgw)| A1/(P%N)+1 448 \Internet/ |XLATE | \Network/ | ----------- 449 ------ ------ ----- | 450 |\ ----------- 451 | -|Host2 (hgw)| A1/(P%N)+2 452 | ----------- 453 | 454 \ ----------- 455 -|HostK (hgw)| A1/(P%N)+K 456 ----------- 458 Figure 8: dIVI end system implementation 460 5. Security Considerations 462 There are no security considerations in this document. 464 6. IANA Considerations 466 This memo adds no new IANA considerations. 468 Note to RFC Editor: This section will have served its purpose if it 469 correctly tells IANA that no new assignments or registries are 470 required, or if those assignments or registries are created during 471 the RFC publication process. From the author's perspective, it may 472 therefore be removed upon publication as an RFC at the RFC Editor's 473 discretion. 475 7. Acknowledgments 477 The authors would like to acknowledge the following contributors in 478 the different phases of the address-sharing IVI and dIVI development: 479 Maoke Chen, Yu Zhai, Wentao Shang, Weifeng Jiang and Yuncehng Zhu. 481 The authors would like to acknowledge the following contributors who 482 provided helpful inputs: Dan Wing, Fred Baker, Dave Thaler, Randy 483 Bush and Kevin Yin. 485 8. References 486 8.1. Normative References 488 [I-D.ietf-behave-dns64] 489 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 490 "DNS64: DNS extensions for Network Address Translation 491 from IPv6 Clients to IPv4 Servers", 492 draft-ietf-behave-dns64-11 (work in progress), 493 October 2010. 495 [I-D.ietf-behave-v6v4-framework] 496 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 497 IPv4/IPv6 Translation", 498 draft-ietf-behave-v6v4-framework-10 (work in progress), 499 August 2010. 501 [I-D.ietf-behave-v6v4-xlate] 502 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 503 Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in 504 progress), September 2010. 506 [I-D.ietf-behave-v6v4-xlate-stateful] 507 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 508 NAT64: Network Address and Protocol Translation from IPv6 509 Clients to IPv4 Servers", 510 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 511 progress), July 2010. 513 [RFC1035] Mockapetris, P., "Domain names - implementation and 514 specification", STD 13, RFC 1035, November 1987. 516 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 517 Requirement Levels", BCP 14, RFC 2119, March 1997. 519 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 520 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 521 October 2010. 523 8.2. Informative References 525 [CERNET] "CERNET Homepage: 526 http://www.edu.cn/english_1369/index.shtml". 528 [CNGI-CERNET2] 529 "CNGI-CERNET2 Homepage: 530 http://www.cernet2.edu.cn/index_en.htm". 532 [I-D.xli-behave-ivi] 533 Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 534 CERNET IVI Translation Design and Deployment for the IPv4/ 535 IPv6 Coexistence and Transition", draft-xli-behave-ivi-07 536 (work in progress), January 2010. 538 [dIVI] "Test homepage for the dIVI: 539 http://202.38.97.114:8056/test.html". 541 Appendix A. Testing environment and workflow examples 543 We have a testing environment for the address-sharing stateless 544 double IVI with 1:N stateless core translator and 1:1 stateless home 545 gateway translators (or modified end systems) deployed in the 546 [CERNET] (IPv4) and [CNGI-CERNET2] (IPv6). 548 The current implementation of the core translator, home gateway 549 translator and the modified end systems are implemented in Linux OS, 550 with a slightly different Port Coding scheme, as shwon in the 551 following figure: 553 | 0 |32 |40 |72 |96 |112 127| 554 ----------------------------------------------------------------- 555 | LIR |FF | IPv4 addr | zero | R |H index | 556 ----------------------------------------------------------------- 558 R: Port multiplexing ratio 559 H index: Host Index 561 Figure 9: Extended IPv4-translatable address format (testing) 563 Where bit 96 to 111 is used to represnet the port multiplexing ratio, 564 for example, 0100 represents port multiplexing ratio 256; bit 112 to 565 127 is used to represent the host index starting from 0 to R-1. 567 The testing environment is shown in the following figure. 569 [2001:DA9:FF3A:C8C0:A00:0:100:0] - 58.200.192.10:4096 570 ---- ----- 571 .-|hgw0|---|Host0| 572 / ---- ----- 573 ------ ----- | 574 / The \ ------ / An \ | 575 | IPv4 |--|1:N |---| IPv6 |-- 576 \Internet/ |XLATE | \Network/ | ---- ----- 577 ------ ------ ----- \--|hgw1|---|Host1| 578 / \ ---- ----- 579 | \ [2001:DA9:FF3A:C8C0:A00:0:100:1] - 58.200.192.10:4097 580 | \ 581 | \ -- 582 | \ ----|S2| 583 -- -- 584 |C1| 202.38.105.1:80 - [2001:252:ffca:2669:100::] 585 -- 586 125.34.46.137 - [2001:DA9:ff7d:222e:8900::] 588 Figure 10: dIVI testing environment 590 In this testing environment, the LIR=2001DA9:ff00::/40 and the port 591 multiplexing ratio R=256. We only show two hosts here, Host0 592 (index=0) and Host1 (index=1). The core translator 1:N XLATE is 593 configured with LIR=2001DA9:ff00::/40 and R=256. The home gateway 594 (hgw1) is configured with LIR=2001DA9:ff00::/40, R=256 and index=0, 595 while the home gateway (hgw2) is configured with LIR=2001DA9: 596 ff00::/40, R=256 and index=1. 598 The testing homepage is at [dIVI] 600 A.1. The host on the IPv4 Internet initiats communication 602 Host C1 (125.34.46.137) in the IPv4 Internet initiates communication 603 with address-sharing end system Host0 (http://58.200.192.10:4096) in 604 an IPv6 network behind home gateway. 606 On the IPv4 Internet 607 Src#p= 125.34.46.137#1856 (#random port) 608 Dst#p= 58.200.192.10:4096 (#server port) 610 On an IPv6 network 611 Src#p= [2001:DA9:ff7d:222e:8900::]#1856 (#random port) 612 Dst#p= [2001:DA9:FF3A:C8C0:A00:0:100:0]#4096 (#server port) 614 On the address-sharing end system Host0 615 Src#p= 125.34.46.137#1856 (#random port) 616 Dst#p= 58.200.192.10:4096 (#server port) 618 Figure 11: Example 1 620 The returning packets reverse the Src and Dst. 622 A.2. The address-sharing end system on an IPv6 network initiats 623 communication 625 An address-sharing end system Host0 (58.200.192.10) in an IPv6 626 network behind home gateway initiates communication with Host S2 627 (http://202.38.105.1:80) in the IPv4 Internet 629 On the end system Host0 630 Src#p= 58.200.192.10:1881 (random port) 631 Dst#p= 202.38.105.1:80#80 (server port) 633 On an IPv6 network 634 Src#p= [2001:DA9:FF3A:C8C0:A00:0:100:0]#8192 (home gateway mapped port) 635 Src#p= [2001:252:ffca:2669:100::]#80 (server port) 637 On the IPv4 Internet 638 Src#p= 58.200.192.10:8192 (home gateway mapped port) 639 Dst#p= 202.38.105.1:80#80 (server port) 641 Figure 12: Example 2 643 The returning packets reverse the Src and Dst, the home gateway maps 644 the "home gateway mapped port (8192)" back to the original "random 645 port (1881)". 647 Authors' Addresses 649 Xing Li 650 CERNET Center/Tsinghua University 651 Room 225, Main Building, Tsinghua University 652 Beijing 100084 653 CN 655 Phone: +86 10-62785983 656 Email: xing@cernet.edu.cn 658 Congxiao Bao 659 CERNET Center/Tsinghua University 660 Room 225, Main Building, Tsinghua University 661 Beijing 100084 662 CN 664 Phone: +86 10-62785983 665 Email: congxiao@cernet.edu.cn 667 Hong Zhang 668 CERNET Center/Tsinghua University 669 Room 225, Main Building, Tsinghua University 670 Beijing 100084 671 CN 673 Phone: +86 10-62785983 674 Email: neilzh@gmail.com