idnits 2.17.1 draft-ietf-6man-enhanced-dad-05.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 RFC4861, but the abstract doesn't seem to directly say this. It does mention RFC4861 though, so this could be OK. -- 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 (May 2, 2014) is 3644 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: 1 error (**), 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 Cisco Systems, Inc. 6 Expires: November 3, 2014 E. Dart 7 Lawrence Berkeley National Laboratory 8 W. George 9 Time Warner Cable 10 C. Pignataro 11 Cisco Systems, Inc. 12 May 2, 2014 14 Enhanced Duplicate Address Detection 15 draft-ietf-6man-enhanced-dad-05 17 Abstract 19 Appendix A of the IPv6 Duplicate Address Detection (DAD) document in 20 RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 21 does not settle on one specific automated means to detect loopback of 22 Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several 23 service provider communities have expressed a need for automated 24 detection of looped backed ND messages used by DAD. This document 25 includes mitigation techniques and then outlines the Enhanced DAD 26 algorithm to automate detection of looped back IPv6 ND messages used 27 by DAD. For network loopback tests, the Enhanced DAD algorithm 28 allows IPv6 to self-heal after a loopback is placed and removed. 29 Further, for certain access networks the document automates resolving 30 a specific 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 November 3, 2014. 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Operational Mitigation Options . . . . . . . . . . . . . . . 4 70 3.1. Disable DAD on Interface . . . . . . . . . . . . . . . . 5 71 3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol . . 5 72 3.3. Operational Considerations . . . . . . . . . . . . . . . 6 73 4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . 6 74 4.1. General Rules . . . . . . . . . . . . . . . . . . . . . . 7 75 4.2. Processing Rules for Senders . . . . . . . . . . . . . . 7 76 4.3. Processing Rules for Receivers . . . . . . . . . . . . . 7 77 4.4. Impact on SEND . . . . . . . . . . . . . . . . . . . . . 8 78 4.5. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8 79 4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 9 80 4.7. Changes to RFC 3971 . . . . . . . . . . . . . . . . . . . 9 81 5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 9 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 85 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Terminology 90 o DAD-failed state - Duplication Address Detection failure as 91 specified in [RFC4862]. Note even Optimistic DAD as specified in 92 [RFC4429] can fail due to a looped back DAD probe. This document 93 covers looped back detection for Optimistic DAD as well. 95 o Looped back message - also referred to as a reflected message. 96 The message sent by the sender is received by the sender due to 97 the network or a Upper Layer Protocol on the sender looping the 98 message back. 100 o Loopback - A function in which the router's interface (or the 101 circuit to which the router's interface is connected) is looped 102 back or connected to itself. Loopback causes packets sent by the 103 interface to be received by the interface, and results in 104 interface unavailability for regular data traffic forwarding. See 105 more details in section 9.1 of [RFC1583]. The Loopback function 106 is commonly used in an interface context to gain information on 107 the quality of the interface, by employing mechanisms such as 108 ICMPv6 pings, bit-error tests, etc. In a circuit context, it is 109 used in wide area environments including optical dense wave 110 division multiplexing (DWDM) and SONET/SDH for fault isolation 111 (e.g. by placing a loopback at different geographic locations 112 along the path of a wide area circuit to help locate a circuit 113 fault). The Loopback function may be employed locally or 114 remotely. 116 o NS(DAD) - shorthand notation to denote an Neighbor Solicitation 117 (NS) with unspecified IPv6 source-address issued during DAD. 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 2. Introduction 127 Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate 128 Address Detection (DAD). However, [RFC4862] does not settle on one 129 specific automated means to detect loopback of ND messages used by 130 DAD. One specific DAD message is a Neighbor Solicitation (NS), 131 specified in [RFC4861]. The NS is issued by the network interface of 132 an IPv6 node for DAD. Another message involved in DAD is a Neighbor 133 Advertisement (NA). The Enhanced DAD algorithm proposed in this 134 document focuses on detecting an NS looped back to the transmitting 135 interface during the DAD operation. Detecting a looped back NA is of 136 no use because no problems with DAD will occur if a node receives a 137 looped back NA. Detection of any other looped back ND messages 138 outside of the DAD operation is not critical and thus this document 139 does not cover such detection. The document also includes a 140 Mitigation section that discusses means already available to mitigate 141 the loopback problem. 143 Recently, service providers have reported a problem with DAD that is 144 caused by looped back NS messages. The following is a description of 145 the circumstances under which the problem arises. Loopback testing 146 for troubleshooting purposes is underway on a circuit connected to an 147 interface on a router. The interface on the router is enabled for 148 IPv6. The interface issues a NS for the IPv6 link-local address DAD. 149 The NS is reflected back to the router interface due to the loopback 150 condition of the circuit, and the router interface enters a DAD- 151 failed state. After the circuit troubleshooting has concluded and 152 the loopback condition is removed, IPv4 will return to operation 153 without further manual intervention. However, IPv6 will remain in 154 DAD-failed state until manual intervention on the router restores 155 IPv6 to operation. 157 There are other conditions which will also trigger similar problems 158 with DAD Loopback. While the following example is not a common 159 configuration, it has occurred in a large service provider network. 160 It is necessary to address it in the proposed solution because the 161 trigger scenario has the potential to cause significant IPv6 service 162 outages when it does occur. Two broadband modems in the same 163 location are served by the same service provider and both modems are 164 served by one access concentrator and one layer 3 interface on the 165 access concentrator. The two modems have the Ethernet ports of each 166 modem connected to a network hub. The access concentrator serving 167 the modems is the first-hop IPv6 router for the modems. The access 168 concentrator also supports proxying of DAD messages. Each modem is 169 enabled for at least data services. The network interface of the 170 access concentrator serving the two broadband modems is enabled for 171 IPv6 and the interface issues a NS(DAD) message for the IPv6 link- 172 local address. The NS message reaches one modem first and this modem 173 sends the message to the network hub which sends the message to the 174 second modem which forwards the message back to the access 175 concentrator. The looped back NS message causes the network 176 interface on the access concentrator to be in a DAD-failed state. 177 Such a network interface typically serves up to 100 thousand 178 broadband modems causing all the modems (and hosts behind the modems) 179 to fail to get IPv6 online on the access network. Additionally, it 180 may be tedious for the access concentrator to find out which of the 181 six thousand or more homes looped back the DAD message. Clearly 182 there is a need for automated detection of looped back NS messages 183 during DAD operations by a node. 185 3. Operational Mitigation Options 187 Two mitigation options are described below. The mechanisms do not 188 require any change to existing implementations. 190 3.1. Disable DAD on Interface 192 One can disable DAD on an interface and then there is no NS(DAD) 193 issued to be looped back. DAD is disabled by setting the interface's 194 DupAddrDetectTransmits variable to zero. While this mitigation may 195 be the simplest the mitigation has three drawbacks. 197 It would likely require careful analysis of configuration on such 198 point-to-point interfaces, a one-time manual configuration on each of 199 such interfaces, and more importantly, genuine duplicates in the link 200 will not be detected. 202 A Service Provider router such as an access concentrator or network 203 core router SHOULD support this mitigation strategy. 205 3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol 207 It is possible that one or more layer 2 protocols include provisions 208 to detect the existence of a loopback on an interface circuit, 209 usually by comparing protocol data sent and received. For example, 210 PPP uses magic number (section 6.4 of [RFC1661]) to detect a loopback 211 on an interface. 213 When a layer 2 protocol detects that a loopback is present on an 214 interface circuit, the device MUST temporarily disable DAD on the 215 interface, and when the protocol detects that a loopback is no longer 216 present (or the interface state has changed), the device MUST 217 (re-)enable DAD on that interface. 219 This solution requires no protocol changes. This solution SHOULD be 220 enabled by default, and MUST be a configurable option if the layer 2 221 technology provides means for detecting loopback messages on an 222 interface circuit. 224 This mitigation has several benefits. They are 226 1. It leverages layer 2 protocol's built-in loopback detection 227 capability, if available. 229 2. It scales better since it relies on an event-driven model which 230 requires no additional state or timer. This may be a significant 231 scaling consideration on devices with hundreds or thousands of 232 interfaces that may be in loopback for long periods of time (such 233 as while awaiting turn-up or during long-duration intrusive bit 234 error rate tests). 236 3.3. Operational Considerations 238 The mitigation options discussed in the document do not require the 239 devices on both ends of the circuit to support the mitigation 240 functionality simultaneously, and do not propose any capability 241 negotiation. The mitigation options discussed in this document are 242 effective for unidirectional circuit or interface loopback (i.e. the 243 the loopback is placed in one direction on the circuit, rendering the 244 other direction non-operational). 246 The mitigation options may not be effective for the bidirectional 247 loopback (i.e. the loopback is placed in both directions of the 248 circuit interface, so as to identify the faulty segment) if only one 249 device followed a mitigation option specified in this document, since 250 the other device would follow current behavior and disable IPv6 on 251 that interface due to DAD until manual intervention restores it. 253 This is nothing different from what happens today (without the 254 solutions proposed by this document) in case of unidirectional 255 loopback. Hence, it is expected that an operator would resort to 256 manual intervention for the devices not compliant with this document, 257 as usual. 259 4. The Enhanced DAD Algorithm 261 The Enhanced DAD algorithm covers detection of a looped back NS(DAD) 262 message. The document proposes use of the Nonce Option specified in 263 the SEND document of [RFC3971]. The nonce is a random number as 264 specified in [RFC3971]. If SEND is enabled on the router and the 265 router also supports the Enhanced DAD algorithm (specified in this 266 document), there is integration with the Enhanced DAD algorithm and 267 SEND. See more details in the Impact on SEND section in section 4.4. 268 Since a nonce is used only once, DAD for each IPv6 address of an 269 interface uses a different nonce. Additional details of the 270 algorithm are included in section 4.2. 272 Six bytes of random nonce is sufficiently large for nonce collisions. 273 However if there is a collision because two nodes that are using the 274 same Target Address in their NS(DAD) generated the same random nonce, 275 then the algorithm will incorrectly detect a looped back NS(DAD) when 276 a genuine address collision has occurred. Since each looped back 277 NS(DAD) event is logged to system management, the administrator of 278 the network will have access to the information necessary to 279 intervene manually. Also, because the nodes will have detected what 280 appear to be looped back NS(DAD) messages, they will continue to 281 probe and it is unlikely that they will choose the same nonce the 282 second time (assuming quality random number generators). 284 The algorithm is capable of detecting any ND solicitation (NS and 285 Router Solicitation) or advertisement (NA and Router Advertisement) 286 that is looped back. However, saving a nonce and nonce related data 287 for all ND messages has impact on memory of the node and also adds 288 the algorithm state to a substantially larger number of ND messages. 289 Therefore this document does not recommend using the algorithm 290 outside of the DAD operation by an interface on a node. 292 4.1. General Rules 294 If an IPv6 node implements the Enhanced DAD algorithm, the node MUST 295 implement detection of looped back NS(DAD) messages during DAD for an 296 interface address. 298 4.2. Processing Rules for Senders 300 If a node has been configured to use the Enhanced DAD algorithm, when 301 sending a NS(DAD) for a tentative or optimistic interface address the 302 sender MUST generate a random nonce associated with the interface 303 address, MUST save the nonce, and MUST include the nonce in the Nonce 304 Option included in the NS(DAD). If the interface does not receive 305 any DAD failure indications within RetransTimer milliseconds after 306 having sent DupAddrDetectTransmits Neighbor Solicitations, the 307 interface moves the Target Address to assigned state. If any probe 308 is looped back within RetransTimer milliseconds after having sent 309 DupAddrDetectTransmits NS(DAD) messages, the interface continues with 310 another MAX_MULTICAST_SOLICIT number of NS(DAD) messages spaced 311 RetransTimer apart. If no probe is looped back within RetransTimer 312 milliseconds after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, 313 the probing stops else a new MAX_MULTICAST_SOLICIT number of NS(DAD) 314 messages sequence is initiated. The MAX_MULTICAST_SOLICIT number of 315 NS(DAD) messages sequence continues until the stop condition is 316 reached or manual intervention is undertaken. The interface moves 317 the Target Address to assigned state. 319 4.3. Processing Rules for Receivers 321 If the node has been configured to use the Enhanced DAD algorithm and 322 an interface on the node receives any NS(DAD) message where the 323 Target Address matches the interface address (in tentative or 324 optimistic state), the receiver compares the nonce, if any, is 325 included in the message with any saved nonce on the receiving 326 interface. If a match is found, the node SHOULD log a system 327 management message, SHOULD update any statistics counter, MUST drop 328 the received message. If the received NS(DAD) message includes a 329 nonce and no match is found with any saved nonce, the node SHOULD log 330 a system management message for DAD-failed and SHOULD update any 331 statistics counter. If the interface does not receive any DAD 332 failure indications within RetransTimer milliseconds after having 333 sent DupAddrDetectTransmits Neighbor Solicitations, the interface 334 moves the Target Address to assigned state. 336 4.4. Impact on SEND 338 The SEND document uses the Nonce Option in the context of matching an 339 NA with an NS. However, no text in SEND has an explicit mention of 340 detecting looped back ND messages. If this document updates 341 [RFC4862], SEND should be updated to integrate with the Enhanced DAD 342 algorithm. A minor update to SEND would be to explicitly mention 343 that the nonce in SEND is also used by SEND to detect looped back NS 344 messages during DAD operations by the node. In a mixed SEND 345 environment with SEND and unsecured nodes, the lengths of the nonce 346 used by SEND and unsecured nodes MUST be identical. 348 4.5. Changes to RFC 4862 350 The following text is added to the end of the Introduction section of 351 [RFC4862]. 353 A network interface of an IPv6 node SHOULD implement the Enhanced DAD 354 algorithm. For example, if the interface on an IPv6 node is 355 connected to a circuit that supports loopback testing, then the node 356 should implement the Enhanced DAD algorithm that allows the IPv6 357 interface to self-heal after loopback testing is ended on the 358 circuit. Another example is when the IPv6 interface resides on an 359 access concentrator running DAD Proxy. The interface supports up to 360 100 thousand IPv6 clients (broadband modems) connected to the 361 interface. If the interface performs DAD for its IPv6 link-local 362 address and if the DAD probe is reflected back to the interface, the 363 interface is stuck in DAD failed state and IPv6 services to the 100 364 thousand clients is denied. Disabling DAD for such an IPv6 interface 365 on an access concentrator is not an option because the network also 366 needs to detect genuine duplicates in the interface downstream 367 network. The Enhanced DAD algorithm also facilitates detecting a 368 genuine duplicate for the interface on the access concentrator. See 369 the Actions to Perform on Detecting a Genuine Duplicate section of 370 the Enhanced DAD document. 372 The following text is added to the end of Appendix A of [RFC4862]. 374 The Enhanced DAD algorithm from TBD RFC is designed to detect looped 375 back DAD probes. A network interface of an IPv6 node SHOULD 376 implement the Enhanced DAD algorithm. 378 4.6. Changes to RFC 4861 380 The following text is appended to the RetransTimer variable 381 description in section 6.3.2 of [RFC4861]. 383 The RetransTimer may be overridden by a link-specific document if a 384 node supports the Enhanced DAD algorithm. 386 The following text is appended to the Source Address definition in 387 section 4.3 of [RFC4861]. 389 If a node has been configured to use the Enhanced DAD algorithm, an 390 NS with an unspecified source address adds the Nonce option to the 391 message and implements the state machine of the Enhanced DAD 392 algorithm. 394 4.7. Changes to RFC 3971 396 The following text is changed in section 5.3.2 of [RFC3971]. 398 The purpose of the Nonce option is to make sure that an advertisement 399 is a fresh response to a solicitation sent earlier by the node. 401 New text is included below. 403 The purpose of the Nonce option is to make sure that an advertisement 404 is a fresh response to a solicitation sent earlier by the node. The 405 nonce is also used to detect looped back NS messages when the network 406 interface performs DAD [RFC4862]. Detecting looped back DAD messages 407 is covered by the Enhanced DAD algorithm as specified in TBD RFC. In 408 a mixed SEND environment with SEND and unsecured nodes, the lengths 409 of the nonce used by SEND and unsecured nodes MUST be identical. 411 5. Actions to Perform on Detecting a Genuine Duplicate 413 As described in paragraphs above the nonce can also serve to detect 414 genuine duplicates even when the network has potential for looping 415 back ND messages. When a genuine duplicate is detected, the node 416 follows the manual intervention specified in section 5.4.5 of 417 [RFC4862]. However, in certain networks such as an access network if 418 the genuine duplicate matches the tentative or optimistic IPv6 419 address of a network interface of the access concentrator, automated 420 actions are proposed. 422 One access network is a cable broadband deployment where the access 423 concentrator is the first-hop IPv6 router to several thousand 424 broadband modems. The router also supports proxying of DAD messages. 425 The network interface on the access concentrator initiates DAD for an 426 IPv6 address and detects a genuine duplicate due to receiving an 427 NS(DAD) or an NA message. On detecting such a duplicate the access 428 concentrator logs a system management message, drops the received ND 429 message, and blocks the modem on whose layer 2 service identifier the 430 NS(DAD) or NA message was received on. 432 The network described above follows a trust model where a trusted 433 router serves un-trusted IPv6 host nodes. Operators of such networks 434 have a desire to take automated action if a network interface of the 435 trusted router has a tentative or optimistic address duplicate with a 436 host served by trusted router interface. Any other network that 437 follows the same trust model MAY use the automated actions proposed 438 in this section. 440 6. Security Considerations 442 The nonce can be exploited by a rogue deliberately changing the nonce 443 to fail the looped back detection specified by the Enhanced DAD 444 algorithm. SEND is recommended to circumvent this exploit. For any 445 mitigation suggested in the document such as disabling DAD has an 446 obvious security issue before a remote node on the link can issue 447 reflected NS(DAD) messages. Again, SEND is recommended for this 448 exploit. 450 7. IANA Considerations 452 None. 454 8. Acknowledgements 456 Thanks (in alphabetical order by first name) to Dmitry Anipko, Eric 457 Levy-Abegnoli, Erik Nordmark, Fred Templin, Jouni Korhonen, Michael 458 Sinatra, Ole Troan, Ray Hunter, Suresh Krishnan, and Tassos 459 Chatzithomaoglou for their guidance and review of the document. 460 Thanks to Thomas Narten for encouraging this work. Thanks to Steinar 461 Haug and Scott Beuker for describing the use cases. 463 9. Normative References 465 [RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994. 467 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 468 RFC 1661, July 1994. 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, March 1997. 473 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 474 Neighbor Discovery (SEND)", RFC 3971, March 2005. 476 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 477 for IPv6", RFC 4429, April 2006. 479 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 480 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 481 September 2007. 483 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 484 Address Autoconfiguration", RFC 4862, September 2007. 486 Authors' Addresses 488 Rajiv Asati 489 Cisco Systems, Inc. 490 7025 Kit Creek road 491 Research Triangle Park, NC 27709-4987 492 USA 494 Email: rajiva@cisco.com 495 URI: http://www.cisco.com/ 497 Hemant Singh 498 Cisco Systems, Inc. 499 1414 Massachusetts Ave. 500 Boxborough, MA 01719 501 USA 503 Phone: +1 978 936 1622 504 Email: shemant@cisco.com 505 URI: http://www.cisco.com/ 507 Wes Beebee 508 Cisco Systems, Inc. 509 1414 Massachusetts Ave. 510 Boxborough, MA 01719 511 USA 513 Phone: +1 978 936 2030 514 Email: wbeebee@cisco.com 515 URI: http://www.cisco.com/ 516 Eli Dart 517 Lawrence Berkeley National Laboratory 518 1 Cyclotron Road, Berkeley, CA 94720 519 USA 521 Email: dart@es.net 522 URI: http://www.es.net/ 524 Wes George 525 Time Warner Cable 526 13820 Sunrise Valley Drive 527 Herndon, VA 20171 528 USA 530 Email: wesley.george@twcable.com 532 Carlos Pignataro 533 Cisco Systems, Inc. 534 7200-12 Kit Creek Road 535 Research Triangle Park, NC 27709 536 USA 538 Email: cpignata@cisco.com 539 URI: http://www.cisco.com/