idnits 2.17.1 draft-cui-softwire-host-4over6-06.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2011) is 4676 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: 'RFC4925' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'RFC5549' is defined on line 460, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4925 ** Downref: Normative reference to an Informational RFC: RFC 4966 ** Obsolete normative reference: RFC 5549 (Obsoleted by RFC 8950) == Outdated reference: A later version (-11) exists of draft-cui-softwire-b4-translated-ds-lite-00 == Outdated reference: A later version (-01) exists of draft-cui-softwire-dhcp-over-tunnel-00 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-13 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Cui 3 Internet-Draft J. Wu 4 Intended status: Standards Track P. Wu 5 Expires: January 9, 2012 Tsinghua University 6 C. Metz 7 Cisco Systems, Inc. 8 O. Vautrin 9 Juniper Networks 10 Y. Lee 11 Comcast 12 July 8, 2011 14 Public IPv4 over Access IPv6 Network 15 draft-cui-softwire-host-4over6-06 17 Abstract 19 This draft proposes a mechanism for bidirectional IPv4 communication 20 between IPv4 Internet and end hosts or IPv4 networks sited in IPv6 21 access network. This mechanism follows the softwire hub and spoke 22 model and uses IPv4-over-IPv6 tunnel as basic method to traverse IPv6 23 network. By allocating public IPv4 addresses to end hosts/networks 24 in IPv6, it can achieve IPv4 end-to-end bidirectional communication 25 between these hosts/networks and IPv4 Internet. This mechanism is an 26 IPv4 access method for hosts and IPv4 networks sited in IPv6. 28 Status of this Memo 30 This Internet-Draft is submitted 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 January 9, 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. Requirements language . . . . . . . . . . . . . . . . . . . . 4 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Deployment scenario . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Scenario and requirements . . . . . . . . . . . . . . . . 6 67 4.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5. Public 4over6 Mechanism . . . . . . . . . . . . . . . . . . . 9 69 5.1. Address allocation and mapping maintenance . . . . . . . . 9 70 5.2. 4over6 initiator behavior . . . . . . . . . . . . . . . . 9 71 5.2.1. Host initiator . . . . . . . . . . . . . . . . . . . . 10 72 5.2.2. CPE initiator . . . . . . . . . . . . . . . . . . . . 10 73 5.3. 4over6 concentrator behavior . . . . . . . . . . . . . . . 11 74 6. Technical advantages . . . . . . . . . . . . . . . . . . . . . 12 75 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 Global IPv4 addresses are running out fast. Meanwhile, the demand 84 for IP address is still growing and may even burst in potential 85 circumstances like "Internet of Things". To satisfy the end users, 86 operators have to push IPv6 to the front, by building IPv6 networks 87 and providing IPv6 services. 89 When IPv6-only networks are widely deployed, users of those networks 90 will probably still need IPv4 connectivity. This is because part of 91 Internet will stay IPv4-only for a long time, and network users in 92 IPv6-only networks will communicate with network users sited in the 93 IPv4-only part of Internet. This demand could eventually decrease 94 with the general IPv6 adoption. 96 Network operators should provide IPv4 services to IPv6 users to 97 satisfy their demand, usually through tunnels. This type of IPv4 98 services differ in provisioned IPv4 addresses. If the users can't 99 get public IPv4 addresses (e.g., new network users join an ISP which 100 don't have enough unused IPv4 addresses), they have to use private 101 IPv4 addresses on the client side, and IPv4-private-to-public 102 translation is required on the carrier side, as is described in Dual- 103 stack Lite[I-D.ietf-softwire-dual-stack-lite]. Otherwise the users 104 can get public IPv4 addresses, and use them for IPv4 communication. 105 In this case, translation on the carrier side won't be necessary. 106 The network users and operators can avoid all the issues raised by 107 translation, such as ALG, NAT traversal, state maintenance, etc. 108 Note that this "public IPv4" situation is actually quite common. 109 There're approximatively 2^32 network users who are using or can 110 potentially get public IPv4 addresses. Most of them will switch to 111 IPv6 sooner or later, and will require IPv4 services for a 112 significant period after the switching. This draft focuses on this 113 situation, i.e., to provide IPv4 access for users in IPv6 networks, 114 where public IPv4 addresses are still available for allocation. 116 2. Requirements language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 3. Terminology 124 Public 4over6: Public 4over6 is the mechanism proposed by this draft. 125 Generally, Public 4over6 supports bidirectional communication between 126 IPv4 Internet and IPv4 hosts or local networks in IPv6 access 127 network, by leveraging IPv4-in-IPv6 tunnel and public IPv4 address 128 allocation. 130 4over6 initiator: in Public 4over6 mechanism, 4over6 initiator is the 131 IPv4-in-IPv6 tunnel initiator located on the user side of IPv6 132 network. The 4over6 initiator can be either a dual-stack capable 133 host or a dual-stack CPE device. In the former case, the host has 134 both IPv4 and IPv6 stack but is provisioned with IPv6 access only. 135 In the latter case, the CPE has both IPv6 interface for access to ISP 136 network and IPv4 interface for local network connection; hosts in the 137 local network can be IPv4-only. 139 4over6 concentrator: in Public 4over6 mechanism, 4over6 concentrator 140 is the IPv4-in-IPv6 tunnel concentrator located in IPv6 ISP network. 141 It's a dual-stack router which connects to both the IPv6 network and 142 IPv4 Internet. 144 4. Deployment scenario 146 4.1. Scenario and requirements 148 The general scenario of Public 4over6 is shown in Figure 1. Users in 149 an IPv6 network take IPv6 as their native service. Some users are 150 end hosts which face the ISP network directly, while others are local 151 networks behind CPEs, such as a home LAN, an enterprise network, etc. 152 The ISP network is IPv6-only rather than dual-stack, which means that 153 ISP can't provide native IPv4 access to its users; however, it's 154 acceptable that one or more routers on the carrier side become dual- 155 stack and get connected to IPv4 Internet. So if network users want 156 to connect to IPv4, these dual-stack routers will be their 157 "entrances". 159 +-------------------------+ 160 | IPv6 ISP Network | 161 +------+ | 162 |host: | | 163 |initi-| | 164 |ator |=================+-------+ +-----------+ 165 +------+ |4over6 | | IPv4 | 166 | IPv4-in-IPv6 |Concen-|---| Internet | 167 +----------+ +------+ |trator | | | 168 |local IPv4|--|CPE: |=================+-------+ +-----------+ 169 | network | |initi-| | 170 +----------+ |ator | | 171 +------+ | 172 | | 173 +-------------------------+ 175 Figure 1 Public 4over6 scenario 177 Before getting into any technical details, the communication 178 requirements should be stated. The first one is that, 4over6 users 179 require IPv4-to-IPv4 communication with the IPv4 Internet. An IPv4 180 access service is needed rather than an IPv6-to-IPv4 translation 181 service. (IPv6-to-IPv4 communication is out of the scope of this 182 draft.) 184 Second, 4over6 users require public IPv4 addresses rather than 185 private addresses. Public IPv4 address means there's no IPv4 CGN 186 along the path, so the acquired IPv4 service is better. In 187 particular, some hosts may be application servers, public address 188 works better for reasons like straightforward access, direct DNS 189 registration, no stateful mapping maintenance on CGN, etc. For the 190 direct-connected host case, each host should get one public IPv4 191 address. For the local IPv4 network case, the CPE can get a public 192 IPv4 address and runs an IPv4 NAT for the local network. Here a 193 local NAT is still much better than the situation that involves a 194 CGN, since this NAT is in local network and can be configured and 195 managed by the users. 197 Third, translation is not preferred in this scenario. If this IPv4- 198 to-IPv4 communication is achieved by IPv4-IPv6 translation, it'll 199 need double translation along the path, one from IPv4 to IPv6 and the 200 other from IPv6 back to IPv4. This would be quite complicated, 201 especially in addressing. Contrarily a tunnel can achieve the IPv4- 202 over-IPv6 traversing easily. That's the reason this draft follows 203 the hub and spoke softwire model. 205 Moreover, the ISP probably would like to keep their IPv4 and IPv6 206 addressing and routing separated when provisioning IPv4 over IPv6. 207 Then the ISP can manage the native IPv6 network more easily and 208 independently, and also provision IPv4 in a flexible, on-demand way. 209 The cost is that the concentrator needs to maintain per-user address 210 mapping state, which would be described in detail. 212 4.2. Use cases 214 Public 4over6 can be applicable in several practical cases. The 215 first one is that ISPs which still own enough IPv4 addresses switch 216 to IPv6. The ISPs can deploy public 4over6 to preserve IPv4 service 217 for the customers. This case is actually quite common. The majority 218 of the wired end users today get Internet access with public IPv4 219 address. When their ISPs switch to IPv6, these users can still use 220 the same amount of IPv4 addresses for IPv4 access. Public 4over6 can 221 leveraging these addresses and offer tunneled IPv4 access. 223 The second case is ISPs which don't have enough IPv4 addresses any 224 more switch to IPv6. For these ISPs, dual-stack lite is so far the 225 most mature solution to provision IPv4 over IPv6. In dual-stack 226 lite, end users use private IPv4 addresses, experience a 44CGN and 227 hence some service degradation. As long as the end users use public 228 IPv4 addresses, all CGN issues can be avoided and the IPv4 service 229 can be full bi-directional. In other words, Public 4over6 can be 230 deployed along with DS-lite, to provide a value-added service. 231 Common users adopt DS-lite to communicate with IPv4 while high-end 232 users adopt Public 4over6. The two mechanisms can actually be 233 coupled easily. 235 There is also a special situation in the second case that the end 236 users are IPv4 application servers. In this situation, public 237 address brings significant convenience. The DNS registration can be 238 direct using dedicated address; the access of application clients can 239 be straightforward with no translation; there's no need to reserve 240 and maintain address mapping on the CGN, and no well-known port 241 collision will come up. So it's better to have servers adopt Public 242 4over6 for IPv4 access when they're located in IPv6 network. 244 Following the principle of Public 4over6, it's also possible to 245 achieve address multiplexing and save IPv4 addresses. There're 246 already efforts on this subject, see 247 [I-D.cui-softwire-b4-translated-ds-lite] and [I-D.sun-v6ops-laft6]. 248 The basic idea is that instead of allocating a full IPv4 address to 249 every end user, the ISP can allocate an IPv4 address with restricted 250 port range to every end user. 252 Besides, the draft would like to be explicit about the scope of 253 direct-connected host case and CPE case. The host case is clear: the 254 host is directly connected to IPv6 network, but the protocol stack on 255 the host support IPv4 too. As to the CPE case, this draft would like 256 to only focus on the case that the local network behind the CPE is 257 private IPv4. If the users want to run public IPv4 into the local 258 network, then they can either run dual-stack in the local network and 259 turn into host case(likely home LAN situation), or they can acquire 260 address blocks from the ISP and build configured tunnel or softwire 261 mesh[RFC5565] with the ISP network(likely enterprise network 262 situation). TC can be implemented to be compatible with the latter 263 case too, though. 265 5. Public 4over6 Mechanism 267 5.1. Address allocation and mapping maintenance 269 Public 4over6 can be generally considered as IPv4-over-IPv6 hub and 270 spoke tunnel using public IPv4 address. Each 4over6 initiator will 271 use public IPv4 address for IPv4-over-IPv6 communication. As is 272 described above, in the host initiator case, every host will get one 273 IPv4 address; in the CPE case, every CPE will get one IPv4 address, 274 which will be shared by hosts behind the CPE. The key problem here 275 is IPv4 address allocation over IPv6 network, from ISP device(s) to 276 separated 4over6 initiators. 278 There're two possibilities here. One is DHCPv4 over IPv6, and the 279 other is static configuration. DHCPv4 over IPv6 is achieved by 280 performing DHCPv4 on IPv4-in-IPv6 tunnel between ISP device and 281 4over6 initiators. There do exist the DHCP encapsulation issue on 282 server side, see details and solutions in 283 [I-D.cui-softwire-dhcp-over-tunnel]. As to static configuration, 284 4over6 users and the ISP operators should negotiate beforehand to 285 authorize the IPv4 address. Application servers usually falls into 286 this case. Public 4over6 supports both address allocation manners. 287 Actually, it is transparent to address allocation methods. 289 Along with IPv4 address allocation, Public 4over6 should maintain the 290 IPv4-IPv6 address mappings on the concentrator. In this type of 291 address mapping, the IPv4 address is the public IPv4 address 292 allocated to a 4over6 initiator, and the IPv6 addresses is the 293 initiator's IPv6 address. This mapping is used to provide correct 294 encapsulation destination address for the concentrator. 296 The initiator sends "pinhole" packets to the concentrator 297 periodically, to install and renew the address mapping. A pinhole 298 packet is an IPv4-in-IPv6 packet, which uses the concentrator's IPv6 299 address as destination IPv6 address, the initiator's IPv6 address as 300 source IPv6 address, and the initiator's IPv4 address as source IPv4 301 address. When the concentrator receives such a packet, it'll resolve 302 the IPv4 and IPv6 address information from the packet and trigger the 303 mapping. Since any IPv4-in-IPv6 data packet from the initiator 304 contains these exact informations, it can also serve as pinhole 305 packet. Then dedicated pinhole packets are sent out when there's no 306 data packets. Another possible way to maintain the address mapping 307 is to run PCP[I-D.ietf-pcp-base] while extending the protocol to 308 support applying for a full address. The following sections describe 309 the mechanism with the pinhole method. 311 5.2. 4over6 initiator behavior 312 4over6 initiator has an IPv6 interface connected to the IPv6 ISP 313 network, and a tunnel interface to support IPv4-in-IPv6 314 encapsulation. In CPE case, it has at least one IPv4 interface 315 connected to IPv4 local network. 317 4over6 initiator should learn the 4over6 concentrator's IPv6 address 318 beforehand. For example, if the initiator gets its IPv6 address by 319 DHCPv6, it can get the 4over6 concentrator's IPv6 address through a 320 DHCPv6 option[I-D.ietf-softwire-ds-lite-tunnel-option]. 322 5.2.1. Host initiator 324 When the initiator is a direct-connected host, it assigns the 325 allocated public IPv4 address to its tunnel interface. The host uses 326 this address for IPv4 communication. If this address is allocated 327 through DHCP, the host should support DHCPv4 over tunnel. After the 328 allocation, the host periodically sends pinhole packet to the 329 concentrator to install the address mapping and keep it alive. 331 For IPv4 data traffic, the host performs the IPv4-in-IPv6 332 encapsulation and decapsulation on the tunnel interface. When 333 sending out an IPv4 packet, it performs the encapsulation, using the 334 IPv6 address of the 4over6 concentrator as the IPv6 destination 335 address, and its own IPv6 address as the IPv6 source address. The 336 encapsulated packet will be forwarded to the IPv6 network. The 337 decapsulation on 4over6 initiator is simple. When receiving an IPv4- 338 in-IPv6 packet, the initiator just drops the IPv6 header, and hands 339 it to upper layer. 341 5.2.2. CPE initiator 343 The CPE case is quite similar to the host initiator case. The CPE 344 assign the allocated IPv4 address to its tunnel interface. The local 345 IPv4 network won't take part in the public IPv4 allocation; instead, 346 end hosts will use private IPv4 addresses, possibly allocated by the 347 CPE. After the allocation, the CPE periodically sends pinhole packet 348 to the concentrator to install the address mapping and keep it alive. 350 On data plan, the CPE can be viewed as a regular IPv4 NAT(using 351 tunnel interface as the NAT outside interface) cascaded with a tunnel 352 initiator. For IPv4 data packets received from the local network, 353 the CPE translates these packets, using the tunnel interface address 354 as the source address, and then encapsulates the translated packet 355 into IPv6, using the concentrator's IPv6 address as the destination 356 address, the CPE's IPv6 address as source address. For IPv6 data 357 packet received from the IPv6 network, the CPE performs decapsulation 358 and IPv4 public-to-private translation. As to the CPE itself, it 359 uses the public, tunnel interface address to communicate with the 360 IPv4 Internet, and the private, IPv4 interface address to communicate 361 with the local network. 363 5.3. 4over6 concentrator behavior 365 4over6 concentrator represents the IPv4-IPv6 border router working as 366 the remote tunnel endpoint for 4over6 initiators, with its IPv6 367 interface connected to the IPv6 network, IPv4 interface connected to 368 the IPv4 Internet, and a tunnel interface supporting IPv4-in-IPv6 369 encapsulation and decapsulation. There's no CGN on the 4over6 370 concentrator, it won't perform any translation function; instead, 371 4over6 concentrator maintains an IPv4-IPv6 address mapping table for 372 IPv4 data encapsulation. 374 4over6 concentrator maintains the address mapping according to the 375 initiators' demand. When receiving a pinhole packet from an 376 initiator, the concentrator reads the IPv4 and IPv6 source addresses 377 from the packet, install the mapping entry into the mapping table or 378 renew it if it already exists. When the lifetime of a mapping entry 379 expires, the concentrator deletes it from the table. So the 380 initiator should send pinhole packet with an interval shorter than 381 the lifetime of the mapping entry. The mapping entry is used to 382 provide correct encapsulation destination address for concentrator 383 encapsulation. As long as the entry exists in the table, the 384 concentrator can encapsulate inbound IPv4 packets destined to the 385 initiator, with the initiator's IPv6 address as IPv6 destination. 387 On the IPv6 side, 4over6 concentrator decapsulates IPv4-in-IPv6 388 packets coming from 4over6 initiators. It removes the IPv6 header of 389 every IPv4-in-IPv6 packet and forwards it to the IPv4 Internet. On 390 the IPv4 side, the concentrator encapsulates the IPv4 packets 391 destined to 4over6 initiators. When performing the IPv4-in-IPv6 392 encapsulation, the concentrator uses its own IPv6 address as the IPv6 393 source address, uses the IPv4 destination address in the packet to 394 look up IPv6 destination address in the address mapping table. After 395 the encapsulation, the concentrator sends the IPv6 packet on its IPv6 396 interface to reach an initiator. 398 The 4over6 concentrator, or its upstream router should advertise the 399 IPv4 prefix which contains the IPv4 addresses of 4over6 users to the 400 IPv4 side, in order to make these initiators reachable on IPv4 401 Internet. 403 Since the concentrator has to maintain the IPv4-IPv6 address mapping 404 table, the concentrator is stateful in IP level. Note that this 405 table will be much smaller than a CGN table, as there is no port 406 information involved. 408 6. Technical advantages 410 Public 4over6 provides a method for users in IPv6 network to 411 communicate with IPv4. In many scenarios, this can be viewed as an 412 alternative to IPv6-IPv4 translation mechanisms which have well-known 413 limitations described in [RFC4966] . 415 Since a 4over6 initiator uses a public IPv4 address, Public 4over6 416 supports full bidirectional communication between IPv4 Internet and 417 hosts/IPv4 networks in IPv6 access network. In particular, it 418 supports the servers in IPv6 network to provide IPv4 application 419 service transparently. 421 Public 4over6 provides IPv4 access over IPv6 network while keeps 422 IPv4-IPv6 addressing and routing separated. Therefore the ISP can 423 manage the native IPv6 network independently without the influence of 424 IPv4-over-IPv6 requirements, and also provision IPv4 in a flexible, 425 on-demand way. 427 Public 4over6 supports dynamic reuse of a single IPv4 address between 428 multiple subscribers based on their dynamic requirement of 429 communicating with IPv4 Internet. A subscriber will request a public 430 IPv4 address for a period of time only when it need to communicate 431 with IPv4 Internet. Besides, in the CPE case, one public IPv4 432 address will be shared by the local network. So Public 4over6 can 433 improve the reuse rate of IPv4 addresses. 435 Public 4over6 is suited for network users/ISPs which can still get/ 436 provide public IPv4 addresses. Dual-stack lite is suited for network 437 users/ISPs which can no longer get/provide public IPv4 addresses. By 438 combining Public 4over6 and Dual-stack lite, the IPv4-over-IPv6 Hub 439 and spoke problem can be well solved. 441 7. Acknowledgement 443 The authors would like to thank Alain Durand and Dan Wing for their 444 valuable comments on this draft. 446 8. References 448 8.1. Normative References 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, March 1997. 453 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 454 Problem Statement", RFC 4925, July 2007. 456 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 457 Address Translator - Protocol Translator (NAT-PT) to 458 Historic Status", RFC 4966, July 2007. 460 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 461 Layer Reachability Information with an IPv6 Next Hop", 462 RFC 5549, May 2009. 464 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 465 Framework", RFC 5565, June 2009. 467 8.2. Informative References 469 [I-D.cui-softwire-b4-translated-ds-lite] 470 Cui, Y., Wu, J., and D. Wu, "B4 translated DS-lite enable 471 AFTR to serve more B4s", 472 draft-cui-softwire-b4-translated-ds-lite-00 (work in 473 progress), October 2010. 475 [I-D.cui-softwire-dhcp-over-tunnel] 476 Cui, Y., Wu, P., and J. Wu, "DHCPv4 Behavior over IP-IP 477 tunnel", draft-cui-softwire-dhcp-over-tunnel-00 (work in 478 progress), June 2011. 480 [I-D.ietf-pcp-base] 481 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 482 Selkirk, "Port Control Protocol (PCP)", 483 draft-ietf-pcp-base-13 (work in progress), July 2011. 485 [I-D.ietf-softwire-ds-lite-tunnel-option] 486 Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 487 Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite", 488 draft-ietf-softwire-ds-lite-tunnel-option-10 (work in 489 progress), March 2011. 491 [I-D.ietf-softwire-dual-stack-lite] 492 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 493 Stack Lite Broadband Deployments Following IPv4 494 Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work 495 in progress), May 2011. 497 [I-D.sun-v6ops-laft6] 498 Sun, Q. and C. Xie, "LAFT6: Lightweight address family 499 transition for IPv6", draft-sun-v6ops-laft6-01 (work in 500 progress), March 2011. 502 Authors' Addresses 504 Yong Cui 505 Tsinghua University 506 Department of Computer Science, Tsinghua University 507 Beijing 100084 508 P.R.China 510 Phone: +86-10-6260-3059 511 Email: yong@csnet1.cs.tsinghua.edu.cn 513 Jianping Wu 514 Tsinghua University 515 Department of Computer Science, Tsinghua University 516 Beijing 100084 517 P.R.China 519 Phone: +86-10-6278-5983 520 Email: jianping@cernet.edu.cn 522 Peng Wu 523 Tsinghua University 524 Department of Computer Science, Tsinghua University 525 Beijing 100084 526 P.R.China 528 Phone: +86-10-6278-5822 529 Email: weapon@csnet1.cs.tsinghua.edu.cn 531 Chris Metz 532 Cisco Systems, Inc. 533 3700 Cisco Way 534 San Jose, CA 95134 535 USA 537 Email: chmetz@cisco.com 539 Olivier Vautrin 540 Juniper Networks 541 1194 N Mathilda Avenue 542 Sunnyvale, CA 94089 543 USA 545 Email: Olivier@juniper.net 546 Yiu L. Lee 547 Comcast 548 One Comcast Center 549 Philadelphia, PA 19103 550 USA 552 Email: yiu_lee@cable.comcast.com