idnits 2.17.1 draft-howard-homenet-routing-comparison-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 29, 2011) is 4499 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 homenet L. Howard 3 Internet-Draft Time Warner Cable 4 Intended status: Informational December 29, 2011 5 Expires: July 1, 2012 7 Evaluation of Proposed Homenet Routing Solutions 8 draft-howard-homenet-routing-comparison-00 10 Abstract 12 This document evaluates the various proposals for routing in an 13 unmanaged home network. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on July 1, 2012. 32 Copyright Notice 34 Copyright (c) 2011 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3.1. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.2. RIPng . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 3.3. UP-PIO . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 3.4. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 3.5. MANEMO . . . . . . . . . . . . . . . . . . . . . . . . . . 10 57 3.6. RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 58 3.7. new section . . . . . . . . . . . . . . . . . . . . . . . 13 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 61 6. Informative References . . . . . . . . . . . . . . . . . . . . 14 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 1. Introduction 66 This document evaluates the suitability of each of the proposed 67 routing solutions for the Homenet problem space. The list of 68 requirements is provided in 69 [draft-howard-homenet-routing-requirements] (soon to be included in 70 [draft-ietf-homenet-arch]). This document is intended to assist the 71 working group in developing consensus around a single solution, so 72 that work may progress. 74 2. Requirements 76 This section includes the requirements from 77 [draft-howard-homenet-routing-requirements]. After each requirement 78 is a short mnemonic, to be used in the table comparing each solution. 80 1. Reachability between all nodes in the home network. Links may 81 be Ethernet, WiFi, MoCA, or any other; test all solutions 82 against mutliple L2 types. [1. Reachability] 84 2. Border detection. Any solution will have to determine the 85 routing boundary. It is assumed that no home networking device 86 can handle a full routing table for the Internet, and that a 87 home router should not be required to do so. [2. Border 88 detection] 90 A. Border may be upstream ISP, or may be a device that is a 91 gateway to SmartGrid devices, e.g. a controller that speaks 92 RPL to 802.15.4 and foo to home net. Or there may be no 93 border, if no external connection has been established. [2a. 94 Any border] 96 B. Must be able to find "up" (a path to the Internet), but must 97 not be dependent on "up" (Internet connectivity) existing 98 for intra-home reachability. [2b. Find "up"] 100 C. May be discovered by routing protocol, or other means. [2c. 101 Border method] 103 3. Robust to routers being moved/added/removed/renumbered. 104 Convergence time a few minutes or less. [3. Handles change] 106 4. No configuration required. It may be acceptable to require a 107 single password or passphrase to be entered on each device, both 108 for security, and to establish the administrative boundary. [4. 109 No config] 111 5. Best-path is a non-requirement. [5. Null requirement] 113 6. Support for multiple upstream networks is a requirement. [6. 114 Multiple upstreams] 116 A. Including wireless offload, video-only, and split-tunnel VPN 117 scenarios. [6a. Split up views] 119 B. It may be assumed that each upstream will be connected via a 120 separate router, not multihomed off the same router. [6b. 121 Null requirement] 123 C. Must support a prefix delegated from each provider. How 124 hosts handle multiple prefixes is not a routing problem. 125 [6c. Multiple PD] 127 D. Load-balancing among providers is a non-requirement. [6d. 128 Null requirement] 130 E. If multiple upstream networks can provide a path to the same 131 destination (such as an Internet host), the solution must 132 allow for backup in case the router or link to one upstream 133 fails. Failover time should be within a few minutes. [6e. 134 Failover] 136 F. Must support a "walled-garden" network. This might routing 137 based on either source address (from the walled garden 138 network) or destination address (to the walled garden 139 network); support for both is not required. [6f. Walled 140 garden] 142 G. Source address selection is out of scope for the routing 143 solution. Choosing which address to use to look up the 144 destination address is out of scope for the routing 145 solution. [6g. Null requirement] 147 7. Cannot assume hierarchical prefix delegation in the home, unless 148 the Homenet working group finds consensus on a hierarchical 149 addressing mechanism. [7. Non-hierarchical] 151 8. A host with mutliple upstream paths to the same destination (in- 152 home or external) should be able to use another in case on 153 fails. [8. Failover] 155 9. Prevent looping. [9. Prevent loops] 157 10. Should be a lightweight solution. [10. Lightweight] 158 11. Must handle multi-dwelling units or other potential dense 159 wireless or wired networks. [11. Robust to MDUs] 161 12. Must be resilient to running on wireless networks. Must be able 162 to handle both wired and wireless links. [12. Wireless] 164 13. Robustness in the face of unintentional joining of networks. 165 [12. Unintended joins] 167 3. Consideration 169 3.1. OSPFv3 171 As documented in [OSPFv3-autoconfig]. 173 1. Reachability. YES, OSPF can detect reachability. 175 2. Border detection. NO. Any node which the router uses as a next 176 hop, but which is not in its OSPF Area 0, may be assumed to be 177 an external border. However, the router will have to be 178 manually configured, or use another routing protocol, to 179 establish a path to that next hop; therefore auto-configured 180 OSPFv3 by itself does not detect borders. 182 A. Any border. NO. 184 B. Find "up". NO. Manual configuration of the router 185 neighboring the ISP is required to set a default route. 187 C. Border method. MANUAL. 189 3. Handles change. YES. OSPFv3 normally handles router additions 190 and removals well, with link-state changes. It may not be able 191 to handle being moved from one existing segment to another. 193 4. No config. YES, but requires manual configuration for security. 195 5. (null) 197 6. Multiple upstreams. YES, OSPFv3 can support multiple default 198 routes, and multiple specific routes. 200 A. Split up views. SOMEWHAT. OSPFv3 can certainly carry many 201 paths, including specific routes for a wireles home agent, 202 video cluster, or VPN concentrator. It cannot, by itself, 203 establish routing policies determining which hosts may use 204 those paths, so the upstream ISP may not have a return path 205 (or may have an asymmetric path). 207 B. (null) 209 C. Multiple PD. YES, OSPFv3 can route for multiple prefixes on 210 a link. 212 D. (null) 214 E. Failover. YES, autoconfigured OSPFv3 detects link state 215 change and reconverges in a reasonable amount of time. 217 F. Walled garden. SOMEWHAT. OSPFv3 can carry destination 218 routes, but cannot by itself support source-based routing. 220 G. (null) 222 7. Non-hierarchical addressing. YES. 224 8. Failover. YES. 226 9. Prevent loops. YES. 228 10. Lightweight. NO. One estimate of a common implementation is 229 50,000 lines of code. 231 11. Robust to MDUs. YES. Full LSAs are sent periodically, but they 232 are not onerus. 234 12. Wireless. YES. 236 13. Unintended joins. NO. Autoconfig OSPFv3 is not resilient 237 against unintended joins unless the recommendation to use 238 authentication hashes [OSPFV3-AUTH-TRAILER] is followed, which 239 requires manual configuration. 241 3.2. RIPng 243 Specified in [RFC2080], but no document specifying how it would be 244 used in a Homenet environment has been written. 246 1. Reachability. YES, RIPng can detect reachability. 248 2. Border detection. NO. Any node which the router uses as a next 249 hop, but which is not speaking RIPng, may be assumed to be an 250 external border. However, the router will have to be manually 251 configured, or use another routing protocol, to establish a path 252 to that next hop; therefore auto-configured RIPng by itself does 253 not detect borders. 255 A. Any border. NO. Some ISPs use RIP (though rarely RIPng) to 256 communicate with customers. 258 B. Find "up". NO. Manual configuration of the router 259 neighboring the ISP is required to set a default route. 261 C. Border method. MANUAL. 263 3. Handles change. YES. RIPng normally handles router additions 264 and removals. It may not be able to handle being moved from one 265 existing segment to another. 267 4. No config. YES. 269 5. (null) 271 6. Multiple upstreams. NO, RIPng does not forward to multiple 272 paths for the same prefix. 274 A. Split up views. YES, RIPng can carry multiple paths, 275 including specific routes for a wireles home agent, video 276 cluster, or VPN concentrator. It cannot, by itself, 277 establish routing policies determining which hosts may use 278 those paths, so the upstream ISP may not have a return path 279 (or may have an asymmetric path). 281 B. (null) 283 C. Multiple PD. Yes, RIPng can support multiple prefixes on a 284 link. 286 D. (null) 288 E. Failover. Yes, RIPng can calculate a new path when one is 289 lost or withdrawn. 291 F. Walled garden. SOMEWHAT. RIPng can carry destination 292 routes, but cannot by itself support source-based routing. 294 G. (null) 296 7. Non-hierarchical addressing. YES. 298 8. Failover. YES. 300 9. Prevent loops. SOMEWHAT. RIPng uses the original RIP count-to- 301 infinity algorithm to prevent infinite loops; it works, but is 302 inefficient, especially in larger networks. 304 10. Lightweight. YES. 306 11. Robust to MDUs. YES. 308 12. Wireless. YES. 310 13. Unintended joins. NO. There is no authorization method; 311 [RFC2080] says to use the Authentication Header built into IPv6, 312 which would allow any RIPng host. 314 3.3. UP-PIO 316 As documented in [UP-PIO], this proposal would overload Router 317 Advertisements to apporximate a distance-vector routing protocol. 319 1. Reachability. YES, UP-PIO will find a path, but it may not be 320 the shortest path. 322 2. Border detection. YES. UP-PIO infers from DHCP-PD where the 323 ISP network is. 325 A. Any border. YES. A dedicated gateway, intended to run 326 between an 802.15.4 network and a Wi-Fi or Ethernet (etc.) 327 segment on a Homenet network, could be preconfigured to 328 establish itself as UP for that prefix. 330 B. Find "up". YES. 332 C. Border method. Assume that DHCP-PD indicates upstream ISP, 333 increment distance with RAs. 335 3. Handles change. YES, UP handles moves/adds/changes/deletions 336 exactly as well as Router Advertisements do. 338 4. No config. YES. 340 5. (null) 342 6. Multiple upstreams. YES, whatever information is included in 343 RAs is propagated. 345 A. Split up views. YES. 347 B. (null) 349 C. Multiple PD. YES. 351 D. (null) 353 E. Failover. 355 F. Walled garden. YES. 357 G. (null) 359 7. Non-hierarchical addressing. NO. UP depends on hierarchical 360 addressing. 362 8. Failover. YES, when RAs are no longer detected, an alternate 363 path is computed. 365 9. Prevent loops. Undefined; the protocol is still being defined. 366 It is expected to prevent loops as well as RIPng. 368 10. Lightweight. YES. 370 11. Robust to MDUs. YES. 372 12. Wireless. YES. 374 13. Unintended joins. NO. Even SEND would only authenticate, not 375 authorize. 377 3.4. IS-IS 379 As defined in [RFC1195], but no document specifying how it would be 380 used in a Homenet environment has been written. 382 1. Reachability. YES. 384 2. Border detection. NO. Any node which the router uses as a next 385 hop, but which is not speaking IS-IS, may be assumed to be an 386 external border. However, the router will have to be manually 387 configured, or use another routing protocol, to establish a path 388 to that next hop; therefore auto-configured IS-IS by itself does 389 not detect borders. 391 A. Any border. NO. 393 B. Find "up". NO. Manual configuration of the router 394 neighboring the ISP is required to set a default route. 396 C. Border method. MANUAL. 398 3. Handles change. YES. 400 4. No config. NO, IS-IS must be configured. 402 5. (null) 404 6. Multiple upstreams. YES. 406 A. Split up views. YES. 408 B. (null) 410 C. Multiple PD. YES. 412 D. (null) 414 E. Failover. YES. 416 F. Walled garden. YES. 418 G. (null) 420 7. Non-hierarchical addressing. YES. 422 8. Failover. YES. 424 9. Prevent loops. YES. 426 10. Lightweight. NO. 428 11. Robust to MDUs. YES. 430 12. Wireless. YES. 432 13. Unintended joins. SOMEWHAT, if [RFC5310] is implemented, but 433 that requires further manual configuration. 435 3.5. MANEMO 437 No document exists describing this mechanism, though several people 438 have suggested it to the working group. Evaluation will have to be 439 undertaken by someone familiar with the mechanism. 441 1. Reachability 442 2. Border detection 444 A. Any border. 446 B. Find "up". 448 C. Border method. 450 3. Handles change. 452 4. No config 454 5. (null) 456 6. Multiple upstreams. 458 A. Split up views. 460 B. (null) 462 C. Multiple PD. 464 D. (null) 466 E. Failover. 468 F. Walled garden. 470 G. (null) 472 7. Non-hierarchical addressing. 474 8. Failover. 476 9. Prevent loops. 478 10. Lightweight. 480 11. Robust to MDUs. 482 12. Wireless. 484 13. Unintended joins. 486 3.6. RPL 488 As documented in [RPL], but no document specifying how it would be 489 used in a Homenet environment has been written. 491 1. Reachability. YES. 493 2. Border detection. NO. 495 A. Any border. NO. 497 B. Find "up". NO. 499 C. Border method. NO. 501 3. Handles change. YES. 503 4. No config. YES? 505 5. (null) 507 6. Multiple upstreams. 509 A. Split up views. 511 B. (null) 513 C. Multiple PD. 515 D. (null) 517 E. Failover. 519 F. Walled garden. 521 G. (null) 523 7. Non-hierarchical addressing. 525 8. Failover. 527 9. Prevent loops. 529 10. Lightweight. YES. 531 11. Robust to MDUs. 533 12. Wireless. 535 13. Unintended joins. 537 3.7. new section 539 +-------------+--------+--------+--------+--------+--------+-----+ 540 | Requirement | OSPFv3 | RIPng | UP PIO | IS-IS | MANEMO | RPL | 541 +-------------+--------+--------+--------+--------+--------+-----+ 542 | 1. | YES | YES | YES | YES | | | 543 | 2. | NO | NO | YES | NO | | | 544 | 2A. | NO | NO | YES | NO | | | 545 | 2B. | NO | NO | YES | NO | | | 546 | 2C. | MANUAL | MANUAL | PD | MANUAL | | | 547 | 3. | YES | YES | YES | YES | | | 548 | 4. | YES | YES | YES | NO | | | 549 | 5. | NA | NA | NA | NA | | | 550 | 6. | YES | NO | YES | YES | | | 551 | 6A. | SOME | YES | YES | YES | | | 552 | 6B. | NA | NA | NA | NA | | | 553 | 6C. | YES | YES | YES | YES | | | 554 | 6D. | NA | NA | NA | NA | | | 555 | 6E. | YES | YES | YES | YES | | | 556 | 6F. | SOME | SOME | YES | YES | | | 557 | 6G. | NA | NA | NA | NA | | | 558 | 7. | YES | YES | NO | YES | | | 559 | 8. | YES | YES | YES | YES | | | 560 | 9. | YES | SOME | TBD | YES | | | 561 | 10. | NO | YES | YES | NO | | | 562 | 11. | YES | YES | YES | YES | | | 563 | 12. | YES | YES | YES | YES | | | 564 | 13. | NO | NO | NO | SOME | | | 565 +-------------+--------+--------+--------+--------+--------+-----+ 567 4. Security Considerations 569 As an evaluation document, no security considerations are created. 570 The solution should be safe from route injection to perpetrate man- 571 in-the-middle attacks, especially in multi-dwelling or other dense/ 572 mesh networks, but this may be a link requirement more than a routing 573 requirement. 575 5. IANA Considerations 577 There are no IANA considerations or implications that arise from this 578 document. 580 6. Informative References 582 [OSPFV3-AUTH-TRAILER] 583 "". 585 [OSPFv3-autoconfig] 586 "draft-acee-ospf-ospfv3-autoconfig". 588 [RFC1195] "Use of OSI IS-IS for Routing in TCP/IP and Dual 589 Environments". 591 [RFC2080] R. Minnear, "RIPng for IPv6". 593 [RFC5310] "IS-IS Generic Cryptographic Authentication". 595 [RPL] "draft-ietf-roll-rpl-19". 597 [UP-PIO] "draft-howard-up-pio-00". 599 [draft-howard-homenet-routing-requirements] 600 "Homenet Routing Requirements", December 2011. 602 [draft-ietf-homenet-arch] 603 "Home Networking Architecture for IPv6". 605 Author's Address 607 Lee Howard 608 Time Warner Cable 609 13820 Sunrise Valley Drive 610 Herndon, VA 20171 611 US 613 Phone: +1 703 345 3513 614 Email: lee.howard@twcable.com