idnits 2.17.1 draft-ietf-softwire-public-4over6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 11, 2012) is 4428 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 422, but no explicit reference was found in the text == Unused Reference: 'RFC4966' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'RFC5549' is defined on line 436, 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-00 Summary: 4 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: Standards Track P. Wu 5 Expires: September 12, 2012 Tsinghua University 6 C. Metz 7 Cisco Systems 8 O. Vautrin 9 Juniper Networks 10 Y. Lee 11 Comcast 12 March 11, 2012 14 Public IPv4 over IPv6 Access Network 15 draft-ietf-softwire-public-4over6-01 17 Abstract 19 When the service provider networks are upgraded to IPv6, IPv4 20 connectivity will still be demanded by network users, at least in the 21 recent future. This draft proposes a mechanism for end hosts or 22 networks in IPv6 access networks to build bidirectional IPv4 23 communication with the IPv4 Internet. The mechanism follows the 24 softwire hub and spoke model, and uses IPv4-over-IPv6 tunnel as basic 25 method to traverse IPv6 network. The bi-directionality of end-to-end 26 communication is achieved by allocating public IPv4 addresses to end 27 hosts/networks. This mechanism is an IPv4 access method for network 28 users in IPv6. 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 September 12, 2012. 47 Copyright Notice 48 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . 3 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Scenario and requirements . . . . . . . . . . . . . . . . 4 68 4.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 5 69 5. Public 4over6 Mechanism . . . . . . . . . . . . . . . . . . . 6 70 5.1. Address allocation and mapping maintenance . . . . . . . . 6 71 5.2. 4over6 initiator behavior . . . . . . . . . . . . . . . . 7 72 5.2.1. Host initiator . . . . . . . . . . . . . . . . . . . . 7 73 5.2.2. CPE initiator . . . . . . . . . . . . . . . . . . . . 8 74 5.3. 4over6 concentrator behavior . . . . . . . . . . . . . . . 8 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 78 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 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. This type of IPv4 services differ in 98 provisioned IPv4 addresses. If the operators cannot provision public 99 IPv4 addresses, the user side can only use private IPv4 addresses, 100 and NAT44 translation is required on the carrier side, as is 101 described in Dual-stack Lite[RFC6333]. Otherwise the operators are 102 capable of provisioning public IPv4 addresses. Then users can 103 directly employ these addresses for IPv4 communication, and carrier- 104 side translation won't be necessary. The network users and operators 105 can avoid all the issues raised by translation, such as ALG, NAT 106 traversal, session state maintenance, etc. 108 This "public IPv4" situation is actually quite common. From the 109 ISPs' perspective, many of them are still capable of providing IPv4 110 addresses in its network, or at least part of its network. From the 111 perspective of the Internet, the majority of the Internet users today 112 are still using public IPv4 addresses. Most of them will switch to 113 IPv6 sooner or later, and will require IPv4 services for a 114 significant long period after the switching. This draft focuses on 115 this public IPv4 situation, i.e., providing IPv4 access to users in 116 IPv6 networks under the condition that IPv4 address allocation is 117 still feasible. 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. Terminology 127 Public 4over6: Public 4over6 is the mechanism proposed by this draft. 129 Public 4over6 supports bidirectional communication between IPv4 130 Internet and IPv4 hosts or local networks in IPv6 access network, by 131 leveraging IPv4-in-IPv6 tunnel and public IPv4 address allocation. 133 4over6 initiator: in Public 4over6 mechanism, 4over6 initiator is the 134 IPv4-in-IPv6 tunnel initiator located on the user side of IPv6 135 network. The 4over6 initiator can be either a dual-stack capable 136 host, or a dual-stack CPE device. In the former case, the host has 137 both IPv4 and IPv6 stack but is provisioned with IPv6 access only. 138 In the latter case, the CPE has both IPv6 interface connecting to ISP 139 network, and IPv4 interface connecting to local network; hosts in the 140 local network can be IPv4-only. 142 4over6 concentrator: in Public 4over6 mechanism, 4over6 concentrator 143 is the IPv4-in-IPv6 tunnel concentrator located in IPv6 ISP network. 144 It's a dual-stack router which connects to both the IPv6 ISP network 145 and IPv4 Internet. 147 4. Deployment Scenario 149 4.1. Scenario and requirements 151 The general scenario of Public 4over6 is shown in Figure 1. Users in 152 an IPv6 network take IPv6 as their native service. Some users are 153 end hosts which face the ISP network directly, while the others are 154 local networks behind CPEs, such as a home LAN, an enterprise 155 network, etc. The ISP network is IPv6-only rather than dual-stack, 156 which means the ISP cannot provide native IPv4 service to users. 157 However, it's acceptable that some router(s) on the carrier side 158 becomes dual-stack and connects to IPv4 Internet. So if network 159 users require IPv4 connectivity, the dual-stack router(s) will work 160 as their "entrance". 162 +-------------------------+ 163 | IPv6 ISP Network | 164 +------+ | 165 |host: | | 166 |initi-| | 167 |ator |=================+-------+ +-----------+ 168 +------+ |4over6 | | IPv4 | 169 | IPv4-in-IPv6 |Concen-|---| Internet | 170 +----------+ +------+ |trator | | | 171 |local IPv4|--|CPE: |=================+-------+ +-----------+ 172 | network | |initi-| | 173 +----------+ |ator | | 174 +------+ | 175 | | 176 +-------------------------+ 178 Figure 1 Public 4over6 scenario 180 From end user perspective, 4over6 users require IPv4-to-IPv4 181 communication with the IPv4 Internet. An IPv4 access service is 182 needed rather than an IPv6-to-IPv4 translation service. Second, 183 public IPv4 addresses will be preferred by 4over6 users. With public 184 IPv4 address provisioning, IPv4 CGN is not required so end-to-end 185 transparency is preserved. For special users like application 186 servers, public address brings great convenience including 187 straightforward access, direct DNS registration, no stateful mapping 188 maintenance on CGN, etc. For the direct-connected host case, each 189 host should get one public IPv4 address. For the local IPv4 network 190 case, the CPE can get a public IPv4 address and runs an IPv4 NAT for 191 the local network. Here a local NAT is still much better than the 192 situation that involves a CGN, since this NAT is in local network and 193 can be configured and managed by the users. 195 From the operator perspective, the ISPs would like to keep their IPv4 196 and IPv6 addressing and routing separated when provisioning IPv4 over 197 IPv6. Then they can manage the native IPv6 networks more easily and 198 independently, and also provision IPv4 in a flexible, on-demand way. 199 The cost is for the concentrator to maintain per-user address mapping 200 state. As a result, double translation is not preferred. Unlike 201 stateless scenario, double translation in this scenario brings more 202 complexity to IPv6 network than tunnel. Therefore this draft follows 203 the hub and spoke softwire model. 205 4.2. Use cases 207 Public 4over6 can be applicable in several practical cases. The 208 first one is that ISPs which still have plenty of IPv4 address 209 resource switch to IPv6. As long as the amount of the remaining and 210 reclaimable IPv4 addresses can match the user amount, the ISPs can 211 deploy public 4over6 to preserve IPv4 service for the customers. 213 The second case is ISPs which don't have enough IPv4 addresses switch 214 to IPv6. For those ISPs, dual-stack lite is so far the most mature 215 solution to provision IPv4 over IPv6. In dual-stack lite, end users 216 use private IPv4 addresses, experience a 44CGN and some service 217 degradation. As long as the end users use public IPv4 addresses, all 218 CGN issues can be avoided and the IPv4 service can be full bi- 219 directional. In other words, Public 4over6 can be deployed along 220 with DS-lite, to provide a value-added service. Common users adopt 221 DS-lite while high-end users adopt Public 4over6. The two mechanisms 222 can actually get coupled easily. 224 There is also a special instance in the second case that the end 225 users are IPv4 application servers. In this circumstance, public 226 address brings significant convenience. The DNS registration can be 227 direct, with dedicated address; the application service access can be 228 straightforward with no translation involved for the clients; there's 229 no need to reserve and hold session state on the CGN, and no well- 230 known port collision will come up. So it's better to have servers 231 take Public 4over6 for IPv4 access when they're located in IPv6 232 network. 234 Following the principle of Public 4over6, it's also possible to 235 achieve address multiplexing between end users. 236 [I-D.cui-softwire-b4-translated-ds-lite] and [I-D.sun-v6ops-laft6] 237 shows the efforts on this. The basic idea is that, instead of 238 allocating a full IPv4 address to every end user, the ISP can 239 allocate a restricted port set within an IPv4 address to every end 240 user. 242 Besides, the document would like to be explicit about the direct- 243 connected host case and the CPE case. The host case is clear: the 244 host is directly connected to IPv6 network, but its protocol stacks 245 have IPv4 support as well. As to the CPE case, this document would 246 like to only focus on the situation that the local network behind the 247 CPE stays in private IPv4. If the local network want to run public 248 IPv4, then it can either run IPv6 as well and enable the hosts to 249 execute Public 4over6, or acquire address blocks from the ISP and 250 build configured tunnel or Softwire Mesh[RFC5565] with the ISP 251 network. The former solution is suitable for the home LAN situation 252 while the latter solution is suitable for the enterprise network 253 situation. 255 5. Public 4over6 Mechanism 257 5.1. Address allocation and mapping maintenance 259 Public 4over6 can be generally considered as IPv4-over-IPv6 hub and 260 spoke tunnel leveraging public IPv4 address. Each 4over6 initiator 261 uses public IPv4 address for IPv4-over-IPv6 communication. As is 262 described above, in the host initiator case, every host gets one IPv4 263 address; in the CPE case, every CPE gets one IPv4 address, which is 264 then shared by hosts behind the CPE. The key problem here is IPv4 265 address allocation over IPv6 network, from ISP device(s) to 4over6 266 initiators. 268 There're two possibilities here. One is DHCPv4 over IPv6, and the 269 other is static configuration. DHCPv4 over IPv6 enables DHCPv4 270 message to be transported in IPv6 packet instead of IPv4 packet, so 271 the address allocation can be achieved between 4over6 concentrator 272 and 4over6 initiators. [I-D.ietf-dhc-dhcpv4-over-ipv6] describes the 273 DHCP protocol format and behavior extensions to support that. As to 274 static configuration, 4over6 users and the ISP operators should 275 negotiate beforehand to authorize the IPv4 address. Application 276 servers can falls into this case. Public 4over6 supports both 277 address allocation manners. 279 Along with IPv4 address allocation, Public 4over6 should maintain the 280 IPv4-IPv6 address mappings on the concentrator. In this type of 281 address mapping, the IPv4 address is the public IPv4 address 282 allocated to a 4over6 initiator, and the IPv6 address is the 283 initiator's IPv6 address. This mapping is used to provide correct 284 encapsulation destination address for the concentrator. 286 If the address is allocated through static configuration, the 287 concentrator should install the mapping manually when assigning the 288 address, and delete the mapping manually when recycling the address. 289 Else the address is allocated by DHCPv4, the concentrator should 290 participate in the DHCP procedure, either run a DHCPv4 server to 291 dynamically allocate public addresses to 4over6 initiators, or 292 perform the DHCP relay functions and leave the actual address 293 allocation job to a dedicated DHCPv4 server located in IPv4. When 294 allocating an IPv4 address (to be more precise, when sending back a 295 DHCP ACK message to a 4over6 initiator), the concentrator should 296 install a mapping entry of the allocated IPv4 address and the 297 initiator's IPv6 address into the address mapping table. This entry 298 should be deleted when receiving a DHCP RELEASE of that IPv4 address, 299 or the lease of that IPv4 address expires. 301 5.2. 4over6 initiator behavior 303 4over6 initiator has an IPv6 interface connected to the IPv6 ISP 304 network, and a tunnel interface to support IPv4-in-IPv6 305 encapsulation. In CPE case, it has at least one IPv4 interface 306 connected to IPv4 local network. 308 4over6 initiator should learn the 4over6 concentrator's IPv6 address 309 beforehand. For example, if the initiator gets its IPv6 address by 310 DHCPv6, it can get the 4over6 concentrator's IPv6 address through a 311 DHCPv6 option[RFC6334]. 313 5.2.1. Host initiator 315 When the initiator is a direct-connected host, it assigns the 316 allocated public IPv4 address to its tunnel interface. The host uses 317 this address for IPv4 communication. If the host acquires this 318 address through DHCP, it should support DHCPv4 over IPv6. 320 For IPv4 data traffic, the host performs the IPv4-in-IPv6 321 encapsulation and decapsulation on the tunnel interface. When 322 sending out an IPv4 packet, it performs the encapsulation, using the 323 IPv6 address of the 4over6 concentrator as the IPv6 destination 324 address, and its own IPv6 address as the IPv6 source address. The 325 encapsulated packet will be forwarded to the IPv6 network. The 326 decapsulation on 4over6 initiator is simple. When receiving an IPv4- 327 in-IPv6 packet, the initiator just drops the IPv6 header, and hands 328 it to upper layer. 330 5.2.2. CPE initiator 332 The CPE case is quite similar to the host initiator case. The CPE 333 assigns the allocated IPv4 address to its tunnel interface. The CPE 334 should support DHCPv4 over IPv6 if it acquires this address through 335 DHCP. The local IPv4 network won't take part in the public IPv4 336 allocation; instead, end hosts will use private IPv4 addresses, 337 possibly allocated by the CPE. 339 On data plan, the CPE can be viewed as a regular IPv4 NAT(using 340 tunnel interface as the NAT outside interface) cascaded with a tunnel 341 initiator. For IPv4 data packets received from the local network, 342 the CPE translates these packets, using the tunnel interface address 343 as the source address, and then encapsulates the translated packet 344 into IPv6, using the concentrator's IPv6 address as the destination 345 address, the CPE's IPv6 address as source address. For IPv6 data 346 packet received from the IPv6 network, the CPE performs decapsulation 347 and IPv4 public-to-private translation. As to the CPE itself, it 348 uses the public, tunnel interface address to communicate with the 349 IPv4 Internet, and the private, IPv4 interface address to communicate 350 with the local network. 352 5.3. 4over6 concentrator behavior 354 4over6 concentrator represents the IPv4-IPv6 border router working as 355 the remote tunnel endpoint for 4over6 initiators, with its IPv6 356 interface connected to the IPv6 network, IPv4 interface connected to 357 the IPv4 Internet, and a tunnel interface supporting IPv4-in-IPv6 358 encapsulation and decapsulation. There is no CGN on the 4over6 359 concentrator, it won't perform any translation function; instead, 360 4over6 concentrator maintains an IPv4-IPv6 address mapping table for 361 IPv4 data encapsulation. 363 4over6 concentrator maintains the IPv4-IPv6 address mapping of 4over6 364 initiators. Besides manual configuration of address mappings, it 365 runs either a DHCP relay or a DHCP server which support DHCPv4 over 366 IPv6. When sending out a DHCP ACK, the concentrator resolves the 367 allocated IPv4 address and the IPv6 destination address, installs the 368 mapping entry into the mapping table or renews it if it already 369 exists. When the lifetime of a mapping entry/a lease of allocated 370 address expires, or when the concentrator receives a DHCP RELEASE of 371 allocated address, the concentrator deletes the corresponding mapping 372 entry from the table. The mapping entry is used to provide correct 373 encapsulation destination address for concentrator encapsulation. As 374 long as the entry exists in the table, the concentrator can 375 encapsulate inbound IPv4 packets destined to the initiator, with the 376 initiator's IPv6 address as IPv6 destination. 378 On the IPv6 side, 4over6 concentrator decapsulates IPv4-in-IPv6 379 packets coming from 4over6 initiators. It removes the IPv6 header of 380 every IPv4-in-IPv6 packet and forwards it to the IPv4 Internet. On 381 the IPv4 side, the concentrator encapsulates the IPv4 packets 382 destined to 4over6 initiators. When performing the IPv4-in-IPv6 383 encapsulation, the concentrator uses its own IPv6 address as the IPv6 384 source address, uses the IPv4 destination address in the packet to 385 look up IPv6 destination address in the address mapping table. After 386 the encapsulation, the concentrator sends the IPv6 packet on its IPv6 387 interface to reach an initiator. 389 The 4over6 concentrator, or its upstream router should advertise the 390 IPv4 prefix which contains the IPv4 addresses of 4over6 users to the 391 IPv4 side, in order to make these initiators reachable on IPv4 392 Internet. 394 Since the concentrator has to maintain the IPv4-IPv6 address mapping 395 table, the concentrator is stateful in IP level. Note that this 396 table will be much smaller than a CGN table, as there is no port 397 information involved. 399 6. Security Considerations 401 The 4over6 concentrator should support ways to limit service only to 402 registered customers. The first step is to allocate IPv4 addresses 403 only to registered customers. One simple solution is to filter on 404 the IPv6 source addresses of incoming DHCP packets and only respond 405 to the ones which have registered IPv6 source address. The 406 concentrator can also perform authentication during DHCP, for 407 example, based on the MAC address of the initiators. As to data 408 packets, the concentrator can implement an IPv6 ingress filter on the 409 tunnel interface to accept only the IPv6 address range defined in the 410 filter. 412 7. References 414 7.1. Normative References 416 [RFC2119] Bradner, S., "Key words for 417 use in RFCs to Indicate 418 Requirement Levels", 419 BCP 14, RFC 2119, 420 March 1997. 422 [RFC4925] Li, X., Dawkins, S., Ward, 423 D., and A. Durand, 424 "Softwire Problem 425 Statement", RFC 4925, 426 July 2007. 428 [RFC4966] Aoun, C. and E. Davies, 429 "Reasons to Move the 430 Network Address Translator 431 - Protocol Translator 432 (NAT-PT) to Historic 433 Status", RFC 4966, 434 July 2007. 436 [RFC5549] Le Faucheur, F. and E. 437 Rosen, "Advertising IPv4 438 Network Layer Reachability 439 Information with an IPv6 440 Next Hop", RFC 5549, 441 May 2009. 443 [RFC5565] Wu, J., Cui, Y., Metz, C., 444 and E. Rosen, "Softwire 445 Mesh Framework", RFC 5565, 446 June 2009. 448 [RFC6333] Durand, A., Droms, R., 449 Woodyatt, J., and Y. Lee, 450 "Dual-Stack Lite Broadband 451 Deployments Following IPv4 452 Exhaustion", RFC 6333, 453 August 2011. 455 [RFC6334] Hankins, D. and T. 456 Mrugalski, "Dynamic Host 457 Configuration Protocol for 458 IPv6 (DHCPv6) Option for 459 Dual-Stack Lite", RFC 6334, 460 August 2011. 462 7.2. Informative References 464 [I-D.cui-softwire-b4-translated-ds-lite] Boucadair, M., Sun, Q., 465 Tsou, T., Lee, Y., and Y. 467 Cui, "Lightweight 4over6: 468 An Extension to DS-Lite 469 Architecture", draft-cui- 470 softwire-b4-translated-ds- 471 lite-05 (work in progress), 472 February 2012. 474 [I-D.ietf-dhc-dhcpv4-over-ipv6] Lemon, T., Cui, Y., Wu, P., 475 and J. Wu, "DHCPv4 over 476 IPv6 Transport", draft- 477 ietf-dhc-dhcpv4-over-ipv6- 478 00 (work in progress), 479 November 2011. 481 [I-D.sun-v6ops-laft6] Sun, Q. and C. Xie, "LAFT6: 482 Lightweight address family 483 transition for IPv6", 484 draft-sun-v6ops-laft6-01 485 (work in progress), 486 March 2011. 488 Authors' Addresses 490 Yong Cui 491 Tsinghua University 492 Department of Computer Science, Tsinghua University 493 Beijing 100084 494 P.R.China 496 Phone: +86-10-6260-3059 497 EMail: yong@csnet1.cs.tsinghua.edu.cn 499 Jianping Wu 500 Tsinghua University 501 Department of Computer Science, Tsinghua University 502 Beijing 100084 503 P.R.China 505 Phone: +86-10-6278-5983 506 EMail: jianping@cernet.edu.cn 508 Peng Wu 509 Tsinghua University 510 Department of Computer Science, Tsinghua University 511 Beijing 100084 512 P.R.China 513 Phone: +86-10-6278-5822 514 EMail: pengwu.thu@gmail.com 516 Chris Metz 517 Cisco Systems 518 3700 Cisco Way 519 San Jose, CA 95134 520 USA 522 EMail: chmetz@cisco.com 524 Olivier Vautrin 525 Juniper Networks 526 1194 N Mathilda Avenue 527 Sunnyvale, CA 94089 528 USA 530 EMail: Olivier@juniper.net 532 Yiu L. Lee 533 Comcast 534 One Comcast Center 535 Philadelphia, PA 19103 536 USA 538 EMail: yiu_lee@cable.comcast.com