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