idnits 2.17.1 draft-ietf-softwire-public-4over6-02.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 date (July 16, 2012) is 4302 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 501, but no explicit reference was found in the text == Unused Reference: 'RFC4966' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'RFC5549' is defined on line 511, 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 (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-03 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: January 17, 2013 Tsinghua University 6 O. Vautrin 7 Juniper Networks 8 Y. Lee 9 Comcast 10 July 16, 2012 12 Public IPv4 over IPv6 Access Network 13 draft-ietf-softwire-public-4over6-02 15 Abstract 17 When the service provider networks are upgraded to IPv6, IPv4 18 connectivity will still be demanded by network users, at least in the 19 recent future. This draft proposes a mechanism for end hosts or 20 networks in IPv6 access networks to build bidirectional IPv4 21 communication with the IPv4 Internet. The mechanism follows the 22 softwire hub and spoke model, and uses IPv4-over-IPv6 tunnel as basic 23 method to traverse IPv6 network. The bi-directionality of end-to-end 24 communication is achieved by allocating public IPv4 addresses to end 25 hosts/networks, with no dependency on IPv6 addressing. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 17, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. Scenario and requirements . . . . . . . . . . . . . . . . 4 66 4.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Public 4over6 Mechanism . . . . . . . . . . . . . . . . . . . 6 68 5.1. IPv4 Address allocation and binding maintenance . . . . . 6 69 5.2. 4over6 initiator behavior . . . . . . . . . . . . . . . . 7 70 5.2.1. Host initiator . . . . . . . . . . . . . . . . . . . . 8 71 5.2.2. CPE initiator . . . . . . . . . . . . . . . . . . . . 8 72 5.3. 4over6 concentrator behavior . . . . . . . . . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 7. Change Log from the -02 Version . . . . . . . . . . . . . . . 10 75 8. Author List . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 IANA has exhausted the Global IPv4 address pool, while the RIRs are 83 running out of IPv4 addresses. On the other hand, the size of 84 Internet is still growing fast, as well as the demand for IP 85 addresses. To satisfy the address demand from end users, operators 86 have to push IPv6 to the front, by building IPv6 networks and 87 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 Therefore, network operators should provide IPv4 services to IPv6 97 users, usually through tunnel. There are two types of this tunneled 98 IPv4 services, differed in provisioned IPv4 addresses. If the 99 operators cannot provision public IPv4 addresses, the user side can 100 only use private IPv4 addresses, and NAT44 translation is required on 101 the carrier side, as is described in Dual-stack Lite[RFC6333]. 102 Otherwise the operators are capable of provisioning public IPv4 103 addresses. Then users can directly employ these addresses for IPv4 104 communication, and carrier-side translation is not needed anymore. 105 The network users and operators can avoid all the issues raised by 106 translation, such as ALG, NAT traversal, session state maintenance, 107 etc. 109 In the second type, there have also been efforts on provisioning 110 port-set rather than full address to individual users. Supporting 111 port-set would require extra extensions on the provision protocol, 112 end-user behavior and data plane function. On the other hand, from 113 the ISPs' perspective, many of them are still capable of providing 114 per-subscriber IPv4 addresses in their networks; in this case port- 115 set support is not a necessary during their transition process. 116 Therefore, this document focuses on specifying a clean IPv4-over-IPv6 117 solution with full IPv4 address provisioning. 119 Unlike stateless IPv4-over-IPv6 mechanisms, the mechanism described 120 in this document still maintains per-subscriber binding state. The 121 benefit is that it keeps IPv4-IPv6 addressing independent, which 122 brings deployment and operation flexibility. The IPv6 infrastructure 123 in the middle does not need to get involved with the IPv4-over-IPv6 124 mechanism at all, no special network planning is required; the 125 deployment can be achieved in on-demand style rather than over the 126 whole network; the IPv4 address resources are managed in a dedicated, 127 centralized way rather than distributed to local sites with IPv6. In 128 general, the two types of mechanisms have different primary targets 129 and application scenarios under the IPv4-over-IPv6 scope. 131 2. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 3. Terminology 139 Public 4over6: Public 4over6 is the mechanism proposed by this draft. 140 Public 4over6 supports bidirectional communication between IPv4 141 Internet and IPv4 hosts or local networks in IPv6 access network, by 142 leveraging IPv4-in-IPv6 tunnel and public IPv4 address allocation. 144 4over6 initiator: in Public 4over6 mechanism, 4over6 initiator is the 145 IPv4-in-IPv6 tunnel initiator located on the user side of IPv6 146 network. The 4over6 initiator can be either a dual-stack capable 147 host, or a dual-stack CPE device. In the former case, the host has 148 both IPv4 and IPv6 stack but is provisioned with IPv6 access only. 149 In the latter case, the CPE has both IPv6 interface connecting to ISP 150 network, and IPv4 interface connecting to local network; hosts in the 151 local network can be IPv4-only. 153 4over6 concentrator: in Public 4over6 mechanism, 4over6 concentrator 154 is the IPv4-in-IPv6 tunnel concentrator located in IPv6 ISP network. 155 It is a dual-stack router which connects to both the IPv6 ISP network 156 and IPv4 Internet. 158 4. Deployment Scenario 160 4.1. Scenario and requirements 162 The general scenario of Public 4over6 is shown in Figure 1. Users in 163 an IPv6 network take IPv6 as their native service. Some users are 164 end hosts which face the ISP network directly, while the others are 165 local networks behind CPEs, such as a home LAN, an enterprise 166 network, etc. The ISP network is IPv6-only rather than dual-stack, 167 which means the ISP cannot provide native IPv4 service to users. 168 However, it is acceptable that some router(s) on the carrier side 169 becomes dual-stack and connects to IPv4 Internet. So if network 170 users require IPv4 connectivity, the dual-stack router(s) will work 171 as their "entrance". 173 +-------------------------+ 174 | IPv6 ISP Network | 175 +------+ | 176 |host: | | 177 |initi-| | 178 |ator |=================+-------+ +-----------+ 179 +------+ |4over6 | | IPv4 | 180 | IPv4-in-IPv6 |Concen-|---| Internet | 181 +----------+ +------+ |trator | | | 182 |local IPv4|--|CPE: |=================+-------+ +-----------+ 183 | network | |initi-| | 184 +----------+ |ator | | 185 +------+ | 186 | | 187 +-------------------------+ 189 Figure 1 Public 4over6 scenario 191 From end user perspective, 4over6 users require IPv4-to-IPv4 192 communication with the IPv4 Internet. An IPv4 access service is 193 needed rather than an IPv6-to-IPv4 translation service. Second, 194 public IPv4 addresses will be preferred by 4over6 users. With public 195 IPv4 address provisioning, IPv4 CGN is not required so end-to-end 196 transparency is preserved. For special users like application 197 servers, public address brings great convenience including 198 straightforward access, direct DNS registration, no stateful binding 199 maintenance on CGN, etc. For the direct-connected host case, each 200 host should get one public IPv4 address. For the local IPv4 network 201 case, the CPE can get a public IPv4 address and runs an IPv4 NAT for 202 the local network. Here a local NAT is still much better than the 203 situation that involves a CGN, since this NAT is in local network and 204 can be configured and managed by the users. 206 From the operator perspective, the ISPs would like to keep their IPv4 207 and IPv6 addressing and routing separated when provisioning IPv4 over 208 IPv6. Then they can manage the native IPv6 networks more easily and 209 independently, and also provision IPv4 in a flexible, on-demand way. 210 The cost is for the concentrator to maintain per-user address binding 211 state. As a result, double translation is not preferred. Unlike 212 stateless scenario, double translation in this scenario brings more 213 complexity to IPv6 network than tunnel. Therefore this draft follows 214 the hub and spoke softwire model. 216 4.2. Use cases 218 Public 4over6 can be applicable in several practical cases. The 219 first one is that ISPs which still have plenty of IPv4 address 220 resource switch to IPv6. As long as the amount of the remaining and 221 reclaimable IPv4 addresses can match the user amount, the ISPs can 222 deploy public 4over6 to preserve IPv4 service for the customers. 224 The second case is ISPs which do not have enough IPv4 addresses 225 switch to IPv6. For those ISPs, dual-stack lite is so far the most 226 mature solution to provision IPv4 over IPv6. In dual-stack lite, end 227 users use private IPv4 addresses, experience a 44CGN and some service 228 degradation. As long as the end users use public IPv4 addresses, all 229 CGN issues can be avoided and the IPv4 service can be full bi- 230 directional. In other words, Public 4over6 can be deployed along 231 with DS-lite, to provide a value-added service. Common users adopt 232 DS-lite while high-end users adopt Public 4over6. The two mechanisms 233 can actually get coupled easily. 235 There is also a special instance in the second case that the end 236 users are IPv4 application servers. In this circumstance, public 237 address brings significant convenience. The DNS registration can be 238 direct, with dedicated address; the application service access can be 239 straightforward with no translation involved for the clients; there 240 is no need to reserve and hold session state on the CGN, and no well- 241 known port collision will come up. So it is better to have servers 242 take Public 4over6 for IPv4 access when they are located in IPv6 243 network. 245 Besides, the document should be explicit about the direct-connected 246 host case and the CPE case. The host case is clear: the host is 247 directly connected to IPv6 network, but its protocol stacks have IPv4 248 support as well. As to the CPE case, this document would like to 249 only focus on the situation that the local network behind the CPE 250 stays in private IPv4. If the local network want to run public IPv4, 251 then it can either run IPv6 as well and enable the hosts to execute 252 Public 4over6, or acquire address blocks from the ISP and build 253 configured tunnel or Softwire Mesh[RFC5565] with the ISP network. 254 The former solution is suitable for the home LAN situation while the 255 latter solution is suitable for the enterprise network situation. 257 5. Public 4over6 Mechanism 259 5.1. IPv4 Address allocation and binding maintenance 261 Public 4over6 can be generally considered as IPv4-over-IPv6 hub and 262 spoke tunnel leveraging public IPv4 address. Each 4over6 initiator 263 uses public IPv4 address for IPv4-over-IPv6 communication. As is 264 described above, in the host initiator case, every host gets one IPv4 265 address; in the CPE case, every CPE gets one IPv4 address, which is 266 then shared by hosts behind the CPE. The key problem here is IPv4 267 address allocation over IPv6 network, from ISP device(s) to 4over6 268 initiators. 270 There are two possibilities here. One is DHCPv4 over IPv6, and the 271 other is static configuration. DHCPv4 over IPv6 enables DHCPv4 272 message to be transported in IPv6 packet instead of IPv4 packet, so 273 the address allocation can be achieved between 4over6 concentrator 274 and 4over6 initiators. [I-D.ietf-dhc-dhcpv4-over-ipv6] describes the 275 DHCP protocol format and behavior extensions to support that. As to 276 static configuration, 4over6 users and the ISP operators MUST 277 negotiate beforehand to authorize the IPv4 address. Application 278 servers can falls into this case. Public 4over6 supports both 279 address allocation manners. 281 Along with IPv4 address allocation, Public 4over6 MUST maintain the 282 IPv4-IPv6 address bindings on the concentrator. In this type of 283 address binding, the IPv4 address is the public IPv4 address 284 allocated to a 4over6 initiator, and the IPv6 address is the 285 initiator's IPv6 address. This binding is used to provide correct 286 encapsulation destination address for the concentrator. 288 If the address is allocated through static configuration, the 289 concentrator installs the binding manually when assigning the 290 address, and delete the binding manually when recycling the address. 291 Else the address is allocated by DHCPv4, the concentrator MUST 292 participate in the DHCP procedure, either run a DHCPv4 server to 293 dynamically allocate public addresses to 4over6 initiators, or 294 perform the DHCP relay functions and leave the actual address 295 allocation job to a dedicated DHCPv4 server located in IPv4. When 296 allocating an IPv4 address (to be more precise, when sending back a 297 DHCP ACK message to a 4over6 initiator), the concentrator installs a 298 binding entry of the allocated IPv4 address and the initiator's IPv6 299 address into the address binding table. This entry MUST be deleted 300 when receiving a DHCP RELEASE of that IPv4 address, or the lease of 301 that IPv4 address expires. 303 5.2. 4over6 initiator behavior 305 4over6 initiator has an IPv6 interface connected to the IPv6 ISP 306 network, and a tunnel interface to support IPv4-in-IPv6 307 encapsulation. In CPE case, it has at least one IPv4 interface 308 connected to IPv4 local network. 310 A 4over6 initiator MUST be provisioned with IPv6 beforehand. It MUST 311 also learn the 4over6 concentrator's IPv6 address. For example, if 312 the initiator gets its IPv6 address by DHCPv6, it can get the 4over6 313 concentrator's IPv6 address through a DHCPv6 option[RFC6334]. Then 314 it runs the DHCPv4 over IPv6 process to dynamically fetch an IPv4 315 address from the concentrator, or negotiate with the ISP and acquire 316 a static IPv4 address from the concentrator. This address is 317 assigned to the IPv4-in-IPv6 tunnel interface. 319 5.2.1. Host initiator 321 When the initiator is a direct-connected host, it assigns the 322 allocated public IPv4 address to its tunnel interface. The host uses 323 this address for IPv4 communication. If the host acquires this 324 address through DHCP, it MUST support DHCPv4 over IPv6. 326 For IPv4 data traffic, the host performs the IPv4-in-IPv6 327 encapsulation and decapsulation on the tunnel interface. When 328 sending out an IPv4 packet, it performs the encapsulation, using the 329 IPv6 address of the 4over6 concentrator as the IPv6 destination 330 address, and its own IPv6 address as the IPv6 source address. The 331 encapsulated packet will be forwarded to the IPv6 network. The 332 decapsulation on 4over6 initiator is simple. When receiving an IPv4- 333 in-IPv6 packet, the initiator just drops the IPv6 header, and hands 334 it to upper layer. 336 5.2.2. CPE initiator 338 The CPE case is quite similar to the host initiator case. The CPE 339 assigns the allocated IPv4 address to the tunnel interface on the 340 CPE. The CPE MUST support DHCPv4 over IPv6 if it acquires this 341 address through DHCP. The local IPv4 network does not take part in 342 the public IPv4 allocation; instead, end hosts will use private IPv4 343 addresses, possibly allocated by the CPE. 345 On data plan, the CPE can be viewed as a regular IPv4 NAT (using the 346 tunnel interface as the NAT external interface) cascaded with a 347 tunnel initiator. For IPv4 data packets received from the local 348 network, the CPE translates these packets, using the tunnel interface 349 address as the source address, and then encapsulates the translated 350 packet into IPv6, using the concentrator's IPv6 address as the 351 destination address, the CPE's IPv6 address as source address. For 352 IPv6 data packet received from the IPv6 network, the CPE performs 353 decapsulation and IPv4 public-to-private translation. As to the CPE 354 itself, it uses the public, tunnel interface address to communicate 355 with the IPv4 Internet, and the private, IPv4 interface address to 356 communicate with the local network. 358 5.3. 4over6 concentrator behavior 360 4over6 concentrator represents the IPv4-IPv6 border router working as 361 the remote tunnel endpoint for 4over6 initiators, with its IPv6 362 interface connected to the IPv6 network, IPv4 interface connected to 363 the IPv4 Internet, and a tunnel interface supporting IPv4-in-IPv6 364 encapsulation and decapsulation. There is no CGN on the 4over6 365 concentrator, it will not perform any translation function; instead, 366 4over6 concentrator maintains an IPv4-IPv6 address binding table for 367 IPv4 data encapsulation. 369 4over6 concentrator maintains the IPv4-IPv6 address binding of 4over6 370 initiators. Besides manual configuration of address binding, it runs 371 either a DHCP relay or a DHCP server which supports DHCPv4 over IPv6. 372 When sending out a DHCP ACK, the concentrator resolves the allocated 373 IPv4 address and the IPv6 destination address, installs the binding 374 entry into the binding table or renews it if it already exists. When 375 the lifetime of a binding entry/a lease of allocated address expires, 376 or when the concentrator receives a DHCP RELEASE of allocated 377 address, the concentrator deletes the corresponding binding entry 378 from the table. The binding entry is used to provide correct 379 encapsulation destination address for concentrator encapsulation. As 380 long as the entry exists in the table, the concentrator can 381 encapsulate inbound IPv4 packets destined to the initiator, with the 382 initiator's IPv6 address as IPv6 destination. 384 On the IPv6 side, 4over6 concentrator decapsulates IPv4-in-IPv6 385 packets coming from 4over6 initiators. It removes the IPv6 header of 386 every IPv4-in-IPv6 packet and forwards it to the IPv4 Internet. 387 Before the decapsulation, the concentrator MUST check the inner IPv4 388 source address against the outer IPv6 source address, by matching 389 such a binding entry in the binding table. If no binding is found, 390 the concentrator silently drops the packet. On the IPv4 side, the 391 concentrator encapsulates the IPv4 packets destined to 4over6 392 initiators. When performing the IPv4-in-IPv6 encapsulation, the 393 concentrator uses its own IPv6 address as the IPv6 source address, 394 uses the IPv4 destination address in the packet to look up IPv6 395 destination address in the address binding table. After the 396 encapsulation, the concentrator sends the IPv6 packet on its IPv6 397 interface to reach an initiator. The concentrator MUST support 398 hairpinning of traffic between two initiators, by performing de- 399 capsulation and re-encapsulation of packets. 401 The 4over6 concentrator, or its upstream router SHOULD advertise the 402 IPv4 prefix which contains the IPv4 addresses of 4over6 users to the 403 IPv4 side, in order to make these initiators reachable on IPv4 404 Internet. 406 Since the concentrator has to maintain the IPv4-IPv6 address binding 407 table, the concentrator is stateful in IP level. Note that this 408 table will be much smaller than a CGN table, as there is no port 409 information involved. 411 6. Security Considerations 413 The 4over6 concentrator SHOULD implement methods to limit service 414 only to registered customers. The first step is to allocate IPv4 415 addresses only to registered customers. One simple solution is to 416 filter on the IPv6 source addresses of incoming DHCP packets and only 417 respond to the ones which have registered IPv6 source address. The 418 concentrator can also perform authentication during DHCP, for 419 example, based on the MAC address of the initiators. As to data 420 packets, the concentrator can implement an IPv6 ingress filter on the 421 tunnel interface to accept only the IPv6 address range defined in the 422 filter, as well as check the IPv4-IPv6 source address binding by 423 looking up the binding table. 425 7. Change Log from the -02 Version 427 1.Add a paragraph in section 1 to discuss the relationship with port- 428 set-enabled solutions, remove the corresponding texts of Lightweight 429 4over6 draft from section 4.2; 431 2.Add a paragraph in section 1 to discuss the relationship with 432 stateless IPv4-over-IPv6 solutions; 434 3.Add a paragraph in section 5.2 describing the provisioning steps; 436 4.State in Section 5.3 that the concentrator should support hairpin; 438 5.Add the behavior of IPv4-IPv6 source address binding verification 439 on the concentrator before decapsulation, in Section 5.3; 441 6.Change the terminology of "mapping" (stateful IPv4-IPv6 address 442 mapping) to "binding", to avoid the possible confusion with 443 "algorithmic mapping" in stateless mechanisms. 445 8. Author List 447 The following are extended authors who contributed to the effort: 449 Huiling Zhao 450 China Telecom 451 Room 502, No.118, Xizhimennei Street 452 Beijing 100035 453 P.R.China 455 Phone: +86-10-58552002 456 Email: zhaohl@ctbri.com.cn 458 Chongfeng Xie 459 China Telecom 460 Room 708, No.118, Xizhimennei Street 461 Beijing 100035 462 P.R.China 464 Phone: +86-10-58552116 465 Email: xiechf@ctbri.com.cn 467 Qiong Sun 468 China Telecom 469 Room 708, No.118, Xizhimennei Street 470 Beijing 100035 471 P.R.China 473 Phone: +86-10-58552936 474 Email: sunqiong@ctbri.com.cn 476 Qi Sun 477 Tsinghua University 478 Beijing 100084 479 P.R.China 481 Phone: +86-10-62785822 482 Email: sunqibupt@gmail.com 484 Chris Metz 485 Cisco Systems 486 3700 Cisco Way 487 San Jose, CA 95134 488 USA 490 Email: chmetz@cisco.com 492 9. References 494 9.1. Normative References 496 [RFC2119] Bradner, S., "Key words for use in 497 RFCs to Indicate Requirement 498 Levels", BCP 14, RFC 2119, 499 March 1997. 501 [RFC4925] Li, X., Dawkins, S., Ward, D., and 502 A. Durand, "Softwire Problem 503 Statement", RFC 4925, July 2007. 505 [RFC4966] Aoun, C. and E. Davies, "Reasons to 506 Move the Network Address Translator 507 - Protocol Translator (NAT-PT) to 508 Historic Status", RFC 4966, 509 July 2007. 511 [RFC5549] Le Faucheur, F. and E. Rosen, 512 "Advertising IPv4 Network Layer 513 Reachability Information with an 514 IPv6 Next Hop", RFC 5549, May 2009. 516 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. 517 Rosen, "Softwire Mesh Framework", 518 RFC 5565, June 2009. 520 [RFC6333] Durand, A., Droms, R., Woodyatt, J., 521 and Y. Lee, "Dual-Stack Lite 522 Broadband Deployments Following IPv4 523 Exhaustion", RFC 6333, August 2011. 525 [RFC6334] Hankins, D. and T. Mrugalski, 526 "Dynamic Host Configuration Protocol 527 for IPv6 (DHCPv6) Option for Dual- 528 Stack Lite", RFC 6334, August 2011. 530 9.2. Informative References 532 [I-D.ietf-dhc-dhcpv4-over-ipv6] Cui, Y., Wu, P., Wu, J., and T. 533 Lemon, "DHCPv4 over IPv6 Transport", 534 draft-ietf-dhc-dhcpv4-over-ipv6-03 535 (work in progress), May 2012. 537 Authors' Addresses 539 Yong Cui 540 Tsinghua University 541 Department of Computer Science, Tsinghua University 542 Beijing 100084 543 P.R.China 545 Phone: +86-10-6260-3059 546 EMail: yong@csnet1.cs.tsinghua.edu.cn 548 Jianping Wu 549 Tsinghua University 550 Department of Computer Science, Tsinghua University 551 Beijing 100084 552 P.R.China 554 Phone: +86-10-6278-5983 555 EMail: jianping@cernet.edu.cn 557 Peng Wu 558 Tsinghua University 559 Department of Computer Science, Tsinghua University 560 Beijing 100084 561 P.R.China 563 Phone: +86-10-6278-5822 564 EMail: pengwu.thu@gmail.com 566 Olivier Vautrin 567 Juniper Networks 568 1194 N Mathilda Avenue 569 Sunnyvale, CA 94089 570 USA 572 EMail: Olivier@juniper.net 574 Yiu L. Lee 575 Comcast 576 One Comcast Center 577 Philadelphia, PA 19103 578 USA 580 EMail: yiu_lee@cable.comcast.com