idnits 2.17.1 draft-ietf-softwire-public-4over6-08.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 (May 2, 2013) is 4012 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4925' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC4966' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'RFC5549' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RFC5565' is defined on line 509, 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-06 Summary: 1 error (**), 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: November 3, 2013 Tsinghua University 6 O. Vautrin 7 Juniper Networks 8 Y. Lee 9 Comcast 10 May 2, 2013 12 Public IPv4 over IPv6 Access Network 13 draft-ietf-softwire-public-4over6-08 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 November 3, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Scenario and Use Cases . . . . . . . . . . . . . . . . . . . . 4 66 4. Public 4over6 Address Provisioning . . . . . . . . . . . . . . 5 67 4.1. Basic Provisioning Steps . . . . . . . . . . . . . . . . . 6 68 4.2. Public IPv4 Address Allocation . . . . . . . . . . . . . . 7 69 5. 4over6 CE Behavior . . . . . . . . . . . . . . . . . . . . . . 7 70 6. 4over6 BR Behavior . . . . . . . . . . . . . . . . . . . . . . 8 71 7. Fragmentation and reassembly . . . . . . . . . . . . . . . . . 9 72 8. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 11. Change Log from the -03 Version (RFC Editors please remove 76 this part) . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 12. Author List . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 80 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 When deploying IPv6 networks, IPv4 connectivity is still a 85 functionality required by end users. It is used for IPv4 86 communication with IPv4-only part of the Internet during the IPv4- 87 IPv6 transition period. IPv4-over-IPv6 tunnel mechanisms are the 88 general solutions to provide this type of IPv4 services. 90 This document describes a mechanism for providing IPv4 connectivity 91 in this situation. The mechanism is similar to the Binding approach 92 of the Unified IPv4-in-IPv6 Softwire CPE effort that is documented in 93 [I-D.bfmk-softwire-unified-cpe] Section 2. Although the 94 functionality documented in the standard is similar, this document 95 describes existing practice that differs from the standard, but that 96 has been deployed in China Next Generation Internet (CNGI) - China 97 Education and Research Network 2 (CERNET2). 99 The purpose of this draft is to document the protocol that was 100 deployed, both for historical purposes and for the benefit of users 101 of that protocol in the field at the time of publication. Future 102 deployments with similar requirements should simply use the related 103 mechanism in [I-D.bfmk-softwire-unified-cpe]. 105 The advantage of IPv4-over-IPv6 tunnel mechanisms is the transparency 106 to the IPv6 infrastructure: since IPv4 is actually only needed on the 107 end user side as well as beyond the tunnel concentrator, most parts 108 and functionalities of the ISP network can remain IPv6 only. 109 Therefore, operators can run an IPv6-only infrastructure instead of a 110 fully dual-stack network, as well as save the IPv4 address resource 111 from being assigned all over the network. 113 While different IPv4-over-IPv6 mechanisms are developed for different 114 application scenarios, the mechanism proposed in this document 115 focuses on providing full end-to-end transparency to the user-side. 116 Therefore, public IPv4 addresses are expected to be provisioned to 117 end users and carrier-side address translation can be avoided. 118 Further more, full address is preferred to port-restricted address. 119 With full address provisioned, user-side address translation is not 120 necessarily needed either. This means minimal changes to the user 121 side: operating system could support the mechanism smoothly, while 122 transparency on upper-layer applications is guaranteed. For many 123 ISPs which are actually capable of provisioning full IPv4 addresses, 124 the mechanism provide a pure, suitable solution. 126 Another focus of this mechanism is deployment and operation 127 flexibility. This mechanism allows IPv4 addressing and IPv6 128 addressing schemes to be independent of each other: end user IPv4 129 address is not embedded in its IPv6 address. The IPv6 infrastructure 130 in the middle is not involved with the IPv4-over-IPv6 mechanism, so 131 no special network planning is required; the service can be provided 132 in on-demand style; the IPv4 address resources can be managed in a 133 flat, centralized manner rather than distributed to customer sites 134 with IPv6. The tradeoff is per-subscriber binding state maintenance 135 on the border relay. 137 The mechanism follows hub and spokes softwire model, and uses IPv4- 138 over-IPv6 tunnel between end host or CPE and border relay as basic 139 data plane method. Full IPv4 addresses are allocated from the ISP to 140 the end host or CPE over IPv6 network. Simultaneously, the binding 141 between the allocated IPv4 address and the end user's IPv6 address 142 are maintained on the border relay for encapsulation usage. 144 2. Terminology 146 Public 4over6: Public 4over6 is a per-subscriber stateful, IPv4-over- 147 IPv6 tunnel mechanism proposed by this document. Public 4over6 148 supports bidirectional communication between IPv4 Internet and IPv4 149 hosts or customer networks in IPv6 access network, by leveraging 150 IPv4-in-IPv6 tunnel and public IPv4 address allocation over IPv6. 152 4over6 Customer Edge (CE): A device functioning as a Customer Edge 153 equipment in Public 4over6 environment. The 4over6 CE can be either 154 a dual-stack capable host, or a dual-stack CPE device, both of which 155 have a tunnel interface to support IPv4-in-IPv6 encapsulation. In 156 the former case, the host supports both IPv4 and IPv6 stack but is 157 provisioned with IPv6 only. In the latter case, the CPE has an IPv6 158 interface connecting to ISP network, and an IPv4 or dual-stack 159 interface connecting to customer network; hosts in the customer 160 network can be IPv4-only or dual-stack. 162 4over6 Border Relay (BR): A router functioning as the border relay in 163 Public 4over6 environment. 4over6 BR is the IPv4-in-IPv6 tunnel 164 concentrator located in IPv6 ISP network. It is a dual-stack router 165 which connects to both the IPv6 ISP network and IPv4 Internet. The 166 4over6 BR also works as a DHCPv4 over IPv6 167 [I-D.ietf-dhc-dhcpv4-over-ipv6] server/relay for assigning public 168 IPv4 address to 4over6 CEs. 170 3. Scenario and Use Cases 172 The general scenario of Public 4over6 is shown in Figure 1. Users in 173 an IPv6 network take IPv6 as their native service. Some users are 174 end hosts which face the ISP network directly, while the others are 175 customer LAN networks behind CPEs, such as a home LAN, an enterprise 176 network, etc. The ISP network is IPv6-only rather than dual-stack, 177 which means the ISP cannot provide native IPv4 service to users. 179 However, it is acceptable that some router(s) on the carrier side 180 becomes dual-stack and connects to IPv4 Internet. So if network 181 users require IPv4 connectivity, the dual-stack router(s) will work 182 as their "entrance". 184 +-------------------------+ 185 | IPv6 ISP Network | 186 +------+ | 187 |4over6|Host | 188 | CE |=================+-------+ +-----------+ 189 +------+ |4over6 | | IPv4 | 190 +---------+ | IPv4-in-IPv6 | BR |---| Internet | 191 |Customer | +------+ | | | | 192 |IPv4 LAN |--|4over6|=================+-------+ +-----------+ 193 | Network | | CE |CPE | 194 +---------+ +------+ | 195 | | 196 +-------------------------+ 198 Figure 1 Public 4over6 scenario 200 Public 4over6 can be applicable in several use cases. If an ISP 201 which switches to IPv6 still has plenty of IPv4 address resource, it 202 can deploy Public 4over6 to provide transparent IPv4 service for all 203 its customers. If the ISP does not have so much IPv4 addresses, it 204 can deploy Dual-Stack Lite [RFC6333] as the basic IPv4-over-IPv6 205 service. Along with DS-Lite, Public 4over6 can be deployed as a 206 value-added service, overcoming the service degradation caused by the 207 CGN. The two mechanisms can be integrated, because the IPv4-in-IPv6 208 tunnel functions are the same; the difference is that DS-Lite employs 209 a CGN while Public 4over6 employs an IPv4 provisioning process. A 210 typical case of the high-end users that could use Public 4over6 is 211 IPv4 application server. Full, public IPv4 address brings 212 significant convenience in this case, which is important to IPv6 213 transition for ICPs. The DNS registration can be direct using 214 dedicated address; the access of the application service can be 215 straightforward, with no translation involved; there will be no need 216 to hold the "pinhole" for incoming traffic, and no well-known port 217 collision will come up. 219 4. Public 4over6 Address Provisioning 221 4.1. Basic Provisioning Steps 222 The following figure shows the basic provisioning steps for Public 223 4over6. 225 4over6 DHCPv6 4over6 DHCPv4 226 CE Server BR Server 227 |Assign IPv6 Addr/Pref +| | | 228 | BR's IPv6 Addr Info | | | 229 |<----------------------| | | 230 | DHCPv6/Other | | | 231 WAN | | 232 IPv6 Configure | | 233 | | | 234 | Assign Public IPv4 Addr(DHCPv4-over-v6/Static Conf) | 235 |<-------------------------------------|<-------------| 236 | | IPv4-IPv6 | 237 | | Binding SYN | 238 Tunnel | 239 IPv4 Configure Binding Update 240 | | 241 | IPv4-in-IPv6 Tunnel | 242 |<------------------------------------>| 243 | | 245 Figure 2 Public 4over6 Address Provisioning 247 The main steps are: 249 o Provision IPv6 address/prefix to 4over6 CE, along with the 250 information of 4over6 BR's IPv6 address, by DHCPv6 or other means. 252 o 4over6 CE configures its WAN interface with globally unique IPv6 253 address which is a result of IPv6 provisioning, including DHCPv6, 254 SLAAC or manual configuration. 256 o Provision IPv4 address to 4over6 CE, by DHCPv4 over IPv6 or static 257 configuration. 259 o Synchronize the IPv4-IPv6 address binding between DHCPv4 server 260 and 4over6 BR, simultaneously with DHCPv4 provisioning. 262 o 4over6 CE configures its tunnel interface, as a result of IPv4 263 provisioning. 265 o 4over6 BR updates the IPv4-IPv6 address binding table, as a result 266 of address binding synchronization. 268 4.2. Public IPv4 Address Allocation 270 Usually each CE is provisioned with one public IPv4 address. However 271 it is possible that a CE would require an IPv4 prefix. The key 272 problem here is the mechanism for IPv4 address provisioning over IPv6 273 network. 275 There are two possibilities: DHCPv4 over IPv6, and static 276 configuration. Public 4over6 supports both these methods. DHCPv4 277 over IPv6 enables DHCPv4 message to be transported in IPv6 rather 278 than IPv4; therefore, the DHCPv4 process can be performed over an 279 IPv6 network, between BR and CE. [I-D.ietf-dhc-dhcpv4-over-ipv6] 280 describes the DHCP protocol extensions to support that. As to static 281 configuration, 4over6 users and the ISP operators negotiate 282 beforehand to authorize the IPv4 address(es). Then the tunnel 283 interface and the address binding are configured by the user and the 284 ISP respectively. 286 While regular users would probably take DHCPv4 over IPv6, the manual 287 configuration is usually seen in two cases: application server, which 288 requires a stable IPv4 address, and enterprise network, which usually 289 requires an IPv4 prefix rather than one single address (Note that 290 DHCPv4 does not support prefix allocation). 292 5. 4over6 CE Behavior 294 A CE is provisioned with IPv6 before Public 4over6. It also learns 295 the BR's IPv6 address beforehand. This IPv6 address can be 296 configured using a variety of methods, ranging from an out-of-band 297 mechanism, manual configuration, or DHCPv6 option. In order to 298 guarantee interoperability, the CE element implements the AFTR-Name 299 DHCPv6 option defined in [RFC6334]. 301 A CE supports DHCPv4 over IPv6[I-D.ietf-dhc-dhcpv4-over-ipv6], to 302 dynamically acquire IPv4 address over IPv6 and assign it to the IPv4- 303 in-IPv6 tunnel interface. The CE regards the BR as DHCPv4-over-IPv6 304 server/relay for public IPv4 address allocation, whose IPv6 address 305 is learned by the CE as described above. 307 A CE also supports static configuration of the tunnel interface. In 308 the case of prefix provisioning, the tunnel interface is assigned 309 with the Well-Known IPv4 Address defined in section 5.7 of [RFC6333], 310 rather than using an address from the prefix. If the CE has multiple 311 IPv6 addresses on its WAN interface, it uses the same IPv6 address 312 for DHCPv4 over IPv6/negotiation of manual configuration, and for 313 data plane encapsulation. 315 A CE performs IPv4-in-IPv6 encapsulation and decapsulation on the 316 tunnel interface. When sending out an IPv4 packet, it performs the 317 encapsulation, using the IPv6 address of the 4over6 BR as the IPv6 318 destination address, and its own IPv6 address as the IPv6 source 319 address. The decapsulation on 4over6 CE is simple. When receiving 320 an IPv4-in-IPv6 packet, the CE just removes the IPv6 header, and 321 either hands it to upper layer or forward it to customer network 322 according to the IPv4 destination address. 324 A CE runs a regular IPv4 NAPT for its customer network when it is 325 provisioned with one single IPv4 address. In that case, the assigned 326 IPv4 address of the tunnel interface would be the external IPv4 327 address of the NAPT. Then the CE performs IPv4 private-to-public 328 translation before encapsulation of IPv4 packets from the customer 329 network, and IPv4 public-to-private translation after decapsulation 330 of IPv4-in-IPv6 packets. 332 IPv4 NAPT is not necessarily when the CE is provisioned with an IPv4 333 prefix. In this case, the detailed customer network planning is out 334 of scope. 336 4over6 CE supports backward compatibility with DS-Lite. A CE can 337 employ Well-Known IPv4 Address for B4 [RFC6333] and switch to Dual- 338 Stack Lite for IPv4 communications, if it can't get a public IPv4 339 address from the DHCPv4 server (for instance, the DHCPv4 over IPv6 340 process fails or the DHCPv4 server refuses to allocate a public IPv4 341 address to it, etc.). 343 6. 4over6 BR Behavior 345 4over6 BR maintains the bindings between the CE IPv6 address and CE 346 IPv4 address (prefixes). The bindings are used to provide correct 347 encapsulation destination address for inbound IPv4 packets, as well 348 as validate the IPv6-IPv4 source of the outbound IPv4-in-IPv6 349 packets. 351 The BR is bound to synchronize the binding information with the IPv4 352 address provisioning process. For static configuration, the BR 353 configures the binding right after negotiation with the customer. As 354 for DHCPv4-over-IPv6, there are multiple possibilities which are 355 deployment-specific: 357 o The BR can be collocated with the DHCPv4-over-IPv6 server. Then 358 the synchronization happens within the BR. It installs a binding 359 when sending out an ACK for a DHCP lease, and delete it when the 360 lease expires or a DHCP RELEASE is received. 362 o The BR can play the role of TRA as described in 363 [I-D.ietf-dhc-dhcpv4-over-ipv6], and snoop for the DHCPv4 ACK and 364 Release messages, as well as keep a timer for each binding 365 according to the DHCP lease time. 367 On the IPv6 side, the BR decapsulates IPv4-in-IPv6 packets coming 368 from 4over6 CEs. It removes the IPv6 header of every IPv4-in-IPv6 369 packet and forwards it to the IPv4 Internet. Before the 370 decapsulation, the BR checks the inner IPv4 source address against 371 the outer IPv6 source address, by matching such a binding entry in 372 the binding table. If no binding is found, the BR silently drops the 373 packet. On the IPv4 side, the BR encapsulates the IPv4 packets 374 destined to 4over6 CEs. When performing the IPv4-in-IPv6 375 encapsulation, the BR uses its own IPv6 address as the IPv6 source 376 address, uses the IPv4 destination address in the packet to look up 377 IPv6 destination address in the address binding table. After the 378 encapsulation, the BR sends the IPv6 packet on its IPv6 interface to 379 reach a CE. 381 The BR supports hairpinning of traffic between two CEs, by performing 382 de-capsulation and re-encapsulation of packets. 384 7. Fragmentation and reassembly 386 The same considerations as described in section 5.3 and section 6.3 387 of [RFC6333] are taken into account. 389 8. DNS 391 The procedure described in Section 5.5 and Section 6.4 of [RFC6333] 392 is followed. 394 9. IANA Considerations 396 This document has no IANA actions. 398 10. Security Considerations 400 In some cases, the 4over6 BR is expected to implement methods to 401 limit service only to registered customers. One simple solution is 402 to make sure the BR allocates IPv4 addresses only to registered 403 customers, i.e. the BR can filter on the IPv6 source addresses of 404 incoming DHCP packets and only respond to the ones which have 405 registered IPv6 source address. The BR can also perform 406 authentication during DHCP, for example, based on the MAC address of 407 the CEs. As to data packets, the BR can implement an IPv6 ingress 408 filter on the tunnel interface to accept only the IPv6 address range 409 defined in the filter, as well as check the IPv4-IPv6 source address 410 binding by looking up the binding table. 412 11. Change Log from the -03 Version (RFC Editors please remove this 413 part) 415 1. Change the Intended Status to Informational, and reword some text 416 to not use RFC2119 language. 418 2. Specify the feature of Public 4over6 and circumstances requiring 419 the mechanism in Abstract. 421 3. Explain the motivation of IPv4-over-IPv6 for Public 4over6 in 422 section 1. 424 4. Explain the relationship between Public 4over6 and Unified CPE, 425 as well as the purpose of this doc. 427 5. Clarify that customer network behind the 4over6 CE could be IPv4- 428 only or dual-stack in section 3. 430 6. Explain how to integrate Public 4over6 and DS-lite as a typical 431 use case in section 4 and section 5. 433 7. Clarify that IPv6 address/prefix can both be supported by 4over6 434 CEs in section 5. 436 8. Improve the preciseness of the texts. 438 9. Remove the text that describes the BR not participating the 439 DHCPv4-over-IPv6 process. 441 10. Updating the references. 443 12. Author List 445 The following are extended authors who contribute to the effort: 447 Huiling Zhao 448 China Telecom 449 Room 502, No.118, Xizhimennei Street 450 Beijing 100035 451 P.R.China 453 Phone: +86-10-58552002 454 Email: zhaohl@ctbri.com.cn 456 Chongfeng Xie 457 China Telecom 458 Room 708, No.118, Xizhimennei Street 459 Beijing 100035 460 P.R.China 462 Phone: +86-10-58552116 463 Email: xiechf@ctbri.com.cn 465 Qiong Sun 466 China Telecom 467 Room 708, No.118, Xizhimennei Street 468 Beijing 100035 469 P.R.China 471 Phone: +86-10-58552936 472 Email: sunqiong@ctbri.com.cn 474 Qi Sun 475 Tsinghua University 476 Beijing 100084 477 P.R.China 479 Phone: +86-10-62785822 480 Email: sunqi@csnet1.cs.tsinghua.edu.cn 482 Chris Metz 483 Cisco Systems 484 3700 Cisco Way 485 San Jose, CA 95134 486 USA 488 Email: chmetz@cisco.com 490 13. References 492 13.1. Normative References 494 [RFC4925] Li, X., Dawkins, S., Ward, D., and 495 A. Durand, "Softwire Problem 496 Statement", RFC 4925, July 2007. 498 [RFC4966] Aoun, C. and E. Davies, "Reasons to 499 Move the Network Address Translator 500 - Protocol Translator (NAT-PT) to 501 Historic Status", RFC 4966, 502 July 2007. 504 [RFC5549] Le Faucheur, F. and E. Rosen, 505 "Advertising IPv4 Network Layer 506 Reachability Information with an 507 IPv6 Next Hop", RFC 5549, May 2009. 509 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. 510 Rosen, "Softwire Mesh Framework", 511 RFC 5565, June 2009. 513 [RFC6333] Durand, A., Droms, R., Woodyatt, J., 514 and Y. Lee, "Dual-Stack Lite 515 Broadband Deployments Following IPv4 516 Exhaustion", RFC 6333, August 2011. 518 [RFC6334] Hankins, D. and T. Mrugalski, 519 "Dynamic Host Configuration Protocol 520 for IPv6 (DHCPv6) Option for Dual- 521 Stack Lite", RFC 6334, August 2011. 523 13.2. Informative References 525 [I-D.bfmk-softwire-unified-cpe] Boucadair, M. and I. Farrer, 526 "Unified IPv4-in-IPv6 Softwire CPE", 527 draft-bfmk-softwire-unified-cpe-02 528 (work in progress), January 2013. 530 [I-D.ietf-dhc-dhcpv4-over-ipv6] Cui, Y., Wu, P., Wu, J., and T. 531 Lemon, "DHCPv4 over IPv6 Transport", 532 draft-ietf-dhc-dhcpv4-over-ipv6-06 533 (work in progress), March 2013. 535 Authors' Addresses 537 Yong Cui 538 Tsinghua University 539 Department of Computer Science, Tsinghua University 540 Beijing 100084 541 P.R.China 543 Phone: +86-10-6260-3059 544 EMail: yong@csnet1.cs.tsinghua.edu.cn 546 Jianping Wu 547 Tsinghua University 548 Department of Computer Science, Tsinghua University 549 Beijing 100084 550 P.R.China 552 Phone: +86-10-6278-5983 553 EMail: jianping@cernet.edu.cn 555 Peng Wu 556 Tsinghua University 557 Department of Computer Science, Tsinghua University 558 Beijing 100084 559 P.R.China 561 Phone: +86-10-6278-5822 562 EMail: pengwu.thu@gmail.com 564 Olivier Vautrin 565 Juniper Networks 566 1194 N Mathilda Avenue 567 Sunnyvale, CA 94089 568 USA 570 EMail: Olivier@juniper.net 572 Yiu L. Lee 573 Comcast 574 One Comcast Center 575 Philadelphia, PA 19103 576 USA 578 EMail: yiu_lee@cable.comcast.com