idnits 2.17.1 draft-wbeebee-v6ops-ipv6-cpe-router-bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 135: '..., the CPE router MUST support a DHCPv6...' RFC 2119 keyword, line 137: '... user MUST allocate an IA_PD or ULA ...' RFC 2119 keyword, line 139: '...ded. The CPE Router MAY support RIPng...' RFC 2119 keyword, line 157: '...n the CPE Router MUST support ND Proxy...' RFC 2119 keyword, line 175: '..., the CPE Router MUST support ND Proxy...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: It is possible that in future, IPv6 global unicast prefix can expand beyond its existing range. Therefore the CE Router MUST not have hard coded filters tied to only allow prefixes in a given range. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5294 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-softwire-hs-framework-l2tpv2' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC4214' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC5214' is defined on line 443, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-01 == Outdated reference: A later version (-16) exists of draft-ietf-v6ops-cpe-simple-security-08 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 4214 (Obsoleted by RFC 5214) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Singh 3 Internet-Draft W. Beebee 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: April 29, 2010 October 26, 2009 7 IPv6 Customer Edge Router Recommendations(bis) 8 draft-wbeebee-v6ops-ipv6-cpe-router-bis-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 29, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document continues the work undertaken by a earlier version of 57 this document that has been a IETF v6ops working Group document. The 58 Working Group preferred to expedite the IPv6 CE Router document with 59 basic technology requirements. Any leftover work is continued in 60 this document and considered as Phase two effort. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 66 3. Conceptual Configuration Variables . . . . . . . . . . . . . . 3 67 4. CPE Router Behavior in a routed network (MEDIUM) . . . . . . . 3 68 5. IPv6 Data Forwarding (CORE) . . . . . . . . . . . . . . . . . 4 69 5.1. IPv6 ND Proxy Behavior (MEDIUM) . . . . . . . . . . . . . 4 70 5.2. IPv6 Multicast Behavior (CORE) . . . . . . . . . . . . . . 5 71 6. Other IPv6 Features . . . . . . . . . . . . . . . . . . . . . 5 72 6.1. Path MTU Discovery Support (MEDIUM) . . . . . . . . . . . 5 73 6.2. Optional RIPng Support (CORE) . . . . . . . . . . . . . . 6 74 6.3. Firewall (DEV) . . . . . . . . . . . . . . . . . . . . . . 6 75 6.3.1. Packet Filters (DEV) . . . . . . . . . . . . . . . . . 6 76 6.4. Zero Configuration Support (MEDIUM) . . . . . . . . . . . 6 77 6.5. 6to4 Automated Tunneling (MEDIUM)/Dual-Stack Lite (DEV) . 6 78 6.6. DNS Support (DEV) . . . . . . . . . . . . . . . . . . . . 7 79 6.7. Quality Of Service(QoS) . . . . . . . . . . . . . . . . . 8 80 6.8. Multi-homed Host Support (MEDIUM) . . . . . . . . . . . . 8 81 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 87 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 This document continues the work undertaken by the IPv6 CE Router 93 work to incorporate technologies under development or any leftover 94 work from the Phase I Working Group document. 96 Technologies are labeled as: CORE (widely deployed in the field, many 97 years of operational experience, one or more standards-track RFC's 98 exist), MEDIUM (standards-track RFC exists, but is a recent 99 development and/or has limited deployments. Technologies under 100 DEVelopment (no standards-track RFC exists and/or has not yet been 101 deployed) have been moved to a bis(updates) version of this document. 103 2. Terminology and Abbreviations 105 mDNS - Multicast Domain Name System - see http://www.zeroconf.org. 107 3. Conceptual Configuration Variables 109 The CE Router maintains such a list of conceptual optional 110 configuration variables. 112 1. Enable RIPng on the LAN. 114 2. Softwire enable. 116 3. More Specifc Route ([RFC4191]) enable and configure routes. 118 4. If DHCPv6 fails, the CE Router may initiate PPPOE, L2TPv2 119 Softwire tunnel, or 6to4 [RFC3056] or 6rd 120 (draft-ietf-softwire-ipv6-6rd-01) operation. 122 5. Change ULA on the device. 124 4. CPE Router Behavior in a routed network (MEDIUM) 126 One example of the CPE Router use in the home is shown below. The 127 home has a broadband modem combined with a CPE Router, all in one 128 device. The LAN interface of the device is connected to another 129 standalone CPE Router that supports a wireless access point. To 130 support such a network, this document recommends using prefix sub- 131 delegation of the prefix obtained either via IA_PD from WAN interface 132 or a ULA from the LAN interface . The network interface of the 133 downstream router may obtain an IA_PD via stateful DHCPv6. If the 134 CPE router supports the routed network through automatic prefix sub- 135 delegation, the CPE router MUST support a DHCPv6 server or DHCPv6 136 relay agent. Further, if an IA_PD is used, the Service Provider or 137 user MUST allocate an IA_PD or ULA prefix short enough to be sub- 138 delegated and subsequently used for SLAAC. Therefore, a prefix 139 length shorter than /64 is needed. The CPE Router MAY support RIPng 140 in the home network. 142 /-------+------------\ /------------+-----\ 143 SP <--+ Modem | CPE Router +--+ CPE Router | WAP + --> PC 144 \-------+------------/ \------------+-----/ 146 WAP = Wireless Access Point 148 Figure 1. 150 5. IPv6 Data Forwarding (CORE) 152 5.1. IPv6 ND Proxy Behavior (MEDIUM) 154 If the CPE Router has only one /64 prefix to be used across multiple 155 LAN interfaces and the CPE Router supports any two LAN interfaces 156 that cannot bridge data between them because the two interfaces have 157 disparate MAC layers, then the CPE Router MUST support ND Proxy 158 [RFC4389]. If any two LAN interfaces support bridging between the 159 interfaces, then ND Proxy is not necessary between the two 160 interfaces. Legacy 3GPP networks have the following requirements: 162 1. No DHCPv6 prefix is delegated to the CPE Router. 164 2. Only one /64 is available on the WAN link. 166 3. The link types between the WAN interface and LAN interface(s) are 167 disparate and, therefore, can't be bridged. 169 4. No NAT66 is to be used. 171 5. Each LAN interface needs global connectivity. 173 6. Uses SLAAC to configure LAN interface addresses. 175 For these legacy 3GPP networks, the CPE Router MUST support ND Proxy 176 between the WAN and LAN interface(s). If a CPE Router will never be 177 deployed in an environment with these characteristics, then ND Proxy 178 is not necessary. 180 5.2. IPv6 Multicast Behavior (CORE) 182 The CPE Router SHOULD follow the model described for MLD Proxy in 183 [RFC4605] to implement multicast. The MLD Proxy model was chosen 184 because it is simpler to implement than more complicated multicast 185 routing functionality. 187 Querier Election rules as described in section 7.6.2 of [RFC3810] do 188 not apply to the CPE Router (even when the home has multiple cascaded 189 routers) since every CPE Router in the cascade is the only router in 190 its own multicast domain. Every CPE Router in the cascade will send 191 MLDv2 Reports with aggregated multicast Group Membership information 192 to the next upstream router. 194 If the CPE Router hardware includes a network bridge between the WAN 195 interface and the LAN interface(s), then the CPE Router MUST support 196 MLDv2 snooping as per [RFC4541]. 198 Consistent with [RFC4605], the CPE Router must not implement the 199 router portion of MLDv2 for the WAN interface. Likewise, the LAN 200 interfaces on the CPE router must not implement an MLDv2 Multicast 201 Listener. However, if a user at home wants to create a new multicast 202 group and send multicast data to other nodes on the Service Provider 203 network, then Protocol Independent Multicast-Source Specific 204 Multicast (PIM-SSM) [RFC3569] is recommended to handle multicast 205 traffic flowing in the upstream direction as a one-to-many multicast 206 flow. 208 6. Other IPv6 Features 210 6.1. Path MTU Discovery Support (MEDIUM) 212 GRE tunnels, such as IPv6 to IPv4 tunnels (which may be terminated on 213 the CPE Router), can modify the default Ethernet MTU of 1500 bytes. 214 Also, in the future, Ethernet Jumbo frames (> 1500 bytes) may also be 215 supported. Since the MTU can vary, a newly initiated TCP stream must 216 detect the largest packet that can be sent to the destination without 217 fragmentation. This can be detected using Path MTU Discovery 218 [RFC1981]. Routers which may encounter a packet too large to be 219 forwarded from source to destination may drop the packet and send an 220 ICMPv6 Packet Too Big message to the source. The CPE Router must 221 route back to the source any ICMPv6 Packet Too Big messages generated 222 anywhere on this path. Issues and solutions to problems with MTUs 223 and tunnels are described more fully in [RFC4459]. 225 6.2. Optional RIPng Support (CORE) 227 The CPE Router may support RIPng routing protocol [RFC2080] so that 228 RIPng operates between the CPE Router and the Service Provider 229 network. RIPng has scaling and security implications for the Service 230 Provider network where one Service Provider router may terminate 231 several tens of thousands of CPE routers. However, RIPng does 232 provide one solution from the CPE Router to the Service Provider 233 network for prefix route injection. 235 6.3. Firewall (DEV) 237 The CE Router must support an IPv6 Firewall feature. The firewall 238 may include features like access-control lists. The firewall may 239 support interpretation or recognition of most IPv6 extension header 240 information including inspecting fragmentation header. The firewall 241 must support stateful and stateless Packet Filters as follows. 243 6.3.1. Packet Filters (DEV) 245 The CE Router must support packet filtering based on IP headers, 246 extended headers, UDP and TCP ports etc. There are numerous filters 247 mentioned (section 3.2) in draft-ietf-v6ops-cpe-simple-security 248 [I-D.ietf-v6ops-cpe-simple-security], like some that allow IKE, IPSec 249 packets while another filter may block Teredo packets. 251 It is possible that in future, IPv6 global unicast prefix can expand 252 beyond its existing range. Therefore the CE Router MUST not have 253 hard coded filters tied to only allow prefixes in a given range. 255 6to4 or 6rd tunnels may be initiated by hosts behind the CE Router. 256 The CE Router MUST NOT block 6to4 or 6rd packets without a 257 configurable override. 259 6.4. Zero Configuration Support (MEDIUM) 261 The CE Router MAY support manual configuration via the web using a 262 URL string like http://router.local as per mDNS described in the 263 Terminology and Abbreviations section. Note that mDNS is a link- 264 local protocol, so extra functionality is required if configuration 265 is to be supported over cascaded routers. Support of configuration 266 through cascaded routers is beyond the scope of this document. 268 6.5. 6to4 Automated Tunneling (MEDIUM)/Dual-Stack Lite (DEV) 270 If the IPv4 address assigned to the WAN interface of the CE Router is 271 a non-[RFC1918] IPv4 address, and the CE Router fails to acquire an 272 IPv6 address before WAN_IP_ACQUIRE_TIMEOUT seconds after acquiring 273 the IPv4 address, then the 6to4 tunneling protocol [RFC3056] SHOULD 274 be enabled automatically, allowing tunneling of IPv6 packets over 275 IPv4 without requiring user configuration. If an anycast 6to4 server 276 cannot be located to establish IPv6 connectivity over the IPv4 277 network. If an IPv6 address is acquired, but no IPv4 address is 278 acquired before WAN_IP_ACQUIRE_TIMEOUT seconds after the IPv6 address 279 was acquired, then the CE Router SHOULD use DS-Lite and disable NAT44 280 in the CE Router. If both IPv6 and IPv4 addresses are acquired 281 within WAN_IP_ACQUIRE_TIMEOUT seconds of each other, then the CE 282 Router operates in dual stack mode, and does not need either 6to4 or 283 DS-Lite. If no IPv4 and no IPv6 address has been acquired, then the 284 CE Router retries acquisition. 286 6to4 can be useful in the scenario where the Service Provider does 287 not yet support IPv6, but devices in the home use IPv6. An IPv6 288 address is constructed automatically from the IPv4 address (V4ADDR) 289 configured on the interface using the prefix 2002:V4ADDR::/48. A 290 6to4 tunnel can be automatically created using a pre-configured 6to4 291 gateway end-point for the tunnel. 293 Several proposals are being considered by IETF related to the problem 294 of IPv4 address depletion, but have not yet achieved working group 295 consensus for publication as an RFC. Dual-stack lite ietf-softwire- 296 dual-stack-lite-00 [I-D.ietf-softwire-dual-stack-lite] requires the 297 CE Router to support features such as v4 in v6 encapsulation and 298 softwires. Further, any approach which requires the use of a tunnel 299 MUST take into account the reduced MTU. The tunnel software on the 300 CE Router MUST be capable of fragmenting data packets. 302 For DS-Lite, the CE Router also discovers the IPv6 address of the 303 Carrier Grade NAT node in the deployment. The ietf-softwire-dual- 304 stack-lite-00 [I-D.ietf-softwire-dual-stack-lite] draft has yet to 305 fully describe the method of discovery. 307 6.6. DNS Support (DEV) 309 For local DNS queries for configuration, the CE Router may include a 310 DNS server to handle local queries. Non-local queries can be 311 forwarded unchanged to a DNS server specified in the DNS server 312 DHCPv6 option. The CE Router may also include DNS64 functionality 313 which is specified in draft-bagnulo-behave-dns64 314 [I-D.bagnulo-behave-dns64]. The local DNS server MAY also handle 315 renumbering from the Service Provider provided prefix for local names 316 used exclusively inside the home (the local AAAA and PTR records are 317 updated). This capability provides connectivity using local DNS 318 names in the home after a Service Provider renumbering. A CE Router 319 MAY add local DNS entries based on dynamic requests from the LAN 320 segment(s). The protocol to carry such requests from hosts to the CE 321 Router is yet to be described. 323 6.7. Quality Of Service(QoS) 325 The CPE router MAY support differentiated services [RFC2474]. 327 6.8. Multi-homed Host Support (MEDIUM) 329 The CE Router MAY support [RFC4191] on its LAN interfaces. Small 330 consumer embedded multi-homed hosts in the home may not have 331 configurable routing tables. The CE Router can communicate More 332 Specific Routes (MSRs) to these hosts to allow them to choose a 333 preferred router to send traffic to for traffic destined to specific 334 prefixes configured through manual configuration. Advertisement of 335 MSRs through RAs is turned off by default. 337 7. Future Work 339 1. Enumerate requirements in list form (to be done after 340 requirements are solidified). 342 8. Security Considerations 344 Security considerations of a CE router are covered by 345 draft-ietf-v6ops-cpe-simple-security 346 [I-D.ietf-v6ops-cpe-simple-security]. 348 9. IANA Considerations 350 None. 352 10. Acknowledgements 354 Thanks (in alphabetical order) to Antonio Querubin, Barbara Stark, 355 Bernie Volz, Brian Carpenter, Carlos Pignataro, Dan Wing, David 356 Miles, Francois-Xavier Le Bail, Fred Baker, James Woodyatt, Mark 357 Townsley, Mikael Abrahamsson, Ole Troan, Remi Denis-Courmont, Shin 358 Miyakawa, Teemu Savolainen, Thomas Herbst, and Tony Hain for their 359 input on the document. 361 11. References 362 11.1. Normative References 364 11.2. Informative References 366 [I-D.bagnulo-behave-dns64] 367 Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and 368 M. Endo, "DNS64: DNS extensions for Network Address 369 Translation from IPv6 Clients to IPv4 Servers", 370 draft-bagnulo-behave-dns64-02 (work in progress), 371 March 2009. 373 [I-D.ietf-softwire-dual-stack-lite] 374 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 375 Y., and R. Bush, "Dual-stack lite broadband deployments 376 post IPv4 exhaustion", 377 draft-ietf-softwire-dual-stack-lite-01 (work in progress), 378 July 2009. 380 [I-D.ietf-softwire-hs-framework-l2tpv2] 381 Storer, B., Pignataro, C., Santos, M., Stevant, B., and J. 382 Tremblay, "Softwire Hub & Spoke Deployment Framework with 383 L2TPv2", draft-ietf-softwire-hs-framework-l2tpv2-13 (work 384 in progress), April 2009. 386 [I-D.ietf-v6ops-cpe-simple-security] 387 Woodyatt, J., "Recommended Simple Security Capabilities in 388 Customer Premises Equipment for Providing Residential 389 IPv6 Internet Service", 390 draft-ietf-v6ops-cpe-simple-security-08 (work in 391 progress), October 2009. 393 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 394 E. Lear, "Address Allocation for Private Internets", 395 BCP 5, RFC 1918, February 1996. 397 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 398 for IP version 6", RFC 1981, August 1996. 400 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 401 January 1997. 403 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 404 "Definition of the Differentiated Services Field (DS 405 Field) in the IPv4 and IPv6 Headers", RFC 2474, 406 December 1998. 408 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 409 via IPv4 Clouds", RFC 3056, February 2001. 411 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 412 Multicast (SSM)", RFC 3569, July 2003. 414 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 415 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 417 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 418 More-Specific Routes", RFC 4191, November 2005. 420 [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, 421 "Intra-Site Automatic Tunnel Addressing Protocol 422 (ISATAP)", RFC 4214, October 2005. 424 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 425 Proxies (ND Proxy)", RFC 4389, April 2006. 427 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 428 Network Tunneling", RFC 4459, April 2006. 430 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 431 "Considerations for Internet Group Management Protocol 432 (IGMP) and Multicast Listener Discovery (MLD) Snooping 433 Switches", RFC 4541, May 2006. 435 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 436 "Internet Group Management Protocol (IGMP) / Multicast 437 Listener Discovery (MLD)-Based Multicast Forwarding 438 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 440 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 441 Address Autoconfiguration", RFC 4862, September 2007. 443 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 444 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 445 March 2008. 447 Authors' Addresses 449 Hemant Singh 450 Cisco Systems, Inc. 451 1414 Massachusetts Ave. 452 Boxborough, MA 01719 453 USA 455 Phone: +1 978 936 1622 456 Email: shemant@cisco.com 457 URI: http://www.cisco.com/ 459 Wes Beebee 460 Cisco Systems, Inc. 461 1414 Massachusetts Ave. 462 Boxborough, MA 01719 463 USA 465 Phone: +1 978 936 2030 466 Email: wbeebee@cisco.com 467 URI: http://www.cisco.com/