idnits 2.17.1 draft-xli-behave-divi-08.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 12 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 (October 17, 2017) is 2380 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2473' is defined on line 408, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-11) exists of draft-bcx-behave-address-fmt-extension-10 Summary: 1 error (**), 0 flaws (~~), 6 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: April 20, 2018 W. Shang 6 CERNET Center/Tsinghua 7 University 8 October 17, 2017 10 dIVI: Dual-Stateless IPv4/IPv6 Translation 11 draft-xli-behave-divi-08 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 April 20, 2018. 42 Copyright Notice 44 Copyright (c) 2017 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 Mapping Algorithm and Address Format Extension . . . . . 5 63 4.1. Port Mapping Algorithm . . . . . . . . . . . . . . . . . . 5 64 4.2. Address Format Extensions . . . . . . . . . . . . . . . . 6 65 4.3. Stateless Translation Algorithm with Address Sharing . . . 7 66 4.4. Partial-state Translation Algorithm with Address 67 Sharing . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5. Dual Stateless Translation . . . . . . . . . . . . . . . . . . 7 69 5.1. Header Translation and MTU Handling . . . . . . . . . . . 8 70 5.2. Port Mapping Algorithm in CPE . . . . . . . . . . . . . . 8 71 6. Implementation Considerations . . . . . . . . . . . . . . . . 8 72 6.1. Host implementation . . . . . . . . . . . . . . . . . . . 9 73 6.2. Port Mapping in the Core Translator . . . . . . . . . . . 9 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 80 Appendix A. Address Format and Workflow Examples . . . . . . . . 11 81 A.1. The address-sharing host on an IPv6 network initiates 82 communication . . . . . . . . . . . . . . . . . . . . . . 12 83 A.2. A host in the IPv4 Internet initiates communication . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 The experiences for the IPv6 deployment in the past 10 years strongly 89 indicate that for a successful transition, the communication between 90 IPv4 and IPv6 address families should be supported. 92 Recently, the stateless and stateful IPv4/IPv6 translation methods 93 are developed and became the IETF standards. The original stateless 94 IPv4/IPv6 translation (stateless 1:1 IVI) is scalable, maintains the 95 end-to-end address transparency and support both IPv6 initiated and 96 IPv4 initiated communications [RFC6052], [RFC6144], [RFC6145], 97 [RFC6147], [RFC6219]. But it can not use the IPv4 addresses 98 effectively. The stateful IPv4/IPv6 translation can share the IPv4 99 addresses among IPv6 hosts, but it only supports IPv6 initiated 100 communication [RFC6052], [RFC6144], [RFC6145], [RFC6146], [RFC6147]. 101 In addition, both stateless and stateful IPv4/IPv6 translation 102 technologies require the application layer gateway (ALG) for the 103 applications which embed IP address literals. 105 In this document, we present concepts and the implementations of the 106 dual-stateless IPv4/IPv6 translation (dIVI). The dIVI can solve the 107 IPv4 address sharing and the ALG problems mentioned above, though 108 still keeps the stateless, end-to-end address transparency and 109 supporting of both IPv6 initiated and IPv4 initiated communications. 110 The dIVI is in the family of stateless IPv4/IPv6 translation, along 111 with IVI and dIVI-PD [I-D.xli-behave-divi-pd]. These techniques are 112 used for the following scenarios with second translation extension 113 defined in [RFC6144]. 115 o Scenario 1: IPv4 hosts via an IPv6 network to the IPv4 Internet. 117 o Scenario 2: The IPv4 Internet via an IPv6 network to IPv4 hosts. 119 o Scenario 5: An IPv6 network via an IPv4 network to IPv4 hosts. 121 o Scenario 6: IPv4 hosts via an IPv4 network to an IPv6 network. 123 2. Applicability 125 The address sharing dual stateless IPv4/IPv6 translation (dIVI) is 126 shown in the following figure. 128 ----- ------ 129 .-|CPE.0|---|Host.0| 130 / ----- ------ 131 ------ ----- | 132 / The \ ------ / An \ | ----- ------ 133 | IPv4 |--| 1:N |---| IPv6 |------|CPE.1|---|Host.1| 134 \Internet/ | XLAT | \Network/ | ----- ------ 135 ------ ------ ----- | 136 |\ ----- ------ 137 | -|CPE.2|---|Host.2| 138 | ----- ------ 139 | ...... 140 \ ----- ------ 141 -|CPE.K|---|Host.K| 142 ----- ------ 143 ...... 145 Figure 1: dIVI 147 Where 149 o The 1:N XLAT (first translator) is the IPv4/IPv6 translator 150 perform stateless 1:N translation between the IPv4 Internet and an 151 IPv6 network. 153 o The CPE.0 to CPE.K (second translators) are 1:1 IPv6/IPv4 154 translators/IPv6 routers which also perform port mapping function 155 for Host.x when it is communicating with the IPv4 Internet with 156 IPv4 address sharing. 158 o The Host.1 to Host.N are the dual-stack hosts. 160 The IPv6 network routes the IPv6 more specific routes of the IPv4- 161 translatable addresses (longer than /64) defined in Section 5 of this 162 document to corresponding CPEs. In the case of prefix delegation 163 (shorter than /64), the dual stateless IPv4/IPv6 translation with 164 prefix delegation (dIVI-pd) defined in [I-D.xli-behave-divi-pd] can 165 be used. 167 3. Terminologies 169 This document uses the terminologies defined in [RFC6144]. 171 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 172 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 173 document, are to be interpreted as described in [RFC2119]. 175 4. Port Mapping Algorithm and Address Format Extension 177 4.1. Port Mapping Algorithm 179 The dual stateless IPv4/IPv6 translation (dIVI) uses the port mapping 180 algorithm defined in [I-D.bcx-behave-address-fmt-extension]. 182 For given sharing ratio (R) and the maximum number of continue ports 183 (M), the generalized modulus algorithm is defined as 185 1. The port number (P) of a given PSID (K) is composed of 187 P = R*M*j + M*K + i 189 Where 190 o PSID: K=0 to R-1 191 o Port range index: j = (1024/M)/R to ((65536/M)/R)-1, if the 192 well-known port numbers (0-1023) are excluded. 193 o Port continue index: i=0 to M-1 195 2. The PSID (K) of a given port number (P) is determined by 197 K = (floor(P/M)) % R 199 Where 200 o % is modular operator 201 o floor(arg) is a function returns the largest integer not 202 greater than arg 204 3. The well-known port number (0-1023) can be used, if additional 205 port mapping rule is defined. 207 For example, for R=128, M=4 209 Port range-1 | Port rang-2 | Port 210 ------------------------------------------------------------------- 211 PSID=0 | 1024, 1025, 1026, 1027, | 1536, 1537, 1538, 1539, | 2048 212 PSID=1 | 1028, 1029, 1030, 1031, | 1540, 1541, 1542, 1543, | .... 213 PSID=2 | 1032, 1033, 1034, 1035, | 1544, 1545, 1546, 1547, | .... 214 PSID=3 | 1036, 1037, 1038, 1039, | 1548, 1549, 1550, 1551, | .... 215 ... 216 PSID=127 | 1532, 1533, 1534, 1535, | 2044, 2045, 2046, 2047, | .... 218 Figure 2: Example 220 4.2. Address Format Extensions 222 The dual stateless IPv4/IPv6 translation (dIVI) uses the address 223 format extension defined in [I-D.bcx-behave-address-fmt-extension]. 225 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 226 |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| 227 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 228 |32| prefix |v4(32) | u | PSID | 0 | Q | 229 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 230 |40| prefix |v4(24) | u |(8)| PSID | 0 | Q | 231 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 232 |48| prefix |v4(16) | u | (16) | PSID | 0 | Q | 233 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 234 |56| prefix |(8)| u | v4(24) | PSID | 0 | Q | 235 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 236 |64| prefix | u | v4(32) |PSID |0| Q | 237 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 239 Figure 3: Address Format 241 Where PL designates the prefix length. 243 The PSID prefix length (Q) is encoded in the last octet (bits 120- 244 127) to indicate the number of ports can be used. When Q=0, the 245 extended address format will become the address format defined in 246 [RFC6052]. The relations between Q, the sharing ratio (R), the 247 maximum continue port range (M) and the number of ports can be shown 248 in the following figure. 250 Q Ratio | Maximum M | # of Ports 251 ------------------------------------------ 252 0 1:1 65,536 65,536 253 1 1:2 32,786 32,786 254 2 1:4 16,384 16,384 255 3 1:8 8,192 8,192 256 4 1:16 4,096 4,096 257 5 1:32 2,048 2,048 258 6 1:64 1,024 1,024 259 7 1:128 512 512 260 8 1:256 256 256 261 9 1:512 128 128 262 10 1:1,024 64 64 263 11 1:2,048 32 32 264 12 1:4,096 16 16 265 ------------------------------------------ 267 Figure 4: Port Range 269 4.3. Stateless Translation Algorithm with Address Sharing 271 For the stateless translation, the IPv6 nodes are required to follow 272 the port number range defined by the extended IPv4-translatable 273 address format when communicating with the IPv4 Internet. The port 274 number handling algorithm is: 276 o If the packets are from the IPv4 Internet to an IPv6 network, the 277 IPv4 source addresses are translated to the IPv4-converted 278 addresses and the source port numbers are unchanged before and 279 after translation; the IPv4 destination addresses are translated 280 to the extended IPv4-translatable addresses based on the 281 destination port number and the destination port numbers are 282 unchanged before and after translation. Note that this means that 283 only a specific IPv6 node can receive the packets for a specific 284 port number. 286 o If the packets are from an IPv6 network to the IPv4 Internet, the 287 IPv6 source addresses and the source port numbers are checked, if 288 the source port number matches the port number range defined by 289 the extended IPv4-translatable address format, the IPv6 source 290 addresses (which are the IPv4-translatable addresses) are 291 translated to the IPv4 addresses and the source port numbers are 292 unchanged before and after translation; the destination IPv6 293 addresses (which are the IPv4-converted addresses) are translated 294 to the IPv4 destination addresses and the destination port numbers 295 are unchanged before and after translation. However, if the 296 source port number does not match the port number range defined by 297 the extended IPv4-translatable address format, the packets will be 298 dropped. 300 4.4. Partial-state Translation Algorithm with Address Sharing 302 Stateless translation requires that IPv6 nodes generate source port 303 number in the range defined by the extended IPv4-translatable 304 address. If this condition does not hold, the partial-state 305 translation algorithm can be used, which can map the random source 306 port number to the extended IPv4-translatable address defined source 307 port number range. Due to the requirement of the states in the 308 translator for the port mapping (no states required for the address 309 mapping), it is named partial state. The technical details of the 310 port mapping state maintaining algorithm is an implementation issue 311 (see Section 6.2). 313 5. Dual Stateless Translation 315 In general dual stateful IPv4/IPv6 translations (IPv4-IPv6-IPv4) are 316 considered harmful, since the two translators cannot synchronize the 317 parameter to translate the IPv4 address to its original format. 318 However, the dual stateless IPv4/IPv6 translation (IPv4-IPv6-IPv4) 319 can translate the IPv4 address to its original format based on 320 algorithm. There are several reasons for using dual stateless IPv4/ 321 IPv6 translation. 323 o The second translator (CPE) performs the port-set mapping 324 algorithm discussed in Section 4.1, therefore, there is no need to 325 modify the host with IPv4 address sharing. 327 o ALG cannot be developed for some applications, or has not been 328 developed during the early transition stage. 330 o DNS64 is not allowed (due to DNSSec, etc.). 332 o All the IPv6 packet processing tools (routing, policy based 333 routing, packet filtering, traffic shaping based on layer 3 and 334 layer 4 can be used for dual stateless translation, while new 335 tools are required for encapsulation and tunneling. 337 5.1. Header Translation and MTU Handling 339 The general header and ICMP translation specifications are defined in 340 [RFC6145]. 342 Special MTU and fragmentation actions must be taken in the case of 343 dual translation. 345 5.2. Port Mapping Algorithm in CPE 347 The port mapping algorithm is straightforward. The port mapping 348 device maintains a database of allowed port numbers defined by the 349 extended IPv4-translatable address format. If the packets from the 350 host contains the source port number which do not match the port 351 number range defined by the extended IPv4-translatable address 352 format, the CPE will map the source port number to an allowed one and 353 keep the record in the database for mapping back the returning 354 packets and all the packets in the same session. 356 The port number database can be refreshed via the corresponding 357 transport layer flags for TCP or via timeout for UDP sessions. 359 6. Implementation Considerations 360 6.1. Host implementation 362 For the wireless mobile Internet environment, it is not difficult to 363 modify the operating system of the mobile device, therefore it 364 possible to integrate the port mapping algorithm and the second IPv4/ 365 IPv6 translation function in the mobile device, which is an IPv6-only 366 host to the network and has a dual-stack socket API for the 367 applications running on this host. 369 6.2. Port Mapping in the Core Translator 371 The port mapping can be performed in the core translator, in this 372 case, there is no need to have the second translator (CPE.x) and no 373 need to modify the IPv6 host for the port restriction requirements. 375 7. Security Considerations 377 There are no security considerations in this document. 379 8. IANA Considerations 381 This memo adds no new IANA considerations. 383 Note to RFC Editor: This section will have served its purpose if it 384 correctly tells IANA that no new assignments or registries are 385 required, or if those assignments or registries are created during 386 the RFC publication process. From the author's perspective, it may 387 therefore be removed upon publication as an RFC at the RFC Editor's 388 discretion. 390 9. Acknowledgments 392 The authors would like to acknowledge the following contributors in 393 the different phases of the address-sharing IVI and dIVI development: 394 Maoke Chen, Hong Zhang, Weifeng Jiang, Yuncehng Zhu and Guoliang Han. 396 The authors would like to acknowledge the following contributors who 397 provided helpful inputs: Dan Wing, Fred Baker, Dave Thaler, Randy 398 Bush, Kevin Yin, Wojciech Dec and Rajiv Asati. 400 10. References 401 10.1. Normative References 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 405 RFC2119, March 1997, 406 . 408 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 409 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 410 December 1998, . 412 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 413 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 414 DOI 10.17487/RFC6052, October 2010, 415 . 417 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 418 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 419 April 2011, . 421 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 422 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 423 . 425 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 426 NAT64: Network Address and Protocol Translation from IPv6 427 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 428 April 2011, . 430 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 431 Beijnum, "DNS64: DNS Extensions for Network Address 432 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 433 DOI 10.17487/RFC6147, April 2011, 434 . 436 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 437 China Education and Research Network (CERNET) IVI 438 Translation Design and Deployment for the IPv4/IPv6 439 Coexistence and Transition", RFC 6219, DOI 10.17487/ 440 RFC6219, May 2011, 441 . 443 10.2. Informative References 445 [I-D.bcx-behave-address-fmt-extension] 446 Bao, C. and X. Li, "Extended IPv6 Addressing for Encoding 447 Port Range", draft-bcx-behave-address-fmt-extension-10 448 (work in progress), January 2017. 450 [I-D.xli-behave-divi-pd] 451 Sun, Q., Asati, R., Xie, C., Li, X., Dec, W., and C. Bao, 452 "dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix 453 Delegation", draft-xli-behave-divi-pd-01 (work in 454 progress), September 2011. 456 Appendix A. Address Format and Workflow Examples 458 The prefix we selected is 2001:da8:a4a6::/48. The formats of the 459 IPv4-converted address and the IPv4-translatable address are: 461 IPv4-converted address 462 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 463 |PL| 0-------------32--40--48--56--64--72--80--88--92--104-112-120-| 464 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 465 |48| prefix |v4(16) | u | (16) | 0 | 466 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 468 IPv4-translatable address 469 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 470 |PL| 0-------------32--40--48--56--64--72--80--88--92--104-112-120-| 471 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 472 |48| prefix |v4(16) | u | (16) |PSID| 0 | Q | 473 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 475 Figure 5: Address format 477 The sharing ratio R=16, so the PSID has 4 bits (Q=4) and each PSID 478 can have (4096-1024/16)= 4032 concurrent port numbers to use. The 479 continue port range M=4, so each PSID will have 1008 available port 480 range. 482 The host in the IPv4 Internet is 202.112.35.254 and the corresponding 483 IPv4-converted address is 2001:da8:a4a6:ca70:23:fe00:: 485 The shared IPv4 address is 202.38.117.1 with sharing ratio 16, the 486 corresponding IPv4-translatable addresses are 488 PSID=0 2001:da8:a4a6:ca26:75:100::4 489 PSID=1 2001:da8:a4a6:ca26:75:110::4 490 PSID=2 2001:da8:a4a6:ca26:75:120::4 491 PSID=3 2001:da8:a4a6:ca26:75:130::4 492 PSID=4 2001:da8:a4a6:ca26:75:140::4 493 PSID=5 2001:da8:a4a6:ca26:75:150::4 494 PSID=6 2001:da8:a4a6:ca26:75:160::4 495 PSID=7 2001:da8:a4a6:ca26:75:170::4 496 PSID=8 2001:da8:a4a6:ca26:75:180::4 497 PSID=9 2001:da8:a4a6:ca26:75:190::4 498 PSID=10 2001:da8:a4a6:ca26:75:1a0::4 499 PSID=11 2001:da8:a4a6:ca26:75:1b0::4 500 PSID=12 2001:da8:a4a6:ca26:75:1c0::4 501 PSID=13 2001:da8:a4a6:ca26:75:1d0::4 502 PSID=14 2001:da8:a4a6:ca26:75:1e0::4 503 PSID=15 2001:da8:a4a6:ca26:75:1f0::4 505 A.1. The address-sharing host on an IPv6 network initiates 506 communication 508 An address-sharing Host.0 (202.38.117.1) in an IPv6 network behind 509 CPE initiates communication with Host 202.112.35.254:80 in the IPv4 510 Internet 512 On the Host.0 513 Src#p= 202.38.117.1#1881 (random port) 514 Dst#p= 202.112.35.254#80 (server port) 516 On an IPv6 network 517 Src#p= [2001:da8:a4a6:ca26:75:0100::4]#8192 (CPE mapped port) 518 Dst#p= [2001:da8:a4a6:ca70:23:fe00::]#80 (server port) 520 On the IPv4 Internet 521 Src#p= 202.38.117.1#8192 (CPE mapped port) 522 Dst#p= 202.112.35.254#80 (server port) 524 Figure 6: Workflow Example 1 526 The returning packets reverse the Src and Dst, the CPE maps the "CPE 527 mapped port (8192)" back to the original "random port (1881)". 529 A.2. A host in the IPv4 Internet initiates communication 531 A host 202.112.35.254 in the IPv4 Internet initiates communication to 532 the address-sharing Host.0 (202.38.117.1#4096) 533 On the IPv4 Internet 534 Src#p= 202.112.35.254#36567 (random port) 535 Dst#p= 202.38.117.1#4096 (server port) 537 On an IPv6 network 538 Src#p= [2001:da8:a4a6:ca70:23:fe00::]#36567 (random port) 539 Dst#p= [2001:da8:a4a6:ca26:75:0100::4]#4096 (server port) 541 On the Host.0 542 Src#p= 202.112.35.254#36567 (random port) 543 Dst#p= 202.38.117.1#4096 (server port) 545 Figure 7: Workflow Example 2 547 The returning packets reverse the Src and Dst. 549 Authors' Addresses 551 Congxiao Bao 552 CERNET Center/Tsinghua University 553 Room 225, Main Building, Tsinghua University 554 Beijing 100084 555 CN 557 Phone: +86 10-62785983 558 Email: congxiao@cernet.edu.cn 560 Xing Li 561 CERNET Center/Tsinghua University 562 Room 225, Main Building, Tsinghua University 563 Beijing 100084 564 CN 566 Phone: +86 10-62785983 567 Email: xing@cernet.edu.cn 569 Yu Zhai 570 CERNET Center/Tsinghua University 571 Room 225, Main Building, Tsinghua University 572 Beijing 100084 573 CN 575 Phone: +86 10-62785983 576 Email: jacky.zhai@gmail.com 577 Wentao Shang 578 CERNET Center/Tsinghua University 579 Room 225, Main Building, Tsinghua University 580 Beijing 100084 581 CN 583 Phone: +86 10-62785983 584 Email: wentaoshang@gmail.com