idnits 2.17.1 draft-ietf-ospf-prefix-hiding-07.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2328, updated by this document, for RFC5378 checks: 1997-11-05) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 17, 2012) is 4119 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group Y. Yang 3 Internet-Draft A. Retana 4 Updates: 2328, 5340 (if approved) A. Roy 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: June 20, 2013 December 17, 2012 8 Hiding Transit-only Networks in OSPF 9 11 Abstract 13 A transit-only network is defined as a network connecting routers 14 only. In OSPF, transit-only networks are usually configured with 15 routable IP addresses, which are advertised in Link State 16 Advertisements (LSAs) but not needed for data traffic. In addition, 17 remote attacks can be launched against routers by sending packets to 18 these transit-only networks. This document presents a mechanism to 19 hide transit-only networks to speed up network convergence and reduce 20 remote attack vulnerability. 22 In the context of this document, 'hiding' implies that the prefixes 23 are not installed in the routing tables on OSPF routers. In some 24 cases, IP addresses may still be visible when using OSPFv2. 26 This document updates RFC 2328 and RFC 5340. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 17, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 4 64 2. Hiding IPv4 Transit-only Networks in OSPFv2 . . . . . . . . . . 4 65 2.1. Point-to-Point Networks . . . . . . . . . . . . . . . . . . 4 66 2.1.1. Advertising Point-to-Point Networks . . . . . . . . . . 4 67 2.1.2. Hiding Point-to-Point Networks . . . . . . . . . . . . 5 68 2.2. Broadcast Networks . . . . . . . . . . . . . . . . . . . . 5 69 2.2.1. Advertising Broadcast Networks . . . . . . . . . . . . 6 70 2.2.2. Hiding Broadcast Networks . . . . . . . . . . . . . . . 6 71 2.2.2.1. Sending Network-LSA . . . . . . . . . . . . . . . . 6 72 2.2.2.2. Receiving Network-LSA . . . . . . . . . . . . . . . 7 73 2.2.2.2.1. Backward Compatibility . . . . . . . . . . . . 7 74 2.3. Non-Broadcast Networks . . . . . . . . . . . . . . . . . . 7 75 2.3.1. NBMA . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 2.3.2. Point-to-MultiPoint . . . . . . . . . . . . . . . . . . 8 77 2.3.2.1. Advertising Point-to-MultiPoint Networks . . . . . 9 78 2.3.2.2. Hiding Point-to-MultiPoint Networks . . . . . . . . 9 79 3. Hiding IPv6 Transit-only Networks in OSPFv3 . . . . . . . . . . 10 80 3.1. Hiding AF Enabled Transit-only Networks in OSPFv3 . . . . . 10 81 4. Operational Considerations . . . . . . . . . . . . . . . . . . 11 82 4.1. Forwarding Address . . . . . . . . . . . . . . . . . . . . 11 83 4.2. Virtual Links . . . . . . . . . . . . . . . . . . . . . . . 11 84 4.3. Unnumbered Interfaces . . . . . . . . . . . . . . . . . . . 12 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 87 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 13 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 A transit-only network is defined as a network connecting routers 96 only. In OSPF, transit-only networks are usually configured with 97 routable IP addresses, which are advertised in LSAs but not needed 98 for data traffic. In addition, remote attacks can be launched 99 against routers by sending packets to these transit-only networks. 100 This document presents a mechanism to hide transit-only networks to 101 speed up network convergence and reduce remote attack vulnerability. 103 Hiding transit-only networks will not impact reachability to the end 104 hosts. 106 In the context of this document, 'hiding' implies that the prefixes 107 are not installed in the routing tables on OSPF routers. In [OSPFv2], 108 the IPv4 interface addresses are still visible in the Router-Links- 109 LSA links and the Network-LSA Link-State ID (LSID). In [OSPFv3], the 110 Router-LSAs and Network-LSAs do not contain IPv6 addresses and are 111 not visible. 113 This document updates [OSPFv2] and [OSPFv3] by specifying a mechanism 114 that can be used to hide transit-only networks. 116 1.1. Requirements notation 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [KEYWORD]. 122 2. Hiding IPv4 Transit-only Networks in OSPFv2 124 In [OSPFv2], networks are classified as point-to-point, broadcast, or 125 non-broadcast. In the following sections, we will review how these 126 OSPF networks are being advertised and discuss how to hide them. 128 2.1. Point-to-Point Networks 130 A point-to-point network joins a single pair of routers. Figure 1 131 shows a point-to-point network connecting routers RT1 and RT2. 133 +---+.1 198.51.100.0/30 .2+---+ 134 |RT1|---------------------------|RT2| 135 +---+ +---+ 137 Figure 1 Physical point-to-point network 139 2.1.1. Advertising Point-to-Point Networks 141 For each numbered point-to-point network, a router has 2 link 142 descriptions in its router-LSA, one Type 1 link (point-to-point) 143 describing the neighboring router, and one Type 3 link (stub) 144 describing the assigned IPv4 subnet. 146 An example of router-LSA originated by RT1 would look like 148 LS age = 0 ;newly (re)originated 149 LS type = 1 ;router-LSA 150 Link State ID = 192.0.2.1 ;RT1's Router ID 151 Advertising Router = 192.0.2.1 ;RT1's Router ID 152 #links = 2 153 Link ID = 192.0.2.2 ;RT2's Router ID 154 Link Data = 198.51.100.1 ;Interface IP address 155 Type = 1 ;connects to RT2 156 Metric = 10 158 Link ID= 198.51.100.0 ;IP network/subnet number 159 Link Data = 255.255.255.252 ;Subnet's mask 160 Type = 3 ;Connects to stub network 161 Metric = 10 163 The Type 1 link will be used for SPF calculation while the Type 3 164 link will be used to install a route to the corresponding subnet in 165 the Routing Information Base (RIB). 167 2.1.2. Hiding Point-to-Point Networks 169 To hide a transit-only point-to-point network, the Type 3 link is 170 omitted from the router-LSA. 172 An example of router-LSA originated by RT1, hiding the point-to-point 173 network depicted in Figure 1, would look like 175 LS age = 0 ;newly (re)originated 176 LS type = 1 ;router-LSA 177 Link State ID = 192.0.2.1 ;RT1's Router ID 178 Advertising Router = 192.0.2.1 ;RT1's Router ID 179 #links = 1 180 Link ID = 192.0.2.2 ;RT2's Router ID 181 Link Data = 198.51.100.1 ;Interface IP address 182 Type = 1 ;connects to RT2 183 Metric = 10 185 2.2. Broadcast Networks 187 A broadcast network joins many (more than two) routers, and supports 188 the capability to address a single physical message to all of the 189 attached routers. Figure 2 shows a broadcast network connecting 190 router RT3, RT4, and RT5. 192 +---+ +---+ 193 |RT3| |RT4| 194 +---+ +---+ 195 |.3 198.51.100.0/24 .4| 196 +-----------------------------+ 197 |.5 199 +---+ 200 |RT5| 201 +---+ 203 Figure 2 Broadcast network 205 2.2.1. Advertising Broadcast Networks 207 For each broadcast network, a designated router (DR) describes it in 208 its network-LSA. Assuming RT3 is elected as the DR in Figure 2, an 209 example of the network-LSA originated by RT3 would look like 211 LS age = 0 ;newly (re)originated 212 LS type = 2 ;network-LSA 213 Link State ID = 198.51.100.3 ;IP address of the DR (RT3) 214 Advertising Router = 192.0.2.3 ;RT3's Router ID 215 Network Mask = 255.255.255.0 216 Attached Router = 192.0.2.3 ;RT3's Router ID 217 Attached Router = 192.0.2.4 ;RT4's Router ID 218 Attached Router = 192.0.2.5 ;RT5's Router ID 220 OSPF obtains the IP network number from the combination of the Link 221 State ID and the Network Mask. In addition, the Link State ID is 222 also being used for 2-way connectivity check. 224 2.2.2. Hiding Broadcast Networks 226 2.2.2.1. Sending Network-LSA 228 A special subnet mask value of 255.255.255.255 MUST be used in the 229 Network-LSA to hide a transit only broadcast network. While a 230 broadcast network connects more than routers, using 255.255.255.255 231 will not hide an access broadcast network accidentally. 233 As there is no change of the Link State ID, the 2-way connectivity 234 check would proceed normally. 236 An example of network-LSA originated by RT3, hiding the broadcast 237 network depicted in Figure 2, would look like 239 LS age = 0 ;newly (re)originated 240 LS type = 2 ;network-LSA 241 Link State ID = 198.51.100.3 ;IP address of the DR (RT3) 242 Advertising Router = 192.0.2.3 ;RT3's Router ID 243 Network Mask = 255.255.255.255 ;special subnet mask 244 Attached Router = 192.0.2.3 ;RT3's Router ID 245 Attached Router = 192.0.2.4 ;RT4's Router ID 246 Attached Router = 192.0.2.5 ;RT5's Router ID 248 2.2.2.2. Receiving Network-LSA 250 It is RECOMMENDED that all routers in an area be upgraded at the same 251 time to process the modified network-LSA correctly and consistently. 253 When a router receives a network-LSA, it MUST calculate the routing 254 table normally [OSPFv2]. However, if the network mask in the 255 network-LSA is 255.255.255.255, the router MUST NOT install the route 256 in the RIB. 258 2.2.2.2.1. Backward Compatibility 260 When a not-yet-upgraded router receives a modified network-LSA, as 261 specified in section 2.2.2.1, a host route to the originating DR will 262 be installed. This is not ideal but better than the current result, 263 which exposes the whole subnet. 265 In a partial deployment scenario, upgraded routers and not-yet- 266 upgraded routers may coexist. The former do not install the host 267 route to the DR's interface, while the latter install it. Such 268 inconsistencies create routing black holes, which should normally be 269 avoided. In this case, however, as packets destined for the transit- 270 only networks are dropped somewhere in the network, the black holes 271 actually help the DRs defend themselves from the remote attacks. 273 In summary, the modification of the network-LSA, as specified in 274 section 2.2.2.1, is backward compatible with the current 275 specification of [OSPFv2], even in a partial deployment scenario. 277 2.3. Non-Broadcast Networks 279 A non-broadcast networks joins many (more than two) routers, but does 280 NOT support the capability to address a single physical message to 281 all of the attached routers. As mentioned in [OSPFv2], OSPF runs in 282 one of two modes over non-broadcast networks: Non-Broadcast Multi- 283 Access (NBMA) or Point-to-MultiPoint. 285 2.3.1. NBMA 287 In NBMA mode, OSPF emulates operation over a broadcast network: a 288 Designated Router is elected for the NBMA network, and the Designated 289 Router originates an LSA for the network. 291 To hide a NBMA transit-only network, OSPF adopts the same 292 modification as over the broadcast transit-only network (see Section 293 2.2.2.). 295 2.3.2. Point-to-MultiPoint 297 In point-to-MultiPoint mode, OSPF treats the non-broadcast network as 298 a collection of point-to-point links. 300 Figure 3 shows a non-broadcast network connecting router RT6, RT7, 301 RT8, and RT9. In this network, all routers can communicate directly, 302 except for routers RT7 and RT8. 304 +---+ +---+ 305 |RT6| |RT7| 306 +---+ +---+ 307 |.6 198.51.100.0/24 .7| 308 +----------------------------+ 309 |.8 .9| 310 +---+ +---+ 311 |RT8| |RT9| 312 +---+ +---+ 314 Figure 3 Non-Broadcast network 316 2.3.2.1. Advertising Point-to-MultiPoint Networks 318 For a point-to-multipoint network, a router has multiple link 319 descriptions in its router-LSA, one Type 1 link (point-to-point) for 320 EACH directly communicable router, and one Type 3 link (stub) 321 advertising its interface IPv4 address with a subnet mask of 322 255.255.255.255. 324 An example of router-LSA originated by RT7 would look like 326 LS age = 0 ;newly (re)originated 327 LS type = 1 ;router-LSA 328 Link State ID = 192.0.2.7 ;RT7's Router ID 329 Advertising Router = 192.0.2.7 ;RT7's Router ID 330 #links = 3 331 Link ID = 192.0.2.6 ;RT6's Router ID 332 Link Data = 198.51.100.7 ;Interface IP address 333 Type = 1 ;connects to RT6 334 Metric = 10 336 Link ID = 192.0.2.9 ;RT9's Router ID 337 Link Data = 198.51.100.7 ;Interface IP address 338 Type = 1 ;connects to RT9 339 Metric = 10 341 Link ID= 198.51.100.7 ;Interface IP address 342 Link Data = 255.255.255.255 ;Subnet's mask 343 Type = 3 ;Connects to stub network 344 Metric = 0 346 2.3.2.2. Hiding Point-to-MultiPoint Networks 348 To hide a transit-only point-to-multipoint network, the Type 3 349 link is omitted from the router-LSA. 351 An example of router-LSA originated by RT7, hiding the point-to- 352 point network depicted in Figure 3, would look like 354 LS age = 0 ;newly (re)originated 355 LS type = 1 ;router-LSA 356 Link State ID = 192.0.2.7 ;RT7's Router ID 357 Advertising Router = 192.0.2.7 ;RT7's Router ID 358 #links = 2 359 Link ID = 192.0.2.6 ;RT6's Router ID 360 Link Data = 198.51.100.7 ;Interface IP address 361 Type = 1 ;connects to RT6 362 Metric = 10 364 Link ID = 192.0.2.9 ;RT9's Router ID 365 Link Data = 198.51.100.7 ;Interface IP address 366 Type = 1 ;connects to RT9 367 Metric = 10 369 3. Hiding IPv6 Transit-only Networks in OSPFv3 371 In [OSPFv3], addressing semantics have been removed from the OSPF 372 protocol packets and the main LSA types, leaving a network-protocol- 373 independent core. 375 More specifically, router-LSAs and network-LSAs no longer contain 376 network addresses, but simply express topology information. Instead, 377 two new LSA types, link-LSA and intra-area-prefix-LSA, have been 378 introduced. A link-LSA associates a list of IPv6 address to a link 379 and has local-link flooding scope, and an intra-area-prefix-LSA 380 either associates a list of IPv6 addresses with a router by 381 referencing a router-LSA, or associates a list of IPv6 addresses with 382 a broadcast/NBMA network by referencing a network-LSA. In the latter 383 case, the prefixes in the link-LSAs from adjacent neighbors are 384 copied into the intra-area-prefix-LSA by the Designated Router. 386 To hide a transit-only network in [OSPFv3], the IPv6 address prefixes 387 are omitted from the router-LSA. Consequently, when a Designated 388 Router builds an intra-area-prefix-LSA referencing a network-LSA, 389 these IPv6 address prefixes will be omitted. 391 In addition, when a router builds an intra-area-prefix-LSA that is 392 referencing a router-LSA, the associated IPv6 address prefixes from 393 the transit-only network MUST also be omitted from the intra-area- 394 prefix-LSA. 396 3.1. Hiding AF Enabled Transit-only Networks in OSPFv3 398 [OSPF-AF] supports multiple Address Families (AFs) by mapping each AF 399 to a separate Instance ID and OSPFv3 instance. 401 In the meantime, each prefix advertised in OSPFv3 has a prefix Length 402 field [OSPFv3], which facilitates advertising prefixes of different 403 lengths in different AFs. The existing LSAs defined in [OSPFv3] are 404 used for prefix advertising and there is no need to define new LSAs. 406 In other words, as link-LSAs and intra-area-prefix-LSAs are still 407 being used, the same mechanism explained in section 3 can be used to 408 hide those AF enabled transit-only networks as well. 410 4. Operational Considerations 412 By eliminating the ability to reach transit-only networks, the 413 ability to manage these interfaces may be reduced. In order to not 414 reduce the functionality and capability of the overall network, it is 415 recommended that extensions such as [RFC5837] be also implemented. 417 Note that the extension defined in [RFC5837] may provide the user 418 with the IP address of an interface. If that address was hidden, as 419 specified in this document, then even though the address is assigned 420 to the interface, it will not be reachable. 422 4.1. Forwarding Address 424 A non-zero forwarding address can be advertised in AS-external-LSAs 425 and NSSA-LSAs [NSSA] to achieve optimal routing to AS external 426 routes. The matching routing table entry for the forwarding address 427 must exist to facilitate the SPF calculation. 429 In other words, when prefix-hiding is configured on the next-hop 430 interface, the next-hop address MUST NOT be advertised as a 431 forwarding address. 433 Consequently, sub-optimal routing to these AS external routes may 434 exist when prefix-hiding is configured. 436 4.2. Virtual Links 438 Virtual links are used to connect physically separate components of 439 the backbone. The virtual link's viability is determined by the 440 existence of an intra-area path between two endpoints. The matching 441 routing table entries of the endpoints must exist to ensure the 442 virtual link's operation. 444 In other words, if prefix-hiding is configured on an interface, the 445 virtual link endpoint MUST NOT use that interface's IP address as the 446 virtual interface's IP address. 448 4.3. Unnumbered Interfaces 450 Note that no host route is generated for, and no IP packets can be 451 addressed to, interfaces to unnumbered point-to-point networks 452 [OSPFv2]. In other words, these addresses are already hidden. 454 However, for manageability purposes, it may be common practice to 455 manually include the numbered interface (for example, a loopback 456 interface to which the unnumbered interface points to) in routing 457 updates. If needed, the numbered interface's address can be hidden 458 using the mechanisms described in this document, or simply not 459 advertising it. 461 Before deciding to hide (or suppress the advertisement of) a numbered 462 interface, it is very important to consider other uses that interface 463 may have. Examples of common uses may include: virtual link 464 endpoint, inter-domain routing peering point, etc. In other words, 465 it may not be possible to hide the address associated to an 466 unnumbered interface due to other applications in the network. 468 5. Security Considerations 470 One motivation for this document is to reduce remote attack 471 vulnerability by hiding transit-only networks. The result should 472 then be that fewer OSPF core networks will be exposed. 474 The mechanisms described above result in reachability information 475 from transit-only networks not being installed in the routers' 476 forwarding tables. The effect is that even if the address of a 477 transit-only network is known, the forwarding information is not 478 present in the routers to reach the destination. Also, in some cases 479 the address information is completely omitted from the LSA. 481 Some information in the LSA (such as the OSPF Router ID) cannot be 482 omitted. Even though the Router ID may be taken from an IPv4 address 483 on the router, the configuration can be easily changed. Note again 484 that having an address doesn't guarantee reachability if the 485 information is hidden from the forwarding tables. 487 While the steps described in this document are meant to be applied to 488 transit-only networks only, they could be used to hide other networks 489 as well. It is expected that the same care that users put on the 490 configuration of other routing protocol parameters is used in the 491 configuration of this extension. 493 6. IANA Considerations 495 No actions are required from IANA as result of the publication of 496 this document. 498 7. Acknowledgments 500 The draft text was produced using Stefan Santesson's NroffEdit 501 application. 503 The idea of using a special subnet mask to hide broadcast networks in 504 OSPF was originally introduced in the US patent "Apparatus and method 505 to hide transit only multi-access networks in OSPF" (patent number: 506 7,929,524), by Yi Yang, Alvaro Retana, James Ng, Abhay Roy, Alfred 507 Lindem, Sina Mirtorabi, Timothy Gage, and Khalid Raza. 509 The authors would like to thank Acee Lindem, Shraddha Hegde, Rajesh 510 Shetty, Marek Karasek, Michael Barnes, Paul Wells, Adrian Farrel and 511 Stephen Farrell for their feedback on the document. 513 8. References 515 8.1. Normative References 517 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, March 1997. 520 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 521 RFC 3101, January 2003. 523 [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 525 [OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem , "OSPF 526 for IPv6", RFC 5340, July 2008. 528 [OSPF-AF] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 529 Aggarwal, "Support of Address Families in OSPFv3", 530 RFC5838, April 2010. 532 8.2. Informative References 534 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 535 Rivers, "Extending ICMP for Interface and Next-Hop 536 Identification", RFC 5837, April 2010. 538 Authors' Addresses 540 Yi Yang 541 Cisco Systems, Inc. 542 7025 Kit Creek Road 543 RTP, NC 27709 544 USA 546 Email: yiya@cisco.com 548 Alvaro Retana 549 Cisco Systems, Inc. 550 7025 Kit Creek Road 551 RTP, NC 27709 552 USA 554 Email: aretana@cisco.com 556 Abhay Roy 557 Cisco Systems, Inc. 558 225 West Tasman Drive 559 San Jose, CA 95134 560 USA 562 Email: akr@cisco.com