idnits 2.17.1 draft-ietf-softwire-public-4over6-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 : ---------------------------------------------------------------------------- ** 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 (February 25, 2013) is 4078 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4925' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC4966' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'RFC5549' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'RFC5565' is defined on line 511, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5549 (Obsoleted by RFC 8950) == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-05 Summary: 2 errors (**), 0 flaws (~~), 6 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: Informational P. Wu 5 Expires: August 29, 2013 Tsinghua University 6 O. Vautrin 7 Juniper Networks 8 Y. Lee 9 Comcast 10 February 25, 2013 12 Public IPv4 over IPv6 Access Network 13 draft-ietf-softwire-public-4over6-05 15 Abstract 17 When the service provider networks are upgraded to IPv6, end users 18 will continue to demand IPv4 connectivity. This document proposes a 19 mechanism for hosts or customer networks in IPv6 access network to 20 build bidirectional IPv4 communication with the IPv4 Internet. The 21 mechanism follows the hub and spokes softwire model, and uses IPv4- 22 over-IPv6 tunnel as basic method to traverse IPv6 network. The bi- 23 directionality of this IPv4 communication is achieved by explicitly 24 allocating public IPv4 addresses to end users, as well as maintaining 25 IPv4-IPv6 address binding on the border relay. This mechanism 26 features the allocation of full IPv4 address over IPv6 network, and 27 has been used in production for high-end IPv4 users, IPv6 transition 28 of ICPs, etc. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 29, 2013. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Scenario and Use Cases . . . . . . . . . . . . . . . . . . . . 4 67 5. Public 4over6 Address Provisioning . . . . . . . . . . . . . . 6 68 5.1. Basic Provisioning Steps . . . . . . . . . . . . . . . . . 6 69 5.2. Public IPv4 Address Allocation . . . . . . . . . . . . . . 7 70 6. 4over6 CE Behavior . . . . . . . . . . . . . . . . . . . . . . 7 71 7. 4over6 BR Behavior . . . . . . . . . . . . . . . . . . . . . . 8 72 8. Fragmentation and reassembly . . . . . . . . . . . . . . . . . 9 73 9. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 11. Change Log from the -03 Version . . . . . . . . . . . . . . . 10 76 12. Author List . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 79 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 When deploying IPv6 networks, IPv4 connectivity is still a required 84 functionality by end users. It is used for IPv4 communication with 85 IPv4-only part of the Internet during the IPv4-IPv6 transition 86 period. IPv4-over-IPv6 tunnel mechanisms are the general solutions 87 to provide this type of IPv4 services. 89 This document describes a mechanism for providing IPv4 connectivity 90 in this situation. The mechanism is similar to the Binding approach 91 of the Unified IPv4-in-IPv6 Softwire CPE effort that is documented in 92 [I-D.bfmk-softwire-unified-cpe] Section 2. Although the 93 functionality documented in the standard is similar, this document 94 describes existing practice that differs from the standard, but that 95 has been deployed in China Next Generation Internet (CNGI) - China 96 Education and Research Network 2 (CERNET2). 98 The purpose of this draft is to document the protocol that was 99 deployed, both for historical purposes and for the benefit of users 100 of that protocol in the field at the time of publication. Future 101 deployments with similar requirements should simply use the related 102 mechanism in [I-D.bfmk-softwire-unified-cpe]. 104 The advantage of IPv4-over-IPv6 tunnel mechanisms is the transparency 105 to the IPv6 infrastructure: since IPv4 is actually only needed on the 106 end user side as well as beyond the tunnel concentrator, most parts 107 and functionalities of the ISP network can remain IPv6 only. 108 Therefore, operators can run an IPv6-only infrastructure instead of a 109 fully dual-stack network, as well as save the IPv4 address resource 110 from being assigned all over the network. 112 While different IPv4-over-IPv6 mechanisms are developed for different 113 application scenarios, the mechanism proposed in this document 114 focuses on providing full end-to-end transparency to the user-side. 115 Therefore, carrier-side address translation should be avoided and 116 public IPv4 addresses should be provisioned to end users. Further 117 more, full address is preferred to port-restricted address. With 118 full address provisioned, user-side address translation is not 119 necessarily needed either. This means minimal changes to the user 120 side: operating system could support the mechanism smoothly, while 121 transparency on upper-layer applications is guaranteed. For many 122 ISPs which are actually capable of provisioning full IPv4 addresses, 123 the mechanism provide a pure, suitable solution. 125 Another focus of this mechanism is deployment and operation 126 flexibility. This mechanism keeps IPv4-IPv6 addressing independent: 127 end user IPv4 address is not embedded in its IPv6 address. The IPv6 128 infrastructure in the middle is not involved with the IPv4-over-IPv6 129 mechanism, so no special network planning is required; the service 130 can be provided in on-demand style; the IPv4 address resources can be 131 managed in a flat, centralized manner rather than distributed to 132 customer sites with IPv6. The tradeoff is per-subscriber binding 133 state maintenance on the border relay. 135 The mechanism follows hub and spokes softwire model, and uses IPv4- 136 over-IPv6 tunnel between end host or CPE and border relay as basic 137 data plane method. Full IPv4 addresses are allocated from the ISP to 138 the end host or CPE over IPv6 network. Simultaneously, the binding 139 between the allocated IPv4 address and the end user's IPv6 address 140 are maintained on the border relay for encapsulation usage. 142 2. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 3. Terminology 150 Public 4over6: Public 4over6 is a per-subscriber stateful, IPv4-over- 151 IPv6 tunnel mechanism proposed by this document. Public 4over6 152 supports bidirectional communication between IPv4 Internet and IPv4 153 hosts or customer networks in IPv6 access network, by leveraging 154 IPv4-in-IPv6 tunnel and public IPv4 address allocation over IPv6. 156 4over6 Customer Edge (CE): A device functioning as a Customer Edge 157 equipment in Public 4over6 environment. The 4over6 CE can be either 158 a dual-stack capable host, or a dual-stack CPE device, both have a 159 tunnel interface to support IPv4-in-IPv6 encapsulation. In the 160 former case, the host supports both IPv4 and IPv6 stack but is 161 provisioned with IPv6 only. In the latter case, the CPE has an IPv6 162 interface connecting to ISP network, and an IPv4 or dual-stack 163 interface connecting to customer network; hosts in the customer 164 network can be IPv4-only or dual-stack. 166 4over6 Border Relay (BR): A router functioning as the border relay in 167 Public 4over6 environment. 4over6 BR is the IPv4-in-IPv6 tunnel 168 concentrator located in IPv6 ISP network. It is a dual-stack router 169 which connects to both the IPv6 ISP network and IPv4 Internet. The 170 4over6 BR also works as a DHCPv4 over IPv6 171 [I-D.ietf-dhc-dhcpv4-over-ipv6] server/relay for assigning public 172 IPv4 address to 4over6 CEs. 174 4. Scenario and Use Cases 176 The general scenario of Public 4over6 is shown in Figure 1. Users in 177 an IPv6 network take IPv6 as their native service. Some users are 178 end hosts which face the ISP network directly, while the others are 179 customer LAN networks behind CPEs, such as a home LAN, an enterprise 180 network, etc. The ISP network is IPv6-only rather than dual-stack, 181 which means the ISP cannot provide native IPv4 service to users. 182 However, it is acceptable that some router(s) on the carrier side 183 becomes dual-stack and connects to IPv4 Internet. So if network 184 users require IPv4 connectivity, the dual-stack router(s) will work 185 as their "entrance". 187 +-------------------------+ 188 | IPv6 ISP Network | 189 +------+ | 190 |4over6|Host | 191 | CE |=================+-------+ +-----------+ 192 +------+ |4over6 | | IPv4 | 193 +---------+ | IPv4-in-IPv6 | BR |---| Internet | 194 |Customer | +------+ | | | | 195 |IPv4 LAN |--|4over6|=================+-------+ +-----------+ 196 | Network | | CE |CPE | 197 +---------+ +------+ | 198 | | 199 +-------------------------+ 201 Figure 1 Public 4over6 scenario 203 Public 4over6 can be applicable in several use cases. If an ISP 204 which switches to IPv6 still has plenty of IPv4 address resource, it 205 can deploy Public 4over6 to provide transparent IPv4 service for all 206 its customers. If the ISP does not have so much IPv4 addresses, it 207 can deploy Dual-Stack Lite [RFC6333] as the basic IPv4-over-IPv6 208 service. Along with DS-Lite, Public 4over6 can be deployed as a 209 value-added service, overcoming the service degradation caused by the 210 CGN. The two mechanisms can be integrated, because the IPv4-in-IPv6 211 tunnel functions are the same; the difference is that DS-Lite employs 212 a CGN while Public 4over6 employs an IPv4 provisioning process. A 213 typical case of the high-end users that could use Public 4over6 is 214 IPv4 application server. Full, public IPv4 address brings 215 significant convenience in this case, which is important to IPv6 216 transition for ICPs. The DNS registration can be direct using 217 dedicated address; the access of the application service can be 218 straightforward, with no translation involved; there will be no need 219 to hold the "pinhole" for incoming traffic, and no well-known port 220 collision will come up. 222 5. Public 4over6 Address Provisioning 224 5.1. Basic Provisioning Steps 226 The following figure shows the basic provisioning steps for Public 227 4over6. 229 4over6 DHCPv6 4over6 DHCPv4 230 CE Server BR Server 231 |Assign IPv6 Addr/Pref +| | | 232 | BR's IPv6 Addr Info | | | 233 |<----------------------| | | 234 | DHCPv6/Other | | | 235 WAN | | 236 IPv6 Configure | | 237 | | | 238 | Assign Public IPv4 Addr(DHCPv4-over-v6/Static Conf) | 239 |<-------------------------------------|<-------------| 240 | | IPv4-IPv6 | 241 | | Binding SYN | 242 Tunnel | 243 IPv4 Configure Binding Update 244 | | 245 | IPv4-in-IPv6 Tunnel | 246 |<------------------------------------>| 247 | | 249 Figure 2 Public 4over6 Address Provisioning 251 The main steps are: 253 o Provision IPv6 address/prefix to 4over6 CE, along with the 254 information of 4over6 BR's IPv6 address, by DHCPv6 or other means. 256 o 4over6 CE configures its WAN interface with globally unique IPv6 257 address which is a result of IPv6 provisioning, including DHCPv6, 258 SLAAC or manual configuration. 260 o Provision IPv4 address to 4over6 CE, by DHCPv4 over IPv6 or static 261 configuration. 263 o Synchronize the IPv4-IPv6 address binding between DHCPv4 server 264 and 4over6 BR, simultaneously with DHCPv4 provisioning. 266 o 4over6 CE configures its tunnel interface, as a result of IPv4 267 provisioning. 269 o 4over6 BR updates the IPv4-IPv6 address binding table, as a result 270 of address binding synchronization. 272 5.2. Public IPv4 Address Allocation 274 Usually each CE is provisioned with one public IPv4 address. However 275 it is possible that a CE would require an IPv4 prefix. The key 276 problem here is the mechanism for IPv4 address provisioning over IPv6 277 network. 279 There are two possibilities here: DHCPv4 over IPv6, and static 280 configuration. Public 4over6 MUST support both. DHCPv4 over IPv6 281 enables DHCPv4 message to be transported in IPv6 rather than IPv4; 282 therefore, the DHCPv4 process can be performed over an IPv6 network, 283 between BR and CE. [I-D.ietf-dhc-dhcpv4-over-ipv6] describes the 284 DHCP protocol extensions to support that. As to static 285 configuration, 4over6 users and the ISP operators MUST negotiate 286 beforehand to authorize the IPv4 address(es). Then the tunnel 287 interface and the address binding are configured by the user and the 288 ISP respectively. 290 While regular users would probably take DHCPv4 over IPv6, the manual 291 configuration is usually seen in two cases: application server, which 292 requires a stable IPv4 address, and enterprise network, which usually 293 requires an IPv4 prefix rather than one single address (Note that 294 DHCPv4 does not support prefix allocation). 296 6. 4over6 CE Behavior 298 A CE MUST be provisioned with IPv6 before Public 4over6. It MUST 299 also learn the BR's IPv6 address. This IPv6 address can be 300 configured using a variety of methods, ranging from an out-of-band 301 mechanism, manual configuration, or DHCPv6 option. In order to 302 guarantee interoperability, the CE element SHOULD implement the AFTR- 303 Name DHCPv6 option defined in [RFC6334]. 305 A CE MUST support DHCPv4 over IPv6[I-D.ietf-dhc-dhcpv4-over-ipv6], to 306 dynamically require IPv4 address over IPv6 and assign it to the IPv4- 307 in-IPv6 tunnel interface. The CE considers the BR as DHCPv4-over- 308 IPv6 server/relay for public IPv4 address allocation, whose IPv6 309 address is learned by the CE as described above. 311 A CE MUST also support static configuration of the tunnel interface. 312 In the case of prefix provisioning, Well-Known IPv4 Address defined 313 in section 5.7 of [RFC6333] SHOULD be assigned to the tunnel 314 interface, rather than using an address from the prefix. If the CE 315 has multiple IPv6 addresses on its WAN interface, it MUST use the 316 same IPv6 address for DHCPv4 over IPv6/negotiation of manual 317 configuration, and for data plane encapsulation. 319 A CE performs IPv4-in-IPv6 encapsulation and decapsulation on the 320 tunnel interface. When sending out an IPv4 packet, it performs the 321 encapsulation, using the IPv6 address of the 4over6 BR as the IPv6 322 destination address, and its own IPv6 address as the IPv6 source 323 address. The decapsulation on 4over6 CE is simple. When receiving 324 an IPv4-in-IPv6 packet, the CE just removes the IPv6 header, and 325 either hands it to upper layer or forward it to customer network 326 according to the IPv4 destination address. 328 A CE runs a regular IPv4 NAPT for its customer network when it is 329 provisioned with one single IPv4 address. In that case, the assigned 330 IPv4 address of the tunnel interface would be the external IPv4 331 address of the NAPT. Then the CE performs IPv4 private-to-public 332 translation before encapsulation of IPv4 packets from the customer 333 network, and IPv4 public-to-private translation after decapsulation 334 of IPv4-in-IPv6 packets. 336 IPv4 NAPT is not necessarily when the CE is provisioned with an IPv4 337 prefix. In this case, the detailed customer network planning is out 338 of scope. 340 4over6 CE supports backward compatibility with DS-Lite. A CE MAY 341 employ Well-Known IPv4 Address for B4 [RFC6333] and switch to Dual- 342 Stack Lite for IPv4 communications, if it can't get a public IPv4 343 address from the DHCPv4 server (maybe because the DHCPv4 over IPv6 344 process fails or the DHCPv4 server refuses to allocate a public IPv4 345 address to it, etc.). 347 7. 4over6 BR Behavior 349 4over6 BR maintains the bindings between the CE IPv6 address and CE 350 IPv4 address (prefixes). The bindings are used to provide correct 351 encapsulation destination address for inbound IPv4 packets, as well 352 as validate the IPv6-IPv4 source of the outbound IPv4-in-IPv6 353 packets. 355 The BR MUST synchronize the binding information with the IPv4 address 356 provisioning process. For static configuration, the BR configures 357 the binding right after negotiation with the customer. As for 358 DHCPv4-over-IPv6, there are multiple possibilities which are 359 deployment-specific: 361 o The BR can be collocated with the DHCPv4-over-IPv6 server. Then 362 the synchronization happens within the BR. It installs a binding 363 when send out an ACK for a DHCP lease, and delete it when the 364 lease expires or a DHCP RELEASE is received. 366 o The BR can play the role of TRA as described in 367 [I-D.ietf-dhc-dhcpv4-over-ipv6], and snoop for the DHCPv4 ACK and 368 Release messages, as well as keep a timer for each binding 369 according to the DHCP lease time. 371 On the IPv6 side, the BR decapsulates IPv4-in-IPv6 packets coming 372 from 4over6 CEs. It removes the IPv6 header of every IPv4-in-IPv6 373 packet and forwards it to the IPv4 Internet. Before the 374 decapsulation, the BR MUST check the inner IPv4 source address 375 against the outer IPv6 source address, by matching such a binding 376 entry in the binding table. If no binding is found, the BR silently 377 drops the packet. On the IPv4 side, the BR encapsulates the IPv4 378 packets destined to 4over6 CEs. When performing the IPv4-in-IPv6 379 encapsulation, the BR uses its own IPv6 address as the IPv6 source 380 address, uses the IPv4 destination address in the packet to look up 381 IPv6 destination address in the address binding table. After the 382 encapsulation, the BR sends the IPv6 packet on its IPv6 interface to 383 reach a CE. 385 The BR MUST support hairpinning of traffic between two CEs, by 386 performing de-capsulation and re-encapsulation of packets. 388 8. Fragmentation and reassembly 390 The same considerations as described in section 5.3 and section 6.3 391 of [RFC6333] are to be taken into account. 393 9. DNS 395 The procedure described in Section 5.5 and Section 6.4 of [RFC6333] 396 is to be followed. 398 10. Security Considerations 400 The 4over6 BR SHOULD implement methods to limit service only to 401 registered customers. The first step is to allocate IPv4 addresses 402 only to registered customers. One simple solution is to filter on 403 the IPv6 source addresses of incoming DHCP packets and only respond 404 to the ones which have registered IPv6 source address. The BR can 405 also perform authentication during DHCP, for example, based on the 406 MAC address of the CEs. As to data packets, the BR can implement an 407 IPv6 ingress filter on the tunnel interface to accept only the IPv6 408 address range defined in the filter, as well as check the IPv4-IPv6 409 source address binding by looking up the binding table. 411 11. Change Log from the -03 Version 413 1. Change the Intended Status to Informational. 415 2. Specify the feature of Public 4over6 and circumstances requiring 416 the mechanism in Abstract. 418 3. Explain the motivation of IPv4-over-IPv6 for Public 4over6 in 419 section 1. 421 4. Explain the relationship between Public 4over6 and Unified CPE, 422 as well as the purpose of this doc. 424 5. Clarify that customer network behind the 4over6 CE could be IPv4- 425 only or dual-stack in section 3. 427 6. Explain how to integrate Public 4over6 and DS-lite as a typical 428 use case in section 4 and section 5. 430 7. Clarify that IPv6 address/prefix can both be supported by 4over6 431 CEs in section 5. 433 8. Improve the preciseness of the texts. 435 9. Remove the text that describes the BR not participating the 436 DHCPv4-over-IPv6 process. 438 10. Updating the references. 440 12. Author List 442 The following are extended authors who contribute to the effort: 444 Huiling Zhao 445 China Telecom 446 Room 502, No.118, Xizhimennei Street 447 Beijing 100035 448 P.R.China 450 Phone: +86-10-58552002 451 Email: zhaohl@ctbri.com.cn 453 Chongfeng Xie 454 China Telecom 455 Room 708, No.118, Xizhimennei Street 456 Beijing 100035 457 P.R.China 459 Phone: +86-10-58552116 460 Email: xiechf@ctbri.com.cn 462 Qiong Sun 463 China Telecom 464 Room 708, No.118, Xizhimennei Street 465 Beijing 100035 466 P.R.China 468 Phone: +86-10-58552936 469 Email: sunqiong@ctbri.com.cn 471 Qi Sun 472 Tsinghua University 473 Beijing 100084 474 P.R.China 476 Phone: +86-10-62785822 477 Email: sunqi@csnet1.cs.tsinghua.edu.cn 479 Chris Metz 480 Cisco Systems 481 3700 Cisco Way 482 San Jose, CA 95134 483 USA 485 Email: chmetz@cisco.com 487 13. References 489 13.1. Normative References 491 [RFC2119] Bradner, S., "Key words for use in 492 RFCs to Indicate Requirement 493 Levels", BCP 14, RFC 2119, 494 March 1997. 496 [RFC4925] Li, X., Dawkins, S., Ward, D., and 497 A. Durand, "Softwire Problem 498 Statement", RFC 4925, July 2007. 500 [RFC4966] Aoun, C. and E. Davies, "Reasons to 501 Move the Network Address Translator 502 - Protocol Translator (NAT-PT) to 503 Historic Status", RFC 4966, 504 July 2007. 506 [RFC5549] Le Faucheur, F. and E. Rosen, 507 "Advertising IPv4 Network Layer 508 Reachability Information with an 509 IPv6 Next Hop", RFC 5549, May 2009. 511 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. 512 Rosen, "Softwire Mesh Framework", 513 RFC 5565, June 2009. 515 [RFC6333] Durand, A., Droms, R., Woodyatt, J., 516 and Y. Lee, "Dual-Stack Lite 517 Broadband Deployments Following IPv4 518 Exhaustion", RFC 6333, August 2011. 520 [RFC6334] Hankins, D. and T. Mrugalski, 521 "Dynamic Host Configuration Protocol 522 for IPv6 (DHCPv6) Option for Dual- 523 Stack Lite", RFC 6334, August 2011. 525 13.2. Informative References 527 [I-D.bfmk-softwire-unified-cpe] Boucadair, M. and I. Farrer, 528 "Unified IPv4-in-IPv6 Softwire CPE", 529 draft-bfmk-softwire-unified-cpe-02 530 (work in progress), January 2013. 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-05 535 (work in progress), September 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 547 Jianping Wu 548 Tsinghua University 549 Department of Computer Science, Tsinghua University 550 Beijing 100084 551 P.R.China 553 Phone: +86-10-6278-5983 554 EMail: jianping@cernet.edu.cn 556 Peng Wu 557 Tsinghua University 558 Department of Computer Science, Tsinghua University 559 Beijing 100084 560 P.R.China 562 Phone: +86-10-6278-5822 563 EMail: pengwu.thu@gmail.com 565 Olivier Vautrin 566 Juniper Networks 567 1194 N Mathilda Avenue 568 Sunnyvale, CA 94089 569 USA 571 EMail: Olivier@juniper.net 573 Yiu L. Lee 574 Comcast 575 One Comcast Center 576 Philadelphia, PA 19103 577 USA 579 EMail: yiu_lee@cable.comcast.com