idnits 2.17.1 draft-ietf-softwire-public-4over6-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 29, 2013) is 3922 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-06 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-01 Summary: 0 errors (**), 0 flaws (~~), 3 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: January 30, 2014 Tsinghua University 6 O. Vautrin 7 Juniper Networks 8 Y. Lee 9 Comcast 10 July 29, 2013 12 Public IPv4 over IPv6 Access Network 13 draft-ietf-softwire-public-4over6-10 15 Abstract 17 This document describes a mechanism called Public 4over6 which is 18 designed to provide IPv4 Internet connectivity over an IPv6 access 19 network using global IPv4 addresses. Public 4over6 was developed in 20 the IETF and is in use in some existing deployments, but is not 21 recommended for new deployments. Future deployments of similar 22 scenarios should use Lightweight 4over6. Public 4over6 follows the 23 Hub and Spoke softwire model, and uses an IPv4-in-IPv6 tunnel to 24 forward IPv4 packets over IPv6 access network. The bi-directionality 25 of the IPv4 communication is achieved by explicitly allocating global 26 non-shared IPv4 addresses to end users, as well as maintaining IPv4- 27 IPv6 address binding on the border relay. Public 4over6 aims to 28 provide uninterrupted IPv4 services to users, like Internet Content 29 Providers, etc., while an operator makes the transition of the access 30 network to an IPv6-only access network. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 30, 2014. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Scenario and Use Cases . . . . . . . . . . . . . . . . . . . . 5 69 4. Public 4over6 Address Provisioning . . . . . . . . . . . . . . 6 70 4.1. Basic Provisioning Steps . . . . . . . . . . . . . . . . . 6 71 4.2. Public IPv4 Address Allocation . . . . . . . . . . . . . . 7 72 5. 4over6 CE Behavior . . . . . . . . . . . . . . . . . . . . . . 7 73 6. 4over6 BR Behavior . . . . . . . . . . . . . . . . . . . . . . 8 74 7. Fragmentation and reassembly . . . . . . . . . . . . . . . . . 9 75 8. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 11. Change Log from the -09 Version (RFC Editors please remove 79 this part) . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 83 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 When operators make the transition of their access networks to IPv6- 88 only, they must continue to provide IPv4 services to their users to 89 access IPv4 contents. IPv4 connectivity is required when 90 communicating with the IPv4-only Internet. This document describes a 91 mechanism called Public 4over6 for providing IPv4 connectivity over a 92 native IPv6-only access network. This memo focuses on interactions 93 between Public 4over6 elements, as well as the deployment 94 architecture. 96 Public 4over6 is in active deployment in some environments, 97 particularly in China Next Generation Internet (CNGI) and China 98 Education and Research Network 2 (CERNET2), but is not recommended 99 for new deployments. Documenting this approach is to benefit users 100 and operators of existing deployments, as well as readers of other 101 IPv4-over-IPv6 documents. 103 In addition to Public 4over6 and its deployment architecture 104 described in this memo, the IETF is currently working on a more 105 generic solution called Lightweight 4over6 106 [I-D.ietf-softwire-lw4over6] that is classified as the binding 107 approach in the Unified IPv4-in-IPv6 Softwire CPE 108 [I-D.ietf-softwire-unified-cpe]. Lightweight 4over6 covers both 109 sharing and non-sharing global IPv4 address in Hub-and-Spoke model. 110 Future deployments should use [I-D.ietf-softwire-lw4over6]. 112 Public 4over6 utilizes the IPv4-in-IPv6 tunnel technique defined in 113 [RFC2473], which enables IPv4 datagrams to traverse through native 114 IPv6 network. IPv4 nodes connect to the Tunnel Entry-Point Node and 115 Tunnel Exit-Point Node to communicate over the IPv6-only network. 116 Therefore, the Internet Service Providers (ISPs) can run an IPv6-only 117 infrastructure instead of a fully dual-stack network, as well as 118 avoiding the need to deploy scarce IPv4 address resources throughout 119 the network. 121 This mechanism focuses on providing full end-to-end transparency to 122 the user-side. Therefore, global IPv4 addresses are expected to be 123 provisioned to end users and carrier-side address translation can be 124 avoided. Furthermore, global non-shared IPv4 address is preferred to 125 shared IPv4 address so that user-side address translation is not 126 necessary either. It is important in particular to users which 127 require to run their applications on IP protocol different from TCP 128 and UDP (e.g., IPSec, L2TP) or on certain well-known TCP/UDP ports 129 (e.g., http, smtp). For many ISPs that are actually capable of 130 provisioning non-shared unique IPv4 addresses, the mechanism provide 131 a pure, suitable solution. 133 Another focus of this mechanism is deployment and operational 134 flexibility. Public 4over6 allows IPv4 and IPv6 address architecture 135 to be totally independent of each other: the end user's IPv4 address 136 is not embedded in its IPv6 address. Therefore, the IPv4 address 137 planning has no implication to the IPv6 address planning. Operators 138 can manage the IPv4 address resources in a flat, centralized manner. 139 This requires the tunnel concentrator [RFC4925] to maintain the 140 binding of IPv4 address and IPv6 address, i.e. maintaining per- 141 subscriber binding state. 143 The mechanism follows the Hub and Spoke softwire model [RFC4925], and 144 uses IPv4-in-IPv6 tunneling as the basic data plane method. Global 145 non-shared IPv4 addresses are allocated from the ISP to end hosts or 146 CPEs over IPv6 network. Simultaneously, the binding between the 147 allocated IPv4 address and the end user's IPv6 address is maintained 148 on the tunnel concentrator for encapsulation usage. 150 2. Terminology 152 Public 4over6: Public 4over6 is a per-subscriber stateful, IPv4-in- 153 IPv6 tunnel mechanism. Public 4over6 supports bidirectional 154 communication between the global IPv4 Internet and IPv4 hosts or 155 customer networks via an IPv6 access network, by leveraging IPv4-in- 156 IPv6 tunneling [RFC2473] and global IPv4 address allocation over 157 IPv6. The term 'public' means the allocated IPv4 address is globally 158 routable. 160 Full IPv4 address: An IPv4 address that is not shared by multiple 161 users. The user with this IPv4 address has full access of all the 162 available ports including the Well-Known ports. 164 4over6 Customer Edge (CE): A device functioning as a Customer Edge 165 equipment in Public 4over6 environment. A 4over6 CE can be either a 166 dual-stack capable host, or a dual-stack CPE device, both of which 167 have a tunnel interface to support IPv4-in-IPv6 encapsulation. In 168 the former case, the host supports both IPv4 and IPv6 stacks but its 169 uplink is IPv6 only. In the latter case, the CPE has an IPv6 170 interface connecting to the ISP network, and an IPv4 or dual-stack 171 interface connecting to the customer network; hosts in the customer 172 network can be IPv4-only or dual-stack. 174 4over6 Border Relay (BR): A router deployed in the edge of the 175 operator's IPv6 access network which supports IPv4-in-IPv6 tunnel 176 termination. A 4over6 BR is a dual-stack router which connects to 177 both the IPv6 access network and the IPv4 Internet. The 4over6 BR 178 can also work as a DHCPv4-over-IPv6 [I-D.ietf-dhc-dhcpv4-over-ipv6] 179 server/relay for assigning and distributing global IPv4 addresses to 180 4over6 CEs. 182 3. Scenario and Use Cases 184 The general scenario of Public 4over6 is shown in Figure 1. Users in 185 an IPv6 network take IPv6 as their native service. Some users are 186 end hosts which face the ISP network directly, while the others are 187 in private networks behind CPEs, such as a home Local Area Network 188 (LAN), an enterprise network, etc. The ISP network is IPv6-only 189 rather than dual-stack, which means the ISP cannot provide native 190 IPv4 service to users. In order to support legacy IPv4 transport, 191 some routers on the carrier side are dual-stack and are connected to 192 the IPv4 Internet. These routers act as 4over6 Border Relays. 193 Network users that require IPv4 connectivity obtain it through these 194 routers. 196 +-------------------------+ 197 | IPv6 ISP Network | 198 | | 199 +------+ | 200 |4over6|Host +-------+ +-----------+ 201 | CE |=================| | | | 202 +------+ | | | | 203 | |4over6 | | IPv4 | 204 +--------------+ +------+ IPv4-in-IPv6 | BR |---| Internet | 205 | Customer | |4over6| | | | | 206 | Private IPv4 |--| CE |=================| | | | 207 | Network | | |CPE +-------+ +-----------+ 208 +--------------+ +------+ | 209 | | 210 | | 211 +-------------------------+ 213 Figure 1 Public 4over6 scenario 215 Public 4over6 can be applicable in several use cases. If an ISP that 216 switches to IPv6 still has plenty of global IPv4 address resource, it 217 can deploy Public 4over6 to provide transparent IPv4 service for all 218 its customers. If the ISP does not have enough IPv4 addresses, it 219 can deploy Dual-Stack Lite [RFC6333] as the basic IPv4-over-IPv6 220 service. Along with Dual-Stack Lite, Public 4over6 can be deployed 221 as a value-added service, overcoming the service degradation caused 222 by the Carrier Grade NAT (CGN). An IPv4 application server is a 223 typical high-end user of Public 4over6. Using a full, global IPv4 224 address brings significant advantages in this case, which is 225 important for Internet Content Providers (ICPs) to make the 226 transition to IPv6: 228 o The DNS registration can be direct using dedicated address; 230 o Access of the application service can be straightforward, with no 231 translation involved; 233 o There will be no need to provide NAT traversal mechanisms for 234 incoming traffic, and no special handling is required for the 235 Well-Known ports. 237 4. Public 4over6 Address Provisioning 239 4.1. Basic Provisioning Steps 241 The following figure shows the basic provisioning steps for Public 242 4over6. 244 4over6 DHCPv6 4over6 DHCPv4 245 CE Server BR Server 246 |Assign IPv6 Addr/Pref +| | | 247 | BR's IPv6 Addr Info | | | 248 |<----------------------| | | 249 | DHCPv6/Other | | | 250 WAN | | 251 IPv6 Configure | | 252 | | | 253 | Assign Public IPv4 Addr(DHCPv4-over-v6/Static Conf) | 254 |<-------------------------------------|<-------------| 255 | | IPv4-IPv6 | 256 | | Binding SYN | 257 Tunnel | 258 IPv4 Configure Binding Update 259 | | 260 | IPv4-in-IPv6 Tunnel | 261 |<------------------------------------>| 262 | | 264 Figure 2 Public 4over6 Address Provisioning 266 The main steps are: 268 o Provision IPv6 address/prefix to 4over6 CE, along with knowledge 269 of 4over6 BR's IPv6 address, using DHCPv6 or other means. 271 o 4over6 CE configures its WAN interface with globally unique IPv6 272 address which is a result of IPv6 provisioning, including DHCPv6, 273 SLAAC or manual configuration. 275 o Provision IPv4 address to 4over6 CE, by DHCPv4 over IPv6 or static 276 configuration. 278 o 4over6 BR obtains the IPv4 and IPv6 addresses of the 4over6 CE 279 using information provided by the DHCPv4 sever. 281 o 4over6 CE configures its tunnel interface, as a result of IPv4 282 provisioning. 284 o 4over6 BR updates the IPv4-IPv6 address binding table, as a result 285 of address binding information acquired from the DHCPv4 server. 287 4.2. Public IPv4 Address Allocation 289 Usually each CE is provisioned with one global IPv4 address. However 290 it is possible that a CE would require an IPv4 prefix. The key 291 problem here is the mechanism for IPv4 address provisioning over IPv6 292 network. 294 There are two possibilities: DHCPv4 over IPv6, and static 295 configuration. Public 4over6 supports both these methods. DHCPv4 296 over IPv6 allows DHCPv4 message to be transported in IPv6 rather than 297 IPv4; therefore, the DHCPv4 process can be performed over an IPv6 298 network, between the BR and the relevant CE. 299 [I-D.ietf-dhc-dhcpv4-over-ipv6] describes the DHCP protocol 300 extensions needed to support this operation. For static 301 configuration, 4over6 users and the ISP operators negotiate 302 beforehand to authorize the IPv4 address(es). Then the tunnel 303 interface and the address binding are configured by the user and the 304 ISP respectively. 306 While regular users would probably opt for DHCPv4 over IPv6, the 307 static configuration is particularly applicable in two cases: for 308 application servers, which require a stable IPv4 address, and for 309 enterprise networks, which usually require an IPv4 prefix rather than 310 one single address (Note that DHCPv4 does not support prefix 311 allocation). 313 5. 4over6 CE Behavior 315 A CE is provisioned with IPv6 before Public 4over6 process. It also 316 learns the BR's IPv6 address beforehand. This IPv6 address can be 317 configured using a variety of methods, ranging from an out-of-band 318 mechanism, manual configuration, or via a DHCPv6 option. In order to 319 guarantee interoperability, the CE element implements the AFTR-Name 320 DHCPv6 option defined in [RFC6334]. 322 A CE supports DHCPv4 over IPv6 [I-D.ietf-dhc-dhcpv4-over-ipv6], to 323 dynamically acquire an IPv4 address over IPv6 and assign it to the 324 IPv4-in-IPv6 tunnel interface. The CE regards the BR as its DHCPv4- 325 over-IPv6 server/relay, which is used to obtain its global IPv4 326 address allocation; its IPv6 address is learned by the CE as 327 described above. 329 A CE also supports static configuration of the tunnel interface. In 330 the case of prefix provisioning, the tunnel interface is assigned 331 with the Well-Known IPv4 Address defined in section 5.7 of [RFC6333], 332 rather than using an address from the prefix. If the CE has multiple 333 IPv6 addresses on its WAN interface, it uses the same IPv6 address 334 for DHCPv4-over-IPv6/negotiation of manual configuration, and for 335 data plane encapsulation. 337 A CE performs IPv4-in-IPv6 encapsulation and decapsulation on the 338 tunnel interface. When sending out an IPv4 packet, it performs the 339 encapsulation, using the IPv6 address of the 4over6 BR as the IPv6 340 destination address, and its own IPv6 address as the IPv6 source 341 address. The decapsulation on the 4over6 CE is simple. When 342 receiving an IPv4-in-IPv6 packet, the CE just removes the IPv6 343 header, and either hands it to a local upper layer or forwards it to 344 the customer network according to the IPv4 destination address. 346 A CE runs a regular IPv4 Network Address and Port Translation (NAPT) 347 for its customer network when it is provisioned with one single IPv4 348 address. In that case, the assigned IPv4 address of the tunnel 349 interface would be the external IPv4 address of the NAPT. Then the 350 CE performs IPv4 private-to-public translation before encapsulation 351 of IPv4 packets from the customer network, and IPv4 public-to-private 352 translation after decapsulation of IPv4-in-IPv6 packets. 354 IPv4 NAPT is not necessary when the CE is provisioned with an IPv4 355 prefix. In this case, the detailed customer network planning is out 356 of scope. 358 The 4over6 CE supports backward compatibility with DS-Lite. A CE can 359 employ the Well-Known IPv4 Address for Basic Bridging BroadBand (B4) 360 element [RFC6333] and switch to Dual-Stack Lite for IPv4 361 communications, if it can't get a global IPv4 address from the DHCPv4 362 server (for instance, if the DHCPv4-over-IPv6 process fails or the 363 DHCPv4 server refuses to allocate a global IPv4 address to it, etc.). 365 6. 4over6 BR Behavior 367 The 4over6 BR maintains the bindings between the CE IPv6 address and 368 CE IPv4 address (prefixes). The bindings are used to provide the 369 correct encapsulation destination address for inbound IPv4 packets, 370 as well as validating the IPv6-IPv4 source of the outbound IPv4-in- 371 IPv6 packets. 373 The BR acquires the binding information through the IPv4 address 374 provisioning process. For static configuration, the operator 375 manually configures the BR using the binding information obtained 376 through negotiation with the customer. As for DHCPv4-over-IPv6, 377 there are multiple possibilities which are deployment-specific: 379 o The BR can be co-located with the DHCPv4-over-IPv6 server. Then 380 the synchronization happens within the BR. It installs a binding 381 when sending out an ACK for a DHCP lease, and deletes it when the 382 lease expires or a DHCP RELEASE message is received. 384 o The BR can play the role of IPv6-Transport Relay Agent (TRA) as 385 described in [I-D.ietf-dhc-dhcpv4-over-ipv6], and snoop for the 386 DHCPv4 ACK and RELEASE messages, as well as keep a timer for each 387 binding according to the DHCP lease time. 389 On the IPv6 side, the BR decapsulates IPv4-in-IPv6 packets coming 390 from 4over6 CEs. It removes the IPv6 header of every IPv4-in-IPv6 391 packet and forwards it to the IPv4 Internet. Before the 392 decapsulation, the BR checks the inner IPv4 source address against 393 the outer IPv6 source address, by matching such a binding entry in 394 the binding table. If no binding is found, the BR silently drops the 395 packet. On the IPv4 side, the BR encapsulates the IPv4 packets 396 destined to 4over6 CEs. When performing the IPv4-in-IPv6 397 encapsulation, the BR uses its own IPv6 address as the IPv6 source 398 address, uses the IPv4 destination address in the packet to look up 399 IPv6 destination address in the address binding table. After the 400 encapsulation, the BR sends the IPv6 packet on its IPv6 interface to 401 reach a CE. 403 The BR supports hairpinning of traffic between two CEs, by performing 404 de-capsulation and re-encapsulation of packets. 406 In the case that the BR manages the global IPv4 address pool, it 407 advertises the routing information of IPv4 addresses to the IPv4 408 Internet. 410 7. Fragmentation and reassembly 412 The same considerations as described in section 5.3 and section 6.3 413 of [RFC6333] are taken into account for the CE and the BR 414 respectively. 416 8. DNS 417 The procedure described in Section 5.5 and Section 6.4 of [RFC6333] 418 is followed by the CE and the BR respectively. 420 9. IANA Considerations 422 This document has no IANA actions. 424 10. Security Considerations 426 The 4over6 BR implements methods to limit service only to registered 427 customers. On the control plane, the BR allocates IPv4 addresses 428 only to registered customers. The BR can filter on the IPv6 source 429 addresses of incoming DHCP requests and only respond to the ones that 430 are conveyed by registered IPv6 source addresses. But this doesn't 431 work in situations where multi-homing is present. In the networks 432 that Public 4over6 is deployed, multi-homing is disallowed to avoid 433 this issue. 435 Alternatively, the BR can filter out the unregistered CEs' requests 436 during the DHCP process. For data packets, the BR does the ingress 437 filtering by looking up the IPv4-IPv6 address binding table for the 438 related matches as described in Section 6. 440 In the case of fallback to DS-Lite, security considerations in 441 Section 11 of [RFC6333] is followed. 443 11. Change Log from the -09 Version (RFC Editors please remove this 444 part) 446 1. Update the Abstract and the Introduction to specify the purpose 447 of the doc. 449 2. Add the definition of 'Full IPv4 Address' in the Terminology. 451 3. Update the definition of '4over6 Border Relay' in the 452 Terminology. 454 4. Replace 'public IPv4 address' with 'global IPv4 address' to 455 consistent with RFC1918. 457 5. Polish the text in the Introduction to make it more RFC 458 compliant. 460 6. Update the Security Considerations to make it more accurate. And 461 add the reference to RFC6333 in the case of fallback to DS-Lite. 463 7. Correct some nits. 465 8. Update the references. 467 12. Contributors 469 The following are those who have made contributions to the effort: 471 Huiling Zhao 472 China Telecom 473 Room 502, No.118, Xizhimennei Street 474 Beijing 100035 475 P.R.China 477 Phone: +86-10-58552002 478 Email: zhaohl@ctbri.com.cn 480 Chongfeng Xie 481 China Telecom 482 Room 708, No.118, Xizhimennei Street 483 Beijing 100035 484 P.R.China 486 Phone: +86-10-58552116 487 Email: xiechf@ctbri.com.cn 489 Qiong Sun 490 China Telecom 491 Room 708, No.118, Xizhimennei Street 492 Beijing 100035 493 P.R.China 495 Phone: +86-10-58552936 496 Email: sunqiong@ctbri.com.cn 498 Qi Sun 499 Tsinghua University 500 Beijing 100084 501 P.R.China 503 Phone: +86-10-62785822 504 Email: sunqi@csnet1.cs.tsinghua.edu.cn 505 Chris Metz 506 Cisco Systems 507 3700 Cisco Way 508 San Jose, CA 95134 509 USA 511 Email: chmetz@cisco.com 513 13. References 515 13.1. Normative References 517 [RFC2473] Conta, A. and S. Deering, "Generic 518 Packet Tunneling in IPv6 519 Specification", RFC 2473, 520 December 1998. 522 [RFC4925] Li, X., Dawkins, S., Ward, D., and 523 A. Durand, "Softwire Problem 524 Statement", RFC 4925, July 2007. 526 [RFC6333] Durand, A., Droms, R., Woodyatt, J., 527 and Y. Lee, "Dual-Stack Lite 528 Broadband Deployments Following IPv4 529 Exhaustion", RFC 6333, August 2011. 531 [RFC6334] Hankins, D. and T. Mrugalski, 532 "Dynamic Host Configuration Protocol 533 for IPv6 (DHCPv6) Option for Dual- 534 Stack Lite", RFC 6334, August 2011. 536 13.2. Informative References 538 [I-D.ietf-dhc-dhcpv4-over-ipv6] Cui, Y., Wu, P., Wu, J., and T. 539 Lemon, "DHCPv4 over IPv6 Transport", 540 draft-ietf-dhc-dhcpv4-over-ipv6-06 541 (work in progress), March 2013. 543 [I-D.ietf-softwire-lw4over6] Cui, Y., Sun, Q., Boucadair, M., 544 Tsou, T., Lee, Y., and I. Farrer, 545 "Lightweight 4over6: An Extension to 546 the DS-Lite Architecture", 547 draft-ietf-softwire-lw4over6-01 548 (work in progress), July 2013. 550 [I-D.ietf-softwire-unified-cpe] Boucadair, M., Farrer, I., 551 Perreault, S., and S. Sivakumar, 552 "Unified IPv4-in-IPv6 Softwire CPE", 553 (work in progress), May 2013. 555 Authors' Addresses 557 Yong Cui 558 Tsinghua University 559 Department of Computer Science, Tsinghua University 560 Beijing 100084 561 P.R.China 563 Phone: +86-10-6260-3059 564 EMail: yong@csnet1.cs.tsinghua.edu.cn 566 Jianping Wu 567 Tsinghua University 568 Department of Computer Science, Tsinghua University 569 Beijing 100084 570 P.R.China 572 Phone: +86-10-6278-5983 573 EMail: jianping@cernet.edu.cn 575 Peng Wu 576 Tsinghua University 577 Department of Computer Science, Tsinghua University 578 Beijing 100084 579 P.R.China 581 Phone: +86-10-6278-5822 582 EMail: pengwu.thu@gmail.com 584 Olivier Vautrin 585 Juniper Networks 586 1194 N Mathilda Avenue 587 Sunnyvale, CA 94089 588 USA 590 EMail: Olivier@juniper.net 592 Yiu L. Lee 593 Comcast 594 One Comcast Center 595 Philadelphia, PA 19103 596 USA 598 EMail: yiu_lee@cable.comcast.com