idnits 2.17.1 draft-xli-behave-divi-03.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 13 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 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 (July 10, 2011) is 4667 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-01) exists of draft-xli-behave-divi-pd-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bao 3 Internet-Draft X. Li 4 Intended status: Informational Y. Zhai 5 Expires: January 11, 2012 W. Shang 6 CERNET Center/Tsinghua 7 University 8 July 10, 2011 10 dIVI: Dual-Stateless IPv4/IPv6 Translation 11 draft-xli-behave-divi-03 13 Abstract 15 This document presents the concepts and the implementations of 16 address-sharing dual-stateless IPv4/IPv6 translation (dIVI). 18 The dIVI is an extension of 1:1 stateless IPv4/IPv6 translation with 19 features of IPv4 address sharing and dual translation. The major 20 benefits of those extensions are using public IPv4 addresses more 21 effectively and removing the requirements of DNS64 and ALG, without 22 loosing the stateless, end-to-end address transparency and 23 bidirectional-initiated communications. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 11, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Port-set Algorithm . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Suffix Coding . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.1. Extended Address Format . . . . . . . . . . . . . . . . . 7 65 5.2. Suffix Table . . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Dual Stateless Translation . . . . . . . . . . . . . . . . . . 8 67 6.1. Header Translation and MTU Handling . . . . . . . . . . . 9 68 6.2. Port Mapping Algorithm in CPE . . . . . . . . . . . . . . 9 69 6.3. Relations to Tunneling . . . . . . . . . . . . . . . . . . 9 70 7. Implementation Considerations . . . . . . . . . . . . . . . . 10 71 7.1. Host implementation . . . . . . . . . . . . . . . . . . . 10 72 7.2. Port Mapping in the Core Translator . . . . . . . . . . . 10 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Appendix A. Testing environment and workflow examples . . . . . . 12 80 A.1. The address-sharing host on an IPv6 network initiates 81 communication . . . . . . . . . . . . . . . . . . . . . . 13 82 A.2. A host in the IPv4 Internet initiates communication . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 The experiences for the IPv6 deployment in the past 10 years strongly 88 indicate that for a successful transition, the communication between 89 IPv4 and IPv6 address families should be supported. 91 Recently, the stateless and stateful IPv4/IPv6 translation methods 92 are developed and became the IETF standards. The original stateless 93 IPv4/IPv6 translation (stateless 1:1 IVI) is scalable, maintains the 94 end-to-end address transparency and support both IPv6 initiated and 95 IPv4 initiated communications [RFC6052], [RFC6144], [RFC6145], 96 [RFC6147], [RFC6219]. But it can not use the IPv4 addresses 97 effectively. The stateful IPv4/IPv6 translation can share the IPv4 98 addresses among IPv6 hosts, but it only supports IPv6 initiated 99 communication [RFC6052], [RFC6144], [RFC6145], [RFC6146], [RFC6147]. 100 In addition, both stateless and stateful IPv4/IPv6 translation 101 technologies require the application layer gateway (ALG) for the 102 applications which embed IP address literals. 104 In this document, we present concepts and the implementations of the 105 dual-stateless IPv4/IPv6 translation (dIVI). The dIVI can solve the 106 IPv4 address sharing and the ALG problems mentioned above, though 107 still keeps the stateless, end-to-end address transparency and 108 supporting of both IPv6 initiated and IPv4 initiated communications. 109 The dIVI is in the family of stateless IPv4/IPv6 translation, along 110 with IVI and dIVI. These techniques are used for the following 111 scenarios defined in [RFC6144]. 113 o Scenario 1: An IPv6 network to the IPv4 Internet. 115 o Scenario 2: The IPv4 Internet to an IPv6 network. 117 o Scenario 5: An IPv6 network to an IPv4 network. 119 o Scenario 6: An IPv4 network to an IPv6 network. 121 2. Applicability 123 The address sharing dual stateless IPv4/IPv6 translation (dIVI) is 124 shown in the following figure. 126 ----- ------ 127 .-|CPE.0|---|Host.0| 128 / ----- ------ 129 ------ ----- | 130 / The \ ------ / An \ | ----- ------ 131 | IPv4 |--| 1:N |---| IPv6 |------|CPE.1|---|Host.1| 132 \Internet/ | XLAT | \Network/ | ----- ------ 133 ------ ------ ----- | 134 |\ ----- ------ 135 | -|CPE.2|---|Host.2| 136 | ----- ------ 137 | ...... 138 \ ----- ------ 139 -|CPE.K|---|Host.K| 140 ----- ------ 141 ...... 143 Figure 1: dIVI 145 Where the 1:N XLAT (first translator) is the IPv4/IPv6 translator 146 perform stateless 1:N translation between the IPv4 Internet and an 147 IPv6 network; The CPE.0 to CPE.K (second translators) are 1:1 IPv6/ 148 IPv4 translators/IPv6 routers which also perform port mapping 149 function for Host.x when it is communicating with the IPv4 Internet 150 with IPv4 address sharing; the Host.1 to Host.N are the dual-stack 151 hosts. 153 The IPv6 network routes the IPv6 more specific routes of the IPv4- 154 translatable addresses (longer than /64) defined in Section 5 of this 155 document to corresponding CPEs. In the case of prefix delegation 156 (shorter than /64), the dual stateless IPv4/IPv6 translation with 157 prefix delegation (dIVI-pd) defined in [I-D.xli-behave-divi-pd] can 158 be used. 160 3. Terminologies 162 This document uses the terminologies defined in [RFC6144]. 164 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 165 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 166 document, are to be interpreted as described in [RFC2119]. 168 4. Port-set Algorithm 170 The address-sharing scheme is shown in the following figure. 172 --------------------------------- 173 -----|IPv4-translatable.0#port-range.0 | 174 / --------------------------------- 175 / --------------------------------- 176 |--------|IPv4-translatable.1#port-range.1 | 177 | --------------------------------- 178 -------------------- | --------------------------------- 179 | IPv4-addr#any ports|-----------|IPv4-translatable.2#port-range.2 | 180 -------------------- | --------------------------------- 181 | --------------------------------- 182 |--------|IPv4-translatable.3#port-range.3 | 183 | --------------------------------- 184 \ ... 185 \ --------------------------------- 186 -----|IPv4-translatable.K#port-range.K | 187 --------------------------------- 188 ... 190 Figure 2: Address Sharing Scheme 192 In the above figure, the IPv4-translatable.0, IPv4-translatable.1, 193 IPv4-translatable.2, ..., IPv4-translatable.K are sharing the same 194 IPv4 address IPv4-addr, but port number range for different IPv4- 195 translatable addresses (i.e. port-range.0, port-range.1, port- 196 range.2, port-range.K) are not overlapped. When an IPv6 node using 197 IPv4-translatable addresses communicates with the IPv4 Internet via a 198 translator, it looks like a single host using IPv4 address (IPv4- 199 addr) communicating with the IPv4 Internet. 201 There exist many port-range coding schemes and each one may have its 202 advantages and disadvantages, as well as has its best application 203 scenario. In this document, we will introduce a simple one, which we 204 believe is suitable for the IPv4/IPv6 stateless translation. This 205 encoding scheme uses the modulus operator to define the port number 206 range for each host to use. 208 o For given multiplexing ratio N, the port-set numbers of a IPv4- 209 translatable address with port-set-id K is composed of P=j*N + K + 210 1024, for all the values of j=0, 1, ..., (65536-N)/N. 212 o For a destination port number (P), the port-set-id of a given 213 IPv4-tanslatable address with port-set-id K is determined by the 214 modulo operation: K=((P-1024)%N) (% is the Modulus Operator). 216 For example, If N=128, then IPv6 node K=5 is only allowed to use port 217 numbers 5, 133, 261, 389, 517, 645, 773, 901, ... 65,413 as the 218 source port, while the packets with these port numbers as the 219 destination port number will be send to IPv6 node K=5. 221 The modulus operator has several features: 223 1. The port ranges are not overlapped for different IPv6 nodes. 225 2. The individual ports for each IPv6 node are not continues and the 226 whole 65536 port range is equally shared by IPv6 nodes. 228 3. The port number range can be uniquely determined by given sharing 229 ratio (N) and the IPv6 node index (K). 231 Based on the modulus operator, We need to encode N and K in the 232 suffix as discussed in [RFC6052]. 234 5. Suffix Coding 236 In Section 2.2 of [RFC6052] IPv4-embedded IPv6 address format is 237 defined which composed of a variable length prefix, the embedded IPv4 238 address, and a variable length suffix, as presented in the following 239 diagram, in which PL designates the prefix length: 241 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 242 |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| 243 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 244 |32| prefix |v4(32) | u | suffix | 245 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 246 |40| prefix |v4(24) | u |(8)| suffix | 247 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 248 |48| prefix |v4(16) | u | (16) | suffix | 249 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 250 |56| prefix |(8)| u | v4(24) | suffix | 251 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 252 |64| prefix | u | v4(32) | suffix | 253 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 254 |96| prefix | v4(32) | 255 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 257 Figure 3: Address Format 259 In Section 3.5 of [RFC6052], it states: 261 "There have been proposals to complement stateless translation 262 with a port-range feature. Instead of mapping an IPv4 address to 263 exactly one IPv6 prefix, the options would allow several IPv6 264 nodes to share an IPv4 address, with each node managing a 265 different range of ports. If a port range extension is needed, it 266 could be defined later, using bits currently reserved as null in 267 the suffix." 269 This document defines such a suffix encoding scheme with the 270 corresponding port-range algorithm. 272 5.1. Extended Address Format 274 It is clear that only Prefix lengths (PL) with 32, 40, 48, 56 and 64 275 have suffix portions, with maximum suffix lengths of 56, 48, 40, 32, 276 24, respectively. In order to use different prefix length and unify 277 the port range encoding method, the suffix should be 24 bits or less. 279 Since the transport port number is a 16 bit integer, the sharing 280 ratio (N) and the port-set index (K) can both have the value from 0 281 to 65535, which requires 32 bits. In order to fit into 24 bit suffix 282 range, we need to do compression. 284 First, we can use number of bits to represent the sharing ratio when 285 the sharing ratio is bit-wise, hence 4 bits is enough for N. 287 Secondly, if sharing ratio N is very high, each IPv6 node can only 288 use a small number of concurrent sessions. For example, if N=4096, 289 each IPv6 node will have 16 concurrent sessions, which may be too 290 small for most of the applications. That may limit the use of some 291 applications, therefore, we set the maximum sharing ratio N=4096, 292 then 12 bits are enough for the IPv6 node index. In this case, we 293 can design suffix which consists of 16 bits for encoding the port 294 range as in the following figures. Note that for different PL, zero 295 padding is needed. 297 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 298 |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| 299 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 300 |32| prefix |v4(32) | u | suffix| zero | 301 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 302 |40| prefix |v4(24) | u |(8)| suffix| zero | 303 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 304 |48| prefix |v4(16) | u | (16) | suffix| zero | 305 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 306 |56| prefix |(8)| u | v4(24) | suffix| zero | 307 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 308 |64| prefix | u | v4(32) | suffix|zer| 309 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 311 Figure 4: Extended Address Format 313 The port range is therefore embedded in the extended IPv4- 314 translatable IPv6 addresses and bound to the IPv6 node index (K), the 315 packets containing extended IPv4-translatable IPv6 addresses as the 316 destination can be routed to different IPv6 nodes. 318 5.2. Suffix Table 320 The suffix table is shown in the following figures, where the most 321 significant 4 bits define the multiplexing ratio and the least 322 significant 12 bits define the port-set index. 324 ratio | suffix range | # of Ports 325 -------------------------------------- 326 1 0000 - 0000 65,536 327 2 1000 - 1001 32,768 328 4 2000 - 2003 16,384 329 8 3000 - 3007 8,192 330 16 4000 - 400f 4,096 331 32 5000 - 501f 2,048 332 64 6000 - 603f 1,024 333 128 7000 - 707f 512 334 256 8000 - 80ff 256 335 512 9000 - 91ff 128 336 1,024 a000 - a3ff 64 337 2,048 b000 - b7ff 32 338 4,096 c000 - cfff 16 339 -------------------------------------- 341 Figure 5: Suffix for Port Range Encoding 343 6. Dual Stateless Translation 345 In general dual stateful IPv4/IPv6 translations (IPv4-IPv6-IPv4) are 346 considered harmful, since the two translators cannot synchronize the 347 parameter to translate the IPv4 address to its original format. 348 However, the dual stateless IPv4/IPv6 translation (IPv4-IPv6-IPv4) 349 can translate the IPv4 address to its original format based on 350 algorithm. There are several reasons for using dual stateless IPv4/ 351 IPv6 translation. 353 o The second translator (CPE) performs the port-set mapping 354 algorithm defined in Section 4, therefore, there is no need to 355 modify the host with IPv4 address sharing. 357 o ALG cannot be developed for some applications, or has not been 358 developed during the early transition stage. 360 o DNS64 is not allowed (due to DNSSec, etc.). 362 6.1. Header Translation and MTU Handling 364 The general header and ICMP translation specifications are defined in 365 [RFC6145]. 367 Special MTU and fragmentation actions must be taken in the case of 368 dual translation. 370 6.2. Port Mapping Algorithm in CPE 372 The port mapping algorithm is straightforward. The port mapping 373 device maintains a database of allowed port numbers defined by the 374 extended IPv4-translatable address format. If the packets from the 375 host contains the source port number which do not match the port 376 number range defined by the extended IPv4-translatable address 377 format, the CPE will map the source port number to an allowed one and 378 keep the record in the database for mapping back the returning 379 packets and all the packets in the same session. 381 The port number database can be refreshed via the corresponding 382 transport layer flags for TCP or via timeout for UDP sessions. 384 6.3. Relations to Tunneling 386 When dual stateless IPv4/IPv6 translation is deployed, its behavior 387 is similar to tunneling. Tunneling do not require DNS64 and ALG., 388 because the communication occurs in same address family. Dual 389 translation don't need DNS64 and ALG as well, even in each translator 390 the communication occurs between different address families. 391 However, there are following differences: 393 o Scalability. Dual stateless translation is based on routing, 394 there is nothing needed to maintain in the translator, operator's 395 management loads are minimum compared with tunneling scheme, which 396 has to maintain tunnel states. 398 o Low OPEX. Dual stateless translation can do traffic engineering 399 and flow analysis without decapsulation which is a must in tunnel 400 case. 402 o Header Compression. The dual stateless IPv4/IPv6 translation does 403 not need to do encapsulation and at least 20 octets header 404 overhead are reduced. 406 o No performance bottlenecks. The dual stateless translation 407 handles the fragmented packets by hosts, while the tunneling 408 handles the fragmented packets in the tunnel end points. 409 Therefore, there is no performance bottlenecks. 411 o Transparent transition to IPv6. The dual stateless translation 412 can be treated as a special case of single stateless translation, 413 the first XLAT performances exactly the same function, no matter 414 there is a XLAT.x or not. Hence it is a unified approach, rather 415 than special setup for the coexistence and transition. This is to 416 say that the ISP can deploy IPv6-only network with XLAT, so the 417 IPv6-only hosts can communicate with both the IPv6 Internet and 418 the IPv4 Internet. However, if for some reason a specific ALG 419 cannot be supported, and for users, who need that specific 420 application, can deploy XLAT.x. When the application is updated, 421 the XLAT.x can be removed. There is nothing to change to XLAT. 422 with more and more contents and users move to IPv6, the working 423 load of XLAT will be less and less, and eventually can be removed. 424 The whole process is transparent, smooth and incremental. 426 7. Implementation Considerations 428 7.1. Host implementation 430 For the wireless mobile Internet environment, it is not difficult to 431 modify the operating system of the mobile device, therefore it 432 possible to integrate the port mapping algorithm and the second IPv4/ 433 IPv6 translation function in the mobile device, which is an IPv6-only 434 host to the network and has a dual-stack socket API for the 435 applications running on this host. 437 7.2. Port Mapping in the Core Translator 439 The port mapping can be performed in the core translator, in this 440 case, in this case, there is no need to have the second translator 441 (CPE.x) and no need to modify the IPv6 host for the port restriction 442 requirements. 444 8. Security Considerations 446 There are no security considerations in this document. 448 9. IANA Considerations 450 This memo adds no new IANA considerations. 452 Note to RFC Editor: This section will have served its purpose if it 453 correctly tells IANA that no new assignments or registries are 454 required, or if those assignments or registries are created during 455 the RFC publication process. From the author's perspective, it may 456 therefore be removed upon publication as an RFC at the RFC Editor's 457 discretion. 459 10. Acknowledgments 461 The authors would like to acknowledge the following contributors in 462 the different phases of the address-sharing IVI and dIVI development: 463 Maoke Chen, Hong Zhang, Weifeng Jiang, Yuncehng Zhu and Guoliang Han. 465 The authors would like to acknowledge the following contributors who 466 provided helpful inputs: Dan Wing, Fred Baker, Dave Thaler, Randy 467 Bush, Kevin Yin, Wojciech Dec and Rajiv Asati. 469 11. References 471 11.1. Normative References 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, March 1997. 476 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 477 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 478 October 2010. 480 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 481 IPv4/IPv6 Translation", RFC 6144, April 2011. 483 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 484 Algorithm", RFC 6145, April 2011. 486 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 487 NAT64: Network Address and Protocol Translation from IPv6 488 Clients to IPv4 Servers", RFC 6146, April 2011. 490 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 491 Beijnum, "DNS64: DNS Extensions for Network Address 492 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 493 April 2011. 495 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 496 China Education and Research Network (CERNET) IVI 497 Translation Design and Deployment for the IPv4/IPv6 498 Coexistence and Transition", RFC 6219, May 2011. 500 11.2. Informative References 502 [I-D.xli-behave-divi-pd] 503 Li, X., Bao, C., Dec, W., and R. Asati, "dIVI-pd: Dual- 504 Stateless IPv4/IPv6 Translation with Prefix Delegation", 505 draft-xli-behave-divi-pd-00 (work in progress), July 2011. 507 Appendix A. Testing environment and workflow examples 509 The prefix we selected is 2001:da8:a4a6::/48. The IPv4-converted 510 address and the IPv4-translatable address are: 512 IPv4-converted address 513 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 514 |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| 515 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 516 |48| prefix |v4(16) | u | (16) | zero | 517 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 519 IPv4-translatable address 520 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 521 |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| 522 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 523 |48| prefix |v4(16) | u | (16) | suffix| zero | 524 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 526 Figure 6: Address format 528 The IPv4 address sharing ratio is 16. So the port-set index is 530 ratio | suffix range | # of Ports 531 -------------------------------------- 532 16 4000 - 400f 4,096 533 -------------------------------------- 535 Figure 7: Address format 537 The public IPv4 address is 202.38.117.0/24. 539 The host in the IPv4 Internet is 202.112.35.254 and the corresponding 540 IPv4-converted address is 2001:da8:b4b6:ca:7023:fe00::. 542 The shared IPv4 address is 202.38.117.1 with sharing ratio 16, the 543 corresponding IPv4-translatable addresses are 2001:da8:b4b6:ca:2675: 545 0140:100::, 2001:da8:b4b6:ca:2675:0140:200::, 2001:da8:b4b6:ca:2675: 546 0140:300::, 2001:da8:b4b6:ca:2675:0140:400::, 2001:da8:b4b6:ca:2675: 547 0140:500::, ..., 2001:da8:b4b6:ca:2675:0140:f00::. 549 A.1. The address-sharing host on an IPv6 network initiates 550 communication 552 An address-sharing Host.0 (202.38.117.1) in an IPv6 network behind 553 CPE initiates communication with Host 202.112.35.254:80 in the IPv4 554 Internet 556 On the Host.0 557 Src#p= 202.38.117.1#1881 (random port) 558 Dst#p= 202.112.35.254#80 (server port) 560 On an IPv6 network 561 Src#p= [2001:da8:b4b6:ca:2675:0140:100::]#8192 (CPE mapped port) 562 Dst#p= [2001:da8:b4b6:ca:7023:fe00::]#80 (server port) 564 On the IPv4 Internet 565 Src#p= 202.38.117.1#8192 (CPE mapped port) 566 Dst#p= 202.112.35.254#80 (server port) 568 Figure 8: Example 1 570 The returning packets reverse the Src and Dst, the CPE maps the "CPE 571 mapped port (8192)" back to the original "random port (1881)". 573 A.2. A host in the IPv4 Internet initiates communication 575 A host 202.112.35.254 in the IPv4 Internet initiates communication to 576 the address-sharing Host.0 (202.38.117.1#2000) 578 On the IPv4 Internet 579 Src#p= 202.112.35.254#36567 (random port) 580 Dst#p= 202.38.117.1#2000 (server port) 582 On an IPv6 network 583 Src#p= [2001:da8:b4b6:ca:7023:fe00::]#36567 (random port) 584 Dst#p= [2001:da8:b4b6:ca:2675:0140:100::]#2000 (server port) 586 On the Host.0 587 Src#p= 202.112.35.254#36567 (random port) 588 Dst#p= 202.38.117.1#2000 (server port) 590 Figure 9: Example 2 592 The returning packets reverse the Src and Dst. 594 Authors' Addresses 596 Congxiao Bao 597 CERNET Center/Tsinghua University 598 Room 225, Main Building, Tsinghua University 599 Beijing 100084 600 CN 602 Phone: +86 10-62785983 603 Email: congxiao@cernet.edu.cn 605 Xing Li 606 CERNET Center/Tsinghua University 607 Room 225, Main Building, Tsinghua University 608 Beijing 100084 609 CN 611 Phone: +86 10-62785983 612 Email: xing@cernet.edu.cn 614 Yu Zhai 615 CERNET Center/Tsinghua University 616 Room 225, Main Building, Tsinghua University 617 Beijing 100084 618 CN 620 Phone: +86 10-62785983 621 Email: jacky.zhai@gmail.com 623 Wentao Shang 624 CERNET Center/Tsinghua University 625 Room 225, Main Building, Tsinghua University 626 Beijing 100084 627 CN 629 Phone: +86 10-62785983 630 Email: wentaoshang@gmail.com