idnits 2.17.1 draft-ietf-softwire-public-4over6-00.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 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 (September 8, 2011) is 4614 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 468, but no explicit reference was found in the text == Unused Reference: 'RFC5549' is defined on line 482, 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-01 Summary: 4 errors (**), 0 flaws (~~), 5 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: March 11, 2012 Tsinghua University 6 C. Metz 7 Cisco Systems, Inc. 8 O. Vautrin 9 Juniper Networks 10 Y. Lee 11 Comcast 12 September 8, 2011 14 Public IPv4 over Access IPv6 Network 15 draft-ietf-softwire-public-4over6-00 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 March 11, 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 . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Scenario and requirements . . . . . . . . . . . . . . . . 4 67 4.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Public 4over6 Mechanism . . . . . . . . . . . . . . . . . . . 6 69 5.1. Address allocation and mapping maintenance . . . . . . . . 6 70 5.2. 4over6 initiator behavior . . . . . . . . . . . . . . . . 7 71 5.2.1. Host initiator . . . . . . . . . . . . . . . . . . . . 8 72 5.2.2. CPE initiator . . . . . . . . . . . . . . . . . . . . 8 73 5.3. 4over6 concentrator behavior . . . . . . . . . . . . . . . 8 74 6. Technical Advantages . . . . . . . . . . . . . . . . . . . . . 9 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Global IPv4 addresses are running out fast. Meanwhile, the demand 83 for IP address is still growing and may even burst in potential 84 circumstances like "Internet of Things". To satisfy the end users, 85 operators have to push IPv6 to the front, by building IPv6 networks 86 and providing IPv6 services. 88 When IPv6-only networks are widely deployed, users of those networks 89 will probably still need IPv4 connectivity. This is because part of 90 Internet will stay IPv4-only for a long time, and network users in 91 IPv6-only networks will communicate with network users sited in the 92 IPv4-only part of Internet. This demand could eventually decrease 93 with the general IPv6 adoption. 95 Network operators should provide IPv4 services to IPv6 users to 96 satisfy their demand, usually through tunnels. This type of IPv4 97 services differ in provisioned IPv4 addresses. If the users can't 98 get public IPv4 addresses (e.g., new network users join an ISP which 99 don't have enough unused IPv4 addresses), they have to use private 100 IPv4 addresses on the client side, and IPv4-private-to-public 101 translation is required on the carrier side, as is described in Dual- 102 stack Lite[RFC6333]. Otherwise the users can get public IPv4 103 addresses, and use them for IPv4 communication. In this case, 104 translation on the carrier side won't be necessary. The network 105 users and operators can avoid all the issues raised by translation, 106 such as ALG, NAT traversal, state maintenance, etc. Note that this 107 "public IPv4" situation is actually quite common. There're 108 approximatively 2^32 network users who are using or can potentially 109 get public IPv4 addresses. Most of them will switch to IPv6 sooner 110 or later, and will require IPv4 services for a significant period 111 after the switching. This draft focuses on this situation, i.e., to 112 provide IPv4 access for users in IPv6 networks, where public IPv4 113 addresses are still available for allocation. 115 2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Terminology 123 Public 4over6: Public 4over6 is the mechanism proposed by this draft. 124 Generally, Public 4over6 supports bidirectional communication between 125 IPv4 Internet and IPv4 hosts or local networks in IPv6 access 126 network, by leveraging IPv4-in-IPv6 tunnel and public IPv4 address 127 allocation. 129 4over6 initiator: in Public 4over6 mechanism, 4over6 initiator is the 130 IPv4-in-IPv6 tunnel initiator located on the user side of IPv6 131 network. The 4over6 initiator can be either a dual-stack capable 132 host or a dual-stack CPE device. In the former case, the host has 133 both IPv4 and IPv6 stack but is provisioned with IPv6 access only. 134 In the latter case, the CPE has both IPv6 interface for access to ISP 135 network and IPv4 interface for local network connection; hosts in the 136 local network can be IPv4-only. 138 4over6 concentrator: in Public 4over6 mechanism, 4over6 concentrator 139 is the IPv4-in-IPv6 tunnel concentrator located in IPv6 ISP network. 140 It's a dual-stack router which connects to both the IPv6 network and 141 IPv4 Internet. 143 4. Deployment Scenario 145 4.1. Scenario and requirements 147 The general scenario of Public 4over6 is shown in Figure 1. Users in 148 an IPv6 network take IPv6 as their native service. Some users are 149 end hosts which face the ISP network directly, while others are local 150 networks behind CPEs, such as a home LAN, an enterprise network, etc. 151 The ISP network is IPv6-only rather than dual-stack, which means that 152 ISP can't provide native IPv4 access to its users; however, it's 153 acceptable that one or more routers on the carrier side become dual- 154 stack and get connected to IPv4 Internet. So if network users want 155 to connect to IPv4, these dual-stack routers will be their 156 "entrances". 158 +-------------------------+ 159 | IPv6 ISP Network | 160 +------+ | 161 |host: | | 162 |initi-| | 163 |ator |=================+-------+ +-----------+ 164 +------+ |4over6 | | IPv4 | 165 | IPv4-in-IPv6 |Concen-|---| Internet | 166 +----------+ +------+ |trator | | | 167 |local IPv4|--|CPE: |=================+-------+ +-----------+ 168 | network | |initi-| | 169 +----------+ |ator | | 170 +------+ | 171 | | 172 +-------------------------+ 174 Figure 1 Public 4over6 scenario 176 Before getting into any technical details, the communication 177 requirements should be stated. The first one is that, 4over6 users 178 require IPv4-to-IPv4 communication with the IPv4 Internet. An IPv4 179 access service is needed rather than an IPv6-to-IPv4 translation 180 service. (IPv6-to-IPv4 communication is out of the scope of this 181 draft.) 183 Second, 4over6 users require public IPv4 addresses rather than 184 private addresses. Public IPv4 address means there's no IPv4 CGN 185 along the path, so the acquired IPv4 service is better. In 186 particular, some hosts may be application servers, public address 187 works better for reasons like straightforward access, direct DNS 188 registration, no stateful mapping maintenance on CGN, etc. For the 189 direct-connected host case, each host should get one public IPv4 190 address. For the local IPv4 network case, the CPE can get a public 191 IPv4 address and runs an IPv4 NAT for the local network. Here a 192 local NAT is still much better than the situation that involves a 193 CGN, since this NAT is in local network and can be configured and 194 managed by the users. 196 Third, translation is not preferred in this scenario. If this IPv4- 197 to-IPv4 communication is achieved by IPv4-IPv6 translation, it'll 198 need double translation along the path, one from IPv4 to IPv6 and the 199 other from IPv6 back to IPv4. This would be quite complicated, 200 especially in addressing. Contrarily a tunnel can achieve the IPv4- 201 over-IPv6 traversing easily. Therefore this draft follows the hub 202 and spoke softwire model. 204 Moreover, the ISP would probably like to keep their IPv4 and IPv6 205 addressing and routing separated when provisioning IPv4 over IPv6. 206 Then the ISP can manage the native IPv6 network more easily and 207 independently, and also provision IPv4 in a flexible, on-demand way. 208 The cost is that the concentrator needs to maintain per-user address 209 mapping state, which would be described in detail. 211 4.2. Use cases 213 Public 4over6 can be applicable in several practical cases. The 214 first one is that ISPs which still own enough IPv4 addresses switch 215 to IPv6. The ISPs can deploy public 4over6 to preserve IPv4 service 216 for the customers. This case is actually quite common. The majority 217 of the wired end users today get Internet access with public IPv4 218 address. When their ISPs switch to IPv6, these users can still use 219 the same amount of IPv4 addresses for IPv4 access. Public 4over6 can 220 leverage these addresses and offer tunneled IPv4 access. 222 The second case is ISPs which don't have enough IPv4 addresses any 223 more switch to IPv6. For these ISPs, dual-stack lite is so far the 224 most mature solution to provision IPv4 over IPv6. In dual-stack 225 lite, end users use private IPv4 addresses, experience a 44CGN and 226 hence some service degradation. As long as the end users use public 227 IPv4 addresses, all CGN issues can be avoided and the IPv4 service 228 can be full bi-directional. In other words, Public 4over6 can be 229 deployed along with DS-lite, to provide a value-added service. 230 Common users adopt DS-lite to communicate with IPv4 while high-end 231 users adopt Public 4over6. The two mechanisms can actually be 232 coupled easily. 234 There is also a special situation in the second case that the end 235 users are IPv4 application servers. In this situation, public 236 address brings significant convenience. The DNS registration can be 237 direct using dedicated address; the access of application clients can 238 be straightforward with no translation; there's no need to reserve 239 and maintain session state on the CGN, and no well-known port 240 collision will come up. So it's better to have servers adopt Public 241 4over6 for IPv4 access when they're located in IPv6 network. 243 Following the principle of Public 4over6, it's also possible to 244 achieve address multiplexing and save IPv4 addresses. There're 245 already efforts on this subject, see 246 [I-D.cui-softwire-b4-translated-ds-lite] and [I-D.sun-v6ops-laft6]. 247 The basic idea is that instead of allocating a full IPv4 address to 248 every end user, the ISP can allocate an IPv4 address with restricted 249 port range to every end user. 251 Besides, the draft would like to be explicit about the scope of 252 direct-connected host case and CPE case. The host case is clear: the 253 host is directly connected to IPv6 network, but the protocol stack on 254 the host support IPv4 too. As to the CPE case, this draft would like 255 to only focus on the case that the local network behind the CPE is 256 private IPv4. If the users want to run public IPv4 in the local 257 network, then they can either run dual-stack and thus turn into 258 direct-connected host case(likely home LAN situation), or they can 259 acquire address blocks from the ISP and build configured tunnel or 260 softwire mesh[RFC5565] with the ISP network(likely enterprise network 261 situation). 4over6 concentrator can be implemented to be compatible 262 with the latter case too, though. 264 5. Public 4over6 Mechanism 266 5.1. Address allocation and mapping maintenance 268 Public 4over6 can be generally considered as IPv4-over-IPv6 hub and 269 spoke tunnel using public IPv4 address. Each 4over6 initiator will 270 use public IPv4 address for IPv4-over-IPv6 communication. As is 271 described above, in the host initiator case, every host will get one 272 IPv4 address; in the CPE case, every CPE will get one IPv4 address, 273 which will be shared by hosts behind the CPE. The key problem here 274 is IPv4 address allocation over IPv6 network, from ISP device(s) to 275 separated 4over6 initiators. 277 There're two possibilities here. One is DHCPv4 over IPv6, and the 278 other is static configuration. DHCPv4 over IPv6 is achieved by 279 performing DHCPv4 over IPv6 network between 4over6 concentrator and 280 4over6 initiators. [I-D.cui-softwire-dhcp-over-tunnel] describes the 281 solution to achieve this by building DHCPv4 procedure on IPv4-in-IPv6 282 tunnel. An evolved draft describing performing DHCPv4 directly on 283 IPv6 environment is coming out soon in DHC working group. As to 284 static configuration, 4over6 users and the ISP operators should 285 negotiate beforehand to authorize the IPv4 address. Application 286 servers can falls into this case. Public 4over6 supports both 287 address allocation manners. 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 If the address is allocated through static configuration, the 297 concentrator should install the mapping manually when assigning the 298 address, and delete the mapping manually when recycling the address. 299 Else the address is allocated by DHCPv4, the concentrator should 300 participate in the DHCP procedure, either run a DHCPv4 server to 301 dynamically allocate public addresses to 4over6 initiators, or 302 perform the DHCP relay functions and leave the actual address 303 allocation job to a dedicated DHCPv4 server located in IPv4. When 304 allocating an IPv4 address(to be more precise, when sending back a 305 DHCP ACK message to a 4over6 intiator), the concentrator should 306 install a mapping entry of the allocated IPv4 address and the 307 initiator's IPv6 address into the address mapping table. This entry 308 should be deleted when receiving a DHCP RE:EASE of that IPv4 address, 309 or the lease of that IPv4 address expires. The latter case requires 310 the concentrator to maintain the lifetime of the address leases, 311 i.e., the mapping entries. 313 5.2. 4over6 initiator behavior 315 4over6 initiator has an IPv6 interface connected to the IPv6 ISP 316 network, and a tunnel interface to support IPv4-in-IPv6 317 encapsulation. In CPE case, it has at least one IPv4 interface 318 connected to IPv4 local network. 320 4over6 initiator should learn the 4over6 concentrator's IPv6 address 321 beforehand. For example, if the initiator gets its IPv6 address by 322 DHCPv6, it can get the 4over6 concentrator's IPv6 address through a 323 DHCPv6 option[RFC6334]. 325 5.2.1. Host initiator 327 When the initiator is a direct-connected host, it assigns the 328 allocated public IPv4 address to its tunnel interface. The host uses 329 this address for IPv4 communication. If the host acquires this 330 address through DHCP, it should support DHCPv4 over IPv6. 332 For IPv4 data traffic, the host performs the IPv4-in-IPv6 333 encapsulation and decapsulation on the tunnel interface. When 334 sending out an IPv4 packet, it performs the encapsulation, using the 335 IPv6 address of the 4over6 concentrator as the IPv6 destination 336 address, and its own IPv6 address as the IPv6 source address. The 337 encapsulated packet will be forwarded to the IPv6 network. The 338 decapsulation on 4over6 initiator is simple. When receiving an IPv4- 339 in-IPv6 packet, the initiator just drops the IPv6 header, and hands 340 it to upper layer. 342 5.2.2. CPE initiator 344 The CPE case is quite similar to the host initiator case. The CPE 345 assigns the allocated IPv4 address to its tunnel interface. The CPE 346 should support DHCPv4 over IPv6 if it acquires this address through 347 DHCP. The local IPv4 network won't take part in the public IPv4 348 allocation; instead, end hosts will use private IPv4 addresses, 349 possibly allocated by the CPE. 351 On data plan, the CPE can be viewed as a regular IPv4 NAT(using 352 tunnel interface as the NAT outside interface) cascaded with a tunnel 353 initiator. For IPv4 data packets received from the local network, 354 the CPE translates these packets, using the tunnel interface address 355 as the source address, and then encapsulates the translated packet 356 into IPv6, using the concentrator's IPv6 address as the destination 357 address, the CPE's IPv6 address as source address. For IPv6 data 358 packet received from the IPv6 network, the CPE performs decapsulation 359 and IPv4 public-to-private translation. As to the CPE itself, it 360 uses the public, tunnel interface address to communicate with the 361 IPv4 Internet, and the private, IPv4 interface address to communicate 362 with the local network. 364 5.3. 4over6 concentrator behavior 366 4over6 concentrator represents the IPv4-IPv6 border router working as 367 the remote tunnel endpoint for 4over6 initiators, with its IPv6 368 interface connected to the IPv6 network, IPv4 interface connected to 369 the IPv4 Internet, and a tunnel interface supporting IPv4-in-IPv6 370 encapsulation and decapsulation. There's no CGN on the 4over6 371 concentrator, it won't perform any translation function; instead, 372 4over6 concentrator maintains an IPv4-IPv6 address mapping table for 373 IPv4 data encapsulation. 375 4over6 concentrator maintains the IPv4-IPv6 address mapping of 4over6 376 initiators. Besides manual configration of address mappings, it runs 377 either a DHCP relay or a DHCP server which support DHCPv4 over IPv6, 378 for 4over6 initiators. When sending out a DHCP ACK, the concentrator 379 reads the allocated IPv4 address and the IPv6 destination address 380 from the packet, installs the mapping entry into the mapping table or 381 renews it if it already exists. When the lifetime of a mapping 382 entry/a lease of allocated address expires, or when the concentrator 383 receives a DHCP RELEASE of allocated address, the concentrator 384 deletes the corresponding mapping entry from the table. The mapping 385 entry is used to provide correct encapsulation destination address 386 for concentrator encapsulation. As long as the entry exists in the 387 table, the concentrator can encapsulate inbound IPv4 packets destined 388 to the initiator, with the initiator's IPv6 address as IPv6 389 destination. 391 On the IPv6 side, 4over6 concentrator decapsulates IPv4-in-IPv6 392 packets coming from 4over6 initiators. It removes the IPv6 header of 393 every IPv4-in-IPv6 packet and forwards it to the IPv4 Internet. On 394 the IPv4 side, the concentrator encapsulates the IPv4 packets 395 destined to 4over6 initiators. When performing the IPv4-in-IPv6 396 encapsulation, the concentrator uses its own IPv6 address as the IPv6 397 source address, uses the IPv4 destination address in the packet to 398 look up IPv6 destination address in the address mapping table. After 399 the encapsulation, the concentrator sends the IPv6 packet on its IPv6 400 interface to reach an initiator. 402 The 4over6 concentrator, or its upstream router should advertise the 403 IPv4 prefix which contains the IPv4 addresses of 4over6 users to the 404 IPv4 side, in order to make these initiators reachable on IPv4 405 Internet. 407 Since the concentrator has to maintain the IPv4-IPv6 address mapping 408 table, the concentrator is stateful in IP level. Note that this 409 table will be much smaller than a CGN table, as there is no port 410 information involved. 412 6. Technical Advantages 414 Public 4over6 provides a method for users in IPv6 network to 415 communicate with IPv4. In many scenarios, this can be viewed as an 416 alternative to IPv6-IPv4 translation mechanisms which have well-known 417 limitations described in [RFC4966]. 419 Since a 4over6 initiator uses a public IPv4 address, Public 4over6 420 supports full bidirectional communication between IPv4 Internet and 421 hosts/IPv4 networks in IPv6 access network. In particular, it 422 supports the servers in IPv6 network to provide IPv4 application 423 service transparently. 425 Public 4over6 provides IPv4 access over IPv6 network while keeps 426 IPv4-IPv6 addressing and routing separated. Therefore the ISP can 427 manage the native IPv6 network independently without the influence of 428 IPv4-over-IPv6 requirements, and also provision IPv4 in a flexible, 429 on-demand way. 431 Public 4over6 supports dynamic reuse of a single IPv4 address between 432 multiple subscribers based on their dynamic requirement of 433 communication with IPv4 Internet. A subscriber will request a public 434 IPv4 address for a period of time only when it need to communicate 435 with IPv4 Internet. Besides, in the CPE case, one public IPv4 436 address will be shared by the local network. So Public 4over6 can 437 improve the reuse rate of IPv4 addresses. 439 Public 4over6 is suited for network users/ISPs which can still get/ 440 provide public IPv4 addresses. Dual-stack lite is suited for network 441 users/ISPs which can no longer get/provide public IPv4 addresses. By 442 combining Public 4over6 and Dual-stack lite, the IPv4-over-IPv6 Hub 443 and spoke problem can be well solved. 445 7. Security Considerations 447 The 4over6 concentrator should support ways to limit service only to 448 registered customers. The first step is to allocate IPv4 addresses 449 only to registered customers. One simple way is to fliter on the 450 IPv6 source addresses of incoming DHCP packets and only respond to 451 the ones with the IPv6 source address range of the customers. The 452 concentrator can also perform authentication during DHCP, for 453 example, based on the MAC address of the initiators. As to data 454 packets, the concentrator can implement an IPv6 ingress filter on the 455 tunnel interface to accept only the IPv6 address range defined in the 456 filter. 458 8. References 460 8.1. Normative References 462 [RFC2119] Bradner, S., "Key words for 463 use in RFCs to Indicate 464 Requirement Levels", 465 BCP 14, RFC 2119, 466 March 1997. 468 [RFC4925] Li, X., Dawkins, S., Ward, 469 D., and A. Durand, 470 "Softwire Problem 471 Statement", RFC 4925, 472 July 2007. 474 [RFC4966] Aoun, C. and E. Davies, 475 "Reasons to Move the 476 Network Address Translator 477 - Protocol Translator 478 (NAT-PT) to Historic 479 Status", RFC 4966, 480 July 2007. 482 [RFC5549] Le Faucheur, F. and E. 483 Rosen, "Advertising IPv4 484 Network Layer Reachability 485 Information with an IPv6 486 Next Hop", RFC 5549, 487 May 2009. 489 [RFC5565] Wu, J., Cui, Y., Metz, C., 490 and E. Rosen, "Softwire 491 Mesh Framework", RFC 5565, 492 June 2009. 494 [RFC6333] Durand, A., Droms, R., 495 Woodyatt, J., and Y. Lee, 496 "Dual-Stack Lite Broadband 497 Deployments Following IPv4 498 Exhaustion", RFC 6333, 499 August 2011. 501 [RFC6334] Hankins, D. and T. 502 Mrugalski, "Dynamic Host 503 Configuration Protocol for 504 IPv6 (DHCPv6) Option for 505 Dual-Stack Lite", RFC 6334, 506 August 2011. 508 8.2. Informative References 510 [I-D.cui-softwire-b4-translated-ds-lite] Cui, Y., Wu, J., Wu, P., 511 Sun, Q., Xie, C., and C. 512 Zhou, "Lightweight 4over6 513 in access network", draft- 514 cui-softwire-b4-translated- 515 ds-lite-01 (work in 516 progress), July 2011. 518 [I-D.cui-softwire-dhcp-over-tunnel] Cui, Y., Wu, P., and J. Wu, 519 "DHCPv4 Behavior over IP-IP 520 tunnel", draft-cui- 521 softwire-dhcp-over-tunnel- 522 01 (work in progress), 523 July 2011. 525 [I-D.sun-v6ops-laft6] Sun, Q. and C. Xie, "LAFT6: 526 Lightweight address family 527 transition for IPv6", 528 draft-sun-v6ops-laft6-01 529 (work in progress), 530 March 2011. 532 Authors' Addresses 534 Yong Cui 535 Tsinghua University 536 Department of Computer Science, Tsinghua University 537 Beijing 100084 538 P.R.China 540 Phone: +86-10-6260-3059 541 EMail: yong@csnet1.cs.tsinghua.edu.cn 543 Jianping Wu 544 Tsinghua University 545 Department of Computer Science, Tsinghua University 546 Beijing 100084 547 P.R.China 549 Phone: +86-10-6278-5983 550 EMail: jianping@cernet.edu.cn 552 Peng Wu 553 Tsinghua University 554 Department of Computer Science, Tsinghua University 555 Beijing 100084 556 P.R.China 558 Phone: +86-10-6278-5822 559 EMail: weapon@csnet1.cs.tsinghua.edu.cn 561 Chris Metz 562 Cisco Systems, Inc. 563 3700 Cisco Way 564 San Jose, CA 95134 565 USA 567 EMail: chmetz@cisco.com 569 Olivier Vautrin 570 Juniper Networks 571 1194 N Mathilda Avenue 572 Sunnyvale, CA 94089 573 USA 575 EMail: Olivier@juniper.net 577 Yiu L. Lee 578 Comcast 579 One Comcast Center 580 Philadelphia, PA 19103 581 USA 583 EMail: yiu_lee@cable.comcast.com