idnits 2.17.1 draft-xli-softwire-divi-pd-01.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 4 instances of too long lines in the document, the longest one being 47 characters 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 31, 2011) is 4560 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'XLAT1' is mentioned on line 144, but not defined == Unused Reference: 'RFC6296' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'I-D.bcx-behave-address-fmt-extension' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC6346' is defined on line 548, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 6144 ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) ** Downref: Normative reference to an Informational RFC: RFC 6219 ** Downref: Normative reference to an Experimental RFC: RFC 6296 == Outdated reference: A later version (-11) exists of draft-bcx-behave-address-fmt-extension-01 == Outdated reference: A later version (-03) exists of draft-mdt-softwire-map-dhcp-option-00 == Outdated reference: A later version (-03) exists of draft-mdt-softwire-mapping-address-and-port-00 == Outdated reference: A later version (-08) exists of draft-xli-behave-divi-04 Summary: 7 errors (**), 0 flaws (~~), 10 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: Standards Track CERNET Center/Tsinghua 5 Expires: May 3, 2012 University 6 W. Dec 7 R. Asati 8 Cisco Systems 9 C. Xie 10 Q. Sun 11 China Telecom 12 October 31, 2011 14 dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix Delegation 15 draft-xli-softwire-divi-pd-01 17 Abstract 19 This document presents the address specifications and deployment 20 considerations of address-sharing dual stateless IPv4/IPv6 21 translation with prefix delegation (dIVI-pd). The dIVI-pd keeps the 22 features of stateless, end-to-end address transparency and 23 bidirectional-initiated communications of the original stateless 24 IPv4/IPv6 translation, while it can utilize the IPv4 addresses more 25 effectively. In addition, it does not require the DNS64 and ALG, and 26 can be used with prefix delegation. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 3, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Port Mapping Algorithm and Address Format . . . . . . . . . . 5 66 4.1. Port Mapping Algorithm . . . . . . . . . . . . . . . . . . 5 67 4.2. Basic Mapping Rule (BMR) . . . . . . . . . . . . . . . . . 6 68 4.3. Default Mapping Rule (DMR) . . . . . . . . . . . . . . . . 7 69 4.4. Address Specifications . . . . . . . . . . . . . . . . . . 7 70 5. Header Translation and MTU Handling . . . . . . . . . . . . . 7 71 6. Dual Stateless Translation . . . . . . . . . . . . . . . . . . 8 72 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 73 8. CE Configuration via DHCP Option . . . . . . . . . . . . . . . 9 74 9. Experimental Evaluation . . . . . . . . . . . . . . . . . . . 10 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 78 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 80 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 The experiences for the IPv6 deployment in the past 10 years strongly 86 indicate that for a successful transition, the communication between 87 IPv4 and IPv6 address families should be supported. 89 Recently, the stateless and stateful IPv4/IPv6 translation methods 90 are developed and became the IETF standards. The original stateless 91 IPv4/IPv6 translation (stateless 1:1 IVI) is scalable, maintains the 92 end-to-end address transparency and support both IPv6 initiated and 93 IPv4 initiated communications [RFC6052], [RFC6144], [RFC6145], 94 [RFC6147], [RFC6219]. But it can not use the IPv4 addresses 95 effectively. The stateful IPv4/IPv6 translation can share the IPv4 96 addresses among IPv6 hosts, but it only supports IPv6 initiated 97 communication [RFC6052], [RFC6144], [RFC6145], [RFC6146], [RFC6147]. 98 In addition, both stateless and stateful IPv4/IPv6 translation 99 technologies require the application layer gateway (ALG) for the 100 applications which embed IP address literals. Furthermore, in ADSL 101 and 3G environment, it requires the prefix delegation (assigning an 102 IPv6 /64 or shorter) to the customer router/L3-device rather than 103 assigning a single IPv4-translatable address to the customer device 104 defined in [RFC6052]. 106 In this document, we present address specifications and deployment 107 considerations for address-sharing dual stateless IPv4/IPv6 108 translation with prefix delegation (dIVI-pd), which is based on basic 109 dIVI model [I-D.xli-behave-divi] with the support of prefix 110 delegation. The dIVI-pd can solve the IPv4 address sharing, the ALG 111 and prefix delegation problems mentioned above, though still keeps 112 the stateless, end-to-end address transparency and supporting of both 113 IPv6 initiated and IPv4 initiated communications. 115 Due to the introduction of the second translation and the prefix 116 delegation, the dIVI-PD is 4-6-4 model and there is a strong 117 correlation to the stateless encapsulation approach 118 [I-D.murakami-softwire-4rd]. This document uses the address format, 119 the port mapping algorithm and DHCP options defined in 120 [I-D.mdt-softwire-mapping-address-and-port]. 121 [I-D.mdt-softwire-map-dhcp-option], which are the joint design works 122 of stateless encapsulation and dual stateless translation. 124 2. Applicability 126 The address-sharing dual stateless IPv4/IPv6 translation with prefix 127 delegation (dIVI-pd) can be used in ADSL or 3G environment when 128 prefix delegation is required. An ADSL example is shown in the 129 following figure. 131 ---- ----- 132 // \\ // \\ ----- 133 / \ / \ // \|------[CPE.1]--{H.1} 134 | +-----+ +----+ | 135 | | | Metro |BRAS| |------[CPE.2]--{H.2} 136 | Backbone|Core | Area |/SR | Access | 137 | Network |Route| Network +----+ Network |------[CPE.k]--{H.k} 138 | | | |AAA | | 139 | +-----+ +----+ |------[CPE.n]--{H.n} 140 \ / \ / \\ /| 141 \\ // \\ // ---- 142 ---- ----|-- | 143 | | 144 IPv4/IPv6 [XLAT1] IPv6-only [XLAT2.x] IPv4/IPv6 145 Internet | Network | Hosts 146 | | 147 Data path: | | 148 IPv6 --------------------------------IPv6-----------|------IPv6---- 149 IPv4 -------------------|------------IPv6-----------|------IPv4---- 150 | | 151 Address assignment: | | 152 IPv6 | [BRAS]->(DHCPv6 PD)->[CPE]->SLAAC->[Host] 153 IPv4 | | \-DHCP-/ 155 Figure 1: BRAS 157 Where the ISP's backbone network is dual stack, as well as part of 158 the metro-area network. The core IPv4/IPv6 translator (XLAT1) is 159 performing the IPv4 address-sharing stateless IPv4/IPv6 translation 160 and connects the dual-stack part and the IPv6-only part of the metro- 161 area networks. The access network is IPv6-only and multiple IPv4/ 162 IPv6 translators (XLAT2.x) are connected to the access network and 163 provide dual-stack access to the customer devices. Each dual-stack 164 customer get a whole IPv6 /64 (or shorter) and a fractional public 165 IPv4 address. 167 The data path of this user case are: The IPv6 packets from customer 168 devices and the IPv6 Internet are not translated, while the IPv4 169 packets from customer devices and the IPv4 Internet are translated 170 twice via stateless IPv4/IPv6 translation technology. Due to the 171 stateless nature, the dual stateless IPv4/IPv6 translation is almost 172 equivalent to tunneling with header compression. 174 There are two address assignment processes: (1) From BRAS to CPE is 175 via IPv6CP and DHCPv6 prefix delegation; (2) From CPE to customer 176 device, the IPv6 is via SLAAC and the IPv4 is via DHCP. Note that if 177 more than one customer device requires IPv4 addresses, a built-in 178 NAT44 in each CPE can be used to translate a fractional IPv4 address 179 to several [RFC1918] defined IPv4 addresses. 181 3. Terminologies 183 This document uses the terminologies defined in 184 [I-D.mdt-softwire-mapping-address-and-port]. 186 This document uses the terminologies defined in [RFC6144]. 188 Since [I-D.mdt-softwire-mapping-address-and-port] is used for both 189 encapsulation and stateless translation, the equivallent 190 terminologies in [RFC6144] are: 192 MAP Border Relay (BR) Address: The MAP Border Relay (BR) Address is 193 the IPv4-converted address defined in [RFC6144] and in [RFC6052]. 195 MAP Customer Edge (CE) Address: The MAP Customer Edge (CE) Address 196 is the IPv4-translatable address defined in [RFC6144] and in 197 [RFC6052]. 199 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 200 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 201 document, are to be interpreted as described in [RFC2119]. 203 4. Port Mapping Algorithm and Address Format 205 The port mapping algorithm and address format are defined in 206 [I-D.mdt-softwire-mapping-address-and-port]. 208 4.1. Port Mapping Algorithm 210 Port mapping algorithm is defined in Section 4.1 of 211 [I-D.mdt-softwire-mapping-address-and-port]. 213 For given sharing ratio (R) and the maximum number of continue ports 214 (M), the generalized modulus algorithm is defined as 216 1. The port number (P) of a given PSID (K) is composed of 218 P = R*M*j + M*K + i 220 Where 221 o PSID: K=0 to R-1 222 o Port range index: j = (1024/M)/R to ((65536/M)/R)-1, if the 223 well-known port numbers (0-1023) are excluded. 224 o Port continue index: i=0 to M-1 226 2. The PSID (K) of a given port number (P) is determined by 228 K = (floor(P/M)) % R 230 Where 231 o % is modular operator 232 o floor(arg) is a function returns the largest integer not 233 greater than arg 235 4.2. Basic Mapping Rule (BMR) 237 Basic mapping rule is used for IPv4 prefix, address or port set 238 assignment. 240 | n bits | o bits | m bits | 128-n-o-m bits | 241 +--------------------+-----------+---------+------------+----------+ 242 | Domain IPv6 prefix | EA bits |subnet ID| interface ID | 243 +--------------------+-----------+---------+-----------------------+ 244 |<--- End-user IPv6 prefix --->| 246 Figure 2: IPv6 address format 248 The Embedded Address bits (EA bits) are unique per end user within a 249 Domain IPv6 prefix. The EA bits encode the CE specific IPv4 address 250 and port information. The EA bits can contain a full or part of an 251 IPv4 prefix or address, and in the shared IPv4 address case contains 252 a Port Set Identifier (PSID). 254 |<------------- EA bits----------->| 255 | r bits | p bits | q bits | 256 +-------------+---------------------+------------+ 257 | Domain IPv4 | IPv4 Address suffix |Port Set ID | 258 +-------------+---------------------+------------+ 259 | 32 bits | 261 Figure 3: Shared IPv4 address 263 The interface ID is defined as 265 <-8-><-------- L>=32 -------><48-L><8-> 266 +---+----------------+------+-----+---+ 267 | u | IPv4 address | PSID | 0 | L | 268 +---+----------------+------+-----+---+ 269 Figure 4: Interface ID 271 Forwarding Mapping Rule (FMR) is used for forwarding, whcih has 272 similar address format to BMR. Specifying forwarding mapping rule 273 determines the prefix of the IPv4-translatable addresses for other 274 CEs, which results in different routing behaviors (Hubs and Spokes or 275 Mesh). 277 4.3. Default Mapping Rule (DMR) 279 The Defualt mapping rule defines an IPv6 prefix (BR's IPv6 prefix). 280 The full destination IPv4 address must be encoded in the IPv6 281 address. 283 4.4. Address Specifications 285 Based on the above discussion, the addresses are defined in the 286 following figure. 288 Source address from a CE to any destination 289 (IPv4-translatable address) 291 <--------- 64 ------------><8 ><-------- L>=32 -----<>-44-L-<>8 < 292 +-------------+--------+---+---+----------------+----+-----+-+---+ 293 |Domain prefix|EA bits | 0 | u | IPv4 address |PSID| 0 | L | 294 +-------------+--------+---+---+----------------+----+-----+-+---+ 296 Destination address from a CE to the outside IPv4 Internet 297 (IPv4-converted address) 299 <--------- 64 ------------>< 8 ><---- 32 ----><----- 24 ----- > 300 +--------------------------+----+---------------+----------------+ 301 | BR prefix | u | IPv4 address | 0 | 302 +--------------------------+----+---------------+----------------+ 304 Figure 5: Extended IPv4-translatable address format 306 5. Header Translation and MTU Handling 308 The general header and ICMP translation specifications are defined in 309 [RFC6145]. 311 Special MTU and fragmentation actions must be taken in the case of 312 dual translation. 314 6. Dual Stateless Translation 316 When dual stateless IPv4/IPv6 translation is deployed, its behavior 317 is similar to tunneling. Tunneling do not require DNS64 and ALG., 318 because the communication occurs in same address family. Dual 319 translation don't need DNS64 and ALG as well, even in each translator 320 the communication occurs between different address families. 321 However, there are following differences: 323 o Scalability. Dual stateless translation is based on routing, 324 there is nothing needed to maintain in the translator, operator's 325 management loads are minimum compared with tunneling scheme, which 326 has to maintain tunnel states. 328 o Low OPEX. Dual stateless translation can do traffic engineering 329 and flow analysis without decapsulation which is a must in tunnel 330 case. 332 o Header Compression. The dual stateless IPv4/IPv6 translation does 333 not need to do encapsulation and 12 octets header overhead are 334 reduced. 336 o Transparent transition to IPv6. The dual stateless translation 337 can be treated as a special case of single stateless translation, 338 the first XLAT performances exactly the same function, no matter 339 there is a XLAT.x or not. Hence it is a unified approach, rather 340 than special setup for the coexistence and transition. This is to 341 say that the ISP can deploy IPv6-only network with XLAT, so the 342 IPv6-only hosts can communicate with both the IPv6 Internet and 343 the IPv4 Internet. However, if for some reason a specific ALG 344 cannot be supported, and for users, who need that specific 345 application, can deploy XLAT.x. When the application is updated, 346 the XLAT.x can be removed. There is nothing to change to XLAT. 347 with more and more contents and users move to IPv6, the working 348 load of XLAT will be less and less, and eventually can be removed. 349 The whole process is transparent, smooth and incremental. 351 Due to the differences between the IPv4 header and the IPv6 header, 352 the dual stateless IPv4/IPv6 translation cannot be entirely lossless 353 [RFC6145], for example the IPv4 options are lost. The experimental 354 data shows that the IPv4 packets which contain options are very few 355 (10e-6) and causes no harm. Another corner case is the fragmetation 356 handling. For IPv4 packets with DF=1 and MF=1, the dual stateless 357 translation will results in DF=0. The experimental data shows that 358 the IPv4 packets with DF=1 and MF=1 are very few (10e-5) and causes 359 no harm. 361 Note that for dual stateless translation, the encapsulation (from 362 IPv4 to IPv6) and decapsulation (from IPv6 to IPv4) defined by 363 [RFC2473] can be implemented in the translators. In this case, the 364 dual stateless translation processes are entirely lossless, it still 365 has the operation and management conveniences of the dual stateless 366 translation in layer 3, but the control in layer 4 is lost. 368 7. Deployment Considerations 370 Given: 372 1. The total number of CEs in this domain. 374 2. The sharing ratio R. 376 3. The port continue parameter M. 378 4. The customer prefix length. 380 5. The ISP's IPv6 prefix. 382 6. The ISP's IPv4 prefix. 384 7. The BR IPv6 prefix. 386 Other dIVI-PD configuration parameters can be derived using the port 387 mapping algorithm and address format defined in this document. 389 8. CE Configuration via DHCP Option 391 Based on the address format and the port mapping algorithm defined in 392 this document, the CE needs to get the corresponding parameters via 393 DHCPv6 [RFC3315][RFC3633] or others signaling scheme. These 394 parameters are: 396 1. The IPv6 prefix 398 2. The IPv6 prefix length 400 3. The IPv4 prefix 402 4. The IPv4 prefix length 404 5. The sharing ratio (R) 406 6. The maximum number of continue ports (M) 407 7. The PSID (K) 409 8. The PSID length (c) 411 9. Experimental Evaluation 413 The basic stateless IPv4/IPv6 translation (IVI) has been deployed 414 since 2007. It connects [CERNET] and [CNGI-CERNET2]. 416 The dual stateless translation with IPv4 address sharing (dIVI) has 417 been deployed in [CERNET] and [CNGI-CERNET2] since 2009. The design 418 and implementation results are presented in [I-D.xli-behave-divi]. 420 The dIVI has also been tested in China Telecom. The 421 [I-D.sunq-v6ops-ivi-sp] summarizes the testing results. 423 The dIVI-pd presented in this document has been running in [CERNET] 424 and [CNGI-CERNET2] since Jan. 2011. The experimental results 425 indicate that the CPE index coding, the suffix coding and port-set ID 426 mapping algorithm work for existing applications without any problem. 428 10. Security Considerations 430 See security considerations presented in [RFC6052] and [RFC6145]. 432 11. IANA Considerations 434 This memo adds no new IANA considerations. 436 Note to RFC Editor: This section will have served its purpose if it 437 correctly tells IANA that no new assignments or registries are 438 required, or if those assignments or registries are created during 439 the RFC publication process. From the author's perspective, it may 440 therefore be removed upon publication as an RFC at the RFC Editor's 441 discretion. 443 12. Acknowledgments 445 The authors would like to acknowledge the following contributors in 446 the different phases of the address-sharing IVI and dIVI development: 447 Hong Zhang, Yu Zhai, Wentao Shang, Weifeng Jiang, Bizhen Fu, Guoliang 448 Han and Weicai Wang. 450 The authors would like to acknowledge the following contributors who 451 provided helpful inputs: Heyu Wang, Lu Yan, Dan Wing, Fred Baker, 452 Dave Thaler, Randy Bush, Kevin Yin and Bobby Li. 454 The authors would like to thank the MAP team for the technical 455 discussions, which make the continue improvements of dIVI-PD. 457 13. References 459 13.1. Normative References 461 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 462 E. Lear, "Address Allocation for Private Internets", 463 BCP 5, RFC 1918, February 1996. 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, March 1997. 468 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 469 IPv6 Specification", RFC 2473, December 1998. 471 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 472 and M. Carney, "Dynamic Host Configuration Protocol for 473 IPv6 (DHCPv6)", RFC 3315, July 2003. 475 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 476 Host Configuration Protocol (DHCP) version 6", RFC 3633, 477 December 2003. 479 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 480 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 481 October 2010. 483 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 484 IPv4/IPv6 Translation", RFC 6144, April 2011. 486 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 487 Algorithm", RFC 6145, April 2011. 489 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 490 NAT64: Network Address and Protocol Translation from IPv6 491 Clients to IPv4 Servers", RFC 6146, April 2011. 493 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 494 Beijnum, "DNS64: DNS Extensions for Network Address 495 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 496 April 2011. 498 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 499 China Education and Research Network (CERNET) IVI 500 Translation Design and Deployment for the IPv4/IPv6 501 Coexistence and Transition", RFC 6219, May 2011. 503 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 504 Translation", RFC 6296, June 2011. 506 13.2. Informative References 508 [CERNET] "CERNET Homepage: 509 http://www.edu.cn/english_1369/index.shtml". 511 [CNGI-CERNET2] 512 "CNGI-CERNET2 Homepage: 513 http://www.cernet2.edu.cn/index_en.htm". 515 [I-D.bcx-behave-address-fmt-extension] 516 Bao, C. and X. Li, "Extended IPv6 Addressing for Encoding 517 Port Range", draft-bcx-behave-address-fmt-extension-01 518 (work in progress), October 2011. 520 [I-D.mdt-softwire-map-dhcp-option] 521 Mrugalski, T., Boucadair, M., and O. Troan, "DHCPv6 522 Options for Mapping of Address and Port", 523 draft-mdt-softwire-map-dhcp-option-00 (work in progress), 524 October 2011. 526 [I-D.mdt-softwire-mapping-address-and-port] 527 Troan, O., "Mapping of Address and Port (MAP)", 528 draft-mdt-softwire-mapping-address-and-port-00 (work in 529 progress), October 2011. 531 [I-D.murakami-softwire-4rd] 532 Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual 533 Deployment on IPv6 infrastructure - protocol 534 specification", draft-murakami-softwire-4rd-01 (work in 535 progress), September 2011. 537 [I-D.sunq-v6ops-ivi-sp] 538 Sun, Q., Xie, C., Li, X., Bao, C., and M. Feng, 539 "Considerations for Stateless Translation (IVI/dIVI) in 540 Large SP Network", draft-sunq-v6ops-ivi-sp-02 (work in 541 progress), March 2011. 543 [I-D.xli-behave-divi] 544 Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual- 545 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-04 546 (work in progress), October 2011. 548 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 549 IPv4 Address Shortage", RFC 6346, August 2011. 551 Authors' Addresses 553 Xing Li 554 CERNET Center/Tsinghua University 555 Room 225, Main Building, Tsinghua University 556 Beijing 100084 557 CN 559 Phone: +86 10-62785983 begin_of_the_skype_highlighting +86 10-62785983 end_of_the_skype_highlighting 560 Email: xing@cernet.edu.cn 562 Congxiao Bao 563 CERNET Center/Tsinghua University 564 Room 225, Main Building, Tsinghua University 565 Beijing 100084 566 CN 568 Phone: +86 10-62785983 begin_of_the_skype_highlighting +86 10-62785983 end_of_the_skype_highlighting 569 Email: congxiao@cernet.edu.cn 571 Wojciech Dec 572 Cisco Systems 573 Haarlerberdweg 13-19 574 Amsterdam 1101 CH 575 NL 577 Email: wdec@cisco.com 579 Rajiv Asati 580 Cisco Systems 581 7025-6 Kit Creek Road 582 Research Triangle Park NC 27709 583 USA 585 Email: rajiva@cisco.com 586 Chongfeng Xie 587 China Telecom 588 Room 708, No.118, Xizhimennei Street 589 Beijing 100035 590 CN 592 Phone: +86-10-58552116 begin_of_the_skype_highlighting +86-10-58552116 end_of_the_skype_highlighting 593 Email: xiechf@ctbri.com.cn 595 Qiong Sun 596 China Telecom 597 Room 708, No.118, Xizhimennei Street 598 Beijing 100035 599 CN 601 Phone: +86-10-58552936 begin_of_the_skype_highlighting +86-10-58552936 end_of_the_skype_highlighting 602 Email: sunqiong@ctbri.com.cn