idnits 2.17.1 draft-ietf-6man-enhanced-dad-03.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) (Using the creation date from RFC4862, updated by this document, for RFC5378 checks: 2004-02-10) -- 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 24, 2013) is 3962 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) == Unused Reference: 'RFC2119' is defined on line 450, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-6man-impatient-nud-06 ** Obsolete normative reference: RFC 1247 (Obsoleted by RFC 1583) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 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 (if approved) W. Beebee 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: November 25, 2013 E. Dart 7 Lawrence Berkeley National Laboratory 8 W. George 9 Time Warner Cable 10 C. Pignataro 11 Cisco Systems, Inc. 12 May 24, 2013 14 Enhanced Duplicate Address Detection 15 draft-ietf-6man-enhanced-dad-03 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 25, 2013. 49 Copyright Notice 51 Copyright (c) 2013 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 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Operational Mitigation Options . . . . . . . . . . . . . . . 4 69 3.1. Disable DAD on Interface . . . . . . . . . . . . . . . . 4 70 3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol . . 5 71 3.3. Operational Considerations . . . . . . . . . . . . . . . 5 72 4. The Enhanced DAD Algorithm . . . . . . . . . . . . . . . . . 6 73 4.1. General Rules . . . . . . . . . . . . . . . . . . . . . . 7 74 4.2. Processing Rules for Senders . . . . . . . . . . . . . . 7 75 4.3. Processing Rules for Receivers . . . . . . . . . . . . . 7 76 4.4. Impact on SEND . . . . . . . . . . . . . . . . . . . . . 8 77 4.5. Changes to RFC 4862 . . . . . . . . . . . . . . . . . . . 8 78 4.6. Changes to RFC 4861 . . . . . . . . . . . . . . . . . . . 8 79 5. Actions to Perform on Detecting a Genuine Duplicate . . . . . 9 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 83 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Terminology 88 o DAD-failed state - Duplication Address Detection failure as 89 specified in [RFC4862]. Failure also includes if the Target 90 Address is optimistic. Optimistic DAD is specified in [RFC4429]. 92 o Looped back message - also referred to as a reflected message. 93 The message sent by the sender is received by the sender due to 94 the network or a Upper Layer Protocol on the sender looping the 95 message back. 97 o Loopback - A function in which the router's interface (or the 98 circuit to which the router's interface is connected) is looped 99 back or connected to itself. Loopback causes packets sent by the 100 interface to be received by the interface, and results in 101 interface unavailability for regular data traffic forwarding. See 102 more details in section 9.1 of [RFC1247]. The Loopback function 103 is commonly used in an interface context to gain information on 104 the quality of the interface, by employing mechanisms such as 105 ICMPv6 pings, bit-error tests, etc. In a circuit context, it is 106 used in wide area environments including optical dense wave 107 division multiplexing (DWDM) and SONET/SDH for fault isolation 108 (e.g. by placing a loopback at different geographic locations 109 along the path of a wide area circuit to help locate a circuit 110 fault). The Loopback function may be employed locally or 111 remotely. 113 o NS(DAD) - shorthand notation to denote an Neighbor Solicitation 114 (NS) with unspecified IPv6 source-address issued during DAD. 116 2. Introduction 118 Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate 119 Address Detection (DAD). However, [RFC4862] does not settle on one 120 specific automated means to detect loopback of ND messages used by 121 DAD. One specific DAD message is a Neighbor Solicitation (NS), 122 specified in [RFC4861]. The NS is issued by the network interface of 123 an IPv6 node for DAD. Another message involved in DAD is a Neighbor 124 Advertisement (NA). The Enhanced DAD algorithm proposed in this 125 document focuses on detecting an NS looped back to the transmitting 126 interface during the DAD operation. Detecting a looped back NA is of 127 no use because no problems with DAD will occur if a node receives a 128 looped back NA. Detection of any other looped back ND messages 129 outside of the DAD operation is not critical and thus this document 130 does not cover such detection. The document also includes a 131 Mitigation section that discusses means already available to mitigate 132 the loopback problem. 134 Recently, service providers have reported a problem with DAD that is 135 caused by looped back NS messages. The following is a description of 136 the circumstances under which the problem arises. Loopback testing 137 for troubleshooting purposes is underway on a circuit connected to an 138 interface on a router. The interface on the router is enabled for 139 IPv6. The interface issues a NS for the IPv6 link-local address DAD. 140 The NS is reflected back to the router interface due to the loopback 141 condition of the circuit, and the router interface enters a DAD- 142 failed state. After the circuit troubleshooting has concluded and 143 the loopback condition is removed, IPv4 will return to operation 144 without further manual intervention. However, IPv6 will remain in 145 DAD-failed state until manual intervention on the router restores 146 IPv6 to operation. 148 There are other conditions which will also trigger similar problems 149 with DAD Loopback. While the following example is not a common 150 configuration, it has occurred in a large service provider network. 151 It is necessary to address it in the proposed solution because the 152 trigger scenario has the potential to cause significant IPv6 service 153 outages when it does occur. Two broadband modems in the same 154 location are served by the same service provider and both modems are 155 served by one access concentrator and one layer 3 interface on the 156 access concentrator. The two modems have the Ethernet ports of each 157 modem connected to a network hub. The access concentrator serving 158 the modems is the first-hop IPv6 router for the modems. The access 159 concentrator also supports proxying of DAD messages. Each modem is 160 enabled for at least data services. The network interface of the 161 access concentrator serving the two broadband modems is enabled for 162 IPv6 and the interface issues a NS(DAD) message for the IPv6 link- 163 local address. The NS message reaches one modem first and this modem 164 sends the message to the network hub which sends the message to the 165 second modem which forwards the message back to the access 166 concentrator. The looped back NS message causes the network 167 interface on the access concentrator to be in a DAD-failed state. 168 Such a network interface typically serves up to 100 thousand 169 broadband modems causing all the modems (and hosts behind the modems) 170 to fail to get IPv6 online on the access network. Additionally, it 171 may be tedious for the access concentrator to find out which of the 172 six thousand or more homes looped back the DAD message. Clearly 173 there is a need for automated detection of looped back NS messages 174 during DAD operations by a node. 176 3. Operational Mitigation Options 178 Two mitigation options are described below. The mechanisms do not 179 require any change to existing implementations. 181 3.1. Disable DAD on Interface 183 One can disable DAD on an interface and then there is no NS(DAD) 184 issued to be looped back. DAD is disabled by setting the interface's 185 DupAddrDetectTransmits variable to zero. While this mitigation may 186 be the simplest the mitigation has three drawbacks. 188 It would likely require careful analysis of configuration on such 189 point-to-point interfaces, a one-time manual configuration on each of 190 such interfaces, and more importantly, genuine duplicates in the link 191 will not be detected. 193 A Service Provider router such as an access concentrator or network 194 core router SHOULD support this mitigation strategy. 196 3.2. Dynamic Disable/Enable of DAD Using Layer 2 Protocol 198 It is possible that one or more layer 2 protocols include provisions 199 to detect the existence of a loopback on an interface circuit, 200 usually by comparing protocol data sent and received. For example, 201 PPP uses magic number (section 6.4 of [RFC1661]) to detect a loopback 202 on an interface. 204 When a layer 2 protocol detects that a loopback is present on an 205 interface circuit, the device MUST temporarily disable DAD on the 206 interface, and when the protocol detects that a loopback is no longer 207 present (or the interface state has changed), the device MUST 208 (re-)enable DAD on that interface. 210 This solution requires no protocol changes. This solution SHOULD be 211 enabled by default, and MUST be a configurable option. 213 This mitigation has several benefits. They are 215 1. It leverages layer 2 protocol's built-in loopback detection 216 capability, if available. 218 2. It scales better since it relies on an event-driven model which 219 requires no additional state or timer. This may be a significant 220 scaling consideration on devices with hundreds or thousands of 221 interfaces that may be in loopback for long periods of time (such 222 as while awaiting turn-up or during long-duration intrusive bit 223 error rate tests). 225 3.3. Operational Considerations 227 The mitigation options discussed in the document do not require the 228 devices on both ends of the circuit to support the mitigation 229 functionality simultaneously, and do not propose any capability 230 negotiation. The mitigation options discussed in this document are 231 effective for unidirectional circuit or interface loopback (i.e. the 232 the loopback is placed in one direction on the circuit, rendering the 233 other direction non-operational). 235 The mitigation options may not be effective for the bidirectional 236 loopback (i.e. the loopback is placed in both directions of the 237 circuit interface, so as to identify the faulty segment) if only one 238 device followed a mitigation option specified in this document, since 239 the other device would follow current behavior and disable IPv6 on 240 that interface due to DAD until manual intervention restores it. 242 This is nothing different from what happens today (without the 243 solutions proposed by this document) in case of unidirectional 244 loopback. Hence, it is expected that an operator would resort to 245 manual intervention for the devices not compliant with this document, 246 as usual. 248 4. The Enhanced DAD Algorithm 250 The Enhanced DAD algorithm covers detection of a looped back NS(DAD) 251 message. The document proposes use of the Nonce Option specified in 252 the SEND document of [RFC3971]. The nonce is a random number as 253 specified in [RFC3971]. If SEND is enabled on the router and the 254 router also supports the Enhanced DAD algorithm (specified in this 255 document), there is integration with the Enhanced DAD algorithm and 256 SEND. See more details in the Impact on SEND section. Since a nonce 257 is used only once, DAD for each IPv6 address of an interface uses a 258 different nonce. 260 The interface follows [RFC4862] behavior by issuing 261 DupAddrDetectTransmits (see [RFC4862]) probes spaced RetransTimer 262 (see [RFC4861]) apart. When the IPv6 network interface issues a 263 NS(DAD) message, the interface includes the Nonce Option in the 264 NS(DAD) message and saves the nonce in local store. Subsequently if 265 the interface receives an identical NS(DAD) message, the interface 266 logs a system management message, updates any statistics counter, 267 drops the looped back NS(DAD), and moves the Target Address to 268 assigned state. If any probe is looped back within RetransTimer 269 milliseconds after having sent DupAddrDetectTransmits NS(DAD) 270 messages, the interface continues with another MAX_MULTICAST_SOLICIT 271 number of NS(DAD) messages spaced RetransTimer apart. If no probe is 272 looped back within RetransTimer milliseconds after 273 MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing stops 274 else a new MAX_MULTICAST_SOLICIT number of NS(DAD) messages sequence 275 is initiated. The MAX_MULTICAST_SOLICIT number of NS(DAD) messages 276 sequence continues until the stop condition is reached. The 277 RetransTimer may be overidden by a link-specific document if a node 278 supports the Enhanced DAD algorithm. Note 279 [I-D.ietf-6man-impatient-nud] has intentions to change probe behavior 280 of [RFC4861]. The RetransTimer value may be overridden by a link- 281 type specific document. 283 If the interface receives a NS(DAD) message with a different nonce 284 but the Target Address matches a tentative or optimistic address on 285 the interface, the interface logs a DAD-failed system management 286 message, updates any statistics, and behaves identical to the 287 behavior specified in [RFC4862] for DAD failure. 289 Six bytes of random nonce is sufficiently large for nonce collisions. 290 However if there is a collision because two nodes generated the same 291 random nonce (that are using the same Target Address in their 292 NS(DAD)), then the algorithm will incorrectly detect a looped back 293 NS(DAD) when the NS(DAD) was issued to signal a genuine duplicate. 294 Since each looped back NS(DAD) event is logged to system management, 295 the administrator of the network will have to intervene manually. 297 The algorithm is capable of detecting any ND solicitation (NS and 298 Router Solicitation) or advertisement (NA and Router Advertisement) 299 that is looped back. However, saving a nonce and nonce related data 300 for all ND messages has impact on memory of the node and also adds 301 the algorithm state to a substantially larger number of ND messages. 302 Therefore this document does not recommend using the algorithm 303 outside of the DAD operation by an interface on a node. 305 4.1. General Rules 307 If an IPv6 node implements the Enhanced DAD algorithm, the node MUST 308 implement detection of looped back NS(DAD) messages during DAD for an 309 interface address. 311 4.2. Processing Rules for Senders 313 If a node has been configured to use the Enhanced DAD algorithm, when 314 sending a NS(DAD) for a tentative or optimistic interface address the 315 sender MUST generate a random nonce associated with the interface 316 address, MUST save the nonce, and MUST include the nonce in the Nonce 317 Option included in the NS(DAD). If any probe is looped back within 318 RetransTimer milliseconds after having sent DupAddrDetectTransmits 319 NS(DAD) messages, the interface continues with another 320 MAX_MULTICAST_SOLICIT number of NS(DAD) messages spaced RetransTimer 321 apart. If no probe is looped back within RetransTimer milliseconds 322 after MAX_MULTICAST_SOLICIT NS(DAD) messages are sent, the probing 323 stops else a new MAX_MULTICAST_SOLICIT number of NS(DAD) messages 324 sequence is initiated. The MAX_MULTICAST_SOLICIT number of NS(DAD) 325 messages sequence continues until the stop condition is reached. 327 4.3. Processing Rules for Receivers 329 If the node has been configured to use the Enhanced DAD algorithm and 330 an interface on the node receives any NS(DAD) message where the 331 Target Address matches the interface address (in tentative or 332 optimistic state), the receiver compares the nonce, if any, is 333 included in the message with any saved nonce on the receiving 334 interface. If a match is found, the node SHOULD log a system 335 management message, SHOULD update any statistics counter, MUST drop 336 the received message, and move the Target Address to assigned state. 338 If the received NS(DAD) message includes a nonce and no match is 339 found with any saved nonce, the node SHOULD log a system management 340 message for DAD-failed and SHOULD update any statistics counter. 342 4.4. Impact on SEND 344 The SEND document uses the Nonce Option in the context of matching an 345 NA with an NS. However, no text in SEND has an explicit mention of 346 detecting looped back ND messages. If this document updates 347 [RFC4862], SEND should be updated to integrate with the Enhanced DAD 348 algorithm. A minor update to SEND would be to explicitly mention 349 that the nonce in SEND is also used by SEND to detect looped back NS 350 messages during DAD operations by the node. In a mixed SEND 351 environment with SEND and unsecured nodes, the lengths of the nonce 352 used by SEND and unsecured nodes MUST be identical. 354 4.5. Changes to RFC 4862 356 The following text is added to [RFC4862]. 358 A network interface of an IPv6 node SHOULD implement the Enhanced DAD 359 algorithm. For example, if the interface on an IPv6 node is 360 connected to a circuit that supports loopback testing, then the node 361 should implement the Enhanced DAD algorithm that allows the IPv6 362 interface to self-heal after loopback testing is ended on the 363 circuit. Another example is when the IPv6 interface resides on an 364 access concentrator running DAD Proxy. The interface supports up to 365 100 thousand IPv6 clients (broadband modems) connected to the 366 interface. If the interface performs DAD for its IPv6 link-local 367 address and if the DAD probe is reflected back to the interface, the 368 interface is stuck in DAD failed state and IPv6 services to the 100 369 thousand clients is denied. Disabling DAD for such an IPv6 interface 370 on an access concentrator is not an option because the network also 371 needs to detect genuine duplicates in the interface downstream 372 network. The Enhanced DAD algorithm also facilitates detecting a 373 genuine duplicate for the interface on the access concentrator. See 374 the Actions to Perform on Detecting a Genuine Duplicate section of 375 the Enhanced DAD document. 377 4.6. Changes to RFC 4861 379 1. The RetransTimer may be overridden by a link-specific document if 380 a node supports the Enhanced DAD algorithm. 382 2. If a node has been configured to use the Enhanced DAD algorithm, 383 an NS with an unspecified source address adds the Nonce option to 384 the message and implements the state machine of the Enhanced DAD 385 algorithm. 387 5. Actions to Perform on Detecting a Genuine Duplicate 389 As described in paragraphs above the nonce can also serve to detect 390 genuine duplicates even when the network has potential for looping 391 back ND messages. When a genuine duplicate is detected, the node 392 follows the manual intervention specified in section 5.4.5 of 393 [RFC4862]. However, in certain networks such as an access network if 394 the genuine duplicate matches the tentative or optimistic IPv6 395 address of a network interface of the access concentrator, automated 396 actions are proposed. 398 One access network is a cable broadband deployment where the access 399 concentrator is the first-hop IPv6 router to several thousand 400 broadband modems. The router also supports proxying of DAD messages. 401 The network interface on the access concentrator initiates DAD for an 402 IPv6 address and detects a genuine duplicate due to receiving an 403 NS(DAD) or an NA message. On detecting such a duplicate the access 404 concentrator logs a system management message, drops the received ND 405 message, and blocks the modem on whose layer 2 service identifier the 406 NS(DAD) or NA message was received on. 408 The network described above follows a trust model where a trusted 409 router serves un-trusted IPv6 host nodes. Operators of such networks 410 have a desire to take automated action if a network interface of the 411 trusted router has a tentative or optimistic address duplicate with a 412 host served by trusted router interface. Any other network that 413 follows the same trust model MAY use the automated actions proposed 414 in this section. 416 6. Security Considerations 418 The nonce can be exploited by a rogue deliberately changing the nonce 419 to fail the looped back detection specified by the Enhanced DAD 420 algorithm. SEND is recommended for this exploit. For any mitigation 421 suggested in the document such as disabling DAD has an obvious 422 security issue before a remote node on the link can issue reflected 423 NS(DAD) messages. Again, SEND is recommended for this exploit. 425 7. IANA Considerations 427 None. 429 8. Acknowledgements 431 Thanks (in alphabetical order by first name) to Dmitry Anipko, Eric 432 Levy-Abegnoli, Erik Nordmark, Fred Templin, Michael Sinatra, Ole 433 Troan, Ray Hunter, Suresh Krishnan, and Tassos Chatzithomaoglou for 434 their guidance and review of the document. Thanks to Thomas Narten 435 for encouraging this work. Thanks to Steinar Haug and Scott Beuker 436 for describing the use cases. 438 9. Normative References 440 [I-D.ietf-6man-impatient-nud] 441 Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 442 Detection is too impatient", draft-ietf-6man-impatient- 443 nud-06 (work in progress), April 2013. 445 [RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991. 447 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 448 RFC 1661, July 1994. 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, March 1997. 453 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 454 Neighbor Discovery (SEND)", RFC 3971, March 2005. 456 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 457 for IPv6", RFC 4429, April 2006. 459 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 460 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 461 September 2007. 463 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 464 Address Autoconfiguration", RFC 4862, September 2007. 466 Authors' Addresses 468 Rajiv Asati 469 Cisco Systems, Inc. 470 7025 Kit Creek road 471 Research Triangle Park, NC 27709-4987 472 USA 474 Email: rajiva@cisco.com 475 URI: http://www.cisco.com/ 476 Hemant Singh 477 Cisco Systems, Inc. 478 1414 Massachusetts Ave. 479 Boxborough, MA 01719 480 USA 482 Phone: +1 978 936 1622 483 Email: shemant@cisco.com 484 URI: http://www.cisco.com/ 486 Wes Beebee 487 Cisco Systems, Inc. 488 1414 Massachusetts Ave. 489 Boxborough, MA 01719 490 USA 492 Phone: +1 978 936 2030 493 Email: wbeebee@cisco.com 494 URI: http://www.cisco.com/ 496 Eli Dart 497 Lawrence Berkeley National Laboratory 498 1 Cyclotron Road, Berkeley, CA 94720 499 USA 501 Email: dart@es.net 502 URI: http://www.es.net/ 504 Wes George 505 Time Warner Cable 506 13820 Sunrise Valley Drive 507 Herndon, VA 20171 508 USA 510 Email: wesley.george@twcable.com 512 Carlos Pignataro 513 Cisco Systems, Inc. 514 7200-12 Kit Creek Road 515 Research Triangle Park, NC 27709 516 USA 518 Email: cpignata@cisco.com 519 URI: http://www.cisco.com/