idnits 2.17.1 draft-cui-softwire-b4-translated-ds-lite-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 2, 2012) is 4466 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) == Unused Reference: 'I-D.sun-v6ops-laft6' is defined on line 562, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3022 ** Downref: Normative reference to an Informational RFC: RFC 6269 ** Downref: Normative reference to an Experimental RFC: RFC 6346 ** Downref: Normative reference to an Informational RFC: RFC 6431 == Outdated reference: A later version (-04) exists of draft-bajko-pripaddrassign-03 == Outdated reference: A later version (-11) exists of draft-cui-softwire-b4-translated-ds-lite-04 == Outdated reference: A later version (-09) exists of draft-donley-behave-deterministic-cgn-01 == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-00 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-22 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-public-4over6-00 == Outdated reference: A later version (-10) exists of draft-tsou-pcp-natcoord-04 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire Working Group Y. Cui 3 Internet-Draft Tsinghua University 4 Intended status: Standards Track Q. Sun 5 Expires: August 5, 2012 China Telecom 6 M. Boucadair 7 France Telecom 8 T. Tsou 9 Huawei Technologies 10 Y. Lee 11 Comcast 12 February 2, 2012 14 Lightweight 4over6: An Extension to DS-Lite Architecture 15 draft-cui-softwire-b4-translated-ds-lite-05 17 Abstract 19 This document specifies an extension to DS-Lite called lightweight 20 4over6. This mechanism moves the translation function from the 21 tunnel concentrator (AFTR) to initiators (B4s), and hence reduces the 22 mapping scale on the concentrator to per-subscriber level. To 23 delegate the NAT function to the initiators, port-restricted IPv4 24 addresses are allocated to the initiators. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 5, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Lightweight 4over6 Overview . . . . . . . . . . . . . . . . . 7 64 5. Port-Restricted IPv4 Address Allocation . . . . . . . . . . . 8 65 6. Lightweight 4over6 Initiator Behavior . . . . . . . . . . . . 9 66 7. Lightweight 4over6 Concentrator Behavior . . . . . . . . . . . 10 67 8. Fragmentation and Reassembly . . . . . . . . . . . . . . . . . 11 68 9. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 10. ICMP processing . . . . . . . . . . . . . . . . . . . . . . . 13 70 11. Mechanism Analysis . . . . . . . . . . . . . . . . . . . . . . 14 71 12. Security Consideration . . . . . . . . . . . . . . . . . . . . 15 72 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 14. Author List . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 75 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 16.1. Normative References . . . . . . . . . . . . . . . . . . 20 77 16.2. Informative References . . . . . . . . . . . . . . . . . 20 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 80 1. Introduction 82 Dual-Stack Lite technique (DS-Lite, [RFC6333]) provides IPv4 access 83 over an IPv6 network relying on two functional elements: B4 and AFTR. 84 The B4 element establishes an IPv4-in-IPv6 softwire to an AFTR and 85 encapsulates IPv4 packets in IPv6 packets. When the AFTR receives 86 theses IPv6 packets, it decapsulates them and then performs NAT44 87 [RFC3022]. This procedure allows AFTR to dynamically assign port 88 numbers to requesting users; hence, increases port-sharing ratio and 89 utilization (see [RFC6269]). There is a trade-off, though: the AFTR 90 is required to maintain active NAT sessions. In the centralized 91 deployment model where one AFTR serves thousands of users, the large 92 numbers of NAT sessions may become a performance bottleneck. First, 93 maintaining active NAT sessions requires AFTR constantly creating and 94 purging NAT sessions. Second, a large NAT table demands more 95 processing power for searching and consumes more memory space. 97 To address these issues, this document proposes an extension to DS- 98 Lite technique. The extension is designed to simplify the AFTR 99 element by distributing NAT function among B4 elements. The B4 100 element is provisioned with an IPv6 address, an IPv4 address and a 101 port-set. The IPv6 address is used to create the Softwire, while the 102 IPv4 address and port-set is used for NAT44 in the home gateway 103 (CPE). The CPE performs NAPT on end user's packets with the IPv4 104 address and port-set. IPv4 packets are forwarded between the CPE and 105 the AFTR using IPv6 encapsulation. The AFTR maintains a mapping 106 entry with the CPE's IPv6 address, IPv4 address and port-set per 107 subscriber. For inbound IPv4 packets received on AFTR, it uses the 108 IPv4 destination address and port to match the IPv6 encapsulation 109 destination in the mapping table. The AFTR does not maintain any NAT 110 session entry. Therefore, this extension removes the NAT module from 111 the AFTR and significantly reduce the AFTR's mapping table size, and 112 it also relaxes the requirement to create a log entry per active NAT 113 session. In fact, the mechanism is an extended case which covers 114 addressing sharing for [I-D.ietf-softwire-public-4over6]. 116 Compared to stateless solutions with port-set allocation such as 117 MAP[I-D.mdt-softwire-mapping-address-and-port], this mechanism is 118 suitable for operators who prefer to keep IPv6 and IPv4 addressing 119 separated. For example, an operator may want to provide IPv4 with an 120 on-demand way in its IPv6 network when subscriber requested, the 121 dynamic allocation of IPv4 address and port-set makes more efficient 122 usage of IPv4 resource. Another example is an operator may only have 123 many small and discontinuous IPv4 blocks available to provide IPv4 124 over IPv6, rather than few large IPv4 blocks. This mechanism 125 preserves the dynamic feature of IPv4/IPv6 address binding as in DS- 126 Lite, so it won't require to administrate and manage many MAP domains 127 in the network and mapping rules in the CPEs. 129 This document is a variant of A+P called Binding Table Mode (see 130 Section 4.4 of [RFC6346]). 132 2. Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 3. Terminology 140 The document defines the following terms: 142 o Lightweight 4over6: lightweight 4over6 is an IPv4-over-IPv6 hub 143 and spoke mechanism, which supports address sharing [RFC6269] and 144 performs the IPv4 translation (NAT44) on the initiator (spoke) 145 side. 147 o Lightweight 4over6 initiator (or "initiator" for short): the 148 tunnel initiator in lightweight 4over6 mechanism. The lightweight 149 4over6 initiator may be a host directly connected to an IPv6 150 network, or a dual-stack CPE connecting an IPv4 local network to 151 an IPv6 network. It is collocated with a NAT44 function in 152 addition to IPv4-in-IPv6 encapsulation and de-capsulation 153 functions. 155 o Lightweight 4over6 concentrator (or "concentrator" for short): the 156 tunnel concentrator in lightweight 4over6 mechanism. The 157 lightweight 4over6 concentrator tunnels IPv4 packets to the IPv4 158 Internet over an IPv6 network. It provides IPv4-in-IPv6 159 encapsulation and decapsulation functions but not NAT function. 161 o Port-restricted IPv4 address: A public IPv4 address with 162 restricted port-set. In lightweight 4over6, multiple initiators 163 may share the same IPv4 address, while the port-sets must be non- 164 overlapping. Source ports of IPv4 packets sent by the initiator 165 must belong to the assigned port-set. 167 4. Lightweight 4over6 Overview 169 Lightweight 4over6 initiators and a lightweight 4over6 concentrator 170 are connected through an IPv6-enabled network. Both use IPv4-in-IPv6 171 encapsulation scheme to deliver IPv4 connectivity services. An 172 initiator uses port-restricted IPv4 address for IPv4 services 173 provisioned by the network. This address may be provisioned via PCP, 174 DHCPv4, DHCPv6, PPP IPCP, etc.(See Section 5 for further detail). 175 The concentrator keeps the mapping between the initiator's IPv6 176 address and the allocated IPv4 address + port-set. 178 +-------------------------+ 179 | IPv6 ISP Network | 180 | Host | 181 +---------+ | 182 |LW 4over6| | 183 |Initiator|===============+---------+ +-----------+ 184 +---------+ |LW 4over6| | IPv4 | 185 +--------+ | IPv4-in-IPv6 |Concen- |---| Internet | 186 | | +---------+ |trator | | | 187 |IPv4 LAN|--|LW 4over6|===============+---------+ +-----------+ 188 | | |Initiator| DHCPv4/PCP | 189 +--------+ +---------+ | 190 | CPE | 191 | | 192 +-------------------------+ 194 Figure 1 Lightweight 4over6 overview 196 5. Port-Restricted IPv4 Address Allocation 198 In lightweight 4over6, an initiator needs to be provisioned with the 199 public address and port-set. Different mechanisms can be used here 200 for port-restricted IPv4 address provisioning, e.g., DHCPv4, DHCPv6, 201 PCP, PPP IPCP, and even manual configuration. 203 Below are listed examples of implementing the provisioning through 204 the above mechanisms. They are not mandatory requirements, and the 205 specific protocol extensions is out of scope in this document. 207 o DHCPv4: the DHCPv4 protocol should be extended to support port-set 208 allocation [I-D.bajko-pripaddrassign]. Besides, the DHCP message 209 should send to the concentrator over IPv6. The concentrator can 210 be the DHCP server or DHCP relay 211 agent[I-D.ietf-dhc-dhcpv4-over-ipv6]. 213 o PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP 214 requests simultaneously to acquire a number ports within the same 215 IPv4 address, or use [I-D.tsou-pcp-natcoord] for one-time port-set 216 allocation. 218 o DHCPv6: the DHCPv6 protocol should be extended to support port-set 219 allocation [I-D.boucadair-dhcpv6-shared-address-option]. 221 o IPCP: IPCP should be extended to carry the port-set. [RFC6431] 222 gives an example. 224 When using dynamic provisioning mechanism such as DHCP or PCP, the 225 initiator gets the IPv4 address and port-set allocated dynamically 226 from the concentrator. While provisioning the initiator, the 227 concentrator records the dynamic mapping rule between the IPv4 228 address, port-set and the IPv6 address simultaneously. The port- 229 restricted address allocation in lightweight 4over6 does not couple 230 with IPv6 addressing. Hence, there is no requirement for IPv4-IPv6 231 mapping relationship such as IPv4 address encoding, IPv6 prefix 232 length, multiplexing ratio, etc. 234 6. Lightweight 4over6 Initiator Behavior 236 A lightweight 4over6 initiator must discover the concentrator's IPv6 237 address. This IPv6 address can be learned through a variety of 238 mechanisms, ranging from an out-of-band mechanism, manual 239 configuration, DHCPv6, etc. The mechanism is out of scope in this 240 document. 242 A lightweight 4over6 initiator should support dynamic port-restricted 243 IPv4 address provisioning, by means of implementing the appropriate 244 mechanism (e.g., DHCP, PCP, etc.). The mechanism must be align 245 between the initiator and the concentrator (i.e. the PCP Server, 246 DHCPv4 server, etc.), which may be co-located with the concentrator. 248 The data plane functions of the initiator include address translation 249 (NAT44) and encapsulation/de-capsulation. The initiator runs a 250 standard NAT44 [RFC3022] using the allocated port-restricted address 251 as external IP and port numbers. Internal connected hosts source 252 IPv4 packets with a [RFC1918] address. When the initiator receives 253 the IPv4 packet, it performs NAT44 function on the source address and 254 port by using the public IPv4 address and a port number from the 255 allocated port-set. Then, it encapsulates the packet. The 256 destination IPv6 address is the concentrator's IPv6 address and the 257 source IPv6 address is the initiator's IPv6 address. Finally, the 258 initiator forwards the encapsulated packet to the configured 259 concentrator. When the initiator receives an IPv4-in-IPv6 packet 260 from the concentrator, it de-capsulates the IPv6 packet to retrieve 261 the embedded IPv4 packet. Then it performs NAT44 function and 262 translates the destination address and port based on the available 263 information in its local NAPT44 table. 265 If the initiator is acting as a CPE, it is responsible for performing 266 ALG functions (e.g., SIP, FTP), and other NAT traversal mechanisms 267 (e.g., UPnP, NAT-PMP, manual mapping configuration, PCP) for the 268 connected hosts. This is the same requirement for typical NAT44 269 gateways available today. 271 If the initiator is collocated in the host, the host will be 272 provisioned with the public IPv4 address and port-set directly. Some 273 applications relies on the socket API to allocate IPv4 source port, 274 the API will randomly allocate an available port to the application. 275 To ensure the port is from the provisioned port-set, the host should 276 either implement a local NAT to map the randomly generated port by 277 the API to the restricted port-set or modify the API to return a port 278 from the restricted port-set. Both options enable the host to source 279 IPv4 packet using the restricted port-set without modifying the IPv4 280 applications. 282 7. Lightweight 4over6 Concentrator Behavior 284 The lightweight 4over6 concentrator must create a table in which each 285 entry contains a public IPv4 address, a port-set and an initiator's 286 IPv6 address. The concentrator MUST synchronize the port-restricted 287 address provisioning process such as DHCP and PCP used by the 288 Initiator. This synchronization is deployment-specific (e.g., embed 289 PCP Server, DHCP relay or Server, RADIUS, etc.) When the IPv4 290 address and port-set is successfully provisioned to the Initiator, 291 the concentrator simultaneously creates a map entry in its table. 292 This entry contains the public IPv4 address, the port-set and the 293 initiator's IPv6 address. The lifetime is determined by the 294 provisioning mechanism. The IPv6 address in the map entry is used as 295 the index for encapsulating inbound packets. This map entry will be 296 deleted when the lifetime expires. The lifetime of the map entry 297 should be refreshed when the initiator renews/extends the allocation. 299 The data plane functions of the concentrator are encapsulation and 300 de-capsulation. When the concentrator receives an IPv4-in-IPv6 301 packet from an initiator, it de-capsulates the IPv6 header and 302 verifies the source port and address in the table. If the source 303 port and address matches the Initiator's IPv6 address in the table, 304 the concentrator forwards the packet to the IPv4 destination. If 305 not, the concentrator must discard the packet. 307 When the concentrator receives an IPv4 packet from the Internet, it 308 uses the destination address and port to lookup the destination 309 initiator's IPv6 address in the table. If a match is found, the 310 concentrator encapsulates the IPv4 Packet. The source is the 311 concentrator's IPv6 address and the destination is the initiator's 312 IPv6 address. Then, the concentrator forwards the packet to the 313 initiator natively over the IPv6 network. When no match is found, 314 the concentrator must discard the packet. 316 8. Fragmentation and Reassembly 318 Same considerations as Section 5.3 and Section 6.3 of [RFC6333] are 319 to be taken into account. 321 9. DNS 323 Section 5.5 and Section 6.4 of [RFC6333] are to be followed. 325 10. ICMP processing 327 ICMP does not work through NAT44 [RFC6269]). When implementing 328 lightweight 4over6, ICMP Identifier MUST be treated as port number 329 for UDP/TCP. Therefore, when the initiator generates an ICMP packet, 330 it MUST use an available port from its port-set as the ICMP 331 identifier. When the concentrator receives an ICMP reply packet from 332 the IPv4 network, it must use the identifier as the port number and 333 search its table. If a match is found, it must forward the ICMP 334 reply packet to the initiator stored in the entry. The lookup 335 process is identical to normal TCP/UDP lookup. For inbound ICMP 336 request packet, the concentrator may be configured in two modes: 338 o Forward the request to the appropriate initiator using the 339 Identifier field when a mapping entry is found; if not the ICMP 340 request is silently dropped. 342 o Discard all inbound ICMP requests. 344 The ICMP policy is determined by service providers. 346 11. Mechanism Analysis 348 Compared with original DS-Lite, lightweight 4over6 move the 349 translation function from the concentrator and distribute it to 350 initiators. This reduces states on the concentrator from per-session 351 level down to per-subscriber level. This potentially reduces the 352 concentrator complexity to manage a relatively large NAT table. In 353 theory, the concentrator should scale better and serve more 354 subscribers on the same hardware platform. 356 The initiator is provisioned with a public IPv4 address and port-set, 357 and translation is performed only once, so it is a single NAT 358 architecture. 360 When the initiator acts as a CPE, it is required to implement ALG and 361 NAT referral problem. These problems are solved today by combination 362 of UPnP, NAT-PmP, etc. Many existing CPEs have already implemented 363 these functionalities. So lightweight 4over6 initiator can leverage 364 these existing mechanisms to address the same problems. 366 When the AFTR performs per-session log, the volume could increase 367 rapidly because each new session may create a new log entry. Some 368 optimization has been discussed to reduce log volume 369 [I-D.donley-behave-deterministic-cgn]. When the concentrator 370 performs per-subscriber tunnel log, each subscriber creates only one 371 log. This is identical to logging subscriber by IPv4 address. This 372 mechanism is widely used today. Service providers can re-use the 373 same mechanism with minor modification. 375 Lightweight 4over6 does not couple port-restricted address and the 376 IPv6 addressing. No specific IPv6 address format is required. IPv4 377 and IPv6 addressing and routing remain separated. The service 378 provider can provide IPv4 in a flexible, on-demand way, as well as 379 manage the native IPv6 network without the influence of IPv4-over- 380 IPv6 requirements. This would ease to achieve future adjustment of 381 IPv4 address pool. 383 The trade-offs of lightweight 4over6 are possibility of lower IPv4 384 address utilization ratio and extra signaling behavior for 385 provisioning. When compared to stateless solutions, lightweight 386 4over6 still keeps subscriber-level states rather than becoming 387 purely stateless. 389 12. Security Consideration 391 As the port space for a subscriber shrinks significantly due to the 392 address sharing, the randomness for the port numbers of the 393 subscriber is decreased significantly. In other words, it is more 394 easier for an attacker to guess the port number used, which results 395 in attacks ranging from throughput reduction to broken connections or 396 data corruption. Here the port-set for a subscriber can be a bulk of 397 contiguous ports or non-contiguous ports. Contiguous port-set can't 398 help the situation, while with non-contiguous port-set (which may be 399 generated in a pseudo-random way [RFC6431]), the randomness of the 400 port number is improved, provided that the attacker is outside the 401 lightweight 4over6 domain and hence doesn't know the port-set 402 generation algorithm. 404 More considerations of IP address sharing discussed in Section 13 of 405 [RFC6269] are applicable to this solution. 407 13. IANA Considerations 409 This document does not include any IANA request. 411 14. Author List 413 The following are extended authors who contributed to the effort: 415 Jianping Wu 417 Tsinghua University 419 Department of Computer Science, Tsinghua University 421 Beijing 100084 423 P.R.China 425 Phone: +86-10-62785983 427 Email: jianping@cernet.edu.cn 429 Peng Wu 431 Tsinghua University 433 Department of Computer Science, Tsinghua University 435 Beijing 100084 437 P.R.China 439 Phone: +86-10-62785822 441 Email: weapon@csnet1.cs.tsinghua.edu.cn 443 Chongfeng Xie 445 China Telecom 447 Room 708, No.118, Xizhimennei Street 449 Beijing 100035 451 P.R.China 453 Phone: +86-10-58552116 454 Email: xiechf@ctbri.com.cn 456 Xiaohong Deng 458 France Telecom 460 Email: xiaohong.deng@orange.com 462 Cathy Zhou 464 Huawei Technologies 466 Section B, Huawei Industrial Base, Bantian Longgang Shenzhen 467 518129 469 P.R.China 471 Email: cathyzhou@huawei.com 473 15. Acknowledgement 475 The authors would like to thank Alain Durand, Ole Troan, Ralph Droms 476 for their comments and feedback. 478 This document is a merge of two documents: 479 [I-D.cui-softwire-b4-translated-ds-lite] and 480 [I-D.zhou-softwire-b4-nat]. 482 16. References 484 16.1. Normative References 486 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 487 E. Lear, "Address Allocation for Private Internets", 488 BCP 5, RFC 1918, February 1996. 490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, March 1997. 493 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 494 Address Translator (Traditional NAT)", RFC 3022, 495 January 2001. 497 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 498 Roberts, "Issues with IP Address Sharing", RFC 6269, 499 June 2011. 501 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 502 Stack Lite Broadband Deployments Following IPv4 503 Exhaustion", RFC 6333, August 2011. 505 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 506 IPv4 Address Shortage", RFC 6346, August 2011. 508 [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and 509 T. Tsou, "Huawei Port Range Configuration Options for PPP 510 IP Control Protocol (IPCP)", RFC 6431, November 2011. 512 16.2. Informative References 514 [I-D.bajko-pripaddrassign] 515 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 516 "Port Restricted IP Address Assignment", 517 draft-bajko-pripaddrassign-03 (work in progress), 518 September 2010. 520 [I-D.boucadair-dhcpv6-shared-address-option] 521 Boucadair, M., Levis, P., Grimault, J., Savolainen, T., 522 and G. Bajko, "Dynamic Host Configuration Protocol 523 (DHCPv6) Options for Shared IP Addresses Solutions", 524 draft-boucadair-dhcpv6-shared-address-option-01 (work in 525 progress), December 2009. 527 [I-D.cui-softwire-b4-translated-ds-lite] 528 Cui, Y., Wu, J., Wu, P., Sun, Q., Xie, C., Zhou, C., Lee, 529 Y., and T. ZOU), "Lightweight 4over6 in access network", 530 draft-cui-softwire-b4-translated-ds-lite-04 (work in 531 progress), October 2011. 533 [I-D.donley-behave-deterministic-cgn] 534 Donley, C., Grundemann, C., Sarawat, V., and K. 535 Sundaresan, "Deterministic Address Mapping to Reduce 536 Logging in Carrier Grade NAT Deployments", 537 draft-donley-behave-deterministic-cgn-01 (work in 538 progress), January 2012. 540 [I-D.ietf-dhc-dhcpv4-over-ipv6] 541 Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6 542 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-00 (work in 543 progress), November 2011. 545 [I-D.ietf-pcp-base] 546 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 547 Selkirk, "Port Control Protocol (PCP)", 548 draft-ietf-pcp-base-22 (work in progress), January 2012. 550 [I-D.ietf-softwire-public-4over6] 551 Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y. 552 Lee, "Public IPv4 over Access IPv6 Network", 553 draft-ietf-softwire-public-4over6-00 (work in progress), 554 September 2011. 556 [I-D.mdt-softwire-mapping-address-and-port] 557 Troan, O., Matsushima, S., Murakami, T., Li, X., and C. 558 Bao, "Mapping of Address and Port (MAP)", 559 draft-mdt-softwire-mapping-address-and-port-03 (work in 560 progress), January 2012. 562 [I-D.sun-v6ops-laft6] 563 Sun, Q. and C. Xie, "LAFT6: Lightweight address family 564 transition for IPv6", draft-sun-v6ops-laft6-01 (work in 565 progress), March 2011. 567 [I-D.tsou-pcp-natcoord] 568 Zhou, C., Tsou, T., Deng, X., Boucadair, M., and Q. Sun, 569 "Using PCP To Coordinate Between the CGN and Home Gateway 570 Via Port Allocation", draft-tsou-pcp-natcoord-04 (work in 571 progress), January 2012. 573 [I-D.zhou-softwire-b4-nat] 574 Deng, X., Boucadair, M., and C. Zhou, "NAT offload 575 extension to Dual-Stack lite", 576 draft-zhou-softwire-b4-nat-04 (work in progress), 577 October 2011. 579 Authors' Addresses 581 Yong Cui 582 Tsinghua University 583 Department of Computer Science, Tsinghua University 584 Beijing 100084 585 P.R.China 587 Phone: +86-10-62603059 588 Email: yong@csnet1.cs.tsinghua.edu.cn 590 Qiong Sun 591 China Telecom 592 Room 708, No.118, Xizhimennei Street 593 Beijing 100035 594 P.R.China 596 Phone: +86-10-58552936> 597 Email: sunqiong@ctbri.com.cn 599 Mohamed Boucadair 600 France Telecom 601 Rennes 35000 602 France 604 Email: mohamed.boucadair@orange.com 606 Tina Tsou 607 Huawei Technologies 608 2330 Central Expressway 609 Santa Clara, CA 95050 610 USA 612 Phone: +1-408-330-4424 613 Email: tena@huawei.com 615 Yiu L. Lee 616 Comcast 617 One Comcast Center 618 Philadelphia, PA 19103 619 USA 621 Email: yiu_lee@cable.comcast.com