idnits 2.17.1 draft-ietf-6man-enhanced-dad-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4862]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4862, but the abstract doesn't seem to directly say this. It does mention RFC4862 though, so this could be OK. -- The draft header indicates that this document updates RFC3971, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3971, updated by this document, for RFC5378 checks: 2003-10-17) -- 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 (October 23, 2014) is 3473 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) ** Obsolete normative reference: RFC 1583 (Obsoleted by RFC 2178) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Asati 3 Internet-Draft H. Singh 4 Updates: 4862, 4861, 3971 (if approved) W. Beebee 5 Intended status: Standards Track C. Pignataro 6 Expires: April 26, 2015 Cisco Systems, Inc. 7 E. Dart 8 Lawrence Berkeley National Laboratory 9 W. George 10 Time Warner Cable 11 October 23, 2014 13 Enhanced Duplicate Address Detection 14 draft-ietf-6man-enhanced-dad-07 16 Abstract 18 IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are 19 discussed in Appendix A of [RFC4862]. That specification mentions a 20 hardware-assisted mechanism to detect looped back DAD messages. If 21 hardware cannot suppress looped back DAD messages, a software 22 solution is required. Several service provider communities have 23 expressed a need for automated detection of looped backed Neighbor 24 Discovery (ND) messages used by DAD. This document includes 25 mitigation techniques and outlines the Enhanced DAD algorithm to 26 automate the detection of looped back IPv6 ND messages used by DAD. 27 For network loopback tests, the Enhanced DAD algorithm allows IPv6 to 28 self-heal after a loopback is placed and removed. Further, for 29 certain access networks the document automates resolving a specific 30 duplicate address conflict. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 26, 2015. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Two Deployment Problems . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 70 3. Operational Mitigation Options . . . . . . . . . . . . . . . 5 71 3.1. Disable DAD on an Interface . . . . . . . . . . . . . . . 5 72 3.2. Dynamic Disable/Enable of DAD Using Layer-2 Protocol . . 5 73 3.3. Operational Considerations . . . . . . . . . . . . . . . 6 74 4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . 6 75 4.1. General Rules . . . . . . . . . . . . . . . . . . . . . . 7 76 4.2. Processing Rules for Senders . . . . . . . . . . . . . . 7 77 4.3. Processing Rules for Receivers . . . . . . . . . . . . . 7 78 4.4. Impact on SEND . . . . . . . . . . . . . . . . . . . . . 8 79 4.5. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8 80 4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 9 81 4.7. Changes to RFC 3971 . . . . . . . . . . . . . . . . . . . 9 82 5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 9 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 86 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 89 1. Introduction 91 IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are 92 discussed in Appendix A of [RFC4862]. That specification mentions a 93 hardware-assisted mechanism to detect looped back DAD messages. If 94 hardware cannot suppress looped back DAD messages, a software 95 solution is required. One specific DAD message is the Neighbor 96 Solicitation (NS), specified in [RFC4861]. The NS is issued by the 97 network interface of an IPv6 node for DAD. Another message involved 98 in DAD is the Neighbor Advertisement (NA). The Enhanced DAD 99 algorithm specified in this document focuses on detecting an NS 100 looped back to the transmitting interface during the DAD operation. 101 Detecting a looped back NA does not solve the looped back DAD 102 problem. Detection of any other looped back ND messages during the 103 DAD operation is outside the scope of this document. This document 104 also includes a section on Mitigation that discusses means already 105 available to mitigate the DAD loopback problem. 107 1.1. Two Deployment Problems 109 In each problem articulated below, the IPv6 link-local address DAD 110 operation fails due to a looped back DAD probe. However, the looped 111 back DAD probe exists for any IPv6 address type including global 112 addresses. 114 Recently, service providers have reported a problem with DAD that is 115 caused by looped back NS messages. The following is a description of 116 the circumstances under which the problem arises. Loopback testing 117 for troubleshooting purposes is underway on a circuit connected to an 118 interface on a router. The interface on the router is enabled for 119 IPv6. The interface issues a NS for the IPv6 link-local address DAD. 120 The NS is reflected back to the router interface due to the loopback 121 condition of the circuit, and the router interface enters a DAD- 122 failed state. After the circuit troubleshooting has concluded and 123 the loopback condition is removed, IPv4 will return to operation 124 without further manual intervention. However, IPv6 will remain in 125 DAD-failed state until manual intervention on the router restores 126 IPv6 to operation. 128 There are other conditions which will also trigger similar problems 129 with DAD Loopback. While the following example is not a common 130 configuration, it has occurred in a large service provider network. 131 It is necessary to address it in the proposed solution because the 132 trigger scenario has the potential to cause significant IPv6 service 133 outages when it does occur. Two broadband modems in the same home 134 are served by the same service provider and both modems are served by 135 one access concentrator and one layer-3 interface on the access 136 concentrator. The two modems have the Ethernet ports of each modem 137 connected to a network hub. The access concentrator serving the 138 modems is the first-hop IPv6 router for the modems. The network 139 interface of the access concentrator serving the two broadband modems 140 is enabled for IPv6 and the interface issues a NS(DAD) message for 141 the IPv6 link-local address. The NS message reaches one modem first 142 and this modem sends the message to the network hub which sends the 143 message to the second modem which forwards the message back to the 144 access concentrator. The looped back NS message causes the network 145 interface on the access concentrator to be in a DAD-failed state. 146 Such a network interface typically serves up to a hundred thousand 147 broadband modems causing all the modems (and hosts behind the modems) 148 to fail to get IPv6 online on the access network. Additionally, it 149 may be tedious for the access concentrator to find out which of the 150 hundred thousand or more homes looped back the DAD message. Clearly 151 there is a need for automated detection of looped back NS messages 152 during DAD operations by a node. 154 2. Terminology 156 o DAD-failed state - Duplication Address Detection failure as 157 specified in [RFC4862]. Note even Optimistic DAD as specified in 158 [RFC4429] can fail due to a looped back DAD probe. This document 159 covers looped back detection for Optimistic DAD as well. 161 o Looped back message - also referred to as a reflected message. 162 The message sent by the sender is received by the sender due to 163 the network or an Upper Layer Protocol on the sender looping the 164 message back. 166 o Loopback - A function in which the router's layer-3 interface (or 167 the circuit to which the router's interface is connected) is 168 looped back or connected to itself. Loopback causes packets sent 169 by the interface to be received by the interface and results in 170 interface unavailability for regular data traffic forwarding. See 171 more details in section 9.1 of [RFC1583]. The Loopback function 172 is commonly used in an interface context to gain information on 173 the quality of the interface, by employing mechanisms such as 174 ICMPv6 pings and bit-error tests. In a circuit context, this 175 function is used in wide area environments including optical Dense 176 Wave Division Multiplexing (DWDM) and SONET/SDH for fault 177 isolation (e.g. by placing a loopback at different geographic 178 locations along the path of a wide area circuit to help locate a 179 circuit fault). The Loopback function may be employed locally or 180 remotely. 182 o NS(DAD) - shorthand notation to denote an Neighbor Solicitation 183 (NS) (as specified in [RFC4861]) with unspecified IPv6 source- 184 address issued during DAD. 186 2.1. Requirements Language 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 3. Operational Mitigation Options 194 Two mitigation options are described below. The mechanisms do not 195 require any change to existing implementations. 197 3.1. Disable DAD on an Interface 199 One can disable DAD on an interface so that there is no NS(DAD) 200 issued to be looped back. DAD is disabled by setting the interface's 201 DupAddrDetectTransmits variable to zero. While this mitigation may 202 be the simplest, the mitigation has three drawbacks. 204 This mitigation would likely require careful analysis of 205 configuration on such point-to-point interfaces, a one-time manual 206 configuration on each of such interfaces, and more importantly, 207 genuine duplicates in the link will not be detected. 209 A Service Provider router, such as an access concentrator, or network 210 core router, SHOULD support this mitigation strategy. 212 3.2. Dynamic Disable/Enable of DAD Using Layer-2 Protocol 214 One or more layer-2 protocols MAY include provisions to detect the 215 existence of a loopback on an interface circuit, usually by comparing 216 protocol data sent and received. For example, PPP uses magic number 217 (section 6.4 of [RFC1661]) to detect a loopback on an interface. 219 When a layer-2 protocol detects that a loopback is present on an 220 interface circuit, the device MUST temporarily disable DAD on the 221 interface. When the protocol detects that a loopback is no longer 222 present (or the interface state has changed), the device MUST 223 (re-)enable DAD on that interface. 225 This solution requires no protocol changes. This solution SHOULD be 226 enabled by default, and MUST be a configurable option if the layer-2 227 technology provides means for detecting loopback messages on an 228 interface circuit. 230 This mitigation has several benefits. They are 232 1. It leverages layer-2 protocol's built-in loopback detection 233 capability, if available. 235 2. It scales better since it relies on an event-driven model which 236 requires no additional state or timer. This may be a significant 237 scaling consideration on devices with hundreds or thousands of 238 interfaces that may be in loopback for long periods of time (such 239 as while awaiting turn-up or during long-duration intrusive bit 240 error rate tests). 242 3.3. Operational Considerations 244 The mitigation options discussed in the document do not require the 245 devices on both ends of the circuit to support the mitigation 246 functionality simultaneously, and do not propose any capability 247 negotiation. The mitigation options discussed in this document are 248 effective for unidirectional circuit or interface loopback (i.e. the 249 the loopback is placed in one direction on the circuit, rendering the 250 other direction non-operational). 252 The mitigation options may not be effective for the bidirectional 253 loopback (i.e. the loopback is placed in both directions of the 254 circuit interface, so as to identify the faulty segment) if only one 255 device followed a mitigation option specified in this document, since 256 the other device would follow current behavior and disable IPv6 on 257 that interface due to DAD until manual intervention restores it. 259 This is nothing different from what happens today (without the 260 solutions proposed by this document) in case of unidirectional 261 loopback. Hence, it is expected that an operator would resort to 262 manual intervention for the devices not compliant with this document, 263 as usual. 265 4. The Enhanced DAD Algorithm 267 The Enhanced DAD algorithm covers detection of a looped back NS(DAD) 268 message. The document proposes use of the Nonce Option specified in 269 the SEND document of [RFC3971]. The nonce is a random number as 270 specified in [RFC3971]. If SEND is enabled on the router and the 271 router also supports the Enhanced DAD algorithm (specified in this 272 document), there is integration with the Enhanced DAD algorithm and 273 SEND. (See more details in the Impact on SEND section section 4.4.) 274 Since a nonce is used only once, The NS(DAD) for each IPv6 address of 275 an interface uses a different nonce. Additional details of the 276 algorithm are included in section 4.2. 278 Six bytes of random nonce is sufficiently large to minimize 279 collisions. However, if there is a collision because two nodes that 280 are using the same Target Address in their NS(DAD) and generated the 281 same random nonce, then the algorithm will incorrectly detect a 282 looped back NS(DAD) when a genuine address collision has occurred. 283 Since each looped back NS(DAD) event is logged to system management, 284 the administrator of the network will have access to the information 285 necessary to intervene manually. Also, because the nodes will have 286 detected what appear to be looped back NS(DAD) messages, they will 287 continue to probe, and it is unlikely that they will choose the same 288 nonce the second time (assuming quality random number generators). 290 The algorithm is capable of detecting any ND solicitation (NS and 291 Router Solicitation) or advertisement (NA and Router Advertisement) 292 that is looped back. However, saving a nonce and nonce related data 293 for all ND messages has impact on memory requirements of the node and 294 also adds the algorithm state to a substantially larger number of ND 295 messages. Therefore, this document does not recommend using the 296 algorithm outside of the DAD operation by an interface on a node. 298 4.1. General Rules 300 If an IPv6 node implements the Enhanced DAD algorithm, the node MUST 301 implement detection of looped back NS(DAD) messages during DAD for an 302 interface address. 304 4.2. Processing Rules for Senders 306 If a node has been configured to use the Enhanced DAD algorithm, when 307 sending an NS(DAD) for a tentative or optimistic interface address 308 the sender MUST generate a random nonce associated with the interface 309 address, MUST save the nonce, and MUST include the nonce in the Nonce 310 Option included in the NS(DAD). If the interface does not receive 311 any DAD failure indications within RetransTimer milliseconds (see 312 [RFC4861]) after having sent DupAddrDetectTransmits Neighbor 313 Solicitations, the interface moves the Target Address to the assigned 314 state. 316 If any probe is looped back within RetransTimer milliseconds after 317 having sent DupAddrDetectTransmits NS(DAD) messages, the interface 318 continues with another MAX_MULTICAST_SOLICIT number of NS(DAD) 319 messages transmitted RetransTimer millseconds apart. If no probe is 320 looped back within RetransTimer milliseconds after 321 MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing stops. 322 The probing MAY be stopped via manual intervention. When probing is 323 stopped, the interface moves the Target Address to the assigned 324 state. 326 4.3. Processing Rules for Receivers 328 If the node has been configured to use the Enhanced DAD algorithm and 329 an interface on the node receives any NS(DAD) message where the 330 Target Address matches the interface address (in tentative or 331 optimistic state), the receiver compares the nonce included in the 332 message, with any saved nonce on the receiving interface. If a match 333 is found, the node SHOULD log a system management message, SHOULD 334 update any statistics counter, and MUST drop the received message. 336 If the received NS(DAD) message includes a nonce and no match is 337 found with any saved nonce, the node SHOULD log a system management 338 message for a DAD-failed state, and SHOULD update any statistics 339 counter. If the interface does not receive any DAD failure 340 indications within RetransTimer milliseconds after having sent 341 DupAddrDetectTransmits Neighbor Solicitations, the interface moves 342 the Target Address to the assigned state. 344 4.4. Impact on SEND 346 The SEND document uses the Nonce Option in the context of matching an 347 NA with an NS. However, no text in SEND has an explicit mention of 348 detecting looped back ND messages. As this document updates 349 [RFC4862], SEND should be updated to integrate with the Enhanced DAD 350 algorithm. A minor update to SEND would be to explicitly mention 351 that the nonce in SEND is also used by SEND to detect looped back 352 NS(DAD) messages during DAD operations by the node. In a mixed SEND 353 environment with SEND and unsecured nodes, the lengths of the nonce 354 used by SEND and unsecured nodes MUST be identical. 356 4.5. Changes to RFC 4862 358 The following text is added to the end of the Introduction section of 359 [RFC4862]. 361 A network interface of an IPv6 node SHOULD implement the Enhanced DAD 362 algorithm. For example, if the interface on an IPv6 node is 363 connected to a circuit that supports loopback testing, then the node 364 SHOULD implement the Enhanced DAD algorithm that allows the IPv6 365 interface to self-heal after loopback testing is ended on the 366 circuit. Another example is when the IPv6 interface resides on an 367 access concentrator running DAD Proxy. The interface supports up to 368 a hundred thousand IPv6 clients (broadband modems) connected to the 369 interface. If the interface performs DAD for its IPv6 link-local 370 address and the DAD probe is reflected back to the interface, the 371 interface is stuck in DAD-failed state and IPv6 services to the 372 hundred thousand clients is denied. Disabling DAD for such an IPv6 373 interface on an access concentrator is less desirable than 374 implementing the algorithm because the network also needs to detect 375 genuine duplicates in the interface downstream network. The Enhanced 376 DAD algorithm also facilitates detecting a genuine duplicate for the 377 interface on the access concentrator. (See the Actions to Perform on 378 Detecting a Genuine Duplicate section of the Enhanced DAD document.) 380 The following text is added to the end of Appendix A of [RFC4862]. 382 The Enhanced DAD algorithm from draft-ietf-6man-enhanced-dad is 383 designed to detect looped back DAD probes. A network interface of an 384 IPv6 node SHOULD implement the Enhanced DAD algorithm. 386 4.6. Changes to RFC 4861 388 The following text is appended to the RetransTimer variable 389 description in section 6.3.2 of [RFC4861]: 391 The RetransTimer may be overridden by a link-specific document if a 392 node supports the Enhanced DAD algorithm. 394 The following text is appended to the Source Address definition in 395 section 4.3 of [RFC4861]: 397 If a node has been configured to use the Enhanced DAD algorithm, an 398 NS with an unspecified source address adds the Nonce option to the 399 message and implements the state machine of the Enhanced DAD 400 algorithm. 402 4.7. Changes to RFC 3971 404 The following text is changed in section 5.3.2 of [RFC3971]: 406 The purpose of the Nonce option is to make sure that an advertisement 407 is a fresh response to a solicitation sent earlier by the node. 409 The new text is included below: 411 The purpose of the Nonce option is to make sure that an advertisement 412 is a fresh response to a solicitation sent earlier by the node. The 413 nonce is also used to detect looped back NS messages when the network 414 interface performs DAD [RFC4862]. Detecting looped back DAD messages 415 is covered by the Enhanced DAD algorithm as specified in draft-ietf- 416 6man-enhanced-dad. In a mixed SEND environment with SEND and 417 unsecured nodes, the lengths of the nonce used by SEND and unsecured 418 nodes MUST be identical. 420 5. Actions to Perform on Detecting a Genuine Duplicate 422 As described in the paragraphs above, the nonce can also serve to 423 detect genuine duplicates even when the network has potential for 424 looping back ND messages. When a genuine duplicate is detected, the 425 node follows the manual intervention specified in section 5.4.5 of 426 [RFC4862]. However, in certain networks such as an access network, 427 if the genuine duplicate matches the tentative or optimistic IPv6 428 address of a network interface of the access concentrator, automated 429 actions are recommended. 431 One access network is a cable broadband deployment where the access 432 concentrator is the first-hop IPv6 router to several hundred thousand 433 broadband modems. The router also supports proxying of DAD messages. 434 The network interface on the access concentrator initiates DAD for an 435 IPv6 address and detects a genuine duplicate due to receiving an 436 NS(DAD) or an NA message. On detecting such a duplicate, the access 437 concentrator logs a system management message, drops the received ND 438 message, and blocks the modem on whose layer-2 service identifier the 439 NS(DAD) or NA message was received on. 441 The network described above follows a trust model where a trusted 442 router serves un-trusted IPv6 host nodes. Operators of such networks 443 have a desire to take automated action if a network interface of the 444 trusted router has a tentative or optimistic address duplicated by a 445 host. Any other network that follows the same trust model MAY use 446 the automated actions proposed in this section. 448 6. Security Considerations 450 The nonce can be exploited by a rogue deliberately changing the nonce 451 to fail the looped back detection specified by the Enhanced DAD 452 algorithm. SEND is recommended to circumvent this exploit. 453 Additionally, the nonce does not protect against the DoS caused by a 454 rogue node replying by a fake NA to all DAD probes. SEND is 455 recommended to circumvent this exploit also. Disabling DAD has an 456 obvious security issue before a remote node on the link can issue 457 reflected NS(DAD) messages. Again, SEND is recommended for this 458 exploit. 460 7. IANA Considerations 462 None. 464 8. Acknowledgements 466 Thanks (in alphabetical order by first name) to Bernie Volz, Dmitry 467 Anipko, Eric Levy-Abegnoli, Eric Vyncke, Erik Nordmark, Fred Templin, 468 Jouni Korhonen, Michael Sinatra, Ole Troan, Ray Hunter, Suresh 469 Krishnan, and Tassos Chatzithomaoglou for their guidance and review 470 of the document. Thanks to Thomas Narten for encouraging this work. 471 Thanks to Steinar Haug and Scott Beuker for describing the use cases. 473 9. Normative References 475 [RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994. 477 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 478 RFC 1661, July 1994. 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, March 1997. 483 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 484 Neighbor Discovery (SEND)", RFC 3971, March 2005. 486 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 487 for IPv6", RFC 4429, April 2006. 489 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 490 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 491 September 2007. 493 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 494 Address Autoconfiguration", RFC 4862, September 2007. 496 Authors' Addresses 498 Rajiv Asati 499 Cisco Systems, Inc. 500 7025 Kit Creek road 501 Research Triangle Park, NC 27709-4987 502 USA 504 Email: rajiva@cisco.com 505 URI: http://www.cisco.com/ 507 Hemant Singh 508 Cisco Systems, Inc. 509 1414 Massachusetts Ave. 510 Boxborough, MA 01719 511 USA 513 Phone: +1 978 936 1622 514 Email: shemant@cisco.com 515 URI: http://www.cisco.com/ 517 Wes Beebee 518 Cisco Systems, Inc. 519 1414 Massachusetts Ave. 520 Boxborough, MA 01719 521 USA 523 Phone: +1 978 936 2030 524 Email: wbeebee@cisco.com 525 URI: http://www.cisco.com/ 526 Carlos Pignataro 527 Cisco Systems, Inc. 528 7200-12 Kit Creek Road 529 Research Triangle Park, NC 27709 530 USA 532 Email: cpignata@cisco.com 533 URI: http://www.cisco.com/ 535 Eli Dart 536 Lawrence Berkeley National Laboratory 537 1 Cyclotron Road, Berkeley, CA 94720 538 USA 540 Email: dart@es.net 541 URI: http://www.es.net/ 543 Wes George 544 Time Warner Cable 545 13820 Sunrise Valley Drive 546 Herndon, VA 20171 547 USA 549 Email: wesley.george@twcable.com